Thougts on "GNOME Files: a detailed examination"

* First off, I'm going to brush off the snarky stuff as a satire that's meant for the entertainment of the readers and ignore it myself.

* For the list/grid switcher, I don't personally think the list/grid view switcher is hard to spot, it has notable and abrupt line between the drop down and the button with the icon.  Also, the two parts get shaded differently when you click or hover on them, and the tooltip disappears and changes when you move from one to the other. I don't recall many seeing anyone complaining about the discoverability of that button in general. Either way, this my anecdote vs. the author's, and would need a user usability study to say for certain.

* For the help guide and documentation part, yes. It is very under-maintained and require substantial care to be on an acceptable level to me. As in many OS projects, everyone works on what they want and that usually means things like help docs, accessibility, and unit testing take the backseat.

* I see your point for the unnecessary/misleading tool-tips. For the tool-tip for the drop down, it likely that it had more controls in it before they were moved but someone forgot to change it to reflect it what it contains more accurately. Coincidentally, the zoom controls were just moved to that menu in the development version so it hopefully will be less misleading moving forward.
For the starred and recent tool-tips, there's an issue or a comment on it from designers somewhere in the issue tracker, but no concrete idea was proposed so far. For the tool-tips in the help docs, it seems to me that it is leftover from a web browser behavior, and should be revised to be more helpful in the context of help pages.

* I very much agree with the click-to-edit path bar comment, and the other contributors also did! So they (very) recently changed it to be so. I didn't dig deep into the history of why this was not done before, but I can remember seeing minor complaints about overlapping with the path bar buttons in long paths.

*
> Upon reaching page three, I learned that there's even a keyboard shortcut for opening the keyboard shortcuts window - but unlike some other shortcuts, it's not shown next to its corresponding GUI entry in the Main Menu.

The shortcuts are visible in the main menu for all actions except Zoom and the About dialog on the latest version, 46, and also on 44 that I just pulled up to verify. Perhaps the author is experiencing a bug?

*
>  I'm not sure why, but the Gnome project has a strong aversion to menu bars. The keyboard shortcuts window may be "reinventing from first principles", but to me this invention looks like a flawed reinterpretation of a traditional menu bar. A menu bar provides a way of exposing categorized program features in a familiar and always-visible UI, lists their keyboard shortcuts in a consistent manner and it lets the user interact with the option immediately upon finding it.

But also duplicates almost all of the functionality that already exist elsewhere and takes permanent amount of space from the window. The vast majority of the functionality can be done/initiated with 1-2 mouse clicks anyway, with a handful of needing 3 clicks.
FWIW, I just opened a new Manjaro KDE installtion in a VM, and it seems like Dolphin 24.05, a recent version, doesn't have the menu bar visible by default either. It also seems according to this link, neither did Plamsa 5 had a menu bar by default: https://docs.kde.org/stable5/en/dolphin/dolphin/using-dolphin.html.

> In Gnome Files, we're instead given a handful of features scattered across the UI. Hidden features (accessible solely through keyboard shorcuts) can only be learned by browsing what is best described as a non-interactive menu of the kind you'd find printed on paper in a restaurant.
> This browsing brings a considerable context switch because the window is modal, so you can't keep it open while experimenting. You have to find what you're looking for, note the keyboard shortcut, close the shortcuts window, and then invoke the feature. Keyboard shortcuts aren't bad, but in a mouse driven environment, having no way of finding and invoking features through the GUI is limiting and confusing. And why force users to memorize a shortcut for something they might only do occasionally?

There are only 4 features out of that 3 page shortcut dialog that can't be accessed or reproduced graphically: Creating link from copied file, creating link from selected file, inverse selection, select files from current view based on a glob pattern (different from searching). I don't see any need to waste space on these features since they are rarely used by a typical user.

