Seth Nickell

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.