I should probably stop going there but I think this article is representative of a certain… fracture within our industry, specifically, a fracture about how the relative importance of design elemenets is perceived. It’s based on the idea that this inconsistency is somehow super important. I think it’s not. And it misses important points about functionality, because it’s written from this perspective that UX and functionality are evolved separately, and on separate tracks, but the practical, everyday reality of writing and maintaing software should’ve long taught us that’s not the case.
First of all: this is 2022, half our tools are web-based. Even if Microsoft were to dump all the pre-Windows 11 era UIs from their system, that would barely make a dent in the consistency of everyone’s interfaces. Not to mention everyone using CAD and gardening apps from the nineties and 00s and whatever in addition to web tools. Pretty much everyone around the world goes on to productively use terribly inconsistent interfaces. I think that, more than, what, fifteen years into the web app revolution, it’s safe to admit the uncomfortable truth we were all afraid to admit about inconsistent UIs back when they became popular: nobody cares about that (for statistically relevant values of nobody, of course: I want the Workbench UI back, and I got friends who want the NeXT UI back, but we’re nerds).
Second, grab your coffee, I’m gonna tell you a boring story. A long time ago, when Windows 95 came out, you could still install the old Windows 3.1 Program Manager shell on it. You could even choose between the two when you installed Windows. By Windows 98, you had to do a registry hack, but the Program Manager was still there. It was finally removed in the days of XP.
Why did the world of computing not go up in flames because Windows offered two shells? Because the new one was good enough that almost nobody wanted the old one. Even in the days of Windows 95, this was mostly a curiosity – some IT departments still rolled out the Program Manager interface, concerned that their less technical staff wouldn’t like the change, but as soon as they saw the taskbar and application icons, they wanted those. Early Windows 95 books (yep, we had those, too) showed both; by the time Rachel began working at Bloomingdale, it was a footnote.
The fact that Microsoft is still putting out UIs at this point isn’t just proof of how messed up the corporate world is: it’s also proof that the new ones just aren’t good enough to make people want to dump the old ones.
So – third, I guess? – I actually like this. One of my work machines runs Windows 11. I’m glad that this is how it works. I don’t care that the Run dialog looks weird, what I care about is that it’s still there, so that I can still use it instead of the hilariously disfunctional Search feature from the start menu. The fact that it hasn’t been removed doesn’t (just) mean Microsoft sucks at UI design – it means they care about (for corporate definitions of “care about”, i.e. they care about the money they get from) the people who still use their old design. If the new one were that good, there wouldn’t be any of those. But it’s not, so there are.
Still allowing people to use the old design, if they’re aware of it, is actually the user-friendly choice here. “Upgrading” me to search system which, because I’ve installed Zotero, insists on autocompleting anything that starts with “intern” to “International Nuclear Information System” instead of Edge, which I use every day (and which we all know why it was offered, seeing how Edge doesn’t start with “intern”…) would’ve been the unfriendly choice here.
And fourth – and, for me, the most important lesson: the Device Manager looks ancient, but the real value in such an ancient program isn’t in muscle program, it’s in reliability.
The Device Manager looks the same as it did twenty years ago. In twenty years, Ubuntu went through like four or five clones of a device manager-like application. Maybe if they’d kept one around for long enough, they would’ve ended up with one that worked well. But they didn’t, and instead of an ancient-looking app that does a bunch of things well, we just got a series of half a dozen fresh-looking apps that were either unstable, useless, or both.
And this hides a bitter piece of irony: we like to shit on proprietary vendors for not giving their users a choice about things. But the next time you have to re-learn how to perform whatever ritual you need to perform to not have blurry fonts in Gnome this year, remember that, if you learned how to manage Windows font settings fifteen years ago, the same company that gave us the Halloween documents still allows you to use that knowledge productively in addition to whatever Gen Z uses, whereas we, the people who are always in control of our computers, regularly learn a different dance for how to not squint at GTK apps.
I get what you’re saying and mostly agree but the problem is that certain areas of functionality that should be consistent aren’t, eg I still can’t edit my pc settings without invariably ending up in some ancient dialog, because the modern settings are still missing all the options. It’s been 25 million year and they still haven’t ported basic mouse and audio settings to the new UI.
That’s much worse than “Photoshop doesn’t look native.”
the problem is that certain areas of functionality that should be consistent aren’t, eg I still can’t edit my pc settings without invariably ending up in some ancient dialog, because the modern settings are still missing all the options. … That’s much worse than “Photoshop doesn’t look native.”
I don’t mean to criticize you for caring about it, but I, for one, can’t imagine I would see ‘how a settings menu looks’ as a problem at all, let alone one ‘much worse’ than how some other program looks.
Wow, I hate all of this. XD Not so much for prioritizing updates to the most-frequently-used programs, or even quite so much for still having 20-year-old programs with Win2000 styled GUI’s. (The ones still using Win3.1 are a little tragic.)
But really, can we please go 5 7 years without needing an entirely new GUI lib, API, and design language with it?
Yeah I was surprised to find that, looking at the examples of Windows 7, I thought “Those look fine.”
Heck, if it weren’t for the pixelation, the 9X UI elements don’t offend me either. The icons there are visually busy, but at least they’re explicit and not abstract shapes. I’m not left guessing what the meaning of three partially-closed squares is in this context versus the other contexts. I think value consistency over this-or-that aesthetic of the moment. Both is nice, but if I had to choose one, consistency is my pick.
GTK4 cannot even scroll lists [1], a bug that is open for literal years. Gnome based UIs are basically falling apart, the situation is extremely dire. KDE and qt on the other hand are doing better.
Oh good, interesting to know that seeing this in GTK4 Nautilus wasn’t just me. It is concerning to find out that it’s a fundamental toolkit bug. I usually don’t run into those on Windows or macOS…
If you study the GTK4 API, you will notice that they painted themselves into a corner in terms of API specification and performance guarantees. The API is very ambitious and I commend them for that, but it will be nearly impossible for the GTK4 library implementers to actually follow through with a sane, correct, robust and complete implementation. Perhaps it’s even mathematically impossible. Furthermore, they are severely understaffed, with only a handful of key contributors (who I respect a lot for their hard work) doing almost everything.
It would be interesting to list all the actual API / GUI library used here.
3.1: Win16, Win32s
95-2000: Win32 (Windows API)
XP: Winforms
Vista-7: WPF?
8-11: WinUI 1, 2, 3?
What am I missing?
MacOS: (essentially 2 layers?), Carbon, Cocoa?
Modern Linux (could be 5 layers?) GTK4, GTK3, Qt6, Qt5, maybe occasional GTK2 application? (Yes, I am aware of other toolkits but they may also just be for a 1-off application).
At least on Windows you have the option of all these layers where as I believe the only Linux distro even packaging GTK1.2 these days is Slackware.
Re: macOS, Carbon is long gone and unsupported. The Cocoa API used today is the same one introduced with Mac OS X around 2000. The only big fork since Carbon was Cocoa itself. Cocoa was pretty futuristic at the time, and it has lasted.
Regarding appearance, Cocoa has evolved release by release—hardware accelerating the compositing and then the window drawing, ditching stripes and brushed metal and largely toning down Aqua, introducing translucent sidebars, dark mode, tabs everywhere, and Big Sur’s revised toolbar style. But with few exceptions, the system apps all kept up to date by virtue of being compiled with the latest SDK version and adapting to any breaking changes.
Recently, we also have the option of building with SwiftUI or Catalyst which sit a layer above, but they inherit and depend on Cocoa’s UI rather than forking it. SwiftUI is increasingly emphasized and may be the main developer path soon. You could say that Catalyst adds to Cocoa by providing the option of iOS or macOS appearance, but the iOS appearance is considered to be a half-baked app implementation, just for the convenience of porting your iOS app without design adjustments.
This is part of the reason macOS users may push back harder against alternate UI appearances and behaviors like you find in Electron apps or JetBrains tools, or lament that the best tool for the job behaves uniquely. Total consistency is almost within reach.
Cocoa was pretty futuristic at the time, and it has lasted.
Cocoa in OS X 10.0 had a very small number of changes from the 1992 OpenStep specification. The fact that it was futuristic is a bit depressing.
The big changes were largely hidden from developers. Windows were always buffered (the unbuffered flag was there, it was just ignored) because RAM was cheaper but CPUs hadn’t increased in performance in line with requirements and so it was faster to buffer windows that were hidden than to redraw them on expose events.
Regarding appearance, Cocoa has evolved release by release—hardware accelerating the compositing and then the window drawing, ditching stripes and brushed metal and largely toning down Aqua, introducing translucent sidebars, dark mode, tabs everywhere, and Big Sur’s revised toolbar style. But with few exceptions, the system apps all kept up to date by virtue of being compiled with the latest SDK version and adapting to any breaking changes.
This is something that I’ve become really impressed by when I learned AppKit by modernizing an old 10.6/10.9 era application. There wasn’t much in the way of breaking changes (pretty much just QTKit to AVFoundation) despite tons of deprecations, and adopting the modern UI conventions both made it look like an application from 2022 and cut a ton of code. For someone who’s main GUI experience is Win32, it’s been an enlightening experience.
Win16, Win32s, and Win32 are all the same thing - an evolution or thunks to/from an evolved version. Windows Forms is a .NET wrapper around Win32.
WPF is its own thing, as is whatever the heck UWP does (I lost track).
While Carbon is gone for developers as other commentators point out, it technically is still around in the dark corners of the OS (menus and the menu bar are Carbon interrnally). There’s a lot of weirdness from Cocoa and Carbon having to coexist and be integrated into each other.
When I switched to Linux operating systems on my desktop, I was afraid I would have problems with inconsistent UI’s like people told me about.
What I did learn is that Windows has waaaay more problems with that than I’ve encountered on Linux. (At least on KDE Plasma things look pretty uniform and nice! Of course the odd Gnome application looks out of place.)
I think the biggest problem with F/OSS desktops is that they’re developed by people who consider Windows to be the gold standard. If your baseline is sufficiently bad, it’s easy to think that you’re doing well.
There’s a config option to put it back in the sensible place. I believe putting it in the middle is a better choice on tablets (I forget the name of the Fitts’ Law equivalent that models finger / thumb position on handheld touchscreens, but the start button is in one of the prime positions that it recommends) but not for mouse / touchpad uses, so I don’t really understand this change.
That said, I think putting the start button or the Apple menu in the corners are both an incredible waste of this space. On a Windows system, I click on the start button maybe a handful of times per day. There are probably at least a hundred operations that I do more frequently than hitting the Start button. On a Mac, I use the Apple menu maybe once a week: almost everything I do with the machine is more frequent than going there.
Aside from just looking like a pile of unfinished redesigns, I think it’s hurting the platform.
I have no idea which UI toolkit to use. Am I supposed to use Win32 like it’s 1995? For whatever other toolkit I hear about, I’m going to question whether it’s already dead or going to be deprecated in the next Windows release when they invent yet another design, make two apps with it, and never touch it ever again.
This inconsistent mishmash means there’s no first-class native look to aspire to. If Microsoft doesn’t care, you can’t expect users to care, so there is no incentive to develop for the native Windows toolkits. Electron apps should look non-native and out of place, but in this chaos, they can easily blend in.
Doesn’t this have more to do with graphic design in particular than UI more broadly? I’m not really seeing any examples of things being rearranged in a way that notably affects the flow of user interaction. Instead, I’m primarily seeing changes to the aesthetic appearance of individual elements, which otherwise function exactly as they used to or with some features removed.
Not really. The legacy dialogs are just painted differently, yes – like, the Run… dialog is just the old Run dialog with a different theme. But newer applications also have completely different widgets, like hamburger and whatever-you-call-three-horizontal-dots menus, and completely different structures.
I should probably stop going there but I think this article is representative of a certain… fracture within our industry, specifically, a fracture about how the relative importance of design elemenets is perceived. It’s based on the idea that this inconsistency is somehow super important. I think it’s not. And it misses important points about functionality, because it’s written from this perspective that UX and functionality are evolved separately, and on separate tracks, but the practical, everyday reality of writing and maintaing software should’ve long taught us that’s not the case.
First of all: this is 2022, half our tools are web-based. Even if Microsoft were to dump all the pre-Windows 11 era UIs from their system, that would barely make a dent in the consistency of everyone’s interfaces. Not to mention everyone using CAD and gardening apps from the nineties and 00s and whatever in addition to web tools. Pretty much everyone around the world goes on to productively use terribly inconsistent interfaces. I think that, more than, what, fifteen years into the web app revolution, it’s safe to admit the uncomfortable truth we were all afraid to admit about inconsistent UIs back when they became popular: nobody cares about that (for statistically relevant values of nobody, of course: I want the Workbench UI back, and I got friends who want the NeXT UI back, but we’re nerds).
Second, grab your coffee, I’m gonna tell you a boring story. A long time ago, when Windows 95 came out, you could still install the old Windows 3.1 Program Manager shell on it. You could even choose between the two when you installed Windows. By Windows 98, you had to do a registry hack, but the Program Manager was still there. It was finally removed in the days of XP.
Why did the world of computing not go up in flames because Windows offered two shells? Because the new one was good enough that almost nobody wanted the old one. Even in the days of Windows 95, this was mostly a curiosity – some IT departments still rolled out the Program Manager interface, concerned that their less technical staff wouldn’t like the change, but as soon as they saw the taskbar and application icons, they wanted those. Early Windows 95 books (yep, we had those, too) showed both; by the time Rachel began working at Bloomingdale, it was a footnote.
The fact that Microsoft is still putting out UIs at this point isn’t just proof of how messed up the corporate world is: it’s also proof that the new ones just aren’t good enough to make people want to dump the old ones.
So – third, I guess? – I actually like this. One of my work machines runs Windows 11. I’m glad that this is how it works. I don’t care that the Run dialog looks weird, what I care about is that it’s still there, so that I can still use it instead of the hilariously disfunctional Search feature from the start menu. The fact that it hasn’t been removed doesn’t (just) mean Microsoft sucks at UI design – it means they care about (for corporate definitions of “care about”, i.e. they care about the money they get from) the people who still use their old design. If the new one were that good, there wouldn’t be any of those. But it’s not, so there are.
Still allowing people to use the old design, if they’re aware of it, is actually the user-friendly choice here. “Upgrading” me to search system which, because I’ve installed Zotero, insists on autocompleting anything that starts with “intern” to “International Nuclear Information System” instead of Edge, which I use every day (and which we all know why it was offered, seeing how Edge doesn’t start with “intern”…) would’ve been the unfriendly choice here.
And fourth – and, for me, the most important lesson: the Device Manager looks ancient, but the real value in such an ancient program isn’t in muscle program, it’s in reliability.
The Device Manager looks the same as it did twenty years ago. In twenty years, Ubuntu went through like four or five clones of a device manager-like application. Maybe if they’d kept one around for long enough, they would’ve ended up with one that worked well. But they didn’t, and instead of an ancient-looking app that does a bunch of things well, we just got a series of half a dozen fresh-looking apps that were either unstable, useless, or both.
And this hides a bitter piece of irony: we like to shit on proprietary vendors for not giving their users a choice about things. But the next time you have to re-learn how to perform whatever ritual you need to perform to not have blurry fonts in Gnome this year, remember that, if you learned how to manage Windows font settings fifteen years ago, the same company that gave us the Halloween documents still allows you to use that knowledge productively in addition to whatever Gen Z uses, whereas we, the people who are always in control of our computers, regularly learn a different dance for how to not squint at GTK apps.
I agree with all of that, but it’s even worse. It’s 2023 now.
Shit. So close, I’d diligently filed everything correctly under 2023 until yesterday. Now every date I write is going to be in 2022 until April :-(.
I get what you’re saying and mostly agree but the problem is that certain areas of functionality that should be consistent aren’t, eg I still can’t edit my pc settings without invariably ending up in some ancient dialog, because the modern settings are still missing all the options. It’s been 25 million year and they still haven’t ported basic mouse and audio settings to the new UI.
That’s much worse than “Photoshop doesn’t look native.”
I don’t mean to criticize you for caring about it, but I, for one, can’t imagine I would see ‘how a settings menu looks’ as a problem at all, let alone one ‘much worse’ than how some other program looks.
Wow, I hate all of this. XD Not so much for prioritizing updates to the most-frequently-used programs, or even quite so much for still having 20-year-old programs with Win2000 styled GUI’s. (The ones still using Win3.1 are a little tragic.)
But really, can we please go
57 years without needing an entirely new GUI lib, API, and design language with it?What’s the most irking is that the Metro-era widgets nowadays look more out of place than those from vista/7 period.
Yeah I was surprised to find that, looking at the examples of Windows 7, I thought “Those look fine.”
Heck, if it weren’t for the pixelation, the 9X UI elements don’t offend me either. The icons there are visually busy, but at least they’re explicit and not abstract shapes. I’m not left guessing what the meaning of three partially-closed squares is in this context versus the other contexts. I think value consistency over this-or-that aesthetic of the moment. Both is nice, but if I had to choose one, consistency is my pick.
It’s funny how much better Microsoft used to be at this. Windows Vista and 7 felt pretty consistent overall.
My takeaway is that Gnome and KDE are doing a great job at evolving their respective desktops and ecosystems.
Meanwhile, my own desktop looks consistently crude at least.
GTK4 cannot even scroll lists [1], a bug that is open for literal years. Gnome based UIs are basically falling apart, the situation is extremely dire. KDE and qt on the other hand are doing better.
[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/2971 (“Scrolling in GtkListView is broken. The scroll is set to random places”)
Oh good, interesting to know that seeing this in GTK4 Nautilus wasn’t just me. It is concerning to find out that it’s a fundamental toolkit bug. I usually don’t run into those on Windows or macOS…
If you study the GTK4 API, you will notice that they painted themselves into a corner in terms of API specification and performance guarantees. The API is very ambitious and I commend them for that, but it will be nearly impossible for the GTK4 library implementers to actually follow through with a sane, correct, robust and complete implementation. Perhaps it’s even mathematically impossible. Furthermore, they are severely understaffed, with only a handful of key contributors (who I respect a lot for their hard work) doing almost everything.
It would be interesting to list all the actual API / GUI library used here.
What am I missing?
MacOS: (essentially 2 layers?), Carbon, Cocoa?
Modern Linux (could be 5 layers?) GTK4, GTK3, Qt6, Qt5, maybe occasional GTK2 application? (Yes, I am aware of other toolkits but they may also just be for a 1-off application).
At least on Windows you have the option of all these layers where as I believe the only Linux distro even packaging GTK1.2 these days is Slackware.
Re: macOS, Carbon is long gone and unsupported. The Cocoa API used today is the same one introduced with Mac OS X around 2000. The only big fork since Carbon was Cocoa itself. Cocoa was pretty futuristic at the time, and it has lasted.
Regarding appearance, Cocoa has evolved release by release—hardware accelerating the compositing and then the window drawing, ditching stripes and brushed metal and largely toning down Aqua, introducing translucent sidebars, dark mode, tabs everywhere, and Big Sur’s revised toolbar style. But with few exceptions, the system apps all kept up to date by virtue of being compiled with the latest SDK version and adapting to any breaking changes.
Recently, we also have the option of building with SwiftUI or Catalyst which sit a layer above, but they inherit and depend on Cocoa’s UI rather than forking it. SwiftUI is increasingly emphasized and may be the main developer path soon. You could say that Catalyst adds to Cocoa by providing the option of iOS or macOS appearance, but the iOS appearance is considered to be a half-baked app implementation, just for the convenience of porting your iOS app without design adjustments.
This is part of the reason macOS users may push back harder against alternate UI appearances and behaviors like you find in Electron apps or JetBrains tools, or lament that the best tool for the job behaves uniquely. Total consistency is almost within reach.
Cocoa in OS X 10.0 had a very small number of changes from the 1992 OpenStep specification. The fact that it was futuristic is a bit depressing.
The big changes were largely hidden from developers. Windows were always buffered (the unbuffered flag was there, it was just ignored) because RAM was cheaper but CPUs hadn’t increased in performance in line with requirements and so it was faster to buffer windows that were hidden than to redraw them on expose events.
This is something that I’ve become really impressed by when I learned AppKit by modernizing an old 10.6/10.9 era application. There wasn’t much in the way of breaking changes (pretty much just QTKit to AVFoundation) despite tons of deprecations, and adopting the modern UI conventions both made it look like an application from 2022 and cut a ton of code. For someone who’s main GUI experience is Win32, it’s been an enlightening experience.
Win16, Win32s, and Win32 are all the same thing - an evolution or thunks to/from an evolved version. Windows Forms is a .NET wrapper around Win32.
WPF is its own thing, as is whatever the heck UWP does (I lost track).
While Carbon is gone for developers as other commentators point out, it technically is still around in the dark corners of the OS (menus and the menu bar are Carbon interrnally). There’s a lot of weirdness from Cocoa and Carbon having to coexist and be integrated into each other.
There’s Catalyst/SwiftUI now, so at least 3.
Carbon was removed in 10.15:
https://en.m.wikipedia.org/wiki/Carbon_(API)
When I switched to Linux operating systems on my desktop, I was afraid I would have problems with inconsistent UI’s like people told me about.
What I did learn is that Windows has waaaay more problems with that than I’ve encountered on Linux. (At least on KDE Plasma things look pretty uniform and nice! Of course the odd Gnome application looks out of place.)
I think the biggest problem with F/OSS desktops is that they’re developed by people who consider Windows to be the gold standard. If your baseline is sufficiently bad, it’s easy to think that you’re doing well.
Wait, does the start button actually move around the screen based on how much crap is currently in the taskbar!?!?
I couldn’t believe they took it out of the corner without putting something more important there. Fitts’s Law going to waste
There’s a config option to put it back in the sensible place. I believe putting it in the middle is a better choice on tablets (I forget the name of the Fitts’ Law equivalent that models finger / thumb position on handheld touchscreens, but the start button is in one of the prime positions that it recommends) but not for mouse / touchpad uses, so I don’t really understand this change.
That said, I think putting the start button or the Apple menu in the corners are both an incredible waste of this space. On a Windows system, I click on the start button maybe a handful of times per day. There are probably at least a hundred operations that I do more frequently than hitting the Start button. On a Mac, I use the Apple menu maybe once a week: almost everything I do with the machine is more frequent than going there.
Aside from just looking like a pile of unfinished redesigns, I think it’s hurting the platform.
I have no idea which UI toolkit to use. Am I supposed to use Win32 like it’s 1995? For whatever other toolkit I hear about, I’m going to question whether it’s already dead or going to be deprecated in the next Windows release when they invent yet another design, make two apps with it, and never touch it ever again.
This inconsistent mishmash means there’s no first-class native look to aspire to. If Microsoft doesn’t care, you can’t expect users to care, so there is no incentive to develop for the native Windows toolkits. Electron apps should look non-native and out of place, but in this chaos, they can easily blend in.
On the plus side, every single one of the dialog boxes in the article, consistently manages to put the buttons the wrong way around for humans.
Doesn’t this have more to do with graphic design in particular than UI more broadly? I’m not really seeing any examples of things being rearranged in a way that notably affects the flow of user interaction. Instead, I’m primarily seeing changes to the aesthetic appearance of individual elements, which otherwise function exactly as they used to or with some features removed.
Not really. The legacy dialogs are just painted differently, yes – like, the Run… dialog is just the old Run dialog with a different theme. But newer applications also have completely different widgets, like hamburger and whatever-you-call-three-horizontal-dots menus, and completely different structures.