Hacker News Reader

While I don't entirely disagree, how many web sites need the kind of features you're talking about? Have you ever looked at Hacker News and thought "if only this had user-definable menu shortcuts," or been shopping on Amazon and thought "this would be so much better if it had toolbars with custom icons"? Probably not.

One of the most frustrating things about modern web development, at least to cranky old people like me, is the conflation of web sites with web applications. If the use case you're talking about is truly trying to replace what would otherwise be a desktop application, like Gmail or (heaven help us) a code editor or word processor, then many of the features you're talking about start becoming useful. But for so, so many web sites, the focus on feature-rich client side toolkits has become, well, kind of a distraction. Is there any real advantage to the user if the New York Times web site is a state-of-the-art React application? Is it improving my reading experience? I not only don't need them to be using a toolkit that gives them desktop-class drag and drop capability, I don't want it, because I'm just there to read a damn article.

So when you write "web application UX designers are still re-inventing the wheel and without some enforced UI guidelines like Apple had in the 90s websites will never fully catch up with desktop apps in terms of usability," my reaction can't help but be: you literally just used "web application" and "website" as if they were interchangeable, and they are not. There's a worthwhile discussion to be had over how much "desktop-class UX" we actually need for our web applications, but I'd like to see our web sites stop being built like they were web applications when they don't need to be.

>”it had toolbars with custom icons"

This would be pretty cool, actually. Specially the AWS services where the icons are more or less divorced from what they’re supposed to represent.

That's true. Sort of like avatars for your specific services. :)

Honestly, I have never wanted user-definable menu shortcuts on a 90's desktop application either. Each time I saw it, it was a crutch for making a badly designed menu a bit less worse, and things would be much better if the time spent on that feature was simply spent on a better menu.

Very few CAD programs gained something from customized menus (not icons). But this one was also almost always a crutch for fixing bad designs, and those same few programs always gained much more by having a good keyboard based interface.

There's a few times I've used macOS's ability to define menu shortcuts -- although it's generally either to add a shortcut to a menu item that didn't have one or to make the shortcut consistent with the OS and/or other applications. But in general, it's not something I think of as a critical missing feature in apps, you're right.

Even if everyone is doing everything really well, there will always be the endless battle between "usability" aka having a few obviously-named-and-organized features that a new user can instantly understand (while severely limiting overall functionality) - think Asana task management software - vs. "flexibility" which is having all the features anyone could want which almost invariable leads to bloated incomprehensible menus that lead to menus that lead to more damn menus - think Jira or Salesforce.

I think non-enterprise sites/web apps are usually going to tack toward "usability" and enterprise sites/web apps are usually going to tack toward "flexibility".

> How many websites have...

Honestly I'd settle for buttons that are obviously buttons and menus that aren't hidden by default.

A lot of web design has gone backwards in usability, especially since Google popularized Material design.

I think we hit a pretty good local maximum for website usability in the few years when "leftnav column, header, content" layouts all looked and worked basically the same and were the standard look for lots of sites. Granted they weren't mobile friendly ("what's mobile?") but at least you could figure out how a site worked pretty fast if they stuck to that.

I liked that era too, and I agree that mobile-unfriendliness is most of what killed it.

I do also think that the incentive of a designer is not to create those kinds of designs. Familiarity is often more usable, but if your designs are familiar, why hire you at all? Why not just copy a competitor?

I Agree about usability regressing. One of the biggest I've seen is this trend towards two part login screens. Now rather than hitting my password manager button once, I have to do it twice, for no good reason. The "best" theory I heard was that the site is checking if you're SSO or not, but you can do that without two steps, just ignore the password and pas to SSO if they are, or use the password if the SSO check fails.

Shuttling the left-column navigation beneath the content, and preserving a minimal header, would preserve most of the functionality and remain mobile-friendly.

> How many websites have user-definable menu shortcuts, unlimited undo, instant user-feedback for every operation, tooltips that can be switched on or off, full internal drag & drop and OS-level drag and drop of files, standard user interface elements that work how the user expects them to work, a context-sensitive online help system, reconfigurable toolbars with user-definable icon sets, multiple open documents at once, movable and reconfigurable tool windows, manye internationalizations, and so on?

The reason you got all that stuff with desktop applications is that the designers of the platforms those applications ran on (Microsoft and Apple, mostly) included them in the platform by default. As long as you colored within the lines of the platform, your application would pick up all those nice features without you having to do any work to add them. You got them all "for free."

You could of course build a desktop application that didn't get those features by coloring outside the lines -- building your own GUI widget set rather than using the one the platform provided, for instance. But, and this is the important bit, that meant doing extra work, and most programmers (like most people) are lazy. They don't want to do extra work unless they really have to. So most developers stayed within the lines, and the platform rewarded them for doing so by giving them all these nice accessibility and usability benefits. The Lazy Way and the Right Way were deliberately aligned, and everybody benefited.

This is what the Web platform is missing: nobody has done the extra work to force the Lazy Way and the Right Way into alignment. The set of UI primitives the Web platform offers a developer is very small, and hasn't really changed since the late '90s. So the inevitable result is that everyone ends up building their own custom versions of everything -- and since people are lazy, those custom versions end up half-baked. They get just enough polish to address the most common cases, but things like accessibility and usability aren't deemed worth the extra effort they'd require to implement. So we get applications that feel broken compared to desktop apps.

What we need is a richer set of common primitives that are attractive enough to convince people to use them instead of rolling their own, and that also provide all those nice features you mentioned by default. We'll never get an accessible Web app ecosystem if we expect every developer to build accessibility for themselves. It only works if they get that stuff for free.

To be really fair, how many applications from around 2000 actually had all of that stuff you're describing.

I know that it was built into a lot of the default application toolkits at the time, but my recollection is that not every application supported everything. Sometimes the things that were supported didn't actually work very well and what actually happened was a bit of a surprise.

>To be fair, a comparison with modern desktop apps is much more favorable, because most of them have regressed in terms of usability.

A lot of desktop apps are basically packaged web apps now, so that's no surprise.