5 ms·

> In discussions like these, there's usually at least one person who shows up to demand data or research, but curiously never presents anything to back up their

> In discussions like these, there's usually at least one person who shows up to demand data or research, but curiously never presents anything to back up their own claims about modern UI superiority. It's easy to make fun of particularly bad modern examples, but I personally think people really take for granted that the baseline of usability for many areas has hugely increased over the last 20 years. My recollection of some things that made older GUIs less usable, especially for non-techy people: vital functionality had to hunted for in menus or (much worse) right-click context menus, annoying modals everywhere, scary technical language, having to read the manual, lack of undo/redo/autosave, complex install processes, information overload sometimes, confusing file systems (like c:\ and weird file extensions), sharing and collaborating on files was cumbersome. This is really obvious if you've ever had to help friends/family use something over the phone, as you realise how much knowledge you have to build up to confidently use some software. It's really amazing what non-techy people can easily do on their phones and computers now, like real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call. Things like this used to be a nightmare to setup and use, and now it's taken for granted.

JohnFen 3y ago
> the baseline of usability for many areas has hugely increased over the last 20 years. I genuinely think the opposite has happened. Most of the things you cite as being problems with UI of the 2000s is really better applied to software of the late 80s/early 90s, although in all eras there have been both fantastic and terrible UIs. But from a usability perspective, I think things peaked in the early 2000s. > It's really amazing what non-techy people can do easily on their phones and computers now It truly is! But that's about functionality improving, not about usability improving.
- chiefalchemist 3y ago
  A few years ago, my then employer, due to a certain client's requirement, had everyone take a certification course on application security. One of the things that stuck in my head was the course advocating for cryptic error messages. The reason given was that the message shouldn't highlight a particular kink in the armor (if you will) that an able hacker could then try to exploit. Too vague and cryptic was best. I admit, it makes a lot of sense. Annoying as a user, but necessary for application safety and security.
  - ISV_Damocles 3y ago
    That's just security-by-obscurity and doesn't actually buy you anything except a speed bump for a hacker. It was a bogus argument from proprietary software vendors against open source a couple of decades ago, and it is a bogus argument for web services, too. The presence of an error at all is a tell for the hacker as they search the surface area of the service's API, making the wording unclear is simply anti-user (sometimes quite literally when these errors are used as part of anti-fraud measures and shut down accounts without informing the user of what they even did wrong).
    - pixl97 3y ago
      I mean showing the exact path to the configuration file likely isn't a good idea, so there is likely a mix of user friendliness and avoiding information leakage.
      - thaumasiotes 3y ago
        You can't avoid showing the exact path to the configuration file. When your software opens the file, that's visible.
      - M95D 3y ago
        Yeah, I love the linux "File not found" without a file name and path that was searched. It does a lot more to prevent fixing bugs rather than prevent exploiting them.
      - Eisenstein 3y ago
        > I mean showing the exact path to the configuration file likely isn't a good idea Why? This is not self-evident to me.
        pixl97 3y ago
        Now I should say in web facing applications, not user ran applications on a computer. Maybe that makes more sense.
- bryanrasmussen 3y ago
  it's also about usability improving because touchscreen models of interaction are less complicated to reason about than mouse based interactions. on edit: really HN, after the years of articles showing computer illiterate people using ipads and phones for tasks they were not using computers for, probably seeing plenty of 1 year olds able to use ipads etc. you're downvoting someone for pointing out touchscreens are easier to understand than using a mouse.
lmm 3y ago
> vital functionality had to hunted for in menus or (much worse) right-click context menus Those are bad, but magic touch-sensitive areas are even worse. The article mentions scrollbars as a clear example. > scary technical language This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke".
- seanwilson 3y ago
  > This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke". Technical language where it's appropriate is fine. For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful. Actually, I forgot about double-clicking which was everywhere on Windows. People would be confused about if single or double-click would do something different and when to do which.
  - usrbinbash 3y ago
    > For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful. What exactly is the point of an error message being "friendly"? Does a sad cartoon face with an "Oops" in a speech bubble make users feel better? No. Not really. Because the user wants the thing to function, and if it doesn't, the user may want someone to help him, and if all that someone gets to work with is a little cartoon picture, that's not going to result in a happier user. If there is an error´ in my app, I make it EASY for the user to see, copy and send it. Yes, I have written apps where an exception results in the stacktrace to be displayed in the actual app. You know what these "unfriendly" errors caused? Countless very happy users, whos problems were quickly solved by knowledgable stuff who got actual error messages and stacktraces to work with. > People would be confused about if single or double-click would do something different and when to do which And did double clicks go away as a result? No. No they did not. And btw. neither did Menu bars. We still have them. Only now, we have them IN COMBINATION with ribbons etc. and they are sometimes themselves hidden behin dsome element.