*
> When trying to activate path editing using the mouse, my vigorous clicking just made the Gnome Files window move around. Since the window has no real title bar, it must be moved by clicking-and-dragging in the top part of the window. This is also where the toolbar resides, which means click-dragging on UI controls that already have a completely different function. You can use the search function by clicking on the search icon - but you can also click the search icon and start dragging the window around.

I don't seen any issue with this pattern by itself. Clicking and dragging buttons does not activate them in many desktop GUIs, even in touch-focused ones. If anything, this is a great thing to take advantage of. Moreover, this is a standard feature on most GNOME apps, so learning this isn't wasteful.

> There's a location history available by either context-clicking or performing a "long click" on the back- and forward buttons, but nothing about the buttons indicate this (and the feature doesn't seem to have a keyboard shortcut), which introduces further ambiguity regarding the click-drag behavior. Confusingly, performing a long click on other items doesn't bring up their context menu.

I suppose this list was meant to replicate the behavior of web browser. I personally never used this list and don't even remember clicking on it by accident. Usually the pathbar parent buttons, history buttons themselves, and the sidebar are well enough. Perhaps we should just restrict to long touch screen presses and mouse right clicks if it's not used that often.

> Activating windows with the mouse is even worse: If I want to bring a window to the front of the stack, I have to search for a non-clickable area, lest I activate the search feature, skip upwards in the path, switch from list view back to icon view or accidentally access some other program feature. This introduces extreme ambiguity that makes me as a user feel insecure and uncomfortable: a simple mouse slip can give the most surprising results. The user is conditioned to be mindful of this, which increases the cognitive load for very simple and common window operations.

In my personal experience, this doesn't matter most of the time since both of the following has to be true for it to be of substantial value:
- Alt-Tab is not suitable to switch to this window for some reason.
- Window is floating (i.e. not snapped or maximized)
- Happen to have the window obstructed by another window and only the header is currently unobstructed by another window (If the header is obstructed then it won't improve anything) OR You use single click to open option in the preferences, so clicking in the main content area is not an easy option.

It try it to experiment this with KDE, and I did find that in a typical setup, I would almost always go to click the content to focus a window, but it did indeed help for the the case described above.

> Another curious idiosyncrasy of forgoing window title bars is that right-clicking on for example the search icon actually brings up a window management menu, with options for closing, maximizing and minimizing the window. This pops up when right clicking anywhere in the top part of the window. Except when right clicking on a directory name in the location bar - that will instead bring up a completely different menu, with various directory actions. Except if you click on the current directory, which won't bring up a context menu. Except sometimes it does, but then it's the window actions menu. Which is also what happens if you miss the context-clickable area of another directory by just a pixel, even if the pointer is still inside the location bar.

I believe the last "Except" doesn't apply to the newest version since the non-button area is used to edit the path now. My opinion is that the generic window actions menu doesn't really matter since it's just does basic things like close, maximize/restore/ minimize. These are already very accessible with dragging and snapping, double clicking to maximize, keyboard shortcuts, etc. I personally never use it in a normal day.

*
> Moving the mouse about in Gnome Files reveals the scroll bar, as depicted in the first picture above. It's very small and very hard to see because of the low contrast, but it's there. But - Ah-hah! - the scroll bar is actually hidden in two steps! When moving the mouse pointer to it, it grows and becomes more visible, as in the second picture above. But when it does, it also moves the entire width of its original size to the left, meaning that my mouse pointer is now pointing at... nothing. Thanks, Gnomebama.

I'd agree that the scrollbar could use some contrast enhancement. I even noticed that it's worse contrast ratio than stock GTK4 demos (1.45:1 vs 2.23:1). Although, any users with reduced vision are better off with making it persistent in the accessibility settings, and potentially enabling the high contrast theme.
As for the movement comment, I'm not entirely sure why the author cares if the small and enlarged scroll bar don't overlap. All of the relevant area, including where the small scroll bar was, is still clickable and draggable as soon as the scroll bar get enlarged, so it hardly matters (Unless this is also a bug where being a pixel doesn't scroll or something?).