> The thing is that GUIs naturally have to evolve to cater to their user base. The "office" metaphor was useful in the 1980s and 90s for making computing familiar to people who were used to "desktops", "folders", "files", etc. Some of these terms still exist today, but the vast majority of users can't relate to it, so it's meaningless to them.
We still 'dial' with our phones, even though phones haven't had dials in over 50 years by this point. Nobody would even explain phones using that metaphor anymore. Even just having a foundation of common terminology is helpful in teaching people new systems.
> This is why GUIs will always have to change and adapt to trends, which will always cause friction for existing users.
I fail to see the connection.
> My point is that by minimizing the amount of graphical elements (note: not completely eliminate them), we minimize the amount of this friction. The difficult thing is, of course, maintaining the appropriate balance of all elements while optimizing for usability, which is ultimately very subjective.
This is true in today's world, but not necessarily in a world where the UI language of computers is stable and users can trust their computers to not change render their understanding of the system from underneath them. If all buttons had the same hints to tell a user 'I'm a button', in the same way default HTML links tell users 'I'm a link', then we could trust users to have this understanding.
> But consider that CLIs are effectively timeless. The friction comes from their lack of discoverability, arcane I/O, every program can have a different UI, etc. And yet this interface has persisted and has largely remained the same for decades. Most programs rarely change their CLI, so the user only needs to learn a few commands to be productive.
It's remained true in a small niche of power users, while for the rest of the world, this environment might as well not exist (beyond the functionality it provides to them after it's been filtered through several layers). CLIs are irrelevant dead-end in the story of user accessible design; one that there's probably some lessons to take from, but not one to entertain in any serious manner.
> That's true. But then again, what exactly is the Windows 9x/2000 design language, and what makes it better than the modern Windows GUI? Is it the basic Start Menu? The task panel with blocks for each window instead of icons? The square instead of round windows? The lack of smooth transitions, transparency, and graphical effects? The overall brutalist theme?
Yes.
> We can certainly add all the features I mentioned to Windows 9x/2000, and we had some of them even back then via 3rd party tools, but isn't that essentially what modern Windows has become? There are ways to revert some Windows 11 features today with alternative shells and such, so is that the ideal UI then?
The classic theme survived up until Windows 7, and I'll give that a pass, since although there still are holes where the newer design language of Windows peeks through, it's stayed mostly consistent, and even managed to add new features without breaking the design language to fit them.
Then that died with Windows 8, and there's been no hope for consistency in UI language since. The dream of a casual user being able to learn a UI and stick to it is dead, since even if they do, it will just change out from underneath them. That's why they don't even bother. Heck, even I barely bother.
> I'm sure that I couldn't stand using its barebones UI today, as much as I would enjoy the simplicity for a brief moment.
I disagree. I don't use many modern UI features, and the few that I do use, like snappable windows, are things I can imagine working within the old design language. I still write documents using a copy of Word 2000 in a Win2K VM every now and then, and when I don't use that, I use LibreOffice, a program many people refuse to use because it looks ancient to them. That's a feature for me. It not changing and thus not breaking my workflow is a huge feature that nothing in Windows 11 can even hope to compare with.