I promised my next blog manifesto would be handed over to The Journal, and, behold, the latest GNOME Journal is upon us.

Read Experimental Culture

In it, I chronicle the rise and fall of GNOME. Its a rousing tale of charred corpses and classical chrome starring Enlightenment as the wayward prostitute and George Jirka as Her Royal Majesty the Queen of England. Cameos by Beagle, PyGTK, and the cultural revolution.

In all seriousness (well, more seriousness, at least), I hope after reading the article people will at least talk about the problem: GNOME is sort of boring right now. When you interpret usability soley as restraint and polishing it can really dampen project enthusiasm over time. All work and no play makes jack a dull boy.

Design not Usability

The partial solution I would proffer is to focus on design instead of usability. There's a big difference. I'm sure there will be a big hoopla over Apple today owing to the expo, and they deserve it. I think it would be very hard to argue that the things Apple does are not interesting. Part of the reason Apple is interesting is because they encourage designs that change market norms. Good design is challenging. I mean that two ways: both that it is hard to do, and that it tends to shake things up.

Extreme shaftation is an oft used and effective approach to producing really good designs. That's part of the reason its far harder to do a good design in a non-1.0 product. In a 1.0 product you don't have existing users, there's nobody to shaft. You can choose who you want to target, and do it well (unless you position yourself, say, as a Microsoft Word replacement in which case you inherit the set of expectations!). As soon as you have users, its very very hard to drop things from the requirements list. The point of the shafting isn't to remove individual features, or to increase simplicity (necessarily). Simplicity sucks if it doesn't do anything. The point is expand the scope of possible designs, its to let you do new and more interesting things.

Focusing on usability devolves into a sort of bean counting. You divide up the "requirements list" and figure out how to cram all of it in, and then trying to organize the minutia (button labels, menu organization, etc) so it somehow still all makes sense. The result isn't very sexy, and is agressively mediocre. Every point on the requirements list pins you down. In the end the requirements list does the design instead of you. When everybody else is producing nutso apps with a billion buttons and no sort of consistency (c.f. GNOME 1.x), the result of usability looks pretty good. But by shedding some constraints, losing most of the requirements, and focusing carefully you can usually make something much better.

Shedding the Requirements List by Zeroing User Expectations (MS Office)

Microsoft Office exemplifies usability in action. They have a huge list of features that Office must have or users will be angry. They have done a good job of taking that massive list and producing something sane. I am sure that every dialogue and menu in MS Office is poured over with excruciating care: "Will that wording confuse people?", "What are people most likely to be looking for in this menu?" etc. It shows. Office is very polished. Its also a very poor design.

If I were commissioned by Microsoft to dramatically improve Office, my first step would be to position the project not as a next-generation Microsoft Office, but as a new product. I might even start with the Office codebase, but I sure as hell couldn't work with the smothering mantle of user expectations that looms over Office. Done well, I think you'd largely displace Office in the market (assuming this was a Microsoft product, I don't mean to imply that anybody could just make a better product and flounce Office in the market). So you are meeting the goals people have in using Office. What you're not doing is slogging through trying to meet the specific needs people have of the existing software. If you do that, you'll just end up writing Office again.

New Software Resets the Requirements List Anyway (E-mail)

Its important to understand that most 'feature' or 'requirements' lists are a reflection of user's needs and desires relative to existing implementations. If you improve the model enough, most of this is renegotiable.

E-mail is a great example of this. Lets say the internet hadn't appeared until 2004. You are right now in the process of designing the first E-mail app. Clearly users need the ability to make tables, right? I mean, that's "word processing 101". And to format them precisely, oh and insert drawings. And equations. And to edit graphs inline, and to set the margins and page settings. etc etc.

You could easily end up with the requirements list for Microsoft Word: a design for creating multi-page labour intensive laid-out documents. These are the requirements you'd extract from the "word processor + postal mail" model. But E-mail totally renegotiated this. Short little messages are the norm, not multi-page documents. You receive many dozens of mails a day, not several. There's no question that being able to insert a table here and there would be nice, but its by no means a requirement. E-mail's one compelling feature, instant and effortless transmission of text, renders the old model's "must have requirements" list a moot point.