<Previous Lesson

Human Computer Interaction

Next Lesson>



As the aim of this lecture is to introduce you the study of Human Computer
Interaction, so that after studying this you will be able to:

. Understand the significance of undo

. Discuss file and save

36.1 Understanding undo

Undo is the remarkable facility that lets us reverse a previous action. Simple and
elegant, the feature is of obvious value. Yet, when we examine undo from a goaldirected
point of view, there appears to be a considerable variation in purpose and
method. Undo is critically important for users, and it's not quite as simple as one
might think. This lecture explores the different ways users think about undo and the
different uses for such a facility.

Users and Undo

Undo is the facility traditionally thought of as the rescuer of users in distress; the
knight in shining armor; the cavalry galloping over the ridge; the superhero swooping
in at the last second.
As a computational facility, undo has no merit. Mistake-free as they are, computers
have no need for undo. Human beings, on the other hand, make mistakes all the time,
and undo is a facility that exists for their exclusive use. This singular observation
should immediately tell us that of all the facilities in a program, undo should be modeled the
least like its construction methods---its implementation model —and the most like the
user's mental model.
Not only do humans make mistakes, they make mistakes as part of their everyday
behavior. From the standpoint of a computer, a false start, a misdirected glance, a
pause, a hiccup, a sneeze, a cough, a blink, a laugh, an "uh," a "you know" are all
errors. But from the standpoint of the human user, they are perfectly normal. Human
mistakes are so commonplace that if you think of them as "errors" or even as
abnormal behavior, you will adversely affect the design of your software.

User mental models of mistakes

Users don't believe, or at least don't want to believe, that they make mistakes. This is
another way of saying that the user's mental model doesn't typically include error on
his part. Following the user's mental model means absolving the user of blame. The
implementation model, however, is based on an error-free CPU. Following the
implementation model means proposing that all culpability must rest with the user.
Thus, most software assumes that it is blameless, and any problems are purely the
fault of the user.

The solution is for the user interface designer to completely abandon the idea that the
user can make a mistake — meaning that everything the user does is something he or
she considers to be valid and reasonable. Users don't like to admit to mistakes in their
own minds, so the program shouldn't contradict these actions in its interactions with

Undo enables exploration

If we design software from the point of view that nothing users do should constitute a
mistake, we immediately begin to see things differently. We cease to imagine the user
as a module of code or a peripheral that drives the computer, and we begin to imagine
him as an explorer, probing the unknown. We understand that exploration involves
inevitable forays into blind alleys and box canyons, down dead ends and into dry
holes. It is natural for humans to experiment, to vary their actions, to probe gently
against the veil of the unknown to see where their boundaries lie. How can they know
what they can do with a tool unless they experiment with it? Of course the degree of
willingness to experiment varies widely from person to person, but most people
experimental least a little bit.
Programmers, who are highly paid to think like computers (Cooper, 1999), view such
behavior only as errors that must be handled by the code. From the implementation
model — necessarily the programmer's point of view such gentle, innocent probing
represents a continuous series of "mistakes”. From our more-enlightened, mental
model point-of-view, these actions are natural and normal. The program has the
choice of either rebuffing those perceived mistakes or assisting the user in his
explorations. Undo is thus the primary tool for supporting exploration in software user
interfaces. It allows the user to reverse one or more previous actions if he decides to
change his mind.
A significant benefit of undo is purely psychological: It reassures users. It is much
easier to enter a cave if you are confident that you can get back out of it at any time.
The undo function is that comforting rope ladder to the surface, supporting the user's
willingness to explore further by assuring him that he can back out of any dead-end
Curiously, users often don't think about undo until they need it, in much the same way
that homeowners don't think about their insurance policies until a disaster strikes.
Users frequently charge into the cave half prepared, and only start looking for the
rope ladder — for undo — after they have encountered trouble

Designing an Undo Facility

