Old codger yells at software, part the latest.

Spring 2024

The story so far

A great amount of my writing on this site revolves around complaining about modern user interface design. Some people agree with me, some don't. Most probably don't care at all. That's fine. What I find interesting is that many (but not all!) people who disagree either present extremely specific non-argument nitpicks like "Something in Windows 3.1 was bad, too!" and ignores the big questions posed, such as whether it's actually a good idea shoving everything into a single hamburger menu, or if mixing touch and desktop paradigms wildly between and sometimes within programs is actually beneficial to end users. Others - despite my efforts to the contrary - use sweeping dismissals of the kind "you just don't like flat design." That's true - I don't like flat design, but many of my arguments have nothing whatsoever to do with aesthetics.

Well, that's what writing on the net is like. But I shall not despair, nor shall I be silenced! Allow me, for a few moments, to focus on a very detailed example that's got nothing to do with flatness, but rather with how to access core program functionality.

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.

Gnome sweet Gnome

For full transparency: It's no secret that I don't particularly enjoy the Gnome desktop. When I installed Ubuntu on my work laptop about a year ago, I wanted to see how long I could get by using Gnome. The answer was "about five minutes". When I decided to switch the default desktop background image to a solid color, I discovered that the only available option in the configuration tool was to select images. Sure, I could google a solution to the problem, which involved a pretty lengthy command line incantation, but depriving the user of a simple option to select a background color was more than my patience could handle.

I've written some pretty harsh critique about Gnome before, but I feel this is a project that does deserve critique. It's not just the default desktop environment in most major Linux distributions, it's also a project that's very vocal - opinionated, as the saying goes - about how to do things. A few examples might be in order:

• "Our software is built to be usable by everyone. We care deeply about user experience."
• "Software should be structurally and aesthetically elegant."
• "People's attention is precious. We pride ourselves in being distraction free."
• "The 'traditional desktop' is dead, and it's not coming back. (...) Instead of trying to bring back old concepts like menu bars or status icons, invent something better from first principles."

Gnome Files

Bold words, indeed! Let's see how they fare in the real world. Recently, in another sudden fit of open-mindedness, I decided to perform some light file organizing using Gnome Files. This isn't just any old Gnome application: the file manager is a central point of any desktop environment, along with window management and a decent set of UI widgets. Surely the Gnome project will have spent a good amount of time and effort on making Gnome Files a flagship application, showcasing their superior UI philosophy from its absolutely best side.

First impressions

Well, it certainly doesn't look too shabby. Clean, elegant, even minimalist. A calming appearance. Sure, it's a flat design, but I can clearly make out the different UI elements and get a good idea of what's clickable or not - or so I'm led to believe. There's just one problem - I'd prefer a list view instead of the large icons. How do I change it?

Hunting for the list view

Note the many distinct-looking icons in the toolbar. From left to right we have three stacked dots, three stacked dots and lines, and three stacked lines. Pretty obvious what they're all about, right? Anyways, this dropdown menu with the tooltip text "View Options" is probably a good start.

Alas, that menu only shows various sort options. This makes me think "Sort Options" would have been a better tooltip text. Then again, I'm not much for reinventing everything from first principles, so what do I know?

What's in the "Main Menu", then? Nothing that has to do with a list view, I'm afraid - though there are options here I'd expect to find in a menu called "View Options", such as Icon Size and Show Hidden Files.

There's a "Folder Menu" too, but that doesn't help me much, either.

Ah! There it is! The "View Options" dropdown is actually a split button, with a toggle part and a dropdown part. That's sort of fine I guess, but I'd expect the toggle options to also be listed in the dropdown portion of the widget. If not, why group them together like this? Why not split them into two clearly separate buttons? This honestly took me a good while to figure out - and I'd like to think I'm neither extremely stupid nor particularly inexperienced with computers.

Yes, it really was this hard for me to find the list view toggle. 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. I was further confused when other actual view options were, in fact, only available in the "Main Menu". To me, this doesn't feel like "structural elegance". By now, my calm was replaced with frustration.

(Not) finding help

I actually resorted to the built-in help function when looking for a way to switch to the list view. I searched for "list view", but didn't find anything immediately helpful. Even though I brought up the help window using Gnome Files' menu option for this, search results were listed for many other applications. Search result number nine, "Browse files and folders", was at least related to Gnome Files - but appeared after things like "Manage volumes and partitions" and "Edit contact details". The only entry I could find while manually browsing the help that mentioned "List View" was about what I could do when the list view had already been selected. I tried my best, but couldn't find any information on how to actually activate it.

Tipping point

While browsing the help, I noticed something else: frivolous tooltips. Tooltips are a great invention and can be very useful, but a lot of programs nowadays seem to just sprinkle them everywhere, with no particular thought as to whether they're actually meaningful or not. Gnome Help is one such case.

Here, I'm just resting my mouse pointer somewhere, as one might do when reading through a bunch of clickable items. Up pops a tooltip that not only completely covers the title of the next item, it also has the exact same text as the header of the item it belongs to. Why? Perhaps it's part of the "distraction free experience".

The same goes for the left hand side toolbar in Gnome Files. Yes, I assumed that "Recent" and "Starred" here, in the context of Gnome Files, are about recent and starred files and not something else. Granted, some of these tooltips show a full path, but honestly - if I've added something to this bar, I probably know what it is and where it's located. A tooltip would be useful if two items have the same name - but why show them everywhere else? To me, at least, it's very annoying that I can't rest my mouse pointer somewhere without having pointless information popping up that covers what I'm really interested in looking at. In fact, I'd say this behavior teaches me as a user that tooltips are pointless and irritating, making me instinctively ignore them even when they might be useful.

