Open Source Design

I really want to love Linux as a desktop OS. I went through a phase where I had nearly convinced myself to switch, but the UI stuff kept stopping me from taking the plunge.

I should clarify: the GUI kept getting in the way. I’m quite fond of the command line, and think there’s an elegance and beauty to a great command line/console interface. And Linux excels here. But let’s put it this way: while I can appreciate things like ratpoison, I’m not about to spend all day working like that. And sadly, when you move into GUI software, the Linux experience still falls down for me, despite big improvements over the last few years.

It may seem superficial, but little things like how fonts look and consistency between applications matter a lot when you work on a computer all day. As design people like to say: design is how it works, not how it looks. It’s not just that GNOME looks like a cartoon interface, or that KDE looks like an ugly version of Windows, it’s that they actually feel and behave like that, too. (I know, I know: lots of people are perfectly happy with GNOME and KDE. Lots of people are happy with Windows, too. And typewriters and chalkboards, for that matter.)

This is not a new criticism of open source software. Gruber expresses a common explanation for open source usability woes:

The distributed, collaborative nature of open source software
works for developer-level software, but works against
user-level software. Imagine a motion picture produced like a
large open source project. Different scenes written and
directed by different people, spread across the world. Editing
decisions forged by group consensus on mailing lists. The
result would be unfocused, incoherent, and unenjoyable.

Software UI design, the argument goes, requires an auteur, a chief architect with a clear, elegant, demanding vision of how things should work. Steve Jobs is obviously the most popular example these days. Everything that comes out of Apple is Steve. Good and bad. But generally good. At least for most people.

Matthew Paul Thomas, who has written two widely cited essays (one, two) on the poor usability of Free Software, also highlights this problem:

In the absence of dedicated designers, many contributors to a
project try to contribute to human interface design, regardless of
how much they know about the subject. And multiple designers
leads to inconsistency, both in vision and in detail. The
quality of an interface design is inversely proportional to the
number of designers.

Solution: Projects could have a lead human interface designer, who
fields everyone else’s suggestions, and works with the
programmers in deciding what is implementable. And more
detailed design specifications and guidelines could help
prevent programmer-specific foibles.

In other words, decision making over design needs to be more centralized and consistent. Thomas is now working on software usability for Canonical, where Mark Shuttleworth has made improving usability a top priority with the Ayatana project:

The focus of the project is to improve the perception and presentation of information in the desktop, hence the name of the project; the Buddhist term for a “sense base” or “sense sphere.

(Notice the missing quote mark at the end of that sentence. Can’t make this stuff up.)

Punctuation problems aside, this is great to see. Shuttleworth has explicitly said he wants to meet or surpass OS X’s usability, specifically.

Given it’s an open source design project, it’s interesting to see how they’re dealing with this “auteur” problem. The other day, Shuttleworth announced he was starting an invitation-only mailing list for those involved in the Ayatana project. The list will still be publicly archived, so anyone can read but only team members can contribute. He adds:

I’m aware this proposal could result in outrage over barriers to
participation. But I think it will be more effective if we try to build a
core team that knows each other well and can establish norms and relationships.

Besides, I don’t think effective design would come from purely freeform
participation. At the moment, I have final signoff of specifications coming
from the design team into Ubuntu. In due course, that responsibility will be
assumed by someone in the Canonical design team.

This seems like a relatively modest thing for a design team to want. Of course, it’s controversial.

Actually, having read through the responses on the mailing list, many, if not most, of the responses are positive. But the critical comments are interesting because they really point to the differences in philosophy about how to make design decisions and organize design work. For example:

I think a more closed list will make it more likely that only one vision appears in the code.

Isn’t that the point?

Another suggestion is to create an “Ubuntu Design Board” that will certify particular people with “Ubuntu Designer” status, qualifying them to participate.

Except design qualifications alone aren’t the problem: even highly competent designers can have wildly different ideas of what’s right. And as a user, I’d rather have to learn a single set of principles that work everywhere—even if they’re not the principles I might have come up with on my own—than have a few applications that work exactly the way I like but have every other application work completely differently.

As neither an expert software developer nor an expert interface designer, I don’t really have much else to offer here other than pointing out an interesting debate. One of the reasons I’d love to switch to Linux is that I love the idea of using only open source software. And, of course, the output of the Ayatana project will be open source software. But will they have to disavow a traditional “open source development model” to build that software?

Although, isn’t the idea of an “open source model” kind of a myth anyway? Most of the classic open source success stories that build developer-level tools are still managed, ultimately, by a handful of people. And when they make decisions about the future of the project, because someone has to, they get called dictators too.

The problem with open source usability may be less about an inability to break with some mythical “open source model” and more about the fact that no one has yet stepped forward to exercise the kind of control necessary to make open source interfaces work well. Maybe the “open source way” is just an excuse that gets in the way because everyone has opinions about GUIs compared to, say, opinions about how the kernel should work. So, good luck, Mark Shuttleworth.