Users can then browse the buffer of deleted data at will, randomly, rather than sequentially. Finding those six missing paragraphs would be a simple, visual procedure, regardless of the number or type of complex, intervening steps she had taken.
A deleted data buffer should be offered in addition to the regular, incremental, multiple Undo because it complements it. The data must be saved in a buffer, anyway.
This feature would be quite useful in most programs, too, whether spreadsheet, drawing program, or invoice generator.
Versioning and reversion
Users occasionally want to back up long distances, but when they do, the granular actions are not terrifically important. The need for an incremental Undo remains, but discerning the individual components of more than the last few operations is overkill in most cases. Versioning (as we’ll discuss more in Chapter 17) simply makes a copy of the entire document the way a camera snapshot freezes an image in time. Because versioning involves the entire document, it is typically implemented by direct use of the file system. The biggest difference between versioning and other Undo systems is that the user must explicitly request the version —
recording a copy or snapshot of the document. After he has done this, he can safely modify the original. If he later decides that his changes were undesirable, he can return to the saved copy — a previous version of the document.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 347
Chapter 16: Understanding Undo
347
Many tools exist to support the milestoning concept in source code, but this concept is just emerging in the world outside of programming. 37signals’ Writeboard, for example, automatically creates versions of a collaborative text document, and allows users to compare versions, and of course, to revert to any previous version (see Figure 16-2).
Critical to the effectiveness of a versioning facility is the behavior of the “revert”
command. It should provide a list of the available saved versions of the document in question, along with some information about each one, such as the time and day it was recorded, the name of the person who recorded it, the size, and some optional user-entered notes. A user should be able to understand the differences among versions and ultimately choose to revert to any one of these versions, in which case, the current state of the document should be saved as another version that can be reverted to.
Figure 16-2 37signals’ Writeboard allows multiple people to collaborate on a single document. It creates a new version every time a user saves changes to the document, and allows users to compare the different versions. This can be quite useful as it allows collaboration to take its course without worry that valuable work will be overwritten.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 348
348
Part III: Designing Interaction Details
Freezing
Freezing, the opposite of milestoning, involves locking the data in a document so that it cannot be changed. Anything that has been entered becomes unmodifiable, although new data can be added. Existing paragraphs are untouchable, but new ones can be added between older ones.
This method is much more useful for a graphic document than for a text document. It is much like an artist spraying a drawing with fixative. All marks made up to that point are now permanent, yet new marks can be made at will. Images already placed on the screen are locked down and cannot be changed, but new images can be freely superimposed on the older ones. Corel Painter offers a similar feature with its Wet Paint and Dry Paint commands.
Undo-Proof Operations
Some operations simply cannot be undone because they involve some action that triggers a device not under the direct control of the program. For example, after an e-mail message has been sent, there is no undoing it. Many operations, however, masquerade as Undo-proof, but they are really easily reversible. For example, when you save a document for the first time in most programs, you can choose a name for the file. But almost no program lets you rename that file. Sure, you can Save As under another name, but that just makes another file under the new name, leaving the old file untouched under the old name. Why isn’t a filename Undo provided?
Because it doesn’t fall into the traditional view of what Undo is for; programmers generally don’t provide a true Undo function for changing a filename.
There are also situations where we’re told that it’s not possible to Undo an action because of business rules or institutional polices. Examples here include records of financial transactions, or entries in a medical record. In these cases, it may very well be true that “Undo” isn’t an appropriate function, but you can still better support human goals and mental models by providing a way to reverse or adjust the action while leaving an audit trail.
Spend some time looking at your own application and see if you can find functions that seem as if they should be undoable, but currently aren’t. You may be surprised by how many you find.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 349
17
Rethinking Files and Save
In the world of digital technology, the place where implementation-model thinking most strikingly rears its ugly head is the management of files and the concept of
“save.” If you have ever tried to teach your mother how to use a computer, you will know that difficult doesn’t really do the problem justice. Things start out all right: You start up the word processor and type a couple sentences. She’s with you all the way — it’s like writing on paper. But when you click the Close button, up pops a dialog box asking “Do you want to save changes?” You and Mom hit a wall together.
She looks at you and asks, “What does this mean? Is everything okay?”
This problem is caused by software that forces people to think like computers by unnecessarily making them confront the internal mechanisms of data storage. This isn’t just a problem for your mother; even sophisticated computer users can easily become confused or make mistakes. People spend thousands of dollars on hardware and software just to confront impertinent questions like “Do you really want me to save this document that you’ve been working on all afternoon?” and must remember to use to the Save As... command when what they really want to do is work on a copy of the document.
In our experience, people find computer file systems — the facilities that store application and data files on disk — very difficult to use and understand. This is one of the most critical components of computers, and errors here have significant
23_084113 ch17.qxp 4/3/07 6:08 PM Page 350
350
Part III: Designing Interaction Details
consequences. The difference between main memory and disk storage is not clear to most people, but unfortunately, the way we’ve historically designed software forces users — even your mom — to know the difference and to think about their documents in terms of the way a computer is constructed.
The popularization of Web applications and other database-driven software has been a great opportunity to abandon this baggage of computer file system implementation-model thinking. Unfortunately, a similar problem has arisen there —
every time a user makes a change to a document or setting, she is typically required to click a Submit or Save Changes button, once again forcing her to think about how the system works — in this case in terms of a client-server architecture.
This chapter provides a different way of presenting interactions involving files and saving — one that is more in harmony with the mental models of the people who use your products. Thankfully, we are not the only ones thinking in this way.
What’s Wrong with Saving
Changes to Files?
Every running application exists in two places at once: in memory and on disk.
The same is true of every open file. For the time being, this is a necessary state of affairs — our technology has different mechanisms for accessing data in a responsive way (memory) and storing that data for future use (disks). This, however
, is not what most people think is going on. Most of our mental models (aside from programmers) are of a single document that we are directly creating and making changes to.
When that Save Changes dialog box, shown in Figure 17-1, opens, users suppress a twinge of fear and confusion and click 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.
Figure 17-1 This is the question Word asks when you close a file after you have edited it. This dialog is a result of the programmer inflicting the implementation-model of the disk file system on the hapless user. This dialog is so unexpected by new users that they often choose No inadvertently.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 351
Chapter 17: Rethinking Files and Save
351
The Save Changes dialog box is based on a poor assumption: That saving and not saving are equally probable behaviors. The dialog gives equal weight to these two options even though the Yes button is clicked orders of magnitude more frequently than the No button. As we discussed in Chapter 10, this is a case of confusing possibility and probability. The user might say no, but the user will almost always say yes. Mom is thinking, “If I didn’t want those changes, why would I have closed the document with them in there?” To her, the question is absurd.
There’s something else a bit odd about this dialog: Why does it only 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 power users have gotten quite familiar with it.
The application issues the Save Changes 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 and the copy on the disk. The way the technology actually implements the facility associates saving changes with Close and Quit, but the user sees no connection. When we leave a room, we don’t consider discarding all 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.
As experienced users, we have learned to use this dialog box for purposes for which it was never intended. There is no easy way to undo massive changes, so we use the Save Changes dialog by choosing 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. This is handy, but it’s also a hack: There are better ways to address these problems (such as a Revert function).
So what is the real problem? The file systems on modern personal computer operating systems, like Windows XP, Vista, or Mac OS X, are technically excellent. The problem Mom is having stems from the simple mistake of faithfully rendering that excellent implementation model as an interface for users.
In actuality, many applications need not even concern themselves with document or file management. Apple’s iPhoto and iTunes both provide rich and easy-to-use functionality that allows a typical user to ignore the fact that a file even exists. In iTunes, a playlist can be created, modified, shared, put onto an iPod, and persist for years, despite the fact that a user has never explicitly saved it. Similarly, in iPhoto, image files are sucked out of a camera into the application and can be organized, shown, e-mailed, and printed, all without users ever thinking about the file system.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 352
352
Part III: Designing Interaction Details
Problems with the Implementation
Model
The computer’s file system is the tool it uses to manage data and applications stored on disk. This means the large hard drives where most of your information resides, but it also includes your flash (or “thumb”) drives, CD-Rs, DVD-Rs, and the hard drives of the servers on your network. The Mac OS Finder and Windows Explorer graphically represent the file system in all its glory.
DESIGN
Managing disks and files is not a user goal.
principle
Even though the file system is an internal facility that shouldn’t be the concern of users, it pervasively influences the user interface of most applications. It’s all too easy to revert to implementation-model thinking because there are difficult problems facing interaction designers looking to improve the experience of dealing with the file system. The implementation details of the file system directly affect our ability to construct useful and meaningful interactions around versions of documents, relationships between documents, and even the procedural framework of our applications. This influence is likely to continue indefinitely unless we make a concerted effort to stop it.
Currently, most software applications treat the file system in much the same way that the operating system does. This is tantamount to making you deal with your car in the same way a mechanic does. Although this approach is unfortunate from an interaction perspective, it is a de facto standard, and there is considerable resistance to improving it.
Closing documents and removing
unwanted changes
Those of us who have been using computers for a long time have been conditioned to think that the document Close function is the appropriate way to abandon unwanted changes if we make an error or are simply noodling around. This is not correct; 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.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 353
Chapter 17: Rethinking Files and Save
353
Save As
When you save a document for the first time or choose the Save As command from the File menu, many applications then present you with the Save As dialog box. A typical example is shown in Figure 17-2.
Functionally, this dialog offers two things: It lets users name a file, and it lets them choose which directory to place it in. Both of these functions demand that users have intimate knowledge of the file system and a fair amount of foresight into how they’ll need to retrieve the file later. Users must know how to formulate an acceptable and memorable filename and understand the hierarchical file directory. Many users who have mastered the name portion have completely given up on trying to understand the directory tree. They put their documents on their Desktop or in the directory that the application chooses for a default. Occasionally, some action will cause the application to forget its default directory, and these users must call in an expert to find their files for them.
Figure 17-2 The Save As dialog provides two functions: It lets you name your file and it lets you place it in a directory you choose. Users, however, don’t have a concept of saving, so the title of the dialog does not match their mental models of the function. Furthermore, if a dialog allows you to name and place a document, you might expect it would allow you to rename and replace a document as well.
Unfortunately, our expectations are confounded by poor design.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 354
354
Part III: Designing Interaction Details
The Save As dialog needs to decide what its purpose truly is. If it is to name and place files, then it does a very poor job. After a user has named and placed a file for the first time, he cannot change its name or its directory without creating a new document — at least not with this dialog, which purports to offer naming and placing functions — nor can he with any other tool in the application itself. In fact, in Windows XP, he can rename other files using this dialog, but not the ones he is currently working on. Huh? Beginners are out of luck, but experienced users learn the hard way that they can close the document, launch Windows Explorer, rename the file, return to the application, summon the Open dialog from the File menu, and reopen the document.
Forcing the user to go to Explorer to rename the document is a minor hardship, but therein lies a hidden trap. The bait is that Windows easily supports several applications running simultaneously. Attracted by this featu
re, 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 17-3. Trying to rename an open file is a sharing violation, and the operating system rejects it with a patronizing error message box.
The innocent user is merely trying to rename his document, and he finds himself lost in operating system arcana. Ironically, the one entity that has both the authority and the responsibility to change the document’s name while it is still open —
the application itself — refuses even to try.
Figure 17-3 If a user attempts to rename a file using the Explorer while Word is still editing it, the Explorer is too stupid to get around the problem. It is also too rude to be nice about it and puts up this patronizing error message. Rebuffed by both the editing application and the OS, it is easy for a new user to imagine that a document cannot be renamed at all.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 355
Chapter 17: Rethinking Files and Save
355
Archiving
There is no explicit function for making a copy of, or archiving, a document. Users must accomplish this with the Save As dialog, and doing so is as clear as mud. If a user has already saved the file as “Alpha,” she must explicitly call up the Save As dialog and change the name. Alpha is closed and put away on disk, and New Alpha is left open for editing. This action makes very little sense from a single-document viewpoint of the world, and it also offers a really nasty trap for the user.
Here is a completely reasonable scenario that leads to trouble: Let’s say that our user has been editing Alpha for the last 20 minutes and now wishes to make an archival copy of it on disk so she can make some big but experimental changes to the original. She calls up the Save As dialog box and changes the filename to “New Alpha.”
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 48