Navigation

Navigating using the Gnome Files UI is fine, for the most part. I'm unused to the button locations, and 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. Clicking on a directory in the location bar will take you there, but it's much easier to misclick and thus less convenient.

When searching for a "parent directory" button, I noticed a few strange behaviors. Clicking on directory names in the location bar is a nice feature. However, many file managers will also let the user directly enter a path here. In fact, it looks a lot like a text box (such as the Folder name widget in the screenshot above) but no matter where I click in it, I cannot activate a normal editing mode.

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. It looks like a text box, and it is indeed a text box - not just all the time. Maybe I'm not supposed to think of it as a text box, but the design language here isn't exactly super clear on what kind of input I'm dealing with, so I'm working from assumptions based on having used computers and GUI file managers for 36 years - which is something developers and designers should take into account when building interfaces.

Having no mouse-driven way of activating a fairly common UI task feels like a step back in discoverability. In fact, I thought the feature hadn't been implemented until I googled it. To be fair, it is listed in the Keyboard Shortcuts window, but call me old school for expecting GUI elements to be accessible with the mouse.

A thousand cuts

The shortcuts list is three pages long. It's got a search function, which is nice - if you know what you're looking for. For example, Gnome Help calls the location bar "the path bar", but searching for "path" gives zero results. If you don't know what to search for, there's no table of contents or other way of quickly viewing the various categories of shortcuts. You have to examine each of the pages and hope to find what you're looking for.

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. Inconsistent and confusing.

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.

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?

In short, this feels like an afterthought rather than a revolutionary new, efficient approach to operating a GUI.

Top o' the window

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.

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.

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.

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.

You can, however, middle click on any directory name - including the current directory - to open it in a new tab. Which is also one of the options available in the context menu.

Scrollolololo

Gnome Files, or rather GTK 4, uses hidden scroll bars. I'm using what I assume to be the default settings and the default GTK 4 theme as supplied by Debian, because I haven't changed anything (except the font). I personally don't like hidden scroll bars, because hiding the scroll bar also hides information not only about what I can do with the GUI itself, but also about where I'm currently positioned in E.G. a file listing or text document.

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.

Summary

The Gnome Files UI feels haphazard, incoherent and sometimes even dangerous:

• Menu names and their contents are confusing, with "View Options" actually being sort options. Actual view options are instead sprinkled across other parts of the UI.
• Keyboard shortcuts aren't consistently listed in menus.
• Some common features are only accessible - and discoverable - through keyboard shortcuts. The keyboard shortcuts listing is non-interactive, modal, and incurs a substantial mental context switch.
• Widgets don't behave quite as you'd expect when compared to other, similar, modern applications.
• Even within the closed world of Gnome Files, widget looks can be deceptive.
• Tooltips are either misleading, or comically uninformative and thus annoyingly distracting.
• Moving windows by clicking on icons that already have a specific function feels unintuitive and introduces an unnecessary risk of misclicking.
• To activate a window without also activating a program feature, time must be spent searching for a non-interactive area of the UI.
• Context-clicking in the top part of the window gives spurious and unpredictable results.
• In the default theme, scroll bars jump away from their original position when you point at them.
• Searching and then browsing the built-in help for "list view" didn't actually help me find out how to enable the list view. The only page I could find that contains the exact phrase appears as #15 among the search results.
• Nomenclature differs between the help texts and the actual GUI.

The many various inconsistencies listed above makes it hard for me as a user to construct mental models and patterns for making efficient and reliable assumptions about the UI. I often have to double check things and look for features in the keyboard shortcuts window, since I don't know if they've been deigned a menu entry or toolbar icon. Ambiguous mouse behavior introduces unnecessary cognitive load, making it hard to build confidence even when performing basic tasks.

Conclusion

Designing user interfaces is hard. Writing software is hard. Designing great interfaces and writing great software is even harder. No matter how hard you try, you can't please everyone. Functionally, Gnome Files lets me do file management. I could, if I had no other options, probably get used to its UI idiosyncrasies. But as I've hopefully demonstrated above, there are many things about Gnome Files - a central part of the Gnome desktop - that can be considered objectively bad from a UI design standpoint.

This doesn't mean that there aren't other bad programs or that previous design paradigms were perfection incarnate. Neither does it mean that every little bit of Gnome Files is worthless, or that Gnome and Gnome Files are unique in employing these patters (but that's hardly a comfort). But shouldn't this new design paradigm produce something better? Isn't that its whole raison d'être? After ten-fifteen years of the old mainstream desktop paradigm, we arrived at Windows 95 - which wasn't perfect, but pretty damn consistent, predictable and reliable. After ten-fifteen years of this new paradigm, we instead have constant redesigns and reworkings of solutions to problems we already know how to solve.

Examining these new solutions suggests to me that maybe proponents of the new UI paradigm should be a bit more humble in their approach to tried and tested patterns. Nearly all of the criticisms examined above already have well known solutions that have been honed for a period of decades. For example: Having actual window title bars, consistently listing keyboard shortcuts in menus, consistently categorizing menus and options, and using a richer design language. Old doesn't automatically mean worse, just as new doesn't automatically mean better.

My personal conclusion is that if this is the result of inventing "something better from first principles" to create "structurally elegant" and "distraction free" software "usable by everyone", I guess I'm just not "everyone". And that would be fine, if it wasn't for the fact that these days, I'm often left with no choice but using programs with UI:s like these.