On the topic of GNOME

Introduction

Every few years, I find myself compelled - almost ritualistically - to revisit the landscape of modern Linux desktop environments. This is not driven by nostalgia, but by a genuine curiosity about the evolution of usability, human–computer interaction, and design philosophy in open-source ecosystems. As someone who has spent decades working with UNIX-like systems, I approach these explorations with both technical familiarity and a critical eye.

My most recent excursion led me to a fresh installation of Fedora 44 running GNOME under Wayland on a ThinkPad T490s - a setup that, on paper, represents one of the most polished and forward-looking Linux desktop experiences available today. What I encountered, however, was not innovation in the service of clarity, but rather a series of catastrophic design decisions that prioritize abstraction over usability in ways that are, frankly, bewildering.

Application Naming

The first and most immediately jarring observation was GNOME’s insistence on generic application naming. At first glance, this may seem like a harmless - or even user-friendly - choice. After all, labels like "Files", "Document Viewer", or "Image Viewer" appear descriptive and approachable at first sight. But this design breaks down rapidly under even minimal scrutiny.

The fundamental issue lies in the complete absence of application identity. These programs do, in fact, have proper names - "Files" is Nautilus, "Document Viewer" is Evince, and the so-called "Audio Player" is actually Decibels. Yet nowhere in the primary interface is this information readily visible. The only reliable way to uncover it is through indirect means, such as navigating into a secondary menu and selecting "Website," where - if you’re lucky - the URL might reveal the underlying name. For instance, see Audio Player. The entire (!) page does not mention the name "Decibels" here, at all, except for a tag bubble on the very bottom of the page. GNOME developers, are you ok?

From a usability engineering perspective, this is deeply problematic. According to established principles in cognitive psychology, particularly those concerning recognition vs. recall, interfaces should minimize the user’s need to infer or remember hidden information. By not having these application identities at all, GNOME violates these principles entirely, effectively massively increasing cognitive load and reducing transparency.

But even MORE puzzling to me is the fact that some applications’ official websites reinforce this ambiguity. In the case of Decibels, the application name is scarcely mentioned - if at all - on its own homepage. This creates a disjointed experience where neither the interface nor the supporting documentation provides a coherent sense of identity.

Why this is simply needlessly confusing

Consider a practical scenario: a user installs two music players. One supports streaming services like Spotify or Tidal, while the other is designed for local media playback. In GNOME’s application grid, both might appear under similarly generic names like "Music Player" or "Audio Player."

Without distinct identifiers, users are forced into a trial-and-error workflow - launching each application to determine its function. This is not merely inconvenient; it is a violation of affordance theory, which emphasizes that the design of an object should suggest its usage. When multiple tools present identical affordances but different capabilities, the system fails to communicate effectively.

This ambiguity also hampers troubleshooting, documentation lookup, and community support. If a user encounters a bug in "Image Viewer," how are they supposed to search for solutions when the actual application name (e.g., Eye of GNOME, a.k.a. "eog") is hidden?

Over-abstraction and over-simplification

Examining these application interfaces further only deepens the confusion more. The window itself, the header bar, the menus, and the text of the application window, offer no indication whatsoever of the program’s real name. From a software engineering standpoint, this is an extreme example of over-abstraction, where the system attempts to generalize user experience at the expense of specificity.

Modern UI/UX design often emphasizes minimalism, but minimalism must not come at the cost of hiding necessary information. The subtle cues that guide users toward understanding a system. By stripping away identifiers, GNOME effectively removes these cues, leaving users disoriented.

There is also a broader philosophical issue at play. GNOME appears to prioritize a kind of "appliance computing" model, where applications are treated as interchangeable tools rather than distinct pieces of software. While this may appeal to casual users in theory, in practice it undermines the flexibility and transparency that have traditionally defined the Linux ecosystem.

The shell extensions horror

Attempting to adapt GNOME into a more functional and personalized environment reveals another layer of complexity: its heavy reliance on shell extensions.

In my recent setup, I found myself installing no fewer than 18 extensions just to achieve what I would consider baseline usability. These included tools for basic window management, visual customization, performance tuning, and system monitoring.
This raises an important question: if such functionality is widely desired, why is it not part of the default experience?

From a systems design perspective, this approach is pretty much a nightmare, as it introduces several risks:

1) Fragility: Extensions (especially specific combinations of those) might break with GNOME updates due to API changes.
2) Inconsistency: Each extension is developed independently, leading to uneven quality and integration.
3) Performance overhead, combination side-effects: Stacking multiple extensions can degrade responsiveness, introduce un-wanted (and difficult-to-debug) behaviour at will, and increase resource usage.

Moreover, the default omission of standard window controls - such as minimize and maximize buttons - reflects a deliberate design philosophy that prioritizes simplicity over user control. While this may align with certain minimalist ideals, it massively clashes with established user expectations and decades of desktop computing conventions. Oh, yes, you heard that right, there is no minimize or maximize button in GNOME by default - you need to install a so called "shell extension" for that.

Broader implications

What makes this situation somewhat mindboggling is the fact that GNOME is often described as the de-facto flagship desktop environment of the Linux world. Its design choices influence distributions, developers, and new users alike.

Yet the current trajectory seems to diverge from principles of user-centered design, where systems are built around real-world usage patterns and mental models. Instead, GNOME appears to follow a top-down philosophy, where design decisions are imposed with the expectation that users will adapt.

This is not inherently wrong - but it does come with trade-offs. And for many users, especially those seeking transparency, configurability, and clarity, those trade-offs are significant.

Conclusions

After this latest evaluation, I find it even MORE difficult to recommend GNOME to others as I did before - particularly to users who value understanding and control over their computing environment. The combination of obscured application identities, reliance on extensions, and unconventional design choices creates an experience that is, at best, opaque and, at worst, actively frustrating.

For those seeking a more traditional and feature-rich desktop environment, alternatives like KDE Plasma continue to offer a more balanced approach - combining modern aesthetics with configurability with clear system feedback. Admittedly, on the Wayland side, the options for full-blown desktop environments is a bit limited right now, but the KDE devs have done quite a bit of homework to make Plasma work mindblowingly smooth and stable on Wayland, so I definitely recommend checking it out.

Perhaps GNOME’s design direction will evolve in the coming years at some point, but in retrospective, I must conclude that I'm not happy about the last 20 years of GNOME development, at all. Open-source ecosystems are, after all, dynamic and responsive to feedback. But for now, my path is clear: I will move on, and I will continue to hope that future iterations reconsider the balance between simplicity and usability again. The current eco-system is, at best, an utter mess.

GNOME doesn't "accidentally suck". It sucks by design. Because it optimizes for a rigid philosophy of over-simplification over flexibility.

Links

John Woltman - I don't care for GNOME
Adrian Vovk - Introducing stronger dependencies on systemd (blogs.gnome.org)
Felipe Contreras - GNOME 3 sucks (Pt. 1)
Felipe Contreras - One decade later, GNOME still sucks (Pt. 2)
HN - GNOME is a complete shitshow
GNOME Linux - a complete disaster
HN - why is GNOME so incredibly, insanely, bad?
Arch Linux Desktop Environments statistics


This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.