Nine Rules for Designing a Linux Desktop

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Recently, the Linux desktop has had some troubled years. Where once the news consisted largely of announcements of features, in recent years it has included debates about features and directions, declarations of forks, and resurrections and re-inventions of older designs.

The result of this activity has often been heated debate — to say the least — and, if user choice has increased, innovation has decreased.

The problem is that, with the exception of a few projects, the free software community is still learning to make user feedback part of the development process. Not long ago, the distinction between user and developer hardly existed in free software. And, even today, users making a suggestion are often told to write the code themselves.

True, Canonical does testing for Ubuntu’s Unity interface. However, to judge from comments on Mark Shuttleworth’s blog, it seems limited, and never seems to have included comparison of existing and proposed interface designs. Moreover, other projects seem to have done even less.

Exactly how usability testing can be integrated into the free software development process has no easy answer. However, one important aspect of the answer is more consideration of the audience and its context. Thinking of the audience is always important in software design, but on the Linux desktop, which has developed in semi-isolation, it is even more important than usual. What will suit Windows or OS X users might be too different for Linux users to accept easily.

Based on what I’ve observed over the last few years about what has and hasn’t been well received, here are nine suggestions about how to design a Linux desktop.

I don’t imagine for a moment that developers will leap to embrace them. If anything, sarcastic cracks about pundits and outsiders seem more likely. All the same, I present them in the hopes of starting discussion.

1) Don’t Invent Problems to Solve
2) Make All Functionality As Accessible As Possible
3) Extend Features, Don’t Remove Them
4) Give Users the Power to Choose Innovations
5) Be Aware of the Limits of Usability Principles
6) Allow Multiple Work Flows
7) Accommodate All Levels of Users
8) Design for the Medium
9) Allow for a High Degree of Configuration
A Plea for Context
RELATED NEWS AND ANALYSIS

1) Don’t Invent Problems to Solve

In all the hours I’ve spent listening to discussions about GNOME 3 and Unity, my greatest impression is how far apart developers and users are. Both these interfaces have been advertised as reducing “clutter” — a problem I’ve yet to hear large bodies of users complain about, no matter how thoroughly I do searches with a thesaurus in my hand.

Under these circumstances, user dissatisfaction shouldn’t be that surprising, should it? GNOME 3’s overview has a certain elegance, but, since users don’t worry about the problem it is trying to solve, not many are likely to appreciate it. That’s why Linux Mint’s Mint GNOME Shell Extensions (MGSE) allow users to ignore the overview, and its GNOME 2 re-creation Cinnamon does away with the overview completely. A feature designed to reduce clutter becomes clutter itself if you don’t want it.

2) Make All Functionality As Accessible As Possible

Asked to choose between a lack of clutter and easy access, most users will choose access every time. Panel applets and desktop application launchers are not elegant, but most users prefer them over a clean desktop. Average users are too busy getting work done to sit back and admire the beauty of a desktop.

That’s why Mark Shuttleworth’s Heads Up Interface (HUD) is unlikely to replace the menus. Menus are ancient and occasionally unwieldy. But, as Shuttleworth admits himself, they provide a map of functionality that HUD doesn’t match. When menus are replaced, it will be by a design that offers equal or greater accessibility to features.

3) Extend Features, Don’t Remove Them

Why did KDE outlast complaints about the early KDE 4 series, while GNOME 3 continues to draw complaints? Partly because KDE developers always intended to restore the functionality of the 4.0 release, while GNOME has never had plans to restore elements like panel applets.

However, an even more important reason is that KDE has tended to extend features rather than remove them. The KDE 4 series is based around the idea of Activities — a series of customized desktops, each with its own set of widgets or icons. Yet, if you prefer to work on a single desktop, as in the KDE 3 series, you still can.

Admittedly, KDE should have made this flexibility more obvious. But that is a lesser mistake than eliminating features altogether.

4) Give Users the Power to Choose Innovations

Another reason why KDE has weathered protests better than other desktops is that, whenever possible, it has allowed users a choice of whether to use an innovation. If you don’t like System Settings presented as icons, you can use a tree view similar to the one in the KDE 3 series. If you don’t like the default menu, you can use the classic menu or the Lancelot widget. If you’re baffled by Activities, you can stick to Virtual Desktops instead, and get much the same results by changing a setting or two.

All of these fallbacks are fully functional, too — in marked contrast to GNOME’s fallback mode, which is a crippled imitation of the GNOME 2 series. Many details of the KDE 3 release series are rearranged or renamed in the latest versions, but the major features, at least, are available if you take the time to explore.

5) Be Aware of the Limits of Usability Principles

Anyone who follows the development of GNOME 3 or Unity can’t help but notice how often the jargon of usability design is tossed around. On both development teams, usability studies are evoked as an authority, intended to stifle criticism.

What no one ever mentions is that, while usability studies have the trappings of scientific study, they are closer to psychology than physics or computer science. They deal with complex, highly contextualized subjects, and very few — if any — usability studies are definitive.

Consequently, as anyone with experience can tell you, success in applying usability principles is highly dependent on your basic principles. In other words, you can easily create an interface whose every feature is in accord with the latest research in usability and still have flawed results because it ignores context and audience. Despite strenuous efforts to raise usability to scientific respectability, interface design stubbornly remains as much an art as a collection of established principles.

6) Allow Multiple Work Flows

Both Unity and the GNOME 3 series are designed with the assumption that there is one optimal way to work. Unity, for example, allows files to be added to the desktop, while applications go on the launcher. Similarly, GNOME 3 assumes that all users want virtual desktops, and automatically creates them — regardless of whether you want them or not.

These ideas have a certain logic behind them, and some users do appreciate them. But what about the users who want easy access to more applications than the dozen or so that the launcher can absorb before it becomes unusable? Or the users who find virtual desktops confusing? These users aren’t going to appreciate being forced to work in a way that makes them uncomfortable, no matter how much logic you muster against them. Custom trumps usability, every time.

7) Accommodate All Levels of Users

Today, Linux interface design seems centered largely on new users. In Unity’s case, this emphasis is probably partially due to Canonical’s march to profitability and its hope of attracting users from other platforms. However, other development teams have also adopted it, usually in the name of not frightening newcomers away.

One result of this emphasis is interfaces that are simple to learn for anyone who has ever used a desktop environment. Unfortunately, though, another result is interfaces that advanced users are likely to find frustrating.

In particular, in both Unity and the GNOME 3 series, reaching configuration options, or even a command line, requires a far longer descent into the menus than with in other interfaces. Advanced users can, of course, customize the interfaces so the features they want are more accessible, but this is still an inconvenience that GNOME 2 or KDE don’t share.

8) Design for the Medium

Maintaining a single code base is obviously convenient for developers. You might also argue that, since mobile devices are the most common computers today, their interfaces should be the standard.

However, what is convenient for developers doesn’t always provide the best user experience. Transparencies and constant screen changes might be endurable on mobile devices — although, even there, I doubt many people like them. But on laptops or workstations, these features only increase the number of mouse-clicks to perform a task.

The best solution I’ve seen to this problem is KDE’s. In KDE, the interface is separated from the functionality, so designing for a different device is largely a matter of designing the interface. This arrangement, which has advanced with every release in the KDE 4 series, is not as convenient as a single code base. But it is nearly as convenient, and allows more flexibility than a single code base could ever possibly equal.

9) Allow for a High Degree of Configuration

On any other operating system, configuration would be much less important. It might not even make this list. But Linux users are accustomed to doing things their way. They may not customize every available feature, but they appreciate having the option.

A strong case can be made that heavy customization is overwhelming for new users. However, this problem can be avoided by supplying intelligent defaults that users can live with until they are comfortable about changing them.

Look at the reactions to KDE 4.0, GNOME 3, or Unity, and by far the largest complaint is the loss of configurability. In comparison, I have yet to encounter anyone who complains about the controls that Linux Mint has added in its efforts to recreate GNOME 2 on top of GNOME 3. Linux users expect to be able to customize their desktops, and grow twitchy when they can’t.

A Plea for Context

These rules are not all that is needed. At least some of the debate over the new interfaces could have been avoided by fully explaining the changes in public, rather than trying to launch an ad campaign as GNOME did, or making them a dictatorial fiat, as Unity did.

Matters might have been improved, too, if the ideas for the interfaces had been discussed among the development communities. Instead, both GNOME and Unity imposed top-down designs, announcing them only when they were ready to implement. This policy not only means that the interfaces were designed more along the lines of proprietary development projects than free software ones, but reduced the possibility of any feedback that might have improved them.

Still, what these suggestions come down to is a plea to think of context in usability. That is the path that Linux Mint has more or less been following, and the one criticism that you tend to hear of its plans is that they are being implemented too slowly.

No doubt, you could follow my suggestions and still have less than ideal results. But at least the user revolts that have become the norm in recent years might be avoided. And who knows? Someone might even produce an interface that people actually want to use.