Although users need undo, it doesn't directly support a particular goal they bring to
their tasks. Rather, it supports a necessary condition — trustworthiness — on the way
to a real goal. It doesn't contribute positively to attaining the user's goal, but keeps
negative occurrences from spoiling the effort.
Users visualize the undo facility in many different ways depending on the situation
and their expectations. If the user is very computer-naive, he might see it as an
unconditional panic button for extricating himself from a hopelessly tangled
misadventure. A more experienced computer user might visualize undo as a storage
facility for deleted data. A really computer-sympathetic user with a logical mind
might see it as a stack of procedures that can be undone one at a time in reverse order.

In order to create an effective undo facility, we must satisfy as many of these mental
models as we expect our users will bring to bear.
The secret to designing a successful undo system is to make sure that it supports
typically used tools and avoids any hint that undo signals (whether visually, audibly,
or textually) a failure by the user. It should be less a tool for reversing errors and more
one for supporting exploration. Errors are generally single, incorrect actions.
Exploration, by contrast, is a long series of probes and steps, some of which are
keepers and others that must be abandoned.
Undo works best as a global, program-wide function that undoes the last action
regardless of whether it was done by direct manipulation or through a dialog box.
This can make undo problematic for embedded objects. If the user makes changes to a
spreadsheet embedded in a Word document, clicks on the Word document, and then
invokes undo, the most recent Word action is undone instead of the most recent
spreadsheet action. Users have a difficult time with this. It fails to render the juncture
between the spreadsheet and the word-processing document seamlessly: The undo
function ceases to be global and becomes modal. This is not an undo problem per se,
but a problem with the embedding technology.

36.2 Types and Variants of

As is so common in the software industry, there is no adequate terminology to
describe the types of undo that exist — they are uniformly called undo and left at that.
This language gap contributes to the lack of innovation in new and better variants of
undo. In this section, we define several undo variants and explain their differences.

36.3 Incremental and procedural actions

First, consider what objects undo operates on: the user's actions. A typical user action
in a typical application has a procedure component—what the user did — and an
optional data component — what information was affected. When the user requests an
undo function, the procedure component of the action is reversed, and if the action
had an optional data component — the user added or deleted data—that data will be
deleted or added back, as appropriate. Cutting, pasting, drawing, typing, and deleting
are all actions that have a data component, so undoing them involves removing or
replacing the affected text or image parts. Those actions that include a data
component are ailed incremental actions.
Many undoable actions are data-free transformations such as a paragraph
reformatting operation in a word processor or a rotation in a drawing program. Both
these operations act on data but neither of them add or delete data. Actions like these
(with only a procedure component) are procedural actions. Most existing undo
functions don't discriminate between procedural and incremental actions but simply
reverse the most recent action.

Blind and explanatory undo

Normally, undo is invoked by a menu item or toolbar control with an unchanging
label or icon. The user knows that triggering the idiom undoes the last operation, but
there is no indication of what that operation is. This is called a blind undo. On the
other hand, if the idiom includes a textual or visual description of the particular
operation that will be undone it is an explanatory undo. If, for example, the user's last

operation was to type in the word design, the undo function on the menu says Undo
Typing design. Explanatory undo is, generally, a much more pleasant feature than
blind undo. It is fairly easy to put on a menu item, but more difficult to put on a
toolbar control, although putting the explanation in a ToolTip is a good compromise.

36.4 Single and multiple undo

The two most-familiar types of undo in common use today are single undo and multiple
undo. Single undo is the most basic variant, reversing the effects of the most recent
user action, whether procedural or incremental. Performing a single undo twice usually
undoes the undo, and brings the system back to the state it was in before the first undo was
This facility is very effective because it is so simple to operate. The user interface is
simple and clear, easy to describe and remember. The user gets precisely one free lunch.
This is by far the most frequent ly implemented undo, and it is certainly adequate, if not
optimal, for many programs. For some users, the absence of this simple undo is sufficient
grounds to abandon a product entirely.
The user generally notices most of his command mistakes right away: Something
about what he did doesn't feel or look right, so he pauses to evaluate the situation. If the
representation is clear, he sees his mistake and selects the undo function to set things back to
the previously correct state; then he proceeds.
Multiple undo can be performed repeatedly in succession — it can revert more than one
previous operation, in reverse temporal order. Any program wi th simple undo must
remember the user's last operation and, if applicable, cache any changed data. If the program
implements multiple undo, it must maintain a stack of operations, the depth of which may be
settable by the user as an advanced preference. Each time undo is invoked, it performs
an incremental undo; it reverses the most recent operation, replacing or removing data
as necessary and discarding the restored operation from the stack.


The biggest limitation of single-level, functional undo is when the user accidentally
short-circuits the capability of the undo facility to rescue him. This problem crops up
when the user doesn't notice his mistake immediately. For example, assume he deletes
six paragraphs of text, then deletes one word, and then decides that the six paragraphs were
erroneously deleted and should be replaced. Unfortunately, performing undo now merely
brings back the one word, and the six paragraphs are lost forever. The undo function has failed
him by behaving literally rather than practically. Anybody can clearly see that the six
paragraphs are more important than the single word, yet the program freely discarded those
paragraphs in favor of the one word. The program's blindness caused it to keep a quarter
and throw away a fifty-dollar bill, simply because the quarter was offered last.
In some programs any click of the mouse, however innocent of function it might be, causes
the single undo function to forget the last meaningful thing the user did. Although
multiple undo solves these problems, it introduces some significant problems of its


"The response to the weaknesses of single-level undo has been to create a multiplelevel
implementation of the same, incremental undo. The program saves each action

the user takes. By selecting undo repeatedly, each action can be undone in the reverse
order of its original invocation. In the above scenario, the user can restore the deleted
word with the first invocation of undo and restore the precious six paragraphs with a
second invocation. Having to redundantly re-delete the single word is a small price to
pay for being able to recover those six valuable paragraphs. The excise of the oneword
re-deletion tends to not be noticed, just as we don't notice the cost of ambulance
trips: Don't quibble over the little stuff when lives are at stake. But this doesn't change
the fact that the undo mechanism is built on a faulty model, and in other
circumstances, undoing functions in a strict LIFO (Last In. First Out) order can make
the cure as painful as the disease.
Imagine again our user deleting six paragraphs of text, then calling up another
document and performing a global find-and-replace function. In order to retrieve the
missing six paragraphs, the user must first unnecessarily undo the rather complex
global find-and replace operation. This time, the intervening operation was not the
insignificant single-word deletion of the earlier exam-pie. The intervening operation
was complex and difficult and having to undo it is clearly an unpleasant, excise effort.
It would sure be nice to be able to choose which operation in the queue to undo and to
be able to leave intervening — but valid — operations untouched.


The problems with multiple undo are not due to its behavior as much as they are due
to its manifest model. Most undo faci l it ies are constructed in an unrelentingly
function-centric manner. They remember what the user does function-by-function and
separate the user's actions by individual function. In the time-honored way of creating
manifest models that follow implementation models, undo systems tend to model code
and data structures instead of user goals. Each click of the Undo button reverses
precisely one function-sized bite of behavior. Reversing on a function-by-function
basis is a very appropriate mental model for solving most simple problems caused by
the user making an erroneous entry. Users sense it right away and fix it right away,
usually within a two- or three-function limit. The Paint program in Windows 95, for
example, had a fixed, three-action undo limit. However, when the problem grows
more convoluted, the incremental, multiple undo models don’t scale up very well.


When the user goes down a logical dead-end (rather than merely mistyping data), he
can often proceed several complex steps into the unknown before realizing that he is
lost and needs to get a bearing on known territory. At this point, however, he may have
performed several interlaced functions, only some of which are undesirable. He may well
want to keep some actions and nullify others, not necessarily in strict reverse order. What if
the user entered some text, edited it, and then decided to undo the entry of that text but not undo
the editing of it? Such an operation is problematic to implement and explain. Neil Rubenking
offers this pernicious example: Suppose the user did a global replace changing tragedy to

