SHARE

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 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.