jwells89 3y ago
The menubars of yesteryear could get out of hand sure, but I’m not convinced that the patterns that came to replace them are clear wins. For instance, menubars at least have the benefit of standardized behavior between programs and platforms. To me that’s better than what we frequently have today, where it’s not unusual for functions to get buried 3 modals deep with zero commonality between programs, aside from maybe involving a hamburger menu (which doesn’t benefit from being a standard, because it’s a junk drawer with contents varying dramatically between apps).
- chinchilla2020 3y ago
  AutoCAD is a great example of menu bar explosion. You have tens of thousands of potential buttons if you loaded up everything. Button spam ends where CLIs begin. When something truly becomes that complicated, it's time to embrace text commands.
  - lemak 3y ago
    AutoCAD does have a command line, though. The most common commands have names one or two characters long, and you can use Space instead of Enter, so it's really comfy, you can dedicate one of your hands entirely to the mouse, and use the keyboard with the other one. Once activated, these commands start asking for arguments, which you can select with similar short abbreviations, or pick a point with the mouse. You also have customizable toolbars, which can be placed both horizontally and vertically around the drawing area, and you can pick which buttons you want exposed and which you don't need (often). The menus are mostly to help you explore the available functionality while you are still a beginner. Also, having a fixed location for a piece of functionality makes it easier to refer to it in a book, for example. This was twenty years ago, though. I remember there was a push to make it more Windows-looking with every new release (It's Unix native, IIRC). Maybe, by now, it's a joke. I don't know.
    - jwells89 3y ago
      > The menus are mostly to help you explore the available functionality while you are still a beginner. Yes, this is one of the most valuable parts of a proper menu system: it’s basically an index of everything a program can do, and it can even be made searchable (like the menus of any app using the native menubar on macOS is). Menus are also an amazing hook point for accessibility utilities and make things like implementing a HUD UI that works across apps (like Ubuntu’s Unity did) trivial.
arp242 3y ago
> My recollection of some things that made older GUIs less usable, especially for non-techy people It's of course entirely possible that usability has increased in some areas and decreased in others. That's more or less my assessment of the situation summarized in a single sentence. Also, there's a difference between "usability" and "easy to get started with". They're not the same thing at all! "Having to read the manual" can make an application MORE usable if it allows for more advanced UI paradigms, and for applications where the users will spend a lot of time this can be a good trade-off (of course, for many other types of applications it's a bad trade-off). It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved.
- comex 3y ago
  > It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved. But that's not true. 2003, 20 years ago, happens to mark the launch of both the first modern collaborative real-time editors (SubEthaEdit and MoonEdit) and a major video calling service (iChat AV). Sure, hardware progress since then has helped. Video calling got much better due to internet, camera, and codec improvements, along with webcams becoming a ubiquitous component of computers rather than an external addon. Collaborative editing really took off once it started to work in web browsers, originally with EtherPad, but more importantly with Google Docs. That's partly due to the UI paradigm of the URL, but the ability for collaborative editing to work in web browsers can also ascribed to faster CPUs, as well as browsers getting more efficient (which is not hardware but also not a matter of UI paradigms). Still. Ignoring the calling part (which really isn't essential, IMO), collaborative editing isn't necessarily very resource intensive (depending on the algorithm). The technical conditions for it to work were satisfied as soon as Internet access became a ubiquitous feature of computers in the late 90s. Yet it wasn't until 2010, when Google Docs gained collaborative editing, that it even started to take off. I'd say that's definitely an example of UI paradigms improving over time. By the way, a form of collaborative editing was shown off in 1968 in the Mother of All Demos, with video calling! It used analog video.
usrbinbash 3y ago
> but I personally think people really take for granted that the baseline of usability for many areas has hugely increased over the last 20 years. I disagree. What has happened, is that products that could get away with it, have hidden more and more functionality away, usually by shoving it into some god-awful hamburger-menu, or simply removed it, to not "confuse the users". That's not improving, that's removing. And it's fruststrating for every power user, and everytime normal users leave the "happy path" the UI-gurus "designing" such things had in mind. > scary technical language, having to read the manual, Yes, people should try and understand the products they use. If they refuse to do so, then the obvious solution are simplified products, which, granted, are easier to understand, with the tradeoff of lacking functionality. Which is completely fine by the way. Right tool for the job and all that. What isn't fine, is if ALL products start doing that, because then it gets really hard for the people who do read manuals to do their job...because suddenly there are no manuals any more, the language used is over-simplified and non-descriptive, and interface elements are god-knows-where. And sadly, that's exactly where we are now in the software world. Because yes, things like a massive WYSIWYG editor is complex. There is no way around that complexity, not if you want it to have all these bells and whistles it's marketed for having. Yes, things like an email client that people organise their online-identiy around is complex. Yes, applications that people manage their financial lifes with have to be complex. No, an error message saying "Oh noes! Something's not working. Maybe try again later!" under the picture of some sad cartoon character is not helpful for tech support to debug problems. My favorite example, and personal beef of mine? Firewall management software. Because, I think we both can agree that people who's job it is to manage corporate firewalls do read the manuals, and are not scared by technical language. But all my reading and being tech savy gets me absolutely nothing, if the only way to configure that thing is by running a click-marathon through what I can only assume was a modern-art design study gone horribly wrong, and the only documentation available is an old youtube video from 2 versions ago. > as you realise how much knowledge you have to build up to confidently use some software. Here is the thing though: In ye 'olde days, all these scary, techy interfaces looked the same. Once you figured out the menu bar in one application, it was easy to transfer that knowledge elsewhere. Want to save something? "File" menu. Want to change what you're working on? "Edit" menu. Want to change settings? Pretty sure there is a "Settings" or "Preferences" hidden somewhere under "Edit". Nowadays, we have a hamburger button, or a 3-dot button, or a title bar, or a sidebar, or maybe it's one of the phones function buttons, or it's a 2-3-4-finger swipe (the directionality of which is anyones guess). The settings may or may not be under Account, or in the App-Settings, or there might not be any settings at all. The account can be reached helpfully via that gear-icon, or by clicking the profile picture, or by hovering over the profile picture and waiting 0.5sec for the dropdown menu to fly in. Or it's not there at all, because that would be scary to the users, and instead I can change account settings via the non-mobile website on my PC. Or via some other app. Oh, and how wonderful those interfaces are where certain elements only become visible when I flip the phone by 90°.. And this continues ad nauseam. There are no rules, no continuity, no obvious way how something works. Knowing how one app works, doesn't teach me anything about the next one, other than how great those ugly textual menu-bars were in comparison.
grishka 3y ago
The thing with complex software is that yes, you have to explore it for some time before you could use it to accomplish your tasks. But after you did explore it, you'll have memorized where the actions you need are located. And probably their corresponding hotkeys too. Technology requires education and getting used to before it can be used to achieve one's goals. It's perfectly normal. For some reason, no one questions the need to take driving lessons before being able to operate a car.
fsckboy 3y ago
>the baseline of usability for many areas has hugely increased over the last 20 years But the baseline for functionality has decreased at the same time; usability has come at the cost of removing useful options in favor of lowest common denominator, not 80/20, more like 50 and "a very bloated 10...GiB". OK-Cancel is gone, changes now are instaneous. Cancel was a useful thing to do. You like that things have gone they way they've gone? That's great! I wouldn't dream of taking that away from you. But why I can't I have mine work the way I like? Why do you support smashing everything into very small smooth round cookie cutters with one cookie recipe?

JohnFen 3y ago

> the baseline of usability for many areas has hugely increased over the last 20 years. I genuinely think the opposite has happened. Most of the things you cite as being problems with UI of the 2000s is really better applied to software of the late 80s/early 90s, although in all eras there have been both fantastic and terrible UIs. But from a usability perspective, I think things peaked in the early 2000s. > It's really amazing what non-techy people can do easily on their phones and computers now It truly is! But that's about functionality improving, not about usability improving.

chiefalchemist 3y ago
A few years ago, my then employer, due to a certain client's requirement, had everyone take a certification course on application security. One of the things that stuck in my head was the course advocating for cryptic error messages. The reason given was that the message shouldn't highlight a particular kink in the armor (if you will) that an able hacker could then try to exploit. Too vague and cryptic was best. I admit, it makes a lot of sense. Annoying as a user, but necessary for application safety and security.
- ISV_Damocles 3y ago
  That's just security-by-obscurity and doesn't actually buy you anything except a speed bump for a hacker. It was a bogus argument from proprietary software vendors against open source a couple of decades ago, and it is a bogus argument for web services, too. The presence of an error at all is a tell for the hacker as they search the surface area of the service's API, making the wording unclear is simply anti-user (sometimes quite literally when these errors are used as part of anti-fraud measures and shut down accounts without informing the user of what they even did wrong).
  - pixl97 3y ago
    I mean showing the exact path to the configuration file likely isn't a good idea, so there is likely a mix of user friendliness and avoiding information leakage.
    - thaumasiotes 3y ago
      You can't avoid showing the exact path to the configuration file. When your software opens the file, that's visible.
    - M95D 3y ago
      Yeah, I love the linux "File not found" without a file name and path that was searched. It does a lot more to prevent fixing bugs rather than prevent exploiting them.
    - Eisenstein 3y ago
      > I mean showing the exact path to the configuration file likely isn't a good idea Why? This is not self-evident to me.
      - pixl97 3y ago
        Now I should say in web facing applications, not user ran applications on a computer. Maybe that makes more sense.
bryanrasmussen 3y ago
it's also about usability improving because touchscreen models of interaction are less complicated to reason about than mouse based interactions. on edit: really HN, after the years of articles showing computer illiterate people using ipads and phones for tasks they were not using computers for, probably seeing plenty of 1 year olds able to use ipads etc. you're downvoting someone for pointing out touchscreens are easier to understand than using a mouse.

lmm 3y ago

> vital functionality had to hunted for in menus or (much worse) right-click context menus Those are bad, but magic touch-sensitive areas are even worse. The article mentions scrollbars as a clear example. > scary technical language This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke".

seanwilson 3y ago
> This could be bad, but frankly a technical error or code that you can google is a lot less bad than a generic "oopsy whoopsy something broke". Technical language where it's appropriate is fine. For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful. Actually, I forgot about double-clicking which was everywhere on Windows. People would be confused about if single or double-click would do something different and when to do which.
- usrbinbash 3y ago
  > For errors, it's easy enough to show a friendly error message at the top with more technical details underneath if it could be useful. What exactly is the point of an error message being "friendly"? Does a sad cartoon face with an "Oops" in a speech bubble make users feel better? No. Not really. Because the user wants the thing to function, and if it doesn't, the user may want someone to help him, and if all that someone gets to work with is a little cartoon picture, that's not going to result in a happier user. If there is an error´ in my app, I make it EASY for the user to see, copy and send it. Yes, I have written apps where an exception results in the stacktrace to be displayed in the actual app. You know what these "unfriendly" errors caused? Countless very happy users, whos problems were quickly solved by knowledgable stuff who got actual error messages and stacktraces to work with. > People would be confused about if single or double-click would do something different and when to do which And did double clicks go away as a result? No. No they did not. And btw. neither did Menu bars. We still have them. Only now, we have them IN COMBINATION with ribbons etc. and they are sometimes themselves hidden behin dsome element.

jwells89 3y ago

The menubars of yesteryear could get out of hand sure, but I’m not convinced that the patterns that came to replace them are clear wins. For instance, menubars at least have the benefit of standardized behavior between programs and platforms. To me that’s better than what we frequently have today, where it’s not unusual for functions to get buried 3 modals deep with zero commonality between programs, aside from maybe involving a hamburger menu (which doesn’t benefit from being a standard, because it’s a junk drawer with contents varying dramatically between apps).

chinchilla2020 3y ago
AutoCAD is a great example of menu bar explosion. You have tens of thousands of potential buttons if you loaded up everything. Button spam ends where CLIs begin. When something truly becomes that complicated, it's time to embrace text commands.
- lemak 3y ago
  AutoCAD does have a command line, though. The most common commands have names one or two characters long, and you can use Space instead of Enter, so it's really comfy, you can dedicate one of your hands entirely to the mouse, and use the keyboard with the other one. Once activated, these commands start asking for arguments, which you can select with similar short abbreviations, or pick a point with the mouse. You also have customizable toolbars, which can be placed both horizontally and vertically around the drawing area, and you can pick which buttons you want exposed and which you don't need (often). The menus are mostly to help you explore the available functionality while you are still a beginner. Also, having a fixed location for a piece of functionality makes it easier to refer to it in a book, for example. This was twenty years ago, though. I remember there was a push to make it more Windows-looking with every new release (It's Unix native, IIRC). Maybe, by now, it's a joke. I don't know.
  - jwells89 3y ago
    > The menus are mostly to help you explore the available functionality while you are still a beginner. Yes, this is one of the most valuable parts of a proper menu system: it’s basically an index of everything a program can do, and it can even be made searchable (like the menus of any app using the native menubar on macOS is). Menus are also an amazing hook point for accessibility utilities and make things like implementing a HUD UI that works across apps (like Ubuntu’s Unity did) trivial.

arp242 3y ago

> My recollection of some things that made older GUIs less usable, especially for non-techy people It's of course entirely possible that usability has increased in some areas and decreased in others. That's more or less my assessment of the situation summarized in a single sentence. Also, there's a difference between "usability" and "easy to get started with". They're not the same thing at all! "Having to read the manual" can make an application MORE usable if it allows for more advanced UI paradigms, and for applications where the users will spend a lot of time this can be a good trade-off (of course, for many other types of applications it's a bad trade-off). It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved.

comex 3y ago
> It's hard to directly compare things to 20 years ago; "real-time collaborative editing of a document (with automatic saving and unlimited undo) over a video call" wasn't done because we lacked the internet speeds and computing power to make that viable, not because UI paradigms improved. But that's not true. 2003, 20 years ago, happens to mark the launch of both the first modern collaborative real-time editors (SubEthaEdit and MoonEdit) and a major video calling service (iChat AV). Sure, hardware progress since then has helped. Video calling got much better due to internet, camera, and codec improvements, along with webcams becoming a ubiquitous component of computers rather than an external addon. Collaborative editing really took off once it started to work in web browsers, originally with EtherPad, but more importantly with Google Docs. That's partly due to the UI paradigm of the URL, but the ability for collaborative editing to work in web browsers can also ascribed to faster CPUs, as well as browsers getting more efficient (which is not hardware but also not a matter of UI paradigms). Still. Ignoring the calling part (which really isn't essential, IMO), collaborative editing isn't necessarily very resource intensive (depending on the algorithm). The technical conditions for it to work were satisfied as soon as Internet access became a ubiquitous feature of computers in the late 90s. Yet it wasn't until 2010, when Google Docs gained collaborative editing, that it even started to take off. I'd say that's definitely an example of UI paradigms improving over time. By the way, a form of collaborative editing was shown off in 1968 in the Mother of All Demos, with video calling! It used analog video.

usrbinbash 3y ago

> but I personally think people really take for granted that the baseline of usability for many areas has hugely increased over the last 20 years. I disagree. What has happened, is that products that could get away with it, have hidden more and more functionality away, usually by shoving it into some god-awful hamburger-menu, or simply removed it, to not "confuse the users". That's not improving, that's removing. And it's fruststrating for every power user, and everytime normal users leave the "happy path" the UI-gurus "designing" such things had in mind. > scary technical language, having to read the manual, Yes, people should try and understand the products they use. If they refuse to do so, then the obvious solution are simplified products, which, granted, are easier to understand, with the tradeoff of lacking functionality. Which is completely fine by the way. Right tool for the job and all that. What isn't fine, is if ALL products start doing that, because then it gets really hard for the people who do read manuals to do their job...because suddenly there are no manuals any more, the language used is over-simplified and non-descriptive, and interface elements are god-knows-where. And sadly, that's exactly where we are now in the software world. Because yes, things like a massive WYSIWYG editor is complex. There is no way around that complexity, not if you want it to have all these bells and whistles it's marketed for having. Yes, things like an email client that people organise their online-identiy around is complex. Yes, applications that people manage their financial lifes with have to be complex. No, an error message saying "Oh noes! Something's not working. Maybe try again later!" under the picture of some sad cartoon character is not helpful for tech support to debug problems. My favorite example, and personal beef of mine? Firewall management software. Because, I think we both can agree that people who's job it is to manage corporate firewalls do read the manuals, and are not scared by technical language. But all my reading and being tech savy gets me absolutely nothing, if the only way to configure that thing is by running a click-marathon through what I can only assume was a modern-art design study gone horribly wrong, and the only documentation available is an old youtube video from 2 versions ago. > as you realise how much knowledge you have to build up to confidently use some software. Here is the thing though: In ye 'olde days, all these scary, techy interfaces looked the same. Once you figured out the menu bar in one application, it was easy to transfer that knowledge elsewhere. Want to save something? "File" menu. Want to change what you're working on? "Edit" menu. Want to change settings? Pretty sure there is a "Settings" or "Preferences" hidden somewhere under "Edit". Nowadays, we have a hamburger button, or a 3-dot button, or a title bar, or a sidebar, or maybe it's one of the phones function buttons, or it's a 2-3-4-finger swipe (the directionality of which is anyones guess). The settings may or may not be under Account, or in the App-Settings, or there might not be any settings at all. The account can be reached helpfully via that gear-icon, or by clicking the profile picture, or by hovering over the profile picture and waiting 0.5sec for the dropdown menu to fly in. Or it's not there at all, because that would be scary to the users, and instead I can change account settings via the non-mobile website on my PC. Or via some other app. Oh, and how wonderful those interfaces are where certain elements only become visible when I flip the phone by 90°.. And this continues ad nauseam. There are no rules, no continuity, no obvious way how something works. Knowing how one app works, doesn't teach me anything about the next one, other than how great those ugly textual menu-bars were in comparison.

grishka 3y ago

The thing with complex software is that yes, you have to explore it for some time before you could use it to accomplish your tasks. But after you did explore it, you'll have memorized where the actions you need are located. And probably their corresponding hotkeys too. Technology requires education and getting used to before it can be used to achieve one's goals. It's perfectly normal. For some reason, no one questions the need to take driving lessons before being able to operate a car.

fsckboy 3y ago

>the baseline of usability for many areas has hugely increased over the last 20 years But the baseline for functionality has decreased at the same time; usability has come at the cost of removing useful options in favor of lowest common denominator, not 80/20, more like 50 and "a very bloated 10...GiB". OK-Cancel is gone, changes now are instaneous. Cancel was a useful thing to do. You like that things have gone they way they've gone? That's great! I wouldn't dream of taking that away from you. But why I can't I have mine work the way I like? Why do you support smashing everything into very small smooth round cookie cutters with one cookie recipe?