It's worth mentioning that I agree that the modern design paradigm probably is friendly to beginner users in many ways. But at some point, people stop being beginners. People who use computers several hours per day, performing a wide variety of tasks in many different programs, should also be taken in to account when designing software. As such, my critique comes from the point of what's usually called a "power user". It's also worth considering that the more an interface hides, the less it offers by way of opportunities for a user to grow and learn.
After that I find it a bit rich to complain that one has to use a keyboard shortcut (even as others have said that's even incorrect), especially for a function that requires using the keyboard anyway.
I also find the arguments about no up button and the list view unconvincing. The list button was immediately obvious to me from the screenshot (and I don't use gnome or any filemanager) and I actually appreciate a window that does not put lost of buttons that present duplicate functionality everywhere (and it's harder to hit? What argument is that, by his own admission he's been using computers for 35 years, but can't use a mouse to hit a path?).
This really just reads like one of the typical rants where someone become somewhat proficient with some system, now considers themselves a "power user" and expects everything else to work exactly the same. The same people often complain that terminals break with "standard shortcuts" because they can't copy with ctrl-C...
The basics: you are not your users. Just because it’s easy for you, doesn’t mean it’s easy for others. That is the entire basis of usability work. I cannot believe how resistant the tech community, like above, is to the very basics of human cognition.
It’s your comment that’s the rant. OP has actual data from decades of research they are applying.
Quoting myself: https://news.ycombinator.com/item?id=41303387
What data does he have? OP wrote a basic opinion-piece on what they dislike. It’s just as valuable as the parent commenter’s opinion, so we can only say that one user found some feature hard to find. There is no ultimate design, and striving for 100% of users knowing everything immediately is just unrealistic.
If we are at opinions, I really dislike this absolutely tone-deaf attacking of GNOME that is always happening under these threads. There is criticism, and there is blind hate. There is definitely places to improve, though, but the style of writing matters.
This should help you trace the argumentation to cited research that is certainly not ”tone deaf”:
https://www.nngroup.com/articles/ten-usability-heuristics/
1. *Consistency and Standards* Claim: "The 'View Options' dropdown didn't contain view options, but rather sort options, and I didn't realize it was a split button with two completely different functions."
Violation: This breaks Consistency and Standards. The user expects consistent terminology and functionality, but the dropdown name doesn't match what it actually does, leading to confusion.
2. *Visibility of System Status* Claim: "Hidden scroll bars... hides information not only about what I can do with the GUI itself, but also about where I'm currently positioned."
Violation: Violates Visibility of System Status. Hidden scrollbars prevent the user from knowing their position in the list or file system, making it difficult to navigate.
3. *User Control and Freedom* Claim: "I miss a button for going one level up, to the parent directory. There are buttons for going back and forward in the navigation history, but that's not the same thing."
Violation: Violates User Control and Freedom. Not having an obvious way to go up a directory removes essential control, forcing users to rely on less intuitive navigation methods.
4. *Recognition Rather Than Recall* Claim: "It seems this editing mode can only be activated using a keyboard shortcut, Ctrl-L, which isn’t immediately apparent—or, to be frank, very logical."
Violation: Violates Recognition Rather than Recall. The user should not need to remember specific keyboard shortcuts to access common functionality. The UI should present these options visibly.
5. *Error Prevention* Claim: "Moving windows by clicking on icons that already have a specific function feels unintuitive and introduces an unnecessary risk of misclicking."
Violation: Violates Error Prevention. The user can easily move the window unintentionally when trying to interact with icons, which increases the chance of errors.
6. *Help and Documentation*
Claim: "Searching and then browsing the built-in help for 'list view' didn’t actually help me find out how to enable the list view."
Violation: Violates Help and Documentation. The help system fails to guide users to solutions for basic tasks, which defeats its purpose.
7. *Aesthetic and Minimalist Design* Claim: "Tooltips are either misleading, or comically uninformative and thus annoyingly distracting."
Violation: Violates Aesthetic and Minimalist Design. Tooltips should convey useful information without being intrusive. Redundant and irrelevant tooltips clutter the interface.
8. *Flexibility and Efficiency of Use*
Claim: "In Gnome Files, we’re instead given a handful of features scattered across the UI. Hidden features (accessible solely through keyboard shortcuts) can only be learned by browsing what is best described as a non-interactive menu."
Violation: Violates Flexibility and Efficiency of Use. Hidden shortcuts reduce the efficiency for experienced users and make the interface less discoverable.
9. *Match Between System and the Real World* Claim: "Menu names and their contents are confusing, with 'View Options' actually being sort options."
Violation: Violates Match Between System and the Real World. The system should use terminology and design elements that align with user expectations, but here the names contradict their function.
10. *Help Users Recognize, Diagnose, and Recover from Errors* Claim: "Context-clicking in the top part of the window gives spurious and unpredictable results."
Violation: Violates Help Users Recognize, Diagnose, and Recover from Errors. Inconsistent behavior in the context-click menus makes it difficult for users to understand or recover from unexpected results.
Something like this would have been a better post than the linked one, but even this is not necessarily objective on each count - and design has a fundamentally subjective, human element based on our collective experience with every kind of interface, ever, which is affected by experience/culture, everything.
E.g. in your list: there is no “dropdown name”, it’s a misidentified element by the post writer. Add to it that he is not using standard configuration, which is just not how any “test” should be conducted. Like, you are not testing cars with flat tires either.
I enjoy GNOME and would prefer a gtk4/libadwaita based UI for e.g. FreeCAD. I brought this up as a counter example to the frequent negativity in GNOME related discussions.
One problem I see of "usability professionals" here and elsewhere is how arguments go little beyond:
1. "you are not the users" - certainly when talking about many apps like a file explorer any user is a user - not all users.
2. "Disheartened by tech community dismissal of basic human cognition" and "decades of research" without actually citing and ideally elaborating on research that many times is targetting very narrow scopes.
1. Users have plenty of individual characteristics. If even ordinarily capable user’s can’t deduce what button does what, forget people with disbilities. It’s obvious you need to usability test this stuff. Gnome has neglected their basic duties.
https://www.nngroup.com/articles/usability-testing-101/
2. Human-Computer Interaction is a scientific field within Computer Science, and this is stuff from any 101 course. Do we really need to cite belief in gravity each time just because self-appointed ”developers” haven’t done the work of learning the basics?
Start here: https://www.nngroup.com/articles/ten-usability-heuristics/
...and here is my missing point 3. "Citing Norman heuristics like gospel"
Thankyou. I’ve been using computers for 35 years (I grew up using xtree to navigate folders on DOS). It would never have occurred to me that both sides of that view options dropdown do different things. Perhaps it’s intuitive for others, but I’ve never seen that before in my life.
I’m increasingly of the opinion that I hate almost all novel interaction patterns in user interfaces. UI components and flows should stick as close to common patterns / system defaults as possible - and no, your app, whatever it is, is not an exception
I would have clicked the down arrow that’s attached to the list icon to get the list options.
It wouldn’t even occur to me that the icon could be a toggle (both because it is not rendered as one, and because I’d expect more than two view options).
It does have a hover effect though. Design is always about discoverability. If you have seen something similar, you will try to apply that solution. If you haven’t, you try different stuff and see what happens.
How do you find out what that keyboard shortcut is? I only found out when reading a similar article as the OP many years ago that complained about the removal of the textbox.
Otherwise I never would've known it is possible to activate the path textbox with a keyboard shortcut.
A UI needs to be both easy to use and discoverable. If "power users" have trouble discovering where the features they need are, why do we think the rest of the UI is easy to use/discoverable for everyone else?
(Although TBH I rarely use UI, and normally just use the terminal, except when upgrading the firmware of my keyboard, in which case I use Jade's file manager).
I only know that shortcut because I use in the browser already.
It does break with standard shortcuts. And worse, there's absolutely no consistency between terminal applications on which shortcuts to use. It's a mess, and complaints are warrented.
Ctrl-C sending a SIGINT to the program running in the terminal is the standard shortcut. Woe to the terminal arrogant enough to assume their precious copy/paste is more important.
Now, Super-C vs Ctrl-Shift-C (across the UI), we can argue about.
You don't need a keyboard to use a text field. You could be pasting a path.
Or using some assistive technology like dictation. Or be using a phone where there's a way to type but no way to press ctrl (althouth the UI on a phone should be judged along other lines).
It was immediately obvious to the author as well -- it was the first thing they clicked on! Or rather, they clicked in the little arrow next to it, that looked like it was part of the same button. When it brought up something entirely unrelated, they very reasonably assumed that it wasn't what they were looking for.