Ten months ago, GNOME 3 was released. Since then, there has been a steady murmur of complaints, mostly about a design that forces all users to work in the same way. And what have GNOME developers learned from the experience?
Judging from Allan Day’s recent blog entry, “A New Approach to GNOME Application Design,” absolutely nothing.
All the complaints, all the extensions to revert to GNOME 2’s behavior, all the interest in Linux Mint’s Cinnamon, which recreates GNOME 2 on top of GNOME 3, and in planning new core applications, GNOME developers continue exactly as they began. They show no recognition that not all users think the way they do.
It’s a persistence that’s so unyielding and shows such little ability to learn that it borders on the perverse.
Day, who is a GNOME designer, makes the project’s position very clear when he begins by saying “We want GNOME applications to be throughly modern, and we want them to be attractive and a delight to use,” emphasizing appearance and perhaps a preoccupation with being as cool as everyone else, and ignoring functionality altogether.
Then he adds, “That means that we have to do application design differently to how we’ve done in the past” — a conclusion that by no means follows, even if you accept his basic premise.
Anyway, who delights in a new interface for more than the first few seconds of viewing it? Most people are more concerned with whether it allows them to get their work done in the way they prefer.
Yet, while users are complaining about GNOME’s basic design, Day talks about “evolving” a new approach based on that basic design, and — perhaps flippantly — of how some designs “have come to have an increasingly important place in our hearts.”
In other words, if much is being done to make the basic design more generally acceptable, it doesn’t rate a mention. To all appearances, GNOME is continuing as it has begun — in fact, Day talks about solidifying the approach GNOME has chosen by writing a new version of the project’s Human Interface Guidelines.
Meanwhile, you can see details of GNOME’s approach in the rest of Day’s blog.
Cures Worse Than the Diseases
Before Windows 95, users wanted the ability to display more than one window at a time. Now, however, Day suggests that “displaying multiple windows at the same time means that screen space isn’t used efficiently, and it means that you don’t get a focused view of what you are interested in.” Seventeen years of interface development, and it turns out that DOS and Windows 3.1 had the right idea after all?
In fact, multiple windows serve all sorts of purposes. They allow users to drag and drop files between open directory windows, or to copy and paste. They allow users to consult one application while working in another, whether you are reading a main page with a terminal open, or (as I am doing now), writing in one window while consulting a page open in another. The mistake that Day makes is assuming that, because you are focused on one window, you are uninterested in other ones.
Day is more to the point when he notes that managing open windows can be troublesome. However, a simple solution for that is a configurable window manager that positions windows better, or at least offers a better view of what is open, the way that GNOME 3’s overview does. Maximizing all but small apps like calculators seems a solution that causes more problems than it solves. Especially when Day adds that title bars will be eliminated as unnecessary, their content moved to the panel, where they are divorced from the window.
The same is true within an application, according to Day: “breaking up an interface into different views makes it more efficient and more pleasurable to use” — although how or why that should be so, he doesn’t explain. In effect, what he proposes is to make what is a necessity on a mobile device the norm on desktop interfaces as well.
As an example, Day shows a screen shot for one view of the GNOME 3 Music app. He argues that users are better if they have to “travel through the application to the functionality that you want, rather than having it presented to you all the time.”
Never mind that shuffling through limited views of an application is even a better way to get lost than sorting out multiple open windows. Unless you are familiar with the app, you are just as likely to start down the wrong trail to the view you want as the right one.
For that matter, even when you know the app, a careless selection can cause momentary confusion. You only have to look at the Amarok music player, with its all-inclusive approach to see that having all functionality available at all times is more efficient than only having a sub-set of functionality visible. In an all-inclusive app like Amarok, you can always close or resize a pane if you want to ignore it, whereas in a limited view, you are more likely to be unsure of where you can go next.
Day also criticizes panels, or “primary toolbars.” Where the GNOME 2 panel was “a mixed bag, containing a variety of things that might or might not be useful to you at any given time” and suffered from a “lack of consistency” and “lacked visual elegance,” he characterizes GNOME 3 panels as containing “only a few elements,” and being “much more consistent across applications.”
Few can argue with his descriptions. However, the point Day fails to mention is that GNOME 2 panels were genuinely useful, and could be customized for each user. Moreover, by radically simplifying the GNOME 3 panel, the project has destroyed at a stroke one of its supporting eco-system of functionality, although a few like Tomboy live on, less accessibly, in the menu.
All these three design decisions share the assumption that simplicity is always desirable, and how an interface looks is more important than its functionality. To many users, I suspect, this is a false dichotomy. After all, why can’t you have functionality and elegance in the same design? But, unlike Day and the other GNOME designers, most users, to judge from their complaints, would rather have functionality than elegance, if they can’t have both.
What surprises me is that, after all the hints and manifestos, GNOME designers seem unaware of this basic preference.
Ears Wide Shut
Not all GNOME’s plans for core applications are as out of touch as these ones. The priorities for a GNOME 3 web browser include such functionality as writing web pages to PDF, and making the reopening of a closed page easy.
Moreover, the plans call for a redesigned email client to replace the antiquated, non-evolving Evolution, while proposed new apps include a backup app and an ebook manager. Such plans conform to what people are actually doing with their computers, and many seem long overdue.
Similarly, Day’s description of plans for “Selections and Contextual Actions” — that is, the appearance of an appropriate toolbar when a box is checked — and for increased availability of search functionality from the desktop are ideas to which few can find any objections.
Yet these seem the exceptions among the plans described by Day. For the most part, GNOME designers continue to work in isolation from feedback, convinced that their approach is the right one for everyone.
In fact, GNOME appears so little interested in feedback that Day simply turned off comments after 115 had been posted. The comments were not particularly hostile — some were favorable and almost all of them polite and informed — but the comments were cut off, despite the obvious eagerness for discussion.
From this reaction, I have to conclude that the problem isn’t that GNOME doesn’t know how users are reacting. Instead, the problem seems to be that GNOME doesn’t want to know.