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.
> There is definitely places to improve, though, but the style of writing matters.
And which kind of "style of writing" would tell them that their GUI sucks big time and they should not reinvent the wheel and should not copy Microsoft and Apple ?
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.
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 think a lot of this disagreement could be cleared up by using “hallway usability testing”. The test is simple: Grab the next 6-8 people who walk past your desk and say “hey do you have 5 minutes to test the usability of something?”. Ask them to do a series of actions with the application (change to a list view, go up one level in the directory hierarchy, etc). Take note of what they find easy and what they struggle to do.
I suspect that I would struggle in many of the same points as the author. I suspect many other people would as well.
If you think this UI is good, do you want to make an objective claim? Do you think 8/8 people who walk past would figure out that split drop down button? It is very easy to test.
Yes this stuff is subjective. But rules and principles fall out pretty naturally from just asking people to try out your interfaces.
Please get to know how comprehensively the heuristics have been condensed into that short list from a much longer list of ovservations and decades of research.
To take into account the remaining subjectivity, there is usability testing. Most findings start to repeat themselves after 5 representative test subjects. But if you don’t test at all, you’re just shooting in the dark, as may have been with this gnome design.
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.