4 ms·

To be honest, I have never encountered a website so far that even remotely had the same level of usability of a really good desktop application around the year

To be honest, I have never encountered a website so far that even remotely had the same level of usability of a really good desktop application around the year 2000 or so. 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 web is still the future, I know, but 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. To be fair, a comparison with modern desktop apps is much more favorable, because most of them have regressed in terms of usability.

smt88 7y ago
> 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.
- shantly 7y ago
  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.
  - smt88 7y ago
    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?
- burnte 7y ago
  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.
- dredmorbius 7y ago
  Shuttling the left-column navigation beneath the content, and preserving a minimal header, would preserve most of the functionality and remain mobile-friendly.
chipotle_coyote 7y ago
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.
- mc32 7y ago
  >”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.
  - chipotle_coyote 7y ago
    That's true. Sort of like avatars for your specific services. :)
- marcosdumay 7y ago
  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.
RandallBrown 7y ago
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.
smacktoward 7y ago
> 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.
carlmr 7y ago
>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.

smt88 7y ago

> 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.

shantly 7y ago
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.
- smt88 7y ago
  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?
burnte 7y ago
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.
dredmorbius 7y ago
Shuttling the left-column navigation beneath the content, and preserving a minimal header, would preserve most of the functionality and remain mobile-friendly.

chipotle_coyote 7y ago

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.

mc32 7y ago
>”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.
- chipotle_coyote 7y ago
  That's true. Sort of like avatars for your specific services. :)
marcosdumay 7y ago
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.

RandallBrown 7y ago

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.

smacktoward 7y ago

> 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.

carlmr 7y ago

>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.