(no title)
imiric | 1 day ago
Forcing users to click on graphical elements presents many challenges: what constitutes an "element"; what are its boundaries; when is it active, inactive, disabled, etc.; if it has icons, what do they mean; are interactive elements visually distinguishable from non-interactive elements; and so on.
A good example of bad UI that drives me mad today on Windows 11 is something as simple as resizing windows. Since the modern trend is to have rounded corners on everything, it's not clear where the "grab" area for resizing a window exists anymore. It seems to exist outside of the physical boundary of the window, and the actual activation point is barely a few pixels wide. Apparently this is an issue on macOS as well[1].
Like you, I do have a soft spot for the Windows 2000 GUI in particular, and consider it the pinnacle of Microsoft's designs, but it still feels outdated and inneficient by modern standards. The reason for this is because it follows the visual trends of the era, and it can't accomodate some of the UX improvements newer GUIs have (universal search, tiled/snappable windows, workspaces, etc.).
So, my point is that eschewing graphics as much as possible, and relying on keyboard input to perform operations, gets rid of the graphical ambiguities, minimizes the amount of trend following making the UI feel timeless, and makes the user feel more in command of their experience, making them more efficient and quicker.
This UI doesn't have to be some inaccessible CLI or TUI, although that's certainly an option for power users, but it should generally only serve to enable the user to do their work as easily as possible, and get out of the way the rest of the time. Unfortunately, most modern OSs have teams of designers and developers that need to justify their salary, and a UI that is invisible and rarely changes won't get anyone promoted. But it's certainly possible for power users to build out this UI themselves using some common and popular software. It takes a bit of work, but the benefits far outweigh the time and effort investment.
cosmic_cheese|1 day ago
Modern UIs aren't great with discoverability, either however and are not an example that should be followed.
zzo38computer|23 hours ago
There are still ways to help, such as having a menu bar, and having good documentation. (Documentation is more important, in my opinion; but both are helpful.)
imiric|20 hours ago
Consider the "Command Palette" and similar features that are part of many UIs (VS Code, Obsidian, Vim, Emacs, etc.). It allows the user to search all possible actions using natural language, and see or assign key bindings to them, so that they can get to their most commonly used actions faster. This search can be global for the entire program, or contextual for the current view.
It is far easier to search for what you want to do, than to learn to what action every GUI element is associated with, or to navigate arbitrarily nested menu hierarchies. This does require the user to be familiar with the domain language somewhat in order to know what to search for, but this too can be simplified, actions can have different names, etc. It also makes the program more accessible for speech navigation, screen readers, and so on.
zzo38computer|23 hours ago
I agree, that the interactivity should be primarily keyboard-driven. However, mouse input is useful for many things as well; if there are many things on the screen, the mouse can be a useful way to select one, even if the keyboard can also be used (if you already know what it is, you can type it in without having to know where on the screen it is; if you do not know what it is, you can see it on the screen and select it by mouse).
> Forcing users to click on graphical elements presents many challenges: what constitutes an "element"; what are its boundaries; when is it active, inactive, disabled, etc.; if it has icons, what do they mean; are interactive elements visually distinguishable from non-interactive elements; and so on.
At least older versions of Windows had a more consistent way of indicating some of these things, although sometimes they did not work very well, often they worked OK. (The conventions for doing so might have been improved, although at least they had some that, at least partially, worked.)
> A good example of bad UI that drives me mad today on Windows 11 is something as simple as resizing windows. ... it's not clear where the "grab" area for resizing a window exists anymore
I had just used ALT+SPACE to do stuff such as resize, move, etc. I have not used Windows 11 so I don't know if it works on Windows 11, but I would hope that it does if Microsoft wants to avoid confusing people. (On other older versions of Windows, even if they moved everything I was able to use it because most of the keyboard commands still work the same as older versions of Windows, so that is helpful (for example, you can still push ALT+TAB to switch between full-screen programs, ALT+F4 to close a full-screen program, etc; I don't know whether or not there is any other way to do such things like that). However, many of the changes will cause confusion despite this, or will cause other problems, that they removed stuff that is useful in favor of less useful or more worthless stuff.)
Telaneo|1 day ago
There are standards and common conventions for a lot of this in the Windows 9X/2000 design language, and even in basic HTML. These challenges could have been solved (for values of) by using them consistently, and I think we might have been there for a little while, at least within the Windows bubble. The fact that we threw all of those out the window with new and worse design, then did that again a few more times just to make sure all the users learned to never bother actually learning the UI, since it will just change on them anyway, doesn't entail that this is an unsolvable problem (well, it might be now, but I doubt it was back in 1995).
> Like you, I do have a soft spot for the Windows 2000 GUI in particular, and consider it the pinnacle of Microsoft's designs, but it still feels outdated and inneficient by modern standards. The reason for this is because it follows the visual trends of the era, and it can't accomodate some of the UX improvements newer GUIs have (universal search, tiled/snappable windows, workspaces, etc.).
I fail to see why any of these features couldn't be implemented within the design constraints of the Windows 9X/2000 design language. There are certainly technical constrains, but I can't see any design constrains. They were never implemented at the time, and those features didn't become relevant until we'd gone through several rounds of different designs, so we never had the opportunity to see how it would work out.
imiric|19 hours ago
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.
This is why GUIs will always have to change and adapt to trends, which will always cause friction for existing users.
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.
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.
So I think that the most usable UI is somewhere in the middle. It should avoid the constant churn of GUIs, and be more accessible than CLIs. This is possible to build for power users, but it can also be made approachable for less technical users.
> I fail to see why any of these features couldn't be implemented within the design constraints of the Windows 9X/2000 design language.
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?
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?
When I think of Win2k, I think of the overall simplicity. This is mostly due to nostalgia than for any practical reasons. 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.
unknown|1 day ago
[deleted]