catastrophe and then another changing cat to dog. To undo the first without undoing the second, can
the program reliably fix all the dogastrophes?
In this more complex situation, the simplistic representation of the undo as a single, straightline,
LIFO stack doesn't satisfy the way it does in-simpler situations. The user may be interested in
studying his actions as a menu and choosing a discontiguous subset of them for reversion, while
keeping some others. This demands an explanatory undo with a more robust presentation than
might otherwise be necessary for a normal, blind, multiple undo. Additionally, the means
for selecting from that presentation must be more sophisticated. Representing the operation in
the to clearly show the user what he is actually undoing is a more difficult problem.


The redo function came into being as the result of the implementation model for undo,
wherein operations must be undone in reverse sequence, and in which no operation may be
undone without first undoing all of the valid intervening operations. Redo essentially
undoes the undo and is easy to implement if the programmer has already gone to the effort to
implement undo.
Redo avoids a diabolical situation in mul t iple undo. If the user wants to back out of halfdozen
or so operations, he clicks the Undo control a few times, waiting to see things return
to the desired state. It is very easy in this situation to press Undo one time too many. He
immediately sees that he has undone something desirable. Redo solves this problem by
allowing him to undo the undo, putting back the last good action.
Many programs that implement single undo treat the last undone action as an undoable
action. In effect, this makes a second invocation of the undo function a minimal redo

Group multiple undo

Microsoft Word has an unusual undo facility, a variation of multiple undo we will call
group multiple undo. It is multiple-level, showing a textual description of each operation in the
undo stack. You can examine the list of past operations and select some operation in the
list to undo; however, you are not undoing that one operation, but rather all operations back
to that point, inclusive (see Figure on next page).
Essentially, you cannot recover the six missing paragraphs without first reversing all
the intervening operations. After you select one or more operations to undo, the list of
undone operations is now available in reverse order in the Redo control. Redo works
exactly the same way as undo works. You can select as many operations to redo as
desired and all operations up to that specific one will be redone.

The program offers two visual cues to this fact. If the user selects the fifth item in the list,
that item and al l four items previous to it in the list are selected. Also, the text legend
says ''Undo 5 actions." The fact that the designers had to add that text legend tells me
that, regardless of how the programmers constructed it , the users were applying a
different mental model. The users imagined that they could go down the list and select
a single action from the past to undo. The program didn't offer that option, so the signs
were posted. This is like the door with a pull handle pasted with Push signs — which
everybody still pulls on anyway.

36.5 Other Models for Undo-Like Behavior

The manifest model of undo in its simplest form, single undo, conforms to the user's
mental model: "I just did something I now wish I hadn't done. I want to click a button and
undo that last thing I did "Unfortunately, this manifest model rapidly diverges from the user's
mental model as the complexity of the situation grows. In this section, we discuss models of
undo-like behavior that work a bit differently from the more standard undo and redo idioms.

Comparison: What would this look like?

Resides providing robust support for the terminally indecisive, the paired undo-redo function is
a convenient comparison tool. Say you'd like to compare the visual effect of ragged-right
margins against justified right margins. Beginning with ragged-right, you invoke Justification.
Now you click Undo to see ragged-right and now you press Redo to see justified margins
again. In effect, toggling between Undo and Redo implements a comparison or what-if
function; it just happens to be represented in the form of its implementation model. If this same

function were to be added to the interface following the user's mental model, it might be
manifested as a comparison control. This function would let you repeatedly take one step
forward or backward to visually compare two states.
Some Sony TV remote controls include a function labeled Jump, which switches between the
current channel and the previous channel—very convenient for viewing two programs
concurrently. The jump function provides the same usefulness as the undo-redo function pair
with a single command—a 50% reduction in excise for the same functionality.
When used as comparison functions, undo and redo are really one function and not two. One
says "Apply this change," and the other says "Don't apply this change." A single Compare
button might more accurately represent the action to the user. Although we have been
describing this tool in the context of a text-oriented word processing program, a compare
function might be most useful in a graphic manipulation or drawing program, where the user is
applying successive visual transformations on images. The ability to see the image with the
transformation quickly and easily compared to the image without the transformation would be
a great help to the digital artist.
Doubtlessly, the compare function would remain an advanced function. Just as the jump
function is probably not used by a majority of TV users, the Compare button would remain one
of those niceties for frequent users. This shouldn't detract from its usefulness, however, because
drawing programs tend to be used very frequently by those who use them at all. For programs
like this, catering to the frequent user is a reasonable design choice.

