|
|
|
|
|
|
Lesson#36
|
BEHAVIOR and FORM-4
|
|
|
|
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.
328
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.
329
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
330
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
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 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.
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 multiplelevel
implementation of the same, incremental undo. The program saves
each action
331
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 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 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.
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
332
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.
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 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
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.
333
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
334
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
characters.
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
335
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
336
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
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
337
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.
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
338
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.
339
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
340
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
341
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.
342
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. |
|
|
|
|