The application puts Alpha away on disk leaving her to edit New Alpha. But Alpha was never saved, so it gets written to disk without any of the changes she made in the last 20 minutes! Those changes only exist in the New Alpha copy that is currently in memory — in the application. As she begins cutting and pasting in New Alpha, trusting that her handiwork is backed up by Alpha, she is actually modifying the sole copy of this information.
Everybody knows that you can use a hammer to drive a screw or 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.
Implementation Model versus
Mental Model
The implementation model of the file system runs contrary to the mental model almost all users bring to it. Most users picture electronic files like printed 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 them. The file system’s implementation model violates both these rules: When a document is open, there are two copies of the document, and they both belong to the application they are open in.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 356
356
Part III: Designing Interaction Details
As we’ve discussed, every data file, every document, and every application, while in use by the computer, exists in two places at once: on disk and in main memory. A user, however, imagines his document as a book on a shelf. Let’s say it is a journal.
Occasionally, it comes down off the shelf to have something 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 and is 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 in computer memory. As the user makes changes to the document, he is actually making changes to the copy in memory, while the original remains untouched on disk. When the user is done and closes the document, the application is faced with a decision: whether to replace the original on disk with the changed copy from memory, or to discard the altered copy. 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 no decision to be made at all.
He made his changes, and 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, penciled in some additions, and then replaced it on the shelf. It’s as if the shelf suddenly were to speak up, asking him if he really wants to keep those changes!
Dispensing with the Implementation
Model
Right now, serious programmer-type readers are beginning to squirm in their seats.
They are thinking that we’re treading on holy ground: A pristine copy on disk is a wonderful thing, and we’d better not advocate getting rid of it. Relax! There is nothing terribly wrong with the implementation of our file systems (although we do look forward to greater support for indexing in Windows). We simply need to hide its existence from users. We can still offer users all the advantages of that extra copy on disk without exploding their mental model.
If we begin to render the file system according to users’ mental models, we can achieve several significant advantages. First, all users will become more effective. If they aren’t forced to spend effort and mental energy managing their computer’s file system, they’re going to be more focused on the task at hand. And of course, they won’t have to redo hours of work lost to a mistake in the complex chess game of versioning in contemporary operating systems.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 357
Chapter 17: Rethinking Files and Save
357
Second, we can all teach Mom how to really use computers well. We won’t have to answer her pointed questions about the inexplicable behavior of the interface. We can show her applications and explain how they allow 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. And Mom is representative of the mass-market of computer buyers, who may own and use computers, but don’t like them, trust them, or use them effectively.
Another big advantage is that interaction designers won’t have to incorporate clumsy file system awareness into their products. We can structure the commands in our applications according to the goals of users instead of according to the needs of the operating system. We no longer need to call the leftmost menu the File menu.
This nomenclature is a bold reminder of how technology currently pokes through the facade of our applications. We’ll discuss some alternatives later in this chapter.
Changing the name and contents of the File menu violates an established, though unofficial, standard. But 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 idioms, 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 no problem, and there will be no loss of functionality. The advantage for new users will be immediate and significant. We computer professionals forget how tall the mountain is after we’ve climbed it, but every day newcomers approach the base of this Everest of computer literacy and are severely discouraged. Anything we can do to lower the heights they must scale will make a big difference, and this step will tame some of the most perilous peaks.
Designing with a Unified File Model
Properly designed software should treat a document as a single thing, never as a copy on disk and a copy in memory. In this unified file model, users should never be forced to confront the internal mechanisms of the computer — it is the file system’s job to manage writing data between the disks and memory.
The established standard suite of file management for most applications includes Open, Save, and Close commands, and the related Save As, Save Changes, and Open dialogs. Collectively, these dialogs are, as we’ve shown, confusing for some tasks and completely incapable of performing other tasks. The following is a different approach to document management that better supports most users’ mental model.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 358
358
Part III: Designing Interaction Details
Besides presenting a document as a single entity, there are several goal-directed functions that a user may need to perform on a document; each one should have its own corresponding function.
Automatically saving
Creating a copy
Creating a version
Naming and renaming
Placing and repositioning in the file system
Specifying the document format
Reversing changes
Reverting to a different version
Automatically saving
One of the most important functions every computer user must learn is how to save a document. Invoking this function means taking whatever changes a user has made to the copy in computer memory and writing them onto the 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.
That doesn’t mean that it disappears from the application; it is still a very necessary operation.
DESIGN
/> Save documents and settings automatically.
principle
Applications should automatically save documents. For starters, when a user is done with a document and requests the Close function, the application should 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, this would be sufficient, 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 save, all your changes are 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 prevent this from happening, the application must also save the document at intervals during the user’s session. Ideally, the application will save every single little change as soon as the user makes it, in other
23_084113 ch17.qxp 4/3/07 6:08 PM Page 359
Chapter 17: Rethinking Files and Save
359
words, after each keystroke. For most applications, this is quite feasible. Another approach is to keep track of small changes in memory and write them to the disk at reasonable intervals.
It’s important that this automatic save function be performed in such a way as to not affect the responsiveness of the user interface. Saving should either be a background function, or should be performed when the user has stopped interacting with the application. Nobody types continuously. Everybody stops to gather his thoughts, or flip a page, or take a sip of coffee. All the application needs to do is wait until the user stops typing for a couple of seconds and then save.
Automatic save will be adequate for almost everybody. However, people who have been using computers for a long time are so paranoid about crashes and data loss that they habitually press Ctrl+S after every paragraph, and sometimes after every sentence. All applications should have manual save controls, but users should not be required to invoke manual saves.
Creating a copy
There should be an explicit function called Create a Copy. The copy will be identical to the original, but 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 of a file named
“Alpha” should automatically be given a name with a standard form like Alpha Copy. If there is already a document with that name, the new copy should be named “Alpha Copy #2.” (Another reasonable form would be “Copy of Alpha” and
“Second Copy of Alpha,” but the problem with this approach is that copies and originals would not be adjacent to each other in the default alphabetically sorted file directory.) 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 application should take its action quietly, efficiently, and sensibly, without badgering the user with silly dialogs like “Are you sure you want to make a Copy?” In the user’s mind it is a simple command. If there are any anomalies, the application should make a constructive decision on its own authority.
Naming and renaming
The name of the document should be shown on the application’s title bar. If the user decides to rename the document, he should be able to click on the title to edit it in place. What could be simpler and more direct than that?
23_084113 ch17.qxp 4/3/07 6:08 PM Page 360
360
Part III: Designing Interaction Details
Placing and moving
Most often when someone uses an application to edit a document, that document already exists. Documents are typically 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 the moment of creation or when we first save it, neither of these events is meaningful outside of the implementation model. The new file should be put somewhere reasonable where the user can find it again (such as the Desktop).
DESIGN
Put files where users can find them.
principle
The specific appropriate location should depend on your users and the posture of the product you are designing. For complex sovereign applications that most people use daily, it is sometimes appropriate to define an application-specific document location, but for transient applications or sovereign applications that are used less frequently, don’t hide your users’ files in your own special corner of the file system.
If a user wants to place the document somewhere else, he can request this function from the menu. A Move dialog would then appear with the current document highlighted. In this dialog (an appropriately named relative of the Save As dialog), the user can move the file to any location. The application thus places all files automatically, and this dialog is used only to move them elsewhere.
Specifying the stored format
At the bottom of the current Save As dialog shown in Figure 17-2, a combo box allows a user to specify a file format. This function should not be located here. By tying the format to the act of saving, users are confronted with additional, unnecessary complexity added to saving. In Word, if a user innocently changes the format, both the save function and any subsequent close action are accompanied by a frightening and unexpected confirmation box. Overriding the format of a file is a relatively rare occurrence. Saving a file is a very common occurrence. These two functions should not be combined.
From a user’s point of view, the format of the document — whether it is rich text, plain text, or Word format, for example — is a characteristic of the document rather than of the disk file. 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, accessible from a mechanism near the display of the document’s filename.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 361
Chapter 17: Rethinking Files and Save
361
This dialog box should have significant cautions built into its interface to make it clear to the user that the function could involve significant data loss.
In the case of some drawing applications, where saving image files to multiple formats is desirable, an Export dialog (which some drawing applications already support) is appropriate for this function.
Reversing changes
If a user inadvertently makes changes to the document that must be reversed, the tool already exists for correcting these actions: Undo (see Chapter 16 for more on Undo behaviors). 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 users in those terms. The concept of going directly to the file system to undo changes merely undermines the Undo function.
The version function described later in this chapter shows how a file-centric vision of Undo can be implemented so that it works well with the unified file model.
Abandoning all changes
While it’s not the most common of tasks, we certainly want to allow a user to discard all the changes she has made after opening or creating a document, so this action should be explicitly supported. Rather than forcing the user to understand the file system to achieve her goal, a simple Abandon Changes function on the main menu would suffice.
A similarly useful way to express this concept is Revert to version, which is based upon a version system described in the next section. Because Abandon Changes involves significant data loss, the user should be protected with clear warning signs. Making this function undoable would also be relatively easy to implement and highly desirable.
Creating a version
Creating a version is very similar to using the Copy command. The difference is that this copy is managed by the application and presented to users as the single document instance after it is made. It should also be clear to users that they can return to the state of the document at e
ach point that a version was made. Users should be able to see a list of versions along with various statistics about them, like the time each was recorded and its size or length. With a click, a user can select a version and, by doing so, he also immediately selects it as the active document. The document that was current at the time of the version selection will be created as a version itself. Also, since disk space is hardly a scarce resource these days, it makes sense to create versions regularly, in case it doesn’t occur to your users.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 362
362
Part III: Designing Interaction Details
A new File menu
Our new File menu now looks like the one shown in Figure 17-4, and functions as described below:
New and Open function as before.
Close closes the document without a dialog box or any other fuss, after automatically saving changes.
Rename/Move brings up a dialog that lets the user rename the current file or move it to another directory.
Create a Copy creates a new file that is a copy of the current document.
Print collects all printer-related controls in a single dialog.
Create Version is similar to Copy, except that the application manages these copies by way of a dialog box summoned by the Revert to Version menu item.
Abandon Changes discards all changes made to the document since it was opened or created.
Document Properties opens a dialog box that lets the user change the physical format of the document.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 49