The design of the design of everyday things

[OK, I haven't written a rant like this in a while, but I've been forced into it. New material, I swear.]

I'm writing a book on the politics of software, and the editor insists I use Microsoft Word. The irony is palpable, since this patent application figures prominently into the book. [For the non-clikers: It's a patent for the Word format, so Microsoft would be able to sue anybody who makes a Word-compatible word processor. The patent explicitly claims any program that can read Word-formatted documents as an invention to which Microsoft hopes to have a limited monopoly. There's another claim at the European Patent Office for the same thing.]

My own kvetching But I tried my hardest to keep a positive attitude while using Word. I had no intention of sabotaging my own book to score some passive-agressive point. I was going to follow Secretary Rumsfeld's advice: "Don't divide the world into 'them' and 'us.' " I was gonna make Word work for me.

Boy, did that ever not happen. The first attempt at converting my book crashed the computers of my editor and a friend. The second attempt worked better: it only took the Econ department's tech lady an hour to realize that it would work once she installled two service packs onto the computer I was using. Indeed, once she did that, it only took a minute to create a master document which pointed to each chapter (in a separate file, as per publisher style guide).

The next day, I learned that if you edit a chapter, and then edit the master document in an unrelated place, then the edits you make in the chapter will be lost. OK, I thought. Now I've learned. Won't do that again. The next ordeal was switching the order of two chapters. That one was also easy: you can't. The master document locks them, perhaps for your protection from errors like the above, and the help is nice and explicit about how you can't unlock them. I wound up with a workaround in which Chapter Three is no longer in the master document, but is at the head of Chapter Four.

The design of Windows This is not really blogworthy (although I do feel better; thanks guys), but that I was haphazardly handed a copy of Design of Everyday Things, by Donald A Norman (herein DOET). It very clearly had an influence on the design of many of Microsoft's products. It in turn was influenced by what was trendy at the time (1988): the original Macintosh features prominently, and there's a whole page on the promise of hypertext, and he complains about emacs. In his section on Two Modes of Computer Usage, he explains that there's a third-person mode wherein you give commands to the computer, and then the computer executes them; and there's a first-person mode where you do things your own darn self. Like telling the computer to multiply matrix A by matrix B versus entering stuff into the cells of a spreadsheet. At the ideal, you can't tell that you're using a computer; the intermediary dissolves away and it just feels like working on a problem. Of course, some tasks are too hard for first-person execution, as Mr. Norman explains: "I find that I often need first-person systems for which there is a backup intermediary, ready to take over when asked, available for advice when needed." This paragraph, I posit without a shred of proof, is the genesis of Clippy the Office Assistant.

[When Office XP came out they `fired' Clippy (which meant that he was off by default). The PR was that Office XP was so easy to use that you wouldn't need him, but it was obvious to all that everybody just found him too annoying. To announce the firing, they put together a series of animated clips with Gilbert Godfrey as the voice of Clippy, in which we witness him getting fired, we met his paperclip family, we see him try to get another job, et cetera. His snippy son taunts, `It looks like you're writing a resume, Dad!' For the ten minutes it took to watch those shorts, I loved Microsoft. They've since pulled it from their website.]

Forcing the user There are two problems with Mr. Norman's setup, both of which I ran into in my experience above. The first is that writing a word-processor document is not like handwriting a letter. For example, you don't hard-code numbers: instead of writing Chapter 3, you'd write Chapter \ref{more_rambling} (LaTeX form; Word has a similar thing), and let the computer work out what number goes with the more_rambling reference. [I used the LaTeX for Chapter \ref{more_rambling} here because it saves me the trouble of having to explain the seven-step process it takes to do the same thing in Word. And while we're in digression brackets, the reader may want to note that if you change the chapter's title, all of the references will break and you'll have to repeat the seven-step process for each reference.]

I gave unsolicited advice to the user about unintuitive, metaphorless, effective methods in an entry from about a year ago. Think of it as the applied version of the theory discussion here.

DOET has much to say about saving the user from him, her, or itself. You should make it impossible to make errors. His shining example of good design are car doors that can only be locked using the key. There's a trade-off of some inconvenience, but it is absolutely impossible to lock the car keys inside. Word clearly fails on this one: you wanna hard-code your references? Feel free; in fact, we're gonna make it hard for you to do otherwise, since doing otherwise doesn't follow the metaphor of simply writing on paper.

More generally, a good design has restrictions: if you can only put your hand in one place, then that's where you'll put your hand, and the door will open on the first try. What about LaTeX? It gives you a blank page. You can type a basically infinite range of possibilities. This is where DOET leaves the command line: it isn't restrictive enough to guide the user, and therefore is a bad design.

