Off the Beat: Bruce Byfield's Blog

The last few years of development on the free desktop have been instructive. First, KDE stumbled and recovered with the KDE 4 series. Then, this year, GNOME and Ubuntu introduced radically new desktops. In each case, user complaints immediately poured in. Although both GNOME and Ubuntu seem determined to ignore these complaints and continue on their course, I keep wondering: could the disastrous receptions have been avoided?

The question is worth asking. On the one hand, free desktops need to innovate steadily, both to attract developers and to stay competitive with proprietary rivals. On the other hand, although many developers disregard users, unsatisfied users may move on and risk reducing a desktop project's influence.

So what can be done to avoid future train-wrecks? As a sometime interface designer and a long-time observer of the free desktop, I make the following modest proposals, in the hopes of being constructive rather than simply critical:

Don't change too much too quickly

A significant number of users are conservative in their habits. Even changes that give new flexibility to their habits, such as KDE's Folder View, may be rejected simply because they are new. Whenever possible, pace the changes, and spread them out over several releases rather than introducing them all at once.

Build user testing into each stage of the development

User testing tends to be sparse on the free desktop at the best of times. But doing it only near the end of the development cycle doesn't provide the necessary feedback. Nor, for that matter, does testing only the interface you want. In either case, developers are likely to be too committed to their plans to alter them greatly.

Whenever possible, leave legacy features in place

No matter how inspired a new design is, some users will always prefer the familiar. If you give them both the new and the familiar, they'll be far more likely to explore the new than if they're complaining about how the project took away features they consider essential. One reason why KDE recovered from its initial stumble is that, while the default menu changed, you could revert to the classical menu. Similarly, if you didn't like the new icon-based System Settings, you could revert to the old tree structure.

Don't impose work-flows from above

The GNOME 2 and KDE 3 series differed greatly from each other. However, one characteristic that both series had in common was that users were not constrained by design in how they could work. If they wanted desktop icons, they could use them; if they preferred using the menus, they could do that, too. If they wanted to load the panel with applets, they could; conversely, they could leave panels applets.

By contrast, GNOME 3 and Unity pressure and frequently force users to work in the way that developers think they should. Under the circumstances, it shouldn't be surprising that some users will find the interfaces restrictive.

Beware of designer fads

Usability and interface design are usually discussed in articles with an academic tone and format. When you first discover them, you can easily over-rate their authority. However, the truth is, these areas of study are as subject to fashion as anything else; despite the apparent objectivity of design studies, in practice you can usually tell within a few years when an interface was designed by the features it uses, such as tabs or combo boxes. Designers need to consider if the elements of an interface are truly useful, and not just throw them in because everyone else is doing so

Don't view function and aesthetics as separate

One of the surest signs that design decisions are being made by amateurs armed with a little knowledge is that an interface choice is defended purely on aesthetic grounds. An interface design should not be added because it is abstractly beautiful, but because it enhances a function.

Users, on the whole, have only a brief appreciation of beautiful design if it doesn't make a function easier to user. In fact, forced to choose between aesthetics and function, most will probably choose function every time (which is why, for instance, people are enthusiastic about the ebook manger calibre: the menus may be ramshackle, but calibre contains almost every function to do with ebooks that anyone could want).

If a design is too noticeable, then maybe it's too clever to use

An effective interface is one that allows users to get on with their work without noticing the design after they first time they use it. An interface that users continually notice, either because of the eye-candy or its restrictions is one that gets in the way of ordinary productivity.

You might say that such interfaces are the equivalent of a book that uses a dozen different fonts per page, or an online document that uses a variety of background colors and text frame layouts. Just because a widget set allows you to do do new things doesn't mean that you need to use all of them at once.

Talk to your readers as you work

Don't spring radical changes on users without any preparation. Blog about what's happening throughout the development process, and be prepared to alter plans after hearing feedback. Users who know what's happening, and even feel a small part of the process are more likely to accept changes.

There may be other guidelines that could be added to this list. However, if you keep aware of these seven, I suspect that it would be hard to create anything that would cause serious complaints without being aware of what you were doing.

Just as importantly, with these guidelines, developers might actually stand a chance of developing interfaces that everybody can use, instead of interfaces that they think we should use.

Comments