Category-specific Undo

The Backspace key is really an undo function, albeit a special one. When the user
mistypes, the Backspace key "undoes" the erroneous characters. If the user mistypes
something, then enters an unrelated function such as paragraph reformatting, then presses
the Backspace key repeatedly, the mistyped characters are erased and the reformatting
operation is ignored. Depending on how you look at it, this can be a great flexible advantage
giving the user the ability to undo discontiguously at any selected location. You could also see
it as a trap for the user because he can move the cursor and inadvertently backspace away
characters that were not the last ones keyed in.
Logic says that this latter case is a problem. Empirical observation says that it is
rarely a problem for users. Such discontiguous, incremental undo — so hard to explain in
words — is so natural and easy to actually use because everything is visible: The user
can clearly see what will be backspaced away. Backspace is a classic example of an
incremental undo, reversing only some data while ignoring other, intervening actions. Yet if
you imagined an undo facility that had a pointer that could be moved and that could undo
the last function that occurred where the pointer points, you'd probably think that such a
feature would be patently unmanageable and would confuse the bejabbers out of a typical
user. Experience tel ls us that Backspace does nothing of the sort. It works as well as it
does because its behavior is consistent wi th the user's mental model of the cursor:
Because it is the source of added characters, it can also reasonably be the locus of deleted
Using this same knowledge, we could create different categories of incremental undo, like
a format-undo function that would only undo preceding format commands and other

types of category-specific undo actions. If the user entered some text, changed it to italic,
entered some more text, increased the paragraph indentation, entered some more text, then
pressed the Format-Undo key, only the indentation increase would be undone. A second press
of the Format-Undo key would reverse the italicize operation. But neither invocation of the
format-undo would affect the content.
What are the implications of category-specific undo in a non-text program? In a
graphics drawing program, for example, there could be separate undo commands for
pigment application tools, transformations, and cut-and-paste. There is really no
reason why we couldn't have independent undo functions for each particular class of
operation in a program

Pigment application tools include all drawing implements — pencils, pens, fills,
sprayers, brushes — and all shape tools — rectangles, lines, ellipses, arrows.
Transformations include all image-manipulation tools — shear, sharpness, hue, rotate,
contrast, line weight. Cut-and-paste tools include all lassos, marquees, clones, drags,
and other repositioning tools. Unlike the Backspace function in the word processor,
undoing a pigment application in a draw program would be temporal and would work
independently of selection. That is, the pigment that is removed first would be the last
pigment applied, regardless of the current selection. In text, there is an implied order from
the upper-left to the lower-right. Deleting from the lower-right to the upper-left maps
to a strong, intrinsic mental model; so it seems natural. In a drawing, no such
conventional order exists so any deletion order other than one based on entry sequence
would be disconcerting to the user.
A better alternative might be to undo wi thin the current selection only. The user
selects a graphic object, for example, and requests a transformation-undo. The last
transformation to have been applied to that selected object would be reversed.
Most software users are familiar with the incremental undo and would find a categoryspecific
undo novel and possibly disturbing. However, the ubiquitousness of the Backspace
key shows that incremental undo is a learned behavior that users find to be helpful. If more
programs had modal undo tools, users would soon adapt to them. They would even come to
expect them the way they expect to find the Backspace key on word processors.

Deleted data buffers

As the user works on a document for an extended time, his desire for a repository of
deleted text grows, it is not that he finds the ability to incrementally undo commands
useless but rather that reversing actions can cease to be so function-specific. Take for
example, our six missing paragraphs. If they are separated from us by a dozen complex
formatting commands, they can be as difficult to reclaim by undo as they are to re-key. The
user is thinking, "If the program would just remember the stuff I deleted and keep it in a
special place, 1 could go get what I want directly."
What the user is imagining is a repository of the data components of his actions, rather
than merely a LIFO stack of procedural — a deleted data buffer. The user wants the missing
text with out regard to which function elided it. The usual manifest model forces him not
only to be aware of every intermediate step but to reverse each of them, in turn. To create a
facility more amenable to the user, we can create, in addition to the normal undo
stack, an independent buffer that collects all deleted text or data. At any time, the user can

