The Register has also published articles claiming (incorrectly because it ignores customisability) that Linux desktop environments are too much like Windows and not innovating.
I agree about the lack of standard key bindings is a problem. It is definitely a problem with things like text editors. Even worse between modal editors, or a mix of modal and modeless - I generally use Helix and occasionally using vi (or nano, or anything else) is a pain.
Talking about out-of-the-box configs (which are important because a lot of users run default or near-default), the argument that Linux DEs that ship with distros have a heavy bias towards the Win9X desktop paradigm holds up pretty well. The only odd ones out are GNOME which is iPadOS-like and Pantheon which is like iPadOS with an OS X 10.9 theme applied.
There aren’t any DEs that for example mimic macOS (modern or classic) and the few that do something different (e.g. GNUSTEP, CDE, etc) don’t ship with distros. As far as I know there haven’t been any recent DEs that were designed from scratch based on research from new user trials and usability studies (which is unfortunate; most of data in this realm dates back 20 years or more and could probably benefit from addition of new data from a modern context).
The problem with Pantheon is that it only captures the skin-deep aspects of macOS. Power user features and progressive disclosure thereof (which are a big reason why macOS has a technically capable userbase) are mostly stripped. Like GNOME, it doesn’t support minimizing windows for example and not only doesn’t have a global menubar but eschews menubars entirely, with functions that don’t fit in hamburger menus either getting buried or cut entirely.
Absolutely; recently I realize I wish I'd never learned vim. I use too many other programs that are at least CUA-ish ( http://zim-wiki.org is the most important app I use ) and now I kind of want out. I haven't yet tried Modeless Vim, but that looks like my next experiment.
Probably the most annoying inconsistency in any UI - no matter the platform - is which mouse button / modifier keys do you use to pan, rotate and zoom. Both in 2D and 3D there's zero consistency across programs.
> Linux desktop environments are too much like Windows and not innovating.
If we're talking the files+folders paradigm, then there's not much innovation remaining outside of cosmetic changes. Desktop computers are "done" much the same way automobile interfaces (steering wheel, foot peddles, etc) are "done". I think true Desktop innovations would require a paradigm shift or new hardware, like eye-tracking or a BCI.
80s 90s and early 2000s it was the OS. All apps running under a specific OS would look similar to each other. Behave same way. File menus looked same. Preferences was in same location.
But somewhere in 2000s this reversed and OS was no longer driver of consistency.
App developers stopped following OS UI guidelines and decided that it's not important for OS to be cohesive. The goal was that app, no matter where it is running, should have consistent look and behavior.
And now we are in application centric world where application dictates UI and there is no OS level consistency.
Additionally Microsoft and Apple did not help the situation by themselves breaking the OS UI paradigms with media players, or in MS case MS Office.
> Additionally Microsoft and Apple did not help the situation by themselves breaking the OS UI paradigms with media players, or in MS case MS Office.
Indeed - I remember this situation very clearly. Back when Office 2007 came out, there was no first-party way to create applications like that, and after a year or two, only few third-party libraries that were lacking in quality and polish.
This was the turning point. Clients asked us for it, we tried, but ultimately we decided to ditch the bad libraries and do our own thing - then the clients decided they might as well define their own UI design language if they're paying for UI component development.
The Ribbon was a travesty. Organized menus were replaced by a giant bar full of incomprehensible icons. If you were decent at Office, then your muscle memory was screwed up. (If you were excellent, then maybe you had all the shortcuts memorized and it didn't matter, but most of us are in an in-between state.) If instead you were completely new to Office, then your consistent, discoverable indication of keyboard shortcuts (in the menus) also went away -- no more skill ladder. The only winners were preliterate toddlers, I have to assume.
This was justified with, "I am an HCI expert, trust me". Which is garbage: I'm the user of the tool; don't try to pretend you know better, like some colonial governor.
Also, it started getting slower. A process that only got worse and worse.
My assumption is that it was really all driven by internal politics within Microsoft, specifically some manager's need to Change Something.
Strongly agreed. Better for newbies, maybe, but disastrous for skilled users. It broke the suite for me: I can't stand it at all, and switched to LibreOffice full time.
Sadly, though, LO Writer doesn't have Outline Mode, the one indispensible bit of MS Office for me. So I keep Word 97 or Word 2000 around, just for outlining.
And Microsoft could have just kept the old menu system. With a single click to switch between the ribbon interface and the menu interface. It could have been as simple as that, saving countless users from so much frustration. Instead they decided to force the inferior interface on every single user, whether they like it or not.
The whole ribbon interface debacle looks like a classic case of enshittification, where the users are no longer the customers anymore.
What for me is really strange, in a way, is that the Mac versions of Office did keep the menu bar, and still do. Until I upgraded to Monterey late last year, I was still using Word 2011. It has the ability to completely hide the entire Ribbon. That suited me well.
But Office 2011 is 32-bit and no longer runs. Now, I only keep Word around. I've been forced to update to 2016, the oldest 64-bit version that'll run on macOS 11 (AIUI).
The menu bar is an inextricable part of the macOS UI so it would be hard to remove, but it demonstrates perfectly that Office for Windows could have kept both UIs, because the macOS version did.
My normal mode of operation in Word for Windows uo to 2003 is just to turn off all the toolbars, and the horizontal scrollbar, and the ruler. It runs well with nothing but a menu bar and every feature is usable.
In the case of Windows, that consistency wasn’t ever really there at any point. DOS was the Wild West when it came to UI and much of that carried over to Windows — it wasn’t unusual to come across Windows programs that looked nothing like the OS in the 95/98/ME/2k/XP era.
It was more of a thing on Macs, which never had a point where the platform didn’t provide guidance for what programs should look like, and that only got stronger with the introduction of OS X where non-native programs stuck out like a sore thumb due to looking so supremely unpolished next to apps built with Cocoa or Carbon, which were richly nuanced.
To my memory, all of this flipped with the introduction of flat design, when it became more acceptable to build software that didn’t have much love put towards UI design. An electron (or similar, e.g. CEF) app built using Material Design 1.0 stuck out much less starkly when framed by the flattened Helveticized OS X Yosemite or Windows 8 than it did framed by OS X Mavericks or Windows 7.
This is true... but, to be fair, there were a handful of apps that went out of their way to look like Turbovision apps but weren't, and by the same token, it was possible to create (e.g.) Delphi apps that didn't look like it.
The first console text editor I really liked on Linux was SETedit.
The whole idea of a "standard user interface" always seemed totally goofy to me.
Do hammers, bulldozers, and microscopes all use a "standard user interface"? No, they do not.
A user interface should be optimized for the tool in question, not optimized to look exactly like the interface for all other tools.
Not to mention the hubris involved with imagining that one has invented the One True User Interface at the very dawn of the technology.
While performing roughly the same task, modern hammers don't have anything like the "user interface" of a Paleolithic hammer stone. Fortunately there weren't any "Human Interface Guidelines" people around when the hammer stone was invented.
App UIs should be optimized for their use case, yes, but I would argue that the idea that a one-off app UI design can do common widgets and interactions as well or better than a platform with tens of thousands of dollars and man-hours poured into user research involves just as much or more hubris as thinking that there’s One True User Interface. The average app with bespoke UI is chock full of usability/accessibility issues that wouldn’t be there had they been built with a platform UI framework.
> A user interface should be optimized for the tool in question, not optimized to look exactly like the interface for all other tools.
When you learn how to drive a car, you can expect the same standard across all cars. You don't relearn how to drive when you get into a new car. There's common UI and UX paradigms across all software and no one should have to learn your bespoke implementation. And I believe these sets should be part of the OS.
When you look at Spotify or Slack UI, there's nothing there that is better than their more native looking alternatives. I have utilities to populate a command panel with menu items, but it's essentially useless on these apps because everything is buried inside the app itself.
> You don't relearn how to drive when you get into a new car.
These days you do. We're at a transition these last 10 years or so as great as the one from crank-start to key-turn start cars, from regular steering to powered steering, and from manual to automatic transmission.
Even back a couple of decades ago I remember my 1980's Buick having shifting on the steering post toggles versus my 2000's Saturn having a standard shift stick.
Standards should change. No one is recommending to keep 1024*800 as the current resolution. I’m for evolution and for consistency. Not changes for the sake of change.
In the 90's it was easier to use the OS native controls and harder to customize them. Adding a small image to a button was pain. Using non-standard fonts or font sizes was pain.
Now it's easier to use HTML stack to create UIs and harder to use OS native controls.
An article about the history of user interfaces that ignores the Xerox Alto? The article has the WIMP interface and graphical desktops emerging from the graphics of 8-bit home computers. The article also ignores that TUIs came from terminals like the VT100 that had cursor positioning, instead claiming that home computers were the source of moving cursors around the screen. The article goes into plenty of obscure details (e.g. where Bucky bits came from), but the history is very strange.
I lived through everything this rambling article poorly articulates. What I realized for myself is that I have two modes:
1) Frequently used applications: doesn't matter if I have to ctrl-alt-right-double-tap a weird key or click on some invisible UI element. I'll learn what it takes and use it without complaint
2) Casual use of a new environment or app: endless complaining about the weirdness until I either cast it aside or use it everyday (see 1 above)
It is overlong, sadly, yes. It was written in some haste, despite considerable planning -- see my docs uploaded to the Internet Archive, for instance -- because one of my planned, agreed interviewees for Retro Tech Week dropped out at the last minute and left me without an article, and I had to rush this.
Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
Bummer about the rush, lots of good stuff in the article, hopefully you'll get another chance to condense it. Definitely brought back a lot of memories for me, my OS/2 phase was a lot of fun and I was sad when it ended.
> my OS/2 phase was a lot of fun and I was sad when it ended.
Same. I have been playing around with eComStation and ArcaOS recently. They are amazingly fast on elderly Core 2 Duo era kit where any modern Linux distro is sluggish... but I can't get wifi working.
UI definitely shouldn't have to be standard, but if it deviates, it should be good! Intuitive, memorable, easy to navigate, etc.
There are as many bad user interfaces out there as there is bad graphic design, although I often think that the majority of "egregious" examples of graphic design (signs, etc) are actually quite functional and informative, just arguably visually-offensive -- they do their job well enough, they're just tarted up like toaster pastries.
Bad UIs on the other hand are genuinely unusable and can make or break an otherwise-brilliant program or service.
37 comments
[ 2.9 ms ] story [ 70.2 ms ] threadI agree about the lack of standard key bindings is a problem. It is definitely a problem with things like text editors. Even worse between modal editors, or a mix of modal and modeless - I generally use Helix and occasionally using vi (or nano, or anything else) is a pain.
There aren’t any DEs that for example mimic macOS (modern or classic) and the few that do something different (e.g. GNUSTEP, CDE, etc) don’t ship with distros. As far as I know there haven’t been any recent DEs that were designed from scratch based on research from new user trials and usability studies (which is unfortunate; most of data in this realm dates back 20 years or more and could probably benefit from addition of new data from a modern context).
I cannot tell how well the distros that do mimic MacOS do it, but from what you say it is not well enough (at least not Pantheon).
https://github.com/SebastianMuskalla/ModelessVim
If we're talking the files+folders paradigm, then there's not much innovation remaining outside of cosmetic changes. Desktop computers are "done" much the same way automobile interfaces (steering wheel, foot peddles, etc) are "done". I think true Desktop innovations would require a paradigm shift or new hardware, like eye-tracking or a BCI.
80s 90s and early 2000s it was the OS. All apps running under a specific OS would look similar to each other. Behave same way. File menus looked same. Preferences was in same location.
But somewhere in 2000s this reversed and OS was no longer driver of consistency.
App developers stopped following OS UI guidelines and decided that it's not important for OS to be cohesive. The goal was that app, no matter where it is running, should have consistent look and behavior.
And now we are in application centric world where application dictates UI and there is no OS level consistency.
Additionally Microsoft and Apple did not help the situation by themselves breaking the OS UI paradigms with media players, or in MS case MS Office.
Indeed - I remember this situation very clearly. Back when Office 2007 came out, there was no first-party way to create applications like that, and after a year or two, only few third-party libraries that were lacking in quality and polish.
This was the turning point. Clients asked us for it, we tried, but ultimately we decided to ditch the bad libraries and do our own thing - then the clients decided they might as well define their own UI design language if they're paying for UI component development.
This was justified with, "I am an HCI expert, trust me". Which is garbage: I'm the user of the tool; don't try to pretend you know better, like some colonial governor.
Also, it started getting slower. A process that only got worse and worse.
My assumption is that it was really all driven by internal politics within Microsoft, specifically some manager's need to Change Something.
Strongly agreed. Better for newbies, maybe, but disastrous for skilled users. It broke the suite for me: I can't stand it at all, and switched to LibreOffice full time.
Sadly, though, LO Writer doesn't have Outline Mode, the one indispensible bit of MS Office for me. So I keep Word 97 or Word 2000 around, just for outlining.
The whole ribbon interface debacle looks like a classic case of enshittification, where the users are no longer the customers anymore.
But Office 2011 is 32-bit and no longer runs. Now, I only keep Word around. I've been forced to update to 2016, the oldest 64-bit version that'll run on macOS 11 (AIUI).
The menu bar is an inextricable part of the macOS UI so it would be hard to remove, but it demonstrates perfectly that Office for Windows could have kept both UIs, because the macOS version did.
My normal mode of operation in Word for Windows uo to 2003 is just to turn off all the toolbars, and the horizontal scrollbar, and the ruler. It runs well with nothing but a menu bar and every feature is usable.
It was more of a thing on Macs, which never had a point where the platform didn’t provide guidance for what programs should look like, and that only got stronger with the introduction of OS X where non-native programs stuck out like a sore thumb due to looking so supremely unpolished next to apps built with Cocoa or Carbon, which were richly nuanced.
To my memory, all of this flipped with the introduction of flat design, when it became more acceptable to build software that didn’t have much love put towards UI design. An electron (or similar, e.g. CEF) app built using Material Design 1.0 stuck out much less starkly when framed by the flattened Helveticized OS X Yosemite or Windows 8 than it did framed by OS X Mavericks or Windows 7.
At the time of Windows 95, things were still basically homogeneous.
You could tell when something was made with Borland and TUI. Professional applications tended to look alike.
This is true... but, to be fair, there were a handful of apps that went out of their way to look like Turbovision apps but weren't, and by the same token, it was possible to create (e.g.) Delphi apps that didn't look like it.
The first console text editor I really liked on Linux was SETedit.
https://setedit.sourceforge.net/#scrnsht
That, I think, uses a 3rd party independent clone of Turbovision.
Do hammers, bulldozers, and microscopes all use a "standard user interface"? No, they do not.
A user interface should be optimized for the tool in question, not optimized to look exactly like the interface for all other tools.
Not to mention the hubris involved with imagining that one has invented the One True User Interface at the very dawn of the technology.
While performing roughly the same task, modern hammers don't have anything like the "user interface" of a Paleolithic hammer stone. Fortunately there weren't any "Human Interface Guidelines" people around when the hammer stone was invented.
When you learn how to drive a car, you can expect the same standard across all cars. You don't relearn how to drive when you get into a new car. There's common UI and UX paradigms across all software and no one should have to learn your bespoke implementation. And I believe these sets should be part of the OS.
When you look at Spotify or Slack UI, there's nothing there that is better than their more native looking alternatives. I have utilities to populate a command panel with menu items, but it's essentially useless on these apps because everything is buried inside the app itself.
These days you do. We're at a transition these last 10 years or so as great as the one from crank-start to key-turn start cars, from regular steering to powered steering, and from manual to automatic transmission.
Even back a couple of decades ago I remember my 1980's Buick having shifting on the steering post toggles versus my 2000's Saturn having a standard shift stick.
I think the better parallel is aspect ratio, not resolution.
Across all cars. Not "across all controllable artifacts" or even "across all vehicles" (driving a bulldozer is way different from driving a car).
An optimal user interface for (e.g.) an accounting package is extremely unlikely to be the same as the interface for (e.g.) a video editor.
For that matter, imagine attempting to drive a car by picking the things you want to do off a menu with a mouse.
It would suck.
Big time.
"Ok, now open the Speed menu and scroll down to 'brake'. Now go to the 'slam' submenu item... whoops! Sorry, kitty!".
I think its perfectly reasonable to expect a program to look and feel similar to other programs on the same OS.
At least for things the OS is somewhat concerned with, like window decorations, menu bars and so on.
If i designed an OS id be frustrated with the inconsistencies in how different applications interact with the design of my OS.
Now it's easier to use HTML stack to create UIs and harder to use OS native controls.
Microsoft is still working hard at Office 365. They are nowhere close.
Java had, at some time, achived this.
1) Frequently used applications: doesn't matter if I have to ctrl-alt-right-double-tap a weird key or click on some invisible UI element. I'll learn what it takes and use it without complaint
2) Casual use of a new environment or app: endless complaining about the weirdness until I either cast it aside or use it everyday (see 1 above)
It is overlong, sadly, yes. It was written in some haste, despite considerable planning -- see my docs uploaded to the Internet Archive, for instance -- because one of my planned, agreed interviewees for Retro Tech Week dropped out at the last minute and left me without an article, and I had to rush this.
Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
> my OS/2 phase was a lot of fun and I was sad when it ended.
Same. I have been playing around with eComStation and ArcaOS recently. They are amazingly fast on elderly Core 2 Duo era kit where any modern Linux distro is sluggish... but I can't get wifi working.
https://www.theregister.com/2023/01/19/retro_tech_week_arca_...
https://www.theregister.com/2023/09/04/arcaos_51/
There are as many bad user interfaces out there as there is bad graphic design, although I often think that the majority of "egregious" examples of graphic design (signs, etc) are actually quite functional and informative, just arguably visually-offensive -- they do their job well enough, they're just tarted up like toaster pastries.
Bad UIs on the other hand are genuinely unusable and can make or break an otherwise-brilliant program or service.