Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Care

johan.hal.se

Post reply on HN
Print view View original

31–40 of 92 posts

Re: Care

#31

Post by zackbrown »

Structure determines behavior. If a technology structurally encourages shooting oneself in the foot, people will shoot themselves in the feet.

The author seems to be arguing the the core problem is behavior — if only developers would stop building flimsy things! But what about a structural view? Is there a certain structure that lends HTML, CSS, and JS to creating frustrating experiences?

The structural heart of this problem is so big it's hard to see — it's the ground we stand on. The designed-by-committee dissonance between "the Web should be a simple document engine" and "the Web should be a game-engine-like interactive graphical runtime" leaves us with a bloated tech stack that doesn't excel at either.

WebAssembly and WebGPU give us a way out. Fork HTML. Employ a better language for authoring documents; employ a better language for authoring apps & games. It is a matter of time.

Re: Care

#32

Post by roenxi »

ozr wrote: post #19
roenxi wrote: post #12

Earlier quoted context omitted.

Well, y'know. You're likely to be better off if you put that desire to one side and focus within. Consider a soup kitchen vs a supermarket checkout. The people working at the soup kitchen arguably care a lot more. The person at the supermarket checkout can be as glassy eyed as they feel and still be part of feeding more people in absolute terms. Humans seem to have some sort of emotional heuristic to focus on care (r…

I've been on large and small teams of people that cared and didn't care. It feels noble and reasonable and right to tie it to a greater purpose; like your soup kitchen vs supermarket example. It's not that type of care the OP is getting at. It's closer to a craftmanship kind of care. Being proud of what you're putting into the world. Caring that it works well, not because the purpose is important, but because it's so…

If someone wants high personal standards then ok, that'll be good for them in the long term. But if we're talking about colleagues that care then that is just a cover for bad management. And fair enough bad management is endemic in the software industry so teams pick up the slack.

But it is management's job to decide on software quality standards and provide feedback to devs. Expecting the developers to be responsible for quality as a baseline is just a path to burnout for those devs; because then they are going to go mad because everyone on the team has different personal standards. The person with the highest standards on the team will never be satisfied.

You can't reasonably expect teammates to cover for bad managers, it is much cleverer to learn to identify good managers and try to work for them. Or become one.

Re: Care

#34

Post by clipsy »

crooked-v wrote: post #25
freeone3000 wrote: post #18

Earlier quoted context omitted.

Input type=“date” was added and is supported in HTML5, no js required. Same with time!

...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.

What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.

Re: Care

#35

Post by wild_egg »

clipsy wrote: post #34
crooked-v wrote: post #25

Earlier quoted context omitted.

...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.

What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.

_date picker_, yes. Calendar display? No native options.

The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do

Re: Care

#36

Post by [deleted] »

wild_egg wrote: post #35
clipsy wrote: post #34

Earlier quoted context omitted.

What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.

_date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do

[deleted]

Re: Care

#37

Post by bombcar »

wild_egg wrote: post #35
clipsy wrote: post #34

Earlier quoted context omitted.

What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.

_date picker_, yes. Calendar display? No native options. The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do

Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.

Re: Care

#38

Post by lmm »

crooked-v wrote: post #10

I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc. Then there's the endless layers of fiddly work needed to make accessibility work cross-platform (check out all the work Adobe puts into the react-aria project for an example), and that there's still fundamentally no browser-native no-J…

> I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc.

This is completely backwards IMO. The problems come from browsers natively implementing all of these things, in ways that are almost, but not quite, good enough for those web apps. The browser has the Python standard library problem of being "where modules go to die", but even worse since browsers can never deprecate anything; as a result we have all these 80% implementations that don't quite solve the problem but are enough to suck all the oxygen away from any good solutions. And then we just pile hacks on hacks to improve these things without ever fixing the underlying stuff. I mean FFS, Chrome will save and sync passwords that I enter in some web form flow based on heuristics, but it won't save actual username/passwords that I enter via the built-in username/password functionality that the browser has; how screwed up is that?

If I was somehow king of the web, what I'd be looking to do is: standardise one of the various "web components" proposals that lets people implement custom tags as libraries. Reimplement almost all of the things that are currently implemented as browser builtins as web components instead, move them out of the core rendering engine and into what are effectively polyfills-in-reverse; make the actual "browser" piece only implement div/span/canvas or something. Normalise pages loading components from libraries, where they can be iterated on and improved more quickly.

But for some reason web folks and especially HN seem to hate the few parts of the web technology stack that actually work well (Javascript, NPM) and love implementing as much as possible in the parts that are awful and unfixable (CSS). So I don't see things ever improving.

Re: Care

#39

Post by lmm »

> I feel like the web used to work better. Not in the sense of features or flagship sites—web-based email clients and word processors and image editors are all waaay better than they used to be and I would say the high-quality stuff is of higher quality than ever. I’m not pining for the HTML-only version of GMail, I promise. But if I were to estimate some rough median of “how well do websites work” I would also say that there’s an incredible amount of jank out there.

Nah. I remember that era. It all sucked, except Flash, which was the only way to have interactive sites that weren't awful. The main reason websites work even less well now is that they got rid of Flash so you have to use an informally-specified bug-ridden implementation of half of Flash instead.

> They expect the Back button to work, and they expect that the stuff they filled out on the previous page will be there when they click it. And it would! If you would just let the browser do what it wants to do!

That's a very recent change, and only after a literal decade of people using javascript to do this put enough pressure on browser makers to fix such basic functionality. I'm not sure it's even implemented in all common browsers yet.

> Every broken contact form or booking site is a truly spectacular own-goal. If your calendar was a bunch of progressively enhanced checkboxes and a submit button, you could be riding off into the sunset and counting money instead of taking support calls from frustrated octogenarians.

Nah. If you did that progressive enhancement nonsense it would take 3x as long and would still work less well. Frankly the biggest thing holding back the web is the opposite, people keep trying to use the broken and awful browser widgets and technologies instead of declaring bankruptcy and just rendering their system via one big canvas element like you would if you were writing a program in a real programming language. We've been trying progressive enhancement for 30 years and it still sucks; how bad does it have to get before we start trying something different?

Re: Care

#40

Post by placebo »

zackbrown wrote: post #31

Structure determines behavior. If a technology structurally encourages shooting oneself in the foot, people will shoot themselves in the feet. The author seems to be arguing the the core problem is behavior — if only developers would stop building flimsy things! But what about a structural view? Is there a certain structure that lends HTML, CSS, and JS to creating frustrating experiences? The structural heart of this…

I think the fact that "structure determines behavior" is true is exactly what it is he is lamenting about. The fact that a tool enables you to shoot yourself in the foot is never an excuse to shoot yourself in the foot. Knowing how not to shoot yourself in the foot with a powerful tool is one thing that separates amateurs from professionals, and you get to be a professional by caring.

That is not to say that work shouldn't be done on making tools which require less cognitive load to use professionally, but until that happens I feel there are too many opinions blaming the tools instead of taking on the responsibility required to use them correctly.

Post reply on HN