I think he's got the interpretation entirely wrong: there is only one thing that you can do with the blank slate that you get in emacs, LaTeX, or a command line: read the manual (RTFM). Just as your car won't let you lock yourself out, you can't write a crappy document in LaTeX until you've gotten a copy of the manual and at least had half a chance to expose yourself to the correct way to do things. Mr. Norman again: "Alas, even the best manuals cannot be counted on; many users do not read them. Obviously it is wrong to expect to operate complex devices without instruction of some sort, but the designers of complex devices have to deal with human nature as it is." Yeah, people won't read manuals unless you force them to. So force them to.

Metaphor shear The other problem is what Neal Stephenson calls metaphor shear. That's when you're happily working with a mental model in the back of your mind, and one day your metaphor breaks. Back to DOET: "Three different aspects of mental models must be distinguished: the design model, the user's model, and the system image [...]. The design model is the conceptualization that the designer had in mind. The user's model is what the user develops to explain the operation of the system. Ideally, the user's model and the design model are equivalent. However, the user and designer communicate only through the system itself: its physical appearance, its operation, the way it responds, and the manuals and intructions that accompany it. Thus, the system image is critical; the designer must ensure that everything about the product is consistent with and exemplifies the operation of the proper conceptual model."

This is where DOET overestimates computing. It's a book that's mostly about doors and faucets and other everyday objects. He's right that if you have to RTFM to work a door (even if the manual just says `Push'), the door's design is broken. He's right that for complex systems, like panels of airline instruments, they should not work against intuition (e.g., if two levers do different things, they should look different). But he combines them into a false conclusion: complex systems should work with intuition so well that you shouldn't have to read the manual.

First, this is absurd in any setting but desktop computers. Would you feel OK if your pilot told you the plane was so intuitive that she didn't bother learning how to use it before the flight?

But back to the main point, making a word processor which is so intuitive to the user that he or she doesn't have to RTFM is a much more complex task than making a manual-less faucet. If we needed to build a faucet such that it runs if the user presses it with his hand, bangs it with a pot, or bumps it with his elbow, that would be easy---put a button on the top. But to program a picture of a faucet such that the user can click on the thing, or double-click on the thing, or type R and all make the picture of a faucet run requires programming a call to the Run method for three separate events. If the user comes up with something that the programmer didn't think of, like holding down the alt key and clicking on the picture, then the user is screwed. What your momma told you is true: it's easier to just put out the truth than weave a whole world around a lie. [For those down with the lingo: every event has to have a method for every object, which is dozens of events times dozens of objects equals hundreds of things that could go wrong with the metaphor---assuming you got good rules about passing the right events to the right objects to begin with. Inheritance doesn't help because most of the time the inherited methods don't quite work as they should, leaving you with objects which almost fit the metaphor.]

Mr. Norman's call for simple interfaces (he doesn't really say anything about metaphors to physical objects, but he does talk about simple mental models, and for most of us that means physical metaphors) therefore leads us down a supremely difficult path: first, the program designer must lie to the user by presenting a metaphor that is easy for the user to immediately guess at. Then, the designer must now design the program so that anything the user does, no matter how unpredictable, will cause the program to behave in the correct metaphorical manner. One easy way to do this, which is in line with the design principle from above, is to limit what the user can do; as noted by my own attempts to move a frigging locked document, this prevents the unexpected at the cost of immense frustration.

Policy implications Mr. Norman is right that we shouldn't want to have to RTFM for simple, everyday tasks. Writing a letter or one-page paper is so common that his principle that it should be manual-less should probably apply. Further, we have the technology. However, as I've learned ever-so-painfully, writing a book is an order of magnitude more technically difficult. Programs like Word and Scientific Word imply that writing a letter and a book are are identical, just a matter of extent, when in the end they aren't: one has a valid paper metaphor attached, which programmers can easily implement, and one does not. A good word processor, then, would let you do basic things without effort, and then put its foot down at some point. You get all the tools you need to write a business letter, and then if you want more, you'll need to get a new tool with a manual. Clearly, nobody is ever going to write a program like this. To some extent, this is a good thing, since it pushes technology forward, but at the expense of annoying users who have to sit through half-appropriate metaphors badly implemented. Mr. Norman writes about creeping featurism as an evil which pervades all of design, and he's right: nobody ever says `I'm done.' [There is a stand-out exception to this: TeX was done in 1988, after nobody claimed the author's cash prize for finding bugs, and the code base has not changed since then. LaTeX's base was cemented in 1994, I think. If you wanna change something in the system, you add a package to the base systems.]

The right way to implement this would be a simple graphical front end to the basic features of a less metaphor-laden back-end program. When you've sapped the offerings of the graphical front end, you'll have a bearing when you RTFM on the less intuitive stuff. This is how a host of Unixy programs work, but the front ends also eventually succumb to featurism. Scientific Word takes it to the extreme, by refusing to admit that it is a front-end (perhaps because it is a front-end to free software) and by trying to give you a button for every last feature.

Since no programmer will ever have the discipline to admit that their manual-less tool will work only for a limited range of tasks, the discipline falls upon the user to realize that it's OK to use simplifying metaphors for simple situations, but complex tasks require tools that don't lie to you.