open this buffer as a document and use standard cut-and-paste or click-and-drag idioms to
examine and recover the desired text. If the entries in this deletion buffer are headed with
simple date stamps and document names, navigation would be very simple and visual
The user could 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 he 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 all programs, too, whether spreadsheet, drawing program, or invoice generator.

Mile stoning 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. Milestoning, simply makes a copy of the entire document the way a camera snapshot
freezes an image in time. Because milestoning involves the entire document, it is always
implemented by direct use of the file system. The biggest difference between milestoning and
other undo systems is that the user must explicitly request the milestone — recording a copy or
snapshot of the document. After he has done this, he can proceed to 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.
Many tools exist to support the milestoning concept in source code; but as yet, no
programs the authors are aware of present it directly to the user. Instead, they rely on the file
system's interface, which, as we have seen, is difficult for many users to understand. If
milestoning were rendered in a non-file-system user model, implementation would be
quite easy, and its management would be equally simple. A single button control could
save the document in its current state. The user could save as many versions at any interval as
he desires. To return to a previously milestoned version, the user would access a reversion facility.
The reversion facility is extremely simple — too simple, perhaps. Its menu item merely
says, Revert to Milestone. This is sufficient for a discussion of the file system; but
when considered as part of an undo function, it should offer more information. For
example, it should display a list of the available saved versions of that document along with
some informat ion about each one, such as the t ime and day it was recorded, the name
of the person who recorded it. the size, and some optional user-entered notes. The user
could choose one of these versions, and the program would load it, discarding any
intervening changes.


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
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. Procreate Painter offers a similar feature with its Wet Paint and Dry Paint

Undo Proof Operation

Some operations simply cannot be undone because they involve some action that
triggers a device not under the direct control of the program. After an e-mail message has
been sent, for example, ^ there is no undoing it. After a computer has been turned off
without saving data, there is no undoing the loss. 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. 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.

36.6 Rethinking Files and Save

If 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 ail right: Start up the
word processor and key in a letter. She's with you all the way. When you are finally done,
you click the Close button, and up pops a dialog box asking "Do you want to save
changes?" You and Mom hi t the wall together. She looks at you and asks, "What does
this mean: “Is everything okay?”
The part of modern computer systems that is the most difficult for users 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. This chapter provides a different way of
presenting interactions involving files and disks — one that is more in harmony with the
mental models of our users.

What's Wrong with Saving Changes to Files?

Every program exists in two places at once: in memory and on disk. The same is true
of every file. However, most users never truly grasp the difference between memory and
disk storage and how it pertains to the tasks they perform on documents in a computer
system. Without a doubt, the file system — along with the disk storage facility it manages
— is the primary cause of disaffection with computers among non-computer-professionals.
When that Save Changes? dialog box, shown in Figure, 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.
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 discussed in Chapter 9, 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 1

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 program 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 an obvious Revert
function). So what is the real problem? The file systems on modern personal computer
operating systems, like Windows XP 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.

Problems with the Implementation Model

The computer's file system is the tool it uses to manage data and programs stored on disk. This
means the large hard disks where most of your information resides, but it also includes your
floppy disks, ZIP disks, CD-ROMs, and DVDs if you have them. The Finder on the Mac and the
Explorer in Windows graphically represent the file system in all its glory.
Even though the file system is an internal facility that shouldn't — by all rights — affect the user, it
creates a large problem because the influence of the file system on the interface of most programs
is very pervasive. Some of the most difficult problems facing interaction designers 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. Kinder). 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 and unwanted changes

We computer geeks are conditioned to think that Close is the time and place for
abandoning unwanted changes if we make some error or are just noodling around. This is
not correct 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.


Save As

When you answer yes to the Save Changes dialog, many programs then present you
with the Save As dialog box.
Most users don't understand the concept of manual saving very well, so from their
point of view, the existing name of this dialog box doesn't make much sense.
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 int imate
knowledge of the file system. The user must know how to formulate a filename and how to
navigate through the file directory. Many users who have mastered the name portion have
completely given up on understanding the directory tree. They put their documents in
the directory that the program chooses for a default. All thei r files 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.
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 the user has named and placed a file, he
cannot then change its name or its directory — 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, you can rename other files using this
dialog, hut not the ones you are currently working on. Huh? The idea, one supposes,
is to allow you to rename other previously saved milestones of your document
because you can't rename the current one. But both operations ought to be possible
and be allowed

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 dialog from the File menu, and reopen the document. In case you
were wondering, the Open dialog doesn't allow renaming or repositioning either,
except in the bizarre cases mentioned in the previous paragraph.
Forcing the user to go to the 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 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. 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 rejects it
with a patronizing error message box.
The innocent user is merely trying to rename his document, and he finds himself lost
in an , archipelago of 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 to even try.

36.7 Archiving

There 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 differently. 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 that away. Others imagine that we
put Alpha away and continue work on Copy of Alpha.
The latter option will likely only occur to those who are already experienced with the
implementation model of file systems. It is how we do it today with the Save As
dialog: You have already saved the file as Alpha; and then you explicitly call up the
Save As dialog and change the name. Alpha is closed and put away on disk, and Copy
of Alpha is left open for editing. This action makes very little sense from a singledocument
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 you
have been editing Alpha for the last twenty minutes and now wish to make an archival
copy of it on disk so you can make some big but experimental changes to the original.
You call'up the Save As dialog box and change the file name to New Alpha. The
program puts Alpha away on disk leaving you to edit New Alpha. But Alpha was
never saved, so it gets written to disk without any of the changes you made in the last
twenty minutes! Those changes only exist in the New Alpha copy that is currently in
memory — in the program. As you begin cutting and pasting in New Alpha, trusting
that your handiwork is backed up by Alpha, you are 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 too! 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.

36.8 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 al l documents: First,
there is only one document; and second, it belongs to them. The file system's
implementation model violates both these rules: There are always two copies of the
document, and they both belong to the program.
Every data file, every document, and every program, while in use by the computer,
exists in two places at once: on disk and in main memory. The 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, 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 pro gram is faced with a decision: whether to replace the
original on disk with the changed copy from memory, or to discard the altered copy.
Prom 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

36.9 Dispensing with the Implementation Model of the
File System

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 wrong
with our file systems. We simply need to hide its existence from the user. We can still offer to
him all the advantages of that extra copy on disk without exploding his mental model.
If we begin to render the file system according to the user's mental model we achieve
a significant advantage: We can all teach our moms how to use computers. We won't have
to answer her pointed 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. And Mom
is representative of the mass-market of computer buyers.
Another big advantage is that interaction designers won't have to incorporate clumsy
f i le 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 nomenclature is a bold
reminder of how technology currently pokes through the facade of our programs. 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 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 no problem, and there will be no loss of functionality for
them. 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 everyday
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.

36.10 Designing a Unified File Presentation Model

Properly designed software will always treat documents as single instances, never as
a copy on disk and a copy in memory: a unified file model. It's the file system's job to
manage information 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 f i le that cannot be
changed because it is in use by another program, the f i le system should indicate this to the
user. Showing the filename in red or with a special symbol next to it would be sufficient. A
new user might still get an error message as shown in Figure 33-3; but, at least, some visual
clues would be present to show him that there was a reason why that error cropped up.

Not only are there two copies of all data files in the current model, but when they are
running, there are two copies of all programs. When the user goes to the Taskbar's
Start menu and launches his word processor, a button corresponding to Word appears on
the Taskbar. But if he returns to the Start menu. Word is st i l l there! Prom the users
point of view, he has pulled his hammer out of his toolbox only to find that there is still a
hammer in his toolbox!
This should probably not be changed; after all, one of the strengths of the computer is
its capa bility to have multiple copies of software running simultaneously. But the
software should help the user to understand this very non-intuitive action. The Start
menu could, for example make some reference to the already running program.

<Previous Lesson

Human Computer Interaction

Next Lesson>


Lesson Plan


Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Go to Top