About Face: The Essentials of User Interface Designby Alan Cooper, Andrew Singer (Foreword by)
The cleverest code in the world is worth nothing if a program's interface proves an unwieldy barrier to users. That's why programmers and designers alike will benefit from About Face: The Essentials of User Interface Design. Here, respected software designer Alan Cooper shares his own real-world experience and design principles so that you, too,/i>/b>
- Editorial Reviews
- Product Details
- Related Subjects
- Read an Excerpt
- What People Are Saying
- Meet the author
The cleverest code in the world is worth nothing if a program's interface proves an unwieldy barrier to users. That's why programmers and designers alike will benefit from About Face: The Essentials of User Interface Design. Here, respected software designer Alan Cooper shares his own real-world experience and design principles so that you, too, can fashion intuitive, effective user interfaces. Applicable to multimedia and Web sites as well as application software, About Face is an invaluable resource for design professionals.
Designing Programs The Microsoft-Centric Way
Alan Cooper has a legendary status among Windows programmers. This is due partly to his talents as a writer and speaker, partly to his somewhat murky reputation as the "Father of Visual Basic," and partly to the widespread perception that he beat Microsoft at their own game, then cashed in and walked away without a scratch. Rather than sit in his gazebo and clip coupons from his Microsoft stock, however, Cooper has chosen to put his fame as a user interface guru on the line in About Face.
The first thirteen chapters of About Face address global issues: programmers' versus users' mental models of program operation and file systems, what Cooper refers to as program "posture," and the application's facilitation of workflow (or impedance of same). The middle set of chapters deal with relatively low level, technical aspects of application "affordances" -- buttons, menus, cursors, dialog boxes, and so on. The last seven chapters return to more philosophical musings on errors, exception handling, installation, personalization, "undo" facilities, and the future of user interfaces.
Cooper has a lot of valuable things to say about program design and behavior. His comments on sovereign as opposed to transient programs, the evolving role of menus in the era of toolbars, nested and tabbed dialogs, drag-and-drop, and the tendency of most commercial applications to "go stupid" without warning for unpredictable lengths of time were interesting and thought-provoking. I particularly enjoyed his railings against the many idiotic applications which provide unbounded controls for user input, and then immediately turn around and slap the user's wrist for entering an illegal value.
Although About Face is subtitled "The Essentials of User Interface Design," it is really about "The Essentials of Windows Application User Interface Design." The book does mention the Apple Macintosh and the Xerox Star in passing, but I get the impression that Cooper's experience with alternative modern GUIs such as OS/2 Warp, Macintosh OS, NextStep, and the UNIX variants is minimal. Certainly Cooper's perspective comes across in the book as quite parochial, and he passes up many opportunities to compare and contrast Windows features with their (often superior) counterparts in other systems.
Other weaknesses of the book include Cooper's widespread use of self-invented, idiosyncratic terms for user-interface issues and objects, wide swings in technical level, and the apparent absence of a strong manuscript editor. But the Windows-95 orientation will probably have the most serious effect on the book's long-term value. Even before the majority of PC-compatible users have switched from Windows 3.1 to Windows-95, Microsoft is preparing to jettison the Windows-95 interface in favor of a new Web-browser-based metaphor.
With typical IDG hyperbole, About Face's cover blurb quotes Stewart Alsop as saying "Alan Cooper is a software god... This is a landmark book." That's stretching things a bit for my taste; my conception of a software god runs more to the likes of Donald Knuth, and of landmarks more to the likes of Donald Norman's Design of Everyday Things. This is a good book, and certainly light-years better than Microsoft's own pathetic little application style guides (which are conspicuously ignored by Microsoft programmers), but it would need a broader base and some stringent editing to be a great one.--Dr. Dobb's Electronic Review of Computer Books
- Publication date:
- Product dimensions:
- 7.50(w) x 9.26(h) x 1.45(d)
Read an Excerpt
Chapter 8: Lord of the FilesIf you have ever tried to teach your Mom how to use a computer, you will know that "difficult" doesn't really do the problem justice. Things start out all right: you fire up the word processor and key in a letter. She's with you all the way. When you are finally done, you press the Close button and up pops that mutant ninja turtle of a dialog box asking "Do you want to save changes?" and you and Mom hit the wall together. She looks at you and asks, "What does this mean? What changes? Is everything OK?" How can you answer her?
The tragedy of the file systemThe part of modern computer systems that is the most difficult to understand is the file system, the facility that stores programs and data files on disk. Telling the uninitiated about disks is very difficult. The difference between "main memory" and "disk storage" is not clear to most people. Unfortunately, the way we design our software forces users-even your Mom-to know the difference. Every program exists in two places at once: in memory and on disk. The same is true of every file, but many users never quite grasp the difference. When that "Save Changes?" dialog box, shown in Figure 8-1, comes up, they just suppress a twinge of fear and confusion and press the yes button out of habit. A dialog box that is always answered the same way is a redundant dialog box that should be eliminated.
The Save Changes dialog box is based on a bad assumption. The very presence of the dialog assumes that saving and not saving are equally probable. The dialog gives equal weight to these two options, even though the yes button is pressed orders of magnitude more frequently than the no button. As Idiscuss in Chapter 11, this is a case of putting might on will. The user might say no, but the user will almost always say yes.
There is another odd thing about the dialog, and Mom will probably wonder about it. Why does it ask about saving changes when you are all done? Why didn't it ask when you actually made them? The connection between closing a document and saving changes isn't all that natural, even though we power-users have gotten quite familiar with it.
Mom is thinking "If I didn't want those changes, I would have undone them long ago." To her, the question is absurd. The program issues the dialog box when the user requests close or quit because that is the time when it has to reconcile the differences between the copy of the document in memory with the copy on disk. The way the technology actually implements the facility associates changes with the close and quit operations, but the user doesn't naturally see the connection. When we leave a room, we don't consider discarding all of the changes we made while we were there. When we put a book back on the shelf, we don't first erase any comments we wrote in the margins.
Computer geeks are very familiar with the connection between saving changes and closing or quitting. They don't want to lose this ability because it is familiar to them, but familiarity is a really bad design rationale. We don't want to keep repairing our car just because we are familiar with the shop. We don't want to keep getting root canals just because we are familiar with the drill.
As experienced users, we have learned to use this dialog box for purposes for which it was never intended. There is no other easy way to undo massive amounts of changes, so we just use the Save Changes dialog and answer it with a no. If you discover yourself making big changes to the wrong file, you use this dialog as a kind of escape valve to return things to the status quo.
The problems caused by disksThe computer's file system is the tool it uses to manage data and programs stored on disk. This means the big hard disks where most of your information resides, but it also includes your floppy drives and your CD-ROM if you have one. The File Manager program in Windows 3.x and the Explorer in Windows 95 graphically represent the file system. Without a doubt, the file system-and the disk storage facility it manages-is the primary cause of disaffection with computers for non-computer-professionals.
AXIOM: Disks and Files Make Users Crazy
Even though the file system is an internal facility that shouldn''t-by all rights-even affect the user, it creates a large problem because the influence of the file system on the interface of most programs is very deep. The most intractable problems facing user interface designers usually concern the file system and its demands. It affects our menus, our dialogs, even the procedural framework of our programs, and this influence is likely to continue indefinitely unless we make a concerted effort to stop it.
Currently, most software treats the file system in much the same way that the operating system shell does (Explorer, File Manager). This is tantamount to you dealing with your car the same way your mechanic does. Even though this approach is tragically bad, it is an established, de facto standard and there is considerable resistance to improving it.
Following the implementation modelBefore I go any further, let me make clear that the file systems on modern personal computer operating systems, like Windows 95, are technically excellent. I have no gripe with the way they are implemented. The problem stems from the simple mistake of rendering that implementation model to the user.
The implementation model of the file system runs contrary to the mental model almost all users bring to it. In other words, they picture files or documents as typical documents in the real world, and they imbue them with the behavioral characteristics of those real objects. In the simplest terms, users visualize two salient facts about all documents: First, there is only one document, and second, it belongs to the user. The file system's implementation model violates both of these rules: There are always at least two copies of the document, and both belong to the program.
Saying that someone is "computer literate" is really a euphemism meaning that he has been indoctrinated and trained in the irrational and counter-intuitive way that file systems work, and once you have been properly subverted into thinking like a computer nerd, the obvious ridiculousness of the way the file system presents itself to the user doesn''t seem so foolish.
Every data file, every document and every program, while in use by the computer, exists in a minimum of two places at once: on disk and in main memory. The user, though, imagines his document as a book on a shelf. Let's say it is a journal he is keeping. Occasionally, it comes down off the shelf to have some words added to it. There is only one journal, and it either resides on the shelf or it resides in the user's hands. On the computer, the disk drive is the shelf, and main memory is the place where editing takes place, equivalent to the user's hands. But in the computer world, the journal doesn't come "off the shelf." Instead a copy is made, and that copy is what resides inside the computer. As the user makes changes to the document, he is actually making changes to the in-memory copy, while the original remains untouched on disk. When the user is done and closes the document, the program is faced with a decision. It must decide whether to replace the original on disk with the changed copy from memory. From the programmer's point of view, equally concerned with all possibilities, this choice could go either way. From the software's implementation model point of view, the choice is the same either way. However, from the user's point of view, there is rarely a decision to be made at all. He made his changes already; now he is just putting the document away. If this were happening with a paper journal in the physical world, the user would have pulled it off the shelf, pencilled in some additions, and is now replacing it on the shelf. It's as if the shelf suddenly spoke up, asking if he really wants to keep those changes!
Right now, the seriously computer-holic readers are beginning to squirm in their seats. They are thinking that I'm treading on holy ground, and a pristine copy on disk is a wonderful thing and that I had better not be advocating getting rid of it. Relax! As I said before, there is nothing wrong with our file systems. I am only advocating that we hide its existence from the user. We can still offer to him all of the advantages of that extra copy on disk without exploding his mental model. I'll show you how.
Dispensing with the disk modelIf we begin to render the file system according to the user's mental model, we achieve a significant advantage. The primary one is that we can all teach our Moms how to use computers. We won't have to answer her challenging questions about the inexplicable behavior of the interface. We can show her the program and explain how it allows her to work on the document and, upon completion, she can store the document on the disk as though it were a journal on a shelf. Our sensible explanation won't be interrupted by that "Save changes?" dialog. Not to put too fine a point on this, but I'm just using Mom as a surrogate representing the mass market of computer buyers.
The other big advantage is that software user interface designers won't have to incorporate clumsy file-system awareness into their products. We can structure the commands in our programs according to the goals of the user instead of according to the needs of the operating system.
We no longer need to call the left-most menu the "File" menu. This older nomenclature is a bold reminder of how the technology pokes through the facade of our programs. We can label this menu after the type of document we are processing-for example, we can call it "Spreadsheet," "Invoice," or "Picture." Alternatively, we can give it a more generic name like "Document," which is a reasonable choice for horizontal programs like word processors or spreadsheets.
Changing the name and contents of the "File" menu violates an established standard. I recognize the impact of this proposal and don't make it lightly. I have tremendous respect for standards, unless they are wrong. This one is wrong, and it's existence makes life more difficult than it has to be for every user of computers, particularly newcomers and casual users. The benefits will far outweigh any dislocation the change might cause. There will certainly be an initial cost as experienced users get used to the new presentation, but it will be far less than you might suppose. This is because these power-users have already shown their ability and tolerance by learning the implementation model. For them, learning the better model will be a slam-dunk, and there will be no loss of functionality.
The advantage for new users will be immediate and big. We computer professionals forget how tall the mountain is once we''ve climbed it, but everyday newcomers approach the base of this Everest of knowledge we sit atop and are severely discouraged. Anything we can do to lower the height can make a big difference, and this step removes a considerable obstacle.
Designing software with the proper modelProperly designed software will always treat documents as single instances, never as a copy on disk and a copy in memory. I call this the unified file model.
DESIGN TERM: Unified File Model
SavingOne of the most important functions every computer user must learn is how to "save." Invoking this function means taking whatever changes the user has made to the in-memory copy and writing them onto the on-disk copy of the document. In the unified model, we abolish all user-interface recognition of the two copies, so the "save" function disappears completely from the mainstream interface. Of course, that doesn''t mean that it disappears from the program. It is still a very necessary operation.
The program will automatically save the document. At the very least, when the user is done with the document and requests the close function, the program will merely go ahead and write the changes out to disk without stopping to ask for confirmation with the "Save Changes" dialog box.
In a perfect world, that would be enough, but computers and software can crash, power can fail, and other unpredictable, catastrophic events can conspire to erase your work. If the power fails before you have pressed close, all of your changes will be lost as the memory containing them scrambles. The original copy on disk will be all right, but hours of work can still be lost. To keep this from happening, the program must also save the document at intervals during the user session. Ideally, the program will save every single little change as soon as the user makes it. In other words, after each keystroke. For most programs on modern computers, this is quite feasible. Only certain programs-word processors leap to mind-would find difficulty with this level of saving (but the solution would still not be impossible). Most documents can be saved to the hard disk in just a fraction of a second, so generally this is not a problem. Still, this is a sensitive area, because the program will hesitate noticeably in a very disturbing way. Word has a facility for automatically saving files to disk, and I never use it for that reason. The problem is caused by the save facility's logic, not because the principle of automatic saving is bad. Word automatically saves the file according to a countdown clock, and you can set the delay to any number of minutes. If you ask for a save every two minutes, for example, after precisely two minutes the program stops accepting your input to write your changes out to disk, regardless of what you are doing at the time. If you are typing when the save begins, it just clamps shut in a very realistic and disconcerting imitation of a broken program. It is a very unpleasant experience. If the algorithm would pay attention to the user instead of the clock, the problem would disappear. Nobody types continuously. Everybody stops to gather his thoughts, or flip a page, or take a sip of coffee. All the program needs to do is wait until the user stops typing for a couple of seconds and then save.
This automatic saving every few minutes and at close time will be adequate for everybody except the really twisted computer-freaks who have been using computers since Bill Gates was just a thousandaire. I include myself in this group. I'm so paranoid about my computer crashing and losing data that I habitually press the ctrl-s key after every paragraph I type, and sometimes after every sentence. (Pressing ctrl-s is the keyboard accelerator for the save function.) I'll typically save a document-like a chapter in this book-more than 1,000* times before it's done! There is no way in the world I would even use a program that didn't provide such manual save capabilities, and all programs should have them. I just don't think that my compulsive behavior should be forced on new or occasional users who are writing the occasional letter or spreadsheet and haven't begun writing a book yet.
Using the revision number feature of Microsoft Word, I print the exact number of saves at the bottom of all of my drafts. I'm not exaggerating.
Right now in Word, the save function is prominently placed in-your-face on the primary program menu. The save dialog is forced on all users when they ask to close the document or to quit or exit the program. These artifacts must go away, but the save functionality can remain in place exactly as it is now.
ClosingThere is no inherent connection between closing and saving in my unified model because there is no concept of saving.
We computer geeks are conditioned to think that close is the time and place for abandoning unwanted changes if we made some error or were just what-if-ing. This is not correct, though, because the proper time to reject changes is when the changes are made. We even have a well-established idiom to support this. The undo function is the proper facility for eradicating changes. We have bent and contorted our thinking so much to accommodate the implementation model that I often hear people bleat in protest over losing the ability to refuse a request to "save changes."
In Chapter 30, "Undo," I'll talk about some more sophisticated variants of undo that allow us to create multiple versions of a document. Currently, savvy computer users who understand the technology can accomplish this by working cleverly with the file system. A better interface could offer these desirable features directly and explicitly.
When you answer yes to the Save changes dialog, virtually every program then presents you with the "Save As" dialog box. A typical example is shown in Figure 8-2.
Neither the typical user nor the unified file model recognizes the concept of manual saving, so, from their point of view, the name of this dialog box doesn't make much sense. Functionally, this dialog offers the user two things. It lets you name your file, and it lets you choose which directory you wish to place it in. Both of these functions demand intimate knowledge of the file system. The user must know how to formulate a file name and how to navigate through the directory tree. I know of many users who have mastered the name portion but who have completely given up on understanding the directory tree. They put all their documents in whatever directory the program chooses for a default. All of their files associated with a particular program are stored in a single directory. Occasionally, some action will cause the program to forget its default directory, and these users must call in an expert to find their files for them. My next door neighbor, Bill, calls me about every six months to help him find his Lotus 1-2-3 files. The first time he called, I asked him where he normally keeps his spreadsheets. He answered innocently "In 1-2-3." Bill's mental model is very different from the software's implementation model and, ultimately, Bill is right.
The Save As dialog needs to decide what its purpose is. If it exists to name and place files, then it does a very bad job of it. Once the user has named and placed a file, he cannot then change its name or directory. At least he can''t with this dialog that purports to offer naming and placing privileges. Nor with any other tool in the application itself.
Beginners are out of luck, but experienced users learn the hard way that they can close the document, change to the Explorer, rename the file, return to the application, summon the Open File dialog, and reopen the document. In case you were wondering, the Open File dialog doesn''t allow renaming or repositioning either.
Forcing the user to go to the Explorer to rename the document is a minor hardship, but therein lies a hidden trap; its teeth sharp and its spring strong. The bait is the fact that Windows easily supports several applications running simultaneously. Attracted by this feature, the user tries to rename the file in the Explorer without first closing the document in the application. This very reasonable action triggers the trap, and the steel jaws clamp down hard on his leg. He is rebuffed with a rude error message box shown in Figure 8-3. He didn't first close the document-how would he know? Trying to rename an open file is a sharing violation, and the operating system summarily rejects it with a truly frightening and unhelpful error message box.
The innocent user is merely trying to name his document, and he finds himself lost in an archipelago of operating-system arcana. Ironically, the one program that has both the authority and the responsibility to change the document''s name while it is still open is the application itself, yet it refuses to even try.
ArchivingThere is no explicit function for making a copy of, or archiving, a document. The user must accomplish this with the Save As dialog, and doing so is as clear as mud. Even if there were a "Copy" command, users visualize this function in different ways. If we are working, for example, on a document called "Alpha," some people imagine that we would create a file called "Copy of Alpha" and store it away. Others imagine that we put Alpha away and continue work on Copy of Alpha.
I suspect that the latter option will only occur to those who are already experienced with the implementation model of file systems. That is, of course, how we would do it today with the Save As dialog: you have already saved the file as Alpha; then you explicitly call up the Save As dialog and change the name. Alpha will be closed and put away on disk, and the new copy will be the version being edited. This action makes very little sense from the single-document viewpoint of the world, and it also offers a really nasty trap for the user.
Here is the completely reasonable scenario that leads to trouble: Let''s say that I have been editing Alpha for the last twenty minutes and now wish to make an archival copy of it on disk so I can make some big, but experimental, changes to the original. I call up the Save As dialog box and change the file name to "New Alpha." The program puts Alpha away on disk leaving me to edit New Alpha. Ahhh, but Alpha was never "Saved," so it gets written to disk without the changes I made in the last twenty minutes! Those changes only exist in the "New Alpha" copy that is currently in memory-in the program. As I begin cutting and pasting in New Alpha-trusting that my handiwork is backed up by "Alpha"-I am actually trashing the sole copy of this information.
Everybody knows that you can use a hammer to drive a screw or a pliers to bash in a nail, but any skilled craftsperson knows that using the wrong tool for the job will eventually catch up with you. The tool will break or the work will be hopelessly ruined. The Save As dialog is the wrong tool for making and managing copies, and it is the user who will eventually have to pick up the pieces caused by the developer's laziness.
Unify the file modelThe application program refuses to rename and reposition the file out of respect for the file system. The file system is the facility whose job it is to manage information that is not in main memory, and it does so by maintaining a second copy on disk. This method is correct, but it is an implementation detail that only confuses the user. Application software should conspire with the file system to hide this unsettling detail from the user.
If the file system is going to show the user a file that cannot be changed because it is in use by another program, the file system should indicate this to the user. Showing the file name in red, or with a special icon next to it would be sufficient. A new user might still get that awful message in Figure 8-3, but at least some visual clues would be present to show him that there is a reason why that error cropped up.
Not only are there two copies of all data files but, when they are running, there are two copies of all programs. When I go to the Startbar's Start menu and launch my word processor, a button corresponding to Word appears on the Startbar. But if I return to the Start menu, Word is still there! From the user's point of view, I have pulled my hammer out of my toolbox, only to find that my hammer is still in my toolbox!
I'm not saying that this should not be the case. After all, one of the great strengths of the computer is its ability to have multiple copies of software running simultaneously. I do think that the software should help the user to understand this very non-intuitive action, however. Maybe the Start menu could make some reference to the already-running program.
Document managementThe established standard suite of file management for most applications consists of the Save As dialog, the Save Changes dialog, and the Open File dialog. Collectively, these dialogs are, as I''ve shown, confusing for some tasks, and completely incapable for others. Here is how I would design an application that really managed documents according to the user's mental model.
Besides rendering the document as a single entity, there are several goal-directed functions that the user may need, and each one should have its own corresponding function.
- Creating a copy of the document
- Creating a milestone copy of the document
- Naming and renaming the document
- Placing and repositioning the document
- Specifying the stored format of the document
- Reversing some changes
- Abandoning all changes
Creating a copy of the documentThis should be an explicit function called "Make Snapshot Copy." The word "snapshot" makes it clear that the copy is identical to the original, while also making it clear that the copy is not tied to the original in any way. That is, subsequent changes to the original will have no effect on the copy. The new copy should be given a name with a standard form like "Copy of Alpha," where "Alpha" is the name of the original document. If there is already a document with that name, the new copy should be named "Second Copy of Alpha." The copy should be placed in the same directory as the original.
It is very tempting to envision the dialog box that accompanies this command, but there should be no such interruption. The program should take its action quietly and efficiently and sensibly, without badgering the user with silly questions. Make a copy. In the user's mind, it is a simple command. If there are any anomalies, the program should make a constructive decision on its own authority.
Naming and renaming the documentThe name of the document should be shown right on the application's toolbar. If the user decides to rename the document, he can just click on it and edit it in place. What could be simpler and more direct than that?
Placing and repositioning the documentMost documents that are edited already exist. They are opened, rather than created from scratch. This means that their position in the file system is already established. Although we think of establishing the home directory for a document at either the moment of creation or the moment of first saving, neither of these events is particularly meaningful outside the implementation model. The new file should be put somewhere reasonable where the user can find it again.
If the user wants to explicitly place the document somewhere in the file-system hierarchy, he can request this function from the menu. A relative of the Save As dialog appears with the current document highlighted. The user can then move the file to any desired location. Essentially, all files are placed automatically by the program, and this dialog is used only to reposition them.
Specifying the stored format of the documentThere is an additional function implemented on the Save As dialog in Figure 8-2. The combobox at the bottom of the dialog allows the user to specify the physical format of the file. This function should not be located here. By tying the physical format to the act of saving, the user is confronted with additional, unnecessary complexity. Saving should be a very simple act. In Word, if the user innocently changes the format, both the save function and any subsequent close action are accompanied by a frightening and unexpected confirmation box.
From the user''s point of view, the physical format of the document-whether it is rich text, ASCII, or Word format, for example-is a characteristic of the document rather than of the disk file, so specifying the format shouldn't be associated with the act of saving the file to disk. It belongs more properly in a "Document Properties" dialog.
Overriding the physical format of a file is a rare occurrence. Saving a file is a very common occurrence. These two functions should not be combined.
The physical format of the document should be specified by way of a small dialog box callable from the main menu. This dialog box should have cautions built into its interface to make it clear to the user that the function can involve significant data loss.
Reversing some changesIf the user inadvertently makes changes to the document that must be reversed, the tool already exists for correcting these actions: undo. The file system should not be called in as a surrogate for undo. The file system may be the mechanism for supporting the function, but that doesn't mean it should be rendered to the user in those terms. The concept of going directly to the file system to undo changes merely undermines the undo function.
The milestone function (description follows) tells how a file-centric vision of undo can be implemented so that it works well with the unified file model.
Abandoning all changesIt is not uncommon for the user to decide that he wants to discard all of the changes he has made since opening or creating a document, so this action should be explicitly supported. Rather than forcing the user to understand the file system to achieve his goal, a simple "Abandon" function on the main menu would suffice. Because this function involves significant data loss, it should be protected by clear warning signs. Additionally, making this function undoable for a week or two would be relatively easy to implement and appreciated more than you might imagine.
Creating a milestone copy of the documentMaking a milestone is very similar to using the copy command.
The difference between them is that the milestone copy is managed by the application after it is made. The user can call up a "Milestone" dialog box that lists each milestone copy along with various statistics about it, like the time it was recorded and its length. With a click, the user can select a milestone copy and, by doing so, immediately return to it as the active document. The version that was current at the time of the reversion will be milestoned itself, for example, under the name "Displaced by Milestone of Alpha 12/17/97, 13:53."
The new menuOur new File menu now looks like the one shown in Figure 8-4. "New" and "Open" function as before, but "Close" will just quietly close the document without a dialog box or any fuss, after assuring that it is completely saved. "Rename/Reposition..." brings up a small dialog box that lets the user rename the current file and/or move it to another directory. "Make Snapshot Copy" quietly creates a new file that is a copy of the current document. "Make Milestone" does the same thing, except that the program manages these copies by way of the dialog box summonable with the "Revert to Milestone" item. "Document Properties" also brings up a dialog box that lets the user change the physical format of the document. The final item is "Abandon Changes" and it discards all changes made to the document since it was opened or created.
File menu?Of course, now that we are manifesting a monolithic model of storage instead of the bifurcated implementation model of disk and RAM, we no longer need to call the left-most menu the "File" menu. This older nomenclature is a bold reminder of how the technology has been inflicted on the user instead of the user's model being reflected in the technology. There are two pretty good alternatives to solving this problem.
As I said earlier, we can label the menu after the type of document we are processing. For example, a spreadsheet might label its left-most menu "Sheet." An invoicing program might label it "Invoice." I designed a patent management program for a client, and in that program we called it "Patent."
Alternatively, we can give the left-most menu a more generic label like "Document." This is certainly a reasonable choice for broad programs like word processors and spreadsheets, but is less appropriate for narrower programs like the patent manager. Conversely, those few programs that do represent the contents of disks as files-generally operating system shells and utilities-should have a "File" menu, because they are addressing files with a studied ignorance of their contents.
How did we get here?If you are still not convinced that disks and their file system are the cause of great user interface confusion, I'd like to show how our disks came to have such a profound effect on our software. From the user's point of view, there is no reason for disks to exist. From the computer engineer's point of view, there are three:
- Disks are cheaper than solid-state memory.
- Once written to, disks don't forget when the power is off.
- Disks provide a physical means of moving information from one computer to another.
Reasons number two and three are certainly useful but are not the exclusive domain of disks. Other technologies work as well or better. There are varieties of RAM that don't forget their data when the power is turned off. CMOS memory is solid state, yet it retains its setting without external power.
Networks and phone lines can be used to physically transport data to other sites, often more easily than with removable disks.
Reason number one-cost-is the real reason why disks exist. CMOS is a lot more expensive than disk drives. Reliable, high-bandwidth networks haven't been around as long as removable disks, and they are still more expensive.
Disk drives have many drawbacks when compared to RAM. Disk drives have always been much slower than solid-state memory. They are much less reliable, too, since they depend on moving parts. They consume more power and can take up more space, as well. The real whammy when it comes to disks, though, is that computers, the actual CPU, can''t really read or write to them! Data must first be brought into main, solid-state memory by the CPU's helpers before the CPU can work with it. When the processor is done, the helpers must once again step in to move the data back out to the disk! This means that all processing involving disks is necessarily orders of magnitude slower and more complex than working in plain RAM.
AXIOM: Disks are a Hack, Not a Design Feature
The time and complexity penalty for using disks is so severe that nothing short of enormous cost-differential could compel us to rely on them. Disk drives are a cost-saving hack. Mind you, there is nothing wrong with using this sophisticated technology to save money, but keep in mind that the technology isn't there to provide us with services we couldn't get in other ways. This means that any changes we make to our interfaces to adjust to the disk technology are likely to be inappropriate from a goal-directed point of view.
So we can see that disks are not a law of nature; they are not architectural features that make computers better, more powerful, faster or easier to use. Instead, they make computers weaker, slower and more complex. They are a compromise, a dilution, an adulteration, a corruption of the pure architecture of digital computers. If early computer designers could have economically used RAM instead of disks, they would have done so without hesitation. Whatever other problems RAM exhibited could have been overcome with technologies simpler than the complexity of disk drives.
The difference between RAM and disk is merely a matter of economics, much like the way you go to a lending library instead of personally owning copies of every book. This means that wherever disk technology has left its mark on the design of our software, it has done so purely for implementation purposes and not for any goal-directed design rationale. While this difference should be of interest only to programmers, in reality, it is imposed on nearly every program and users are forced to master it. Any construction that supports disks is for the convenience of the programmer and the computer, and not to help the user.
The pervasiveness of the file system in our thinking and our design of software is as though refrigeration technology dominated the design of every room in our houses. Certainly, the invention of cheap mechanical refrigeration affected our domestic lives, but we don''t turn our houses into shrines to Freon. Yet this is largely what we have done on our desktop computers.
It is one thing to weave a technology invisibly into our lives. It is another thing altogether to allow our lives to be dominated by that technology. Refrigeration plays a big part in our lives in many ways, including food preparation, the production and storage of some medicines and air conditioning, yet we don''t usually find ourselves expressing our desires in terms of it. We don't go into a restaurant and say, "I'll have the salmon. It's been refrigerated, hasn't it?" We don't say, "You'll love working here, it's air conditioned." Omnipresent technologies don''t have to intrude on our conscious thoughts to work well for us. Unfortunately, this realization hasn't yet dawned on the computer industry, and we remain sadly dependent on the file-system model.
The last gaspThere are only two arguments that can be mounted in favor of application software implemented in the file-system model: Our software is already designed and built that way, and users are used to it.
Neither of these arguments holds water, though. The first one is irrelevant because new programs written with a unified file model can freely coexist with the older implementation model applications. The underlying file system doesn't change at all. In much the same way that toolbars have invaded the interfaces of most Windows applications in the last few years accompanied only by cheers and encouragement, the unified file model could also be implemented.
The second argument is more insidious, because its proponents are placing the user community in front of them like a shield. What's more, if you ask the users themselves, they will reject the new solution because they abhor change, particularly when that change affects something they have already worked hard to master-like the file system. In the '80s, the Chrysler company showed car-buyers early sketches of a dramatically new automobile design: the minivan. The buyers were asked if they would be interested in this new vehicle, and the public uniformly gave a thumbs-down to the new design. Chrysler went ahead and produced the Caravan anyway, convinced that the design was superior. They were right, and those same people who rejected the design have not only made the Caravan the best-selling minivan, but have made the minivan the most popular new automotive archetype since the convertible.
People will gladly give up painful, poorly designed software for easier, better software even if they don''t understand the explanations. After all, users aren''t software designers and they cannot be expected to visualize the larger effect of the change. Saying that users want to keep their familiar file-system model is like saying you want to break your leg again so you can return to the hospital because the food was so good the last time you were in there.
What People are Saying About This
Meet the Author
About the Author Alan Cooper is one of the most respected software designers of our time. He is the winner of the Microsoft Windows Pioneer Award for his work in designing Visual Basic. He is also one of the most outspoken critics of how the software industry goes about building the interface between products and people. His thirteen-year-old software design consulting company, Cooper Interaction Design, is based in Palo Alto, CA.
Most Helpful Customer Reviews
See all customer reviews