BEHAVIOR & FORM: UNDERSTANDING UNDO, TYPES AND VARIANTS, INCREMENTAL AND PROCEDURAL ACTIONS

<< THE RELATIONSHIP BETWEEN EVALUATION AND USABILITY

UNIFIED DOCUMENT MANAGEMENT, CREATING A MILESTONE COPY OF THE DOCUMENT >>

Human Computer Interaction (CS408)

Lecture36

Lecture 36. Behavior & Form Part IV

Learning Goals

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

Understanding undo

36.1

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 goal-

directed 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.

327

Human Computer Interaction (CS408)

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

users.

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

caverns.

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.

328

Human Computer Interaction (CS408)

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.

Types and Variants of

36.2

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.

Incremental and procedural actions

36.3

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

329

Human Computer Interaction (CS408)

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.

Single and multiple undo

36.4

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

activated.

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 frequently 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 with 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.

LIMITATIONS OF SINGLE UNDO

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

own.

LIMITATIONS OF MULTIPLE UNDO

"The response to the weaknesses of single-level undo has been to create a multiple-

level implementation of the same, incremental undo. The program saves each action

330

Human Computer Interaction (CS408)

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 one-

word 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 MODEL PROBLEMS OF MULTIPLE UNDO

The problems with multiple undo are not due to its behavior as much as they are due

to its manifest model. Most undo facilities 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.

TOU BET YOUR LIFO

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

331

Human Computer Interaction (CS408)

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, straight-

line, 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.

Redo

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 multiple undo. If the user wants to back out of half-

dozen 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 h i m 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

function.

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.

332

Human Computer Interaction (CS408)

The program offers two visual cues to this fact. If the user selects the fifth item in the list,

that item and all 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.

Other Models for Undo-Like Behavior

36.5

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

333

Human Computer Interaction (CS408)

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 t h i n k that such a

feature would be patently unmanageable and would confuse the bejabbers out of a typical

user. Experience tells us that Backspace does nothing of the sort. It works as well as it

does because its behavior is consistent wi t h 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

characters.

Using this same knowledge, we could create different categories of incremental undo, like

a format-undo function tha t would only undo preceding format commands and other

334

Human Computer Interaction (CS408)

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 wit h i n 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 category-

specific 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

335

Human Computer Interaction (CS408)

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 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. The user

could choose one of these versions, and the program would load it, discarding any

intervening changes.

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

336

Human Computer Interaction (CS408)

ones. Procreate Painter offers a similar feature with its Wet Paint and Dry Paint

commands.

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.

Rethinking Files and Save

36.6

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 h i 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

337

Human Computer Interaction (CS408)

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 t h i n k 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.

338

Human Computer Interaction (CS408)

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 intimate

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 t h e i 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.

Archiving

36.7

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

339

Human Computer Interaction (CS408)

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 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 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.

Implementation Model versus Mental Model

36.8

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: 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

340

Human Computer Interaction (CS408)

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 of the

36.9

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

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 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.

Designing a Unified File Presentation Model

36.10

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 file that cannot be

changed because it is in use by another program, the file 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.

341

Human Computer Interaction (CS408)

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 th e 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 still 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.

342

Table of Contents: