<Previous Lesson

Human Computer Interaction

Next Lesson>



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

. Discuss Unified Document Management

. Understand considerate and smart software

37.1 Unified Document Management

The established standard suite of file management for most applications consists of the
Save As dialog, the Save Changes dialog, and the Open File dialog. Collectively, these
dialogs are, as we've shown, confusing for some tasks and completely incapable of
performing others. The following is a different approach that manages documents according
to the user's mental model.
Besides rendering the document as a single entity, there are several goal-directed
functions that the user may have need for and each one should have its own
corresponding function.

. Automatically saving the document

. Creating a copy of the document

. Creating a milestone/milestoned copy of the document

. Naming and renaming the document

. Placing and repositioning the document

. Specifying the stored format of the document

. Reversing some changes

. Abandoning all changes

Automatically saving the document

One of the most important functions every computer user must learn is how to save a
document. Invoking this function means taking whatever changes the user has made to the
copy in computer memory and writing them onto the disk copy of the document. In the
unified model, we abolish all user interface recognition of the two copies, so the Save
function disappears completely from the mainstream interface. That doesn't mean that it
disappears from the program; it is still a very necessary operation.
The program should automatically save the document. At the very least, when the
user is done with the document and requests the Close function, the program will merely
go ahead and write the changes out to disk without stopping to ask for confirmation
with the Save Changes dialog box.
In a perfect world, that would be enough, but computers and software can crash,
power can fail, and other unpredictable, catastrophic events can conspire to erase your
work. If the power fails before you have clicked Close, all your changes are lost as the
memory containing them scrambles. The original copy on disk will be all right, but hours
of work can still be lost. To keep this from happening, the program must also save the
document at intervals during the user's session. Ideally, the program will save every single

little change as soon as the user makes it, in other words, after each keystroke. For most
programs, this is quite feasible. Most documents can be saved to hard disk in just a
fraction of a second. Only for certain programs—word processors leap to mind — would
this level of saving be difficult (but not impossible).
Word wi l l automatically save according to a countdown clock, and you can set the
delay to any number of minutes. If you ask for a save every two minutes, for example,
after precisely two minutes the program wi l l stop to write your changes out to disk
regardless of what you are doing at the time. If you are typing when the save begins, it
just clamps shut in a very realistic and disconcerting imitation of a broken program. It
is a very unpleasant experience. If the algorithm would pay attention to the user instead of
the clock, the problem would disappear. Nobody types continuously. Everybody stops to
gather his thoughts, or flip a page, or take a sip of coffee. All the program needs to do is
wait until the user stops typing for a couple of seconds and then save.
This automatic saving every few minutes and at close time will be adequate for
almost even body. Some people though, like the authors, are so paranoid about
crashing and losing data that they habitually press Ctrl+S after every paragraph, and
sometimes after every sentence (Ctrl+S is the keyboard accelerator for the manual save
function). AM programs should have manual save controls, but users should not be
required to invoke manual saves.
Right now, the save function is prominently placed on the primary program menu.
The save dialog is forced on all users whose documents contain unsaved changes when
users ask to close the document or to qui t or exit the program. These artifacts must go
away, but the manual save functionality can and should remain in place exactly as it is now.

Creating a copy of the document

This should be an explicit function called Snapshot Copy. The word snapshot makes it
clear that the copy is identical to the original, while also making it clear that the copy is not
tied to the original in any way. That is, subsequent changes to the original will have no
effect on the copy. The new copy should automatically be given a name with a standard
form like Copy of Alpha, where Alpha is the name of the original document. If there is
already a document with that name, the new copy should be named Second Copy of Alpha.
The copy should be placed in the same directory as the original.
It is very tempting to envision the dialog box that accompanies this command, but
there should be no such interruption. The program should take its action quietly,
efficiently, and sensibly, without badgering the user with silly questions like Make a
Copy? In the user's mind it is a simple command. If there are any anomalies, the program
should make a constructive decision on its own authority.

Naming and renaming the document

The name of the document should be shown on the application's title bar. If the user
decides to rename the document, he can just click on it and edit it in place. What could be
simpler and more direct than that?

Placing and moving the document

Most desktop productivity documents that are edited already exist. They are opened
rather than created from scratch. This means that their position in the file system is
already established. Although we think of establishing the home directory for a document
at either the moment of creation or the moment of first saving, neither of these events is

particularly meaningful outside of the implementation model. The new file should be put
somewhere reasonable where the user can find it again. .
If the user wants to explicitly place the document somewhere in the file system
hierarchy, he can request this function from the menu. A relative of the Save As
dialog appears with the current document highlighted. The user can then move the
file to any desired location. The program thus places all files automatically, and this
dialog is used only to move them elsewhere.

Specifying the stored format of the document

There is an additional function implemented on the Save As dialog.
The combo box at the bottom of the dialog allows the user to specify the physical format of
the file. This function should not be located here. By tying the physical format to the
act of saving, the user is confronted with additional, unnecessary complexity added to
saving. In Word, if the user innocently changes the format, both the save function and any
subsequent close action is accompanied by a frightening and unexpected confirmation box.
Overriding the physical format of a file is a relatively rare occurrence. Saving a file is a very
common occurrence. These two functions should not be combined.
From the user's point-of-view, the physical format of the document—whether it is rich text,
ASCII, or Word format, for example — is a characteristic of the document rather than of the
disk file. Specifying the format shouldn't be associated with the act of saving the file to disk.
It belongs more properly in a Document Properties dialog
The physical format of the document should be specified by way of a small dialog box
callable from the main menu. This dialog box should have significant cautions built into its
interface to make it clear to the user that the function could involve significant data loss.

In the case of some drawing programs, where saving image files to multiple formats is
desirable, an Export dialog (which some drawing programs already support) is appropriate
for this function.

Reversing changes

If the user inadvertently makes changes to the document that must be reversed, the
tool already exists for correcting these actions: undo. The file system should not be
called in as a surrogate for undo. The fi le system may be the mechanism for supporting
the function, but that doesn't mean it should be rendered to the user in those terms. The
concept of going directly to the file system to undo changes merely undermines the
undo function.
The milestoning function described later in this chapter shows how a file-centric
vision of undo can be implemented so that it works well with the unified file model.

Abandoning all changes

It is not uncommon for the user to decide that she wants to discard all the changes she
has made after opening or creating a document, so this action should be explicitly
supported. Rather than forcing the user to understand the file system to achieve her
goal, a simple Abandon Changes function on the main menu would suffice. Because
this function involves significant data loss, the user should be protected with clear
warning signs. Making this function undoable would also be relatively easy to implement
and highly desirable.

37.2 Creating a milestone copy of the document

Milestoning is very similar to the Copy command. The difference is that this copy is
managed by the application after it is made. The user can call up a Milestone dialog
box that lists each milestone along with various statistics about it, like the time it was
recorded and its length. With a click, the user can select a milestone and, by doing so,
he also immediately selects it as the active document. The document that was current at
the time of the new milestone selection wi l l be milestoned itself, for example, under
the name Milestone of Alpha 12/17/03, 1:53 PM. Milestoning is, in essence, a lightweight
form of versioning.

A new File menu

Our new File menu now looks like the one shown in Figure
New and Open function as before, but Close closes the document without a dialog
box or any other fuss, after an automatic save of changes. Rename/Move brings up a dialog that
lets the user rename the current file or move it to another directory. Make Snapshot
Copy creates a new file that is a copy of the current document. Print collects all printer-related
controls in a single dialog. Make Milestone is similar to Copy, except that the program manages
these copies by way of a dialog box summoned by the Revert to Milestone menu item. Abandon
Changes discards all changes made to the document since it was opened or created. Document
Properties opens a dialog box that lets the user change the physical format of the document. Exit
behaves as it does now, closing the document and application.


A new name for the File menu

Now that we are presenting a unified model of storage instead of the bifurcated
implementation model of disk and RAM, we no longer need to call the left-most application
menu the File menu — a reflection on the implementation model, not the user's model.
There are two reasonable alternatives.
We could label the menu after the type of documents the application processes. For
example, a spreadsheet application might label its left-most menu Sheet. An invoicing program
might label it Invoice,.
Alternatively, we can give the left-most menu a more generic label such as Document. This is a
reasonable choice for applications like word processors, spreadsheets, and drawing programs, but
may be less appropriate for more specialized niche applications.
Conversely, those few programs that do represent the contents of disks as files — generally
operating system shells and utilities —should have a File menu because they are addressing files
as files.

37.3 Are Disks and Files Systems a Feature?

From the user's point of view, there is no reason for disks to exist. From the hardware
engineer's point of view, there are three:

. Disks are cheaper than solid-state memory.

. Once written to, disks don't forget when the power is off.

. Disks provide a physical means of moving information from one computer to
Reasons two and three are certainly useful, but they are also not the exclusive
domains of disks. Other technologies work as well or better. There are varieties of RAM
that don't forget thei r data when the power is turned off. Some types of solid-state memory
can retain data with little or no power. Networks and phone lines can be used to
physically transport data to other sites, often more easily than with removable disks.
Reason number one — cost — is the real reason why disks exist. Non-volatile solid-state memory
is a lot more expensive than disk drives. Reliable, high-bandwidth networks haven't
been around as long as removable disks, and they are more expensive.
Disk drives have many drawbacks compared to RAM. Disk drives are much slower
than solid-state memory. They are much less reliable, too, because they depend on
moving parts. They generally consume more power and take up more space, too. But the
biggest problem with disks is that the computer, the actual CPU, can't directly read or write to
them! Its helpers must first bring data into solid-state memory before the CPU can work with
it. When the CPU is done, its helpers must once again move the data back out to the disk.
This means that processing that involves disks is necessarily orders of magnitude slower and
more complex than working in plain RAM.
The time and complexity penalty for using disks is so severe that nothing short of enormous
cost-differential could compel us to rely on them. Disks do not make computers
better, more powerful, faster, or easier to use. Instead, they make computers weaker,
slower, and more complex. They are a compromise, a dilution of the solid-state
architecture of digital computers. If computer designers could have economically used
RAM instead of disks they would have done so without hesitation - and in fact they do, in

the newest breeds of handheld communicators and PDAs that make use of Compact Plash
and similar solid-state memory technologies.
Wherever disk technology has left its mark on the design of our software, it has done so
for implementation purposes only, and not in the service of users or any goal-directed design

37.4 Time for Change

There are only two arguments that can be mounted in favor of application software implemented
in the file system model: Our software is already designed and built that way, and users are used
to it
Neither of these arguments is valid. The first one is irrelevant because new programs written with
a unified file model can freely coexist with the older implementation model applications. The
underlying file system doesn't change at all. In much the same way that toolbars quickly invaded
the interfaces of most applications in the last few years, the unified file model could also be
implemented with similar success and user acclaim.
The second argument is more insidious, because its proponents place the user community in
front of them like a shield. What's more, if you ask users themselves, they will reject the new
solution because they abhor change, particularly when that change affects something they have
already worked hard to master — like the file system. However, users are not always the best
predictors of design successes, especially when the designs are different from anything they've
already experienced,
In the eighties, Chrysler showed consumers early sketches of a dramatic new
automobile design: the minivan. The public gave a uniform thumbs-down to the new
design. Chrysler went ahead and produced the Caravan anyway, convinced that the
design was superior. They were right, and the same people who initially rejected the
design have not only made the Caravan the one of the best-selling minivans, but also
made the minivan the most popular new automotive archetype since the convertible.
Users aren't interaction designers, and they cannot be expected to visualize the larger
effects of interaction paradigm shifts. But the market has shown that people will
gladly give up painful, poorly designed software for easier, better software even if
they don't understand the explanations behind the design rationale

37.5 Making Software Considerate

Two Stanford sociologists, Clifford Nass and Byron Reeves, discovered that humans
seem to have instincts that tell them how to behave around other sentient beings. As
soon as any artifact exhibits sufficient levels of interactivity — such as that found in
your average software application — these instincts are activated. Our reaction to
software as sentient is both unconscious and unavoidable.
The implication of this research is profound: If we want users to like our software, we
should design it to behave in the same manner as a likeable person. If we want users
to be productive with our software, we should design it to behave like a supportive
human colleague.

Designing Considerate Software

Nass and Reeves suggest that software should be polite, but the term considerate is
preferred. Although politeness could be construed as a matter of protocol —saying

please and thank you, but doing little else helpful — being truly considerate means
putting the needs of others first. Considerate software has the goals and needs of its
users as its primary concern beyond its basic functions.
If software is stingy with information, obscures its process, forces the user to hunt around
for common functions, and is quick to blame the user for its own failings, the user will dislike
the software and have an unpleasant experience. This will happen regardless of how cute, how
representational, how visually metaphoric, how content-filled, or how anthropomorphic the
software is.
On the other hand, if the interaction is respectful, generous, and helpful, the user will like
the software and will have a pleasant experience. Again, this will happen regardless of the
composition of the interface; a green-screen command-line interface will be well liked if it can
deliver on these other points.

What Makes Software Considerate?

Humans have many wonderful characteristics that make them considerate but whose
definitions are fuzzy and imprecise. The following list enumerates some of the
characteristics of considerate interactions that software-based products (and humans)
should possess:

. Considerate software takes an interest.

. Considerate software is deferential.

. Considerate software is forthcoming.

. Considerate software uses common sense.

. Considerate software anticipates needs.

. Considerate software is conscientious.

. Considerate software doesn't burden you with its personal problems.

. Considerate software keeps you informed.

. Considerate software is perceptive.

. Considerate software is self-confident.

. Considerate software doesn't ask a lot of questions.

. Considerate software takes responsibility.

. Considerate software knows when to bend the rules.
Well now discuss the characteristics in detail.

Considerate software takes an interest

A considerate friend wants to know more about you. He remembers likes and
dislikes so he can please you in the future. Everyone appreciates being treated
according to his or her own personal tastes
Most software, on the other hand, doesn't know or care who is using it. Little, if any, of the
personal software on our personal computers seems to remember anything about us, in
spite of the fact that we use it constantly, repetitively, and exclusively.
Software should work hard to remember our work habits and, particularly, everything that
we say to it. To the programmer writing the program, it's a just-in-time information world,
so when the program needs some tidbit of information, it simply demands that the user
provide it. The-program then discards that tidbit, assuming that it can merely ask for it
again if necessary. Not only is the program better suited to remembering than the
human, the program is also inconsiderate when, acting as a supposedly helpful tool, it


Considerate software is deferential

A good service provider defers to her client. She understands the person she is
serving is the boss. When a restaurant host shows us to a table in a restaurant, we consider
his choice of table to be a suggestion, not an order. If we politely request another table
in an otherwise empty restaurant, we expect to be accommodated. If the host refuses,
we are likely to choose a different restaurant where our desires take precedence over the
Inconsiderate software supervises and passes judgment on human actions. Software is
wi thin its rights to express its opinion that we are making a mistake, but it is being
presumptuous when it judges our actions. Software can suggest that we not Submit our
entry until we've typed in our telephone number. It should also explain the consequences,
but if we wish to Submit without the number, we expect the software to do as it is told.
(The very word Submit and the concept it stands for are a reversal of the deferential role.
The software should submit to the user, and any program that proffers a Submit button is
being rude. Take notice, almost every transactional site on the World Wide Web!)

Considerate software is forthcoming

If we ask a store employee where to locate an item, we expect him to not only answer
the question, but to volunteer the extremely useful collateral information that a more
expensive, higher quality item like it is currently on sale for a similar price.
Most software doesn't attempt to provide related information. Instead, it only
narrowly answers the precise questions we ask it, and it is typically not forthcoming
about other information even if it is clearly related to our goals. When we tell our word
processor to print a document, it doesn't tell us when the paper supply is low, or when
forty other documents are queued up before us, or when another nearby printer is free. A
helpful human would.

Considerate software uses common sense

Offering inappropriate functions in inappropriate places is a hallmark of software-based
products. Most software-based products put controls for constantly used functions adjacent
to never-used controls. You can easily find menus offering simple, harmless functions
adjacent to irreversible ejector-seat-lever expert functions. It's like seating you at a dining
table right next to an open grill.

Considerate software anticipates needs

A human assistant knows that you will require a hotel room when you travel to another
city, even when you don't ask explicitly. She knows the kind of room you like and reserves
one without any request on your part. She anticipates needs.
A Web browser spends most of its time idling while we peruse Web pages. It could easily
anticipate needs and prepare for them while we are reading. It could use that idle time to
preload all the links that are visible. Chances are good that we will soon ask the browser to
examine one or more of those links. It is easy to abort an unwanted request, but it is always
time-consuming to wait for a request to be filled.


Considerate software is conscientious

A conscientious person has a larger perspective on what it means to perform a task.
Instead of just washing the dishes, for example, a conscientious person also wipes down the
counters and empties the trash because those tasks are also related to the larger goal: cleaning
up the kitchen. A conscientious person, when drafting a report, also puts a handsome cover
page on it and makes enough photocopies for the entire department.

Considerate software doesn't burden you with its personal problems

At a service desk, the agent is expected to keep mum about her problems and to show a reasonable
interest in yours. It might not be fair to be so one-sided, but that's the nature of the
service business. Software, too, should keep quiet about its problems and show interest in ours.
Because computers don't have egos or tender sensibilities, they should be perfect in this role; but
they typically behave the opposite way.
Software whines at us with error messages, interrupts us with confirmation dialog
boxes, and brags to us with unnecessary notifiers (Document Successfully Saved!
How nice for you, Mr. Software: Do you ever unsuccessfully save?). We aren't interested
in the program's crisis of confidence about whether or not to purge its Recycle bin. We
don't want to hear its whining about not being sure where to put a file on disk. We don't
need to see information about the computer's data transfer rates and its loading
sequence, any more than we need information about the customer service agent's
unhappy love affair. Not only should software keep quiet about its problems, but it should
also have the intelligence, confidence, and authority to fix its problems on its own.

Considerate software keeps us informed

Although we don't want our software pestering us incessantly with its little fears and
triumphs, we do want to be kept informed about the things that matter to us. Software can
provide us with modeless feedback about what is going on.

Considerate software is perceptive

Most of our existing software is not very perceptive. It has a very narrow
understanding of the scope of most problems. It may willingly perform difficult work,
but only when given the precise command at precisely the correct time. If, for example, you
ask the inventory query system to tell you how many widgets are in stock, it will
dutifully ask the database and report the number as of the time you ask. But what if,
twenty minutes later, someone in your office cleans out the entire stock of widgets. You
are now operating under a potentially embarrassing misconception, while your computer
sits there, idling away billions of wasted instructions. It is not being perceptive. If you
want to know about widgets once, Isn't that a good clue that you probably will want to
know about widgets again? You may not want to hear widget status reports every day for
the rest of your life, but maybe you'll want to get them for the rest of the week.
Perceptive software observes what the user is doing and uses those patterns to offer
relevant information.
Software should also watch our preferences and remember them without being asked
explicitly to do so. If we always maximize an application to use the entire available
screen, the application should get the idea after a few sessions and always launch in that

configuration. The same goes for placement of palettes, default tools, frequently used
templates, and other useful settings.

Considerate software is self-confident

Software should stand by its convictions. If we tell the computer to discard a file, It
shouldn't ask, "Are you sure?" Of course we're sure, otherwise we wouldn't have asked. It
shouldn't second-guess itself or us.
On the other hand, if the computer has any suspicion that we might be wrong (which
Is always), it should anticipate our changing our minds by being prepared to undelete the
file upon our request.
How often have you clicked the Print button and then gone to get a cup of coffee, only to
return to find a fearful dialog box quivering in the middle of the screen asking, "Are you sure
you want to print?" This insecurity is infuriating and the antithesis of considerate human

Considerate software doesn't ask a lot of questions

Inconsiderate software asks lots of annoying questions- Excessive choices quickly
stop being a benefit and become an ordeal.
Choices can be offered in different ways. They can be offered in the way that we window shop.
We peer in the window at our leisure, considering, choosing, or ignoring the goods offered
to us — no questions asked. Alternatively, choices can be forced on us like an interrogation
by a customs officer at a border crossing: "Do you have anything to declare?" We don't
know the consequences of the question. Will we be searched or not? Software should
never put users through this kind of intimidation.

Considerate software fails gracefully

When a friend of yours makes a serious faux pas, he tries to make amends later and
undo what damage can be undone. When a program discovers a fatal problem, it has the
choice of taking the time and effort to prepare for its failure without hurting the user, or it
can simply crash and burn. In other words, it can either go out like a psychotic postal
employee, taking the work of a dozen coworkers and supervisors with it, or it can tidy up
its affairs, ensuring that as much data as possible is preserved in a recoverable format.
Most programs are filled with data and settings. When they crash, that information
is normally just discarded. The user is left holding the bag. For example, say a program is
computing merrily along, downloading your e-mail from a server when it runs out of
memory at some procedure buried deep in the internals of the program. The program,
like most desktop software, issues a message that says, in effect, "You are completely
hosed," and terminates immediately after you click OK. You restart the program, or
sometimes the whole computer, only to find that the program lost your e-mail and, when
you interrogate the server, you find that it has also erased your mail because the mail was
already handed over to your program. This is not what we should expect of good
In our e-mail example, the program accepted e-mail from the server — which then
erased its copy — but didn't ensure that the e-mail was properly recorded locally. If the email
program had made sure that those messages were promptly written to the local disk,

even before it informed the server that the messages were successfully downloaded, the
problem would never have arisen.
Even when programs don't crash, inconsiderate behavior is rife, particularly on the
Web. Users often need to enter detailed information into a set of forms on a page. After
filling in ten or eleven fields, a user might press the Submit button, and, due to
some mistake or omission on his part, the site rejects his input and tells him to correct
it. The user then clicks the back arrow to return to the page, and lo, the ten valid entries
were inconsiderately discarded along with the single invalid one.

Considerate software knows when to bend the rules

When manual information processing systems are translated into computerized
systems, something is lost in the process. Although an automated order entry system
can handle millions more orders than a human clerk can, the human clerk has the ability
to work the system in a way most automated systems ignore. There is almost never a way to
jigger the functioning to give or take slight advantages in an automated system.
In a manual system, when the clerk's friend from the sales force calls on the phone
and explains that getting the order processed speedily means additional business, the
clerk can expedite that one order. When another order comes in with some critical
information missing, the clerk can go ahead and process it, remembering to acquire and
record the information later. This flexibility is usually absent from automated systems.
In most computerized systems, there are only two states: non existence or fullcompliance.
No intermediate states are recognized or accepted. In any manual system,
there is an important but paradoxical state — unspoken, undocumented, but widely relied
upon — of suspense, wherein a transaction can be accepted although still not being ful ly
processed. The human operator creates that state in his head or on his desk or in his back
For example, a digital system needs both customer and order information before it can
post an invoice. Whereas the human clerk can go ahead and post an order in advance of
detailed customer information, the computerized system will reject the transaction,
unwilling to allow the invoice to be entered without it.
The characteristic of manual systems that let humans perform actions out of sequence
or before prerequisites are satisfied is called fudgeability. It is one of the first
casualties when systems are computerized, and its absence is a key contributor to the
inhumanity of digital systems. It is a natural result of the implementation model. The
programmers don't see any reason to create intermediate states because the computer
has no need for them. Yet there are strong human needs to be able to bend the system
One of the benefits of fudgeable systems is the reduction of mistakes. By allowing many
small temporary mistakes into the system and entrusting humans to correct them before
they cause problems downstream, we can avoid much bigger, more permanent
mistakes. Paradoxically, most of the hard-edged rules enforced by computer systems are
imposed to prevent just such mistakes. These inflexible rules cast the human and the
software as adversaries, and because the human is prevented from fudging to prevent big
mistakes, he soon stops caring about protecting the software from really colossal problems.
When inflexible rules are imposed on flexible humans, both sides lose. It is invariably bad
for business to prevent humans from doing what they want, and the computer system usually
ends up having to digest invalid data anyway.

In the real world, both missing information and extra information that doesn't fit into a
standard field are important tools for success. Information processing systems rarely handle
this real-world data. They only model the rigid, repeatable data portion of
transactions, a sort of skeleton of the actual transaction, which may involve dozens of
meetings, travel and entertainment, names of spouses and kids, golf games and favorite sports
figures. Maybe a transaction can only be completed if the termination date is extended two
weeks beyond the official limit. Most companies would rather fudge on the termination
date than see a million-dollar deal go up in smoke. In the real world, limits are fudged
all the time. Considerate software needs to realize and embrace this fact.

Considerate software 'takes' responsibility

Too much software takes the attitude: "It isn't my responsibility." When it passes a
job along some hardware device, it washes its hands of the action, leaving the stupid hardware
to finish up. Any user can see that the software isn't being considerate or conscientious, that the
software isn’t shouldering i ts part of the burden for helping the user become more effective.
In a typical print operation, for example, a program begins sending the 20 pages of a report to
the printer and simultaneously puts up a print process dialog box with a Cancel button. If the user
quickly realizes that he forgot to make an important change, he clicks the Cancel button just
as the first page emerges from the printer. The program immediately cancels the print
operation. But unbeknownst to the user, while the printer was beginning to work on
page 1, the compute has already sent 15 pages into the printer's buffer. The program cancels
the last five pages, but the printer doesn't know anything about the cancellation; it just knows
that it was sent 15 pages, so it goes ahead and prints them. Meanwhile, the program smugly tells
the user that the function was canceled. The program lies, as the user can plainly see.
The user isn't very sympathetic to the communication problems between the
application am the printer. He doesn't care that the communications are one-way. All he knows
is that he decide not to print the document before the first page appeared in the printer's
output basket, he clicked the Cancel button, and then the stupid program continued
printing for 15 pages even though hi acted in plenty of time to stop it. It even acknowledged
his Cancel command. As he throws the 15 wasted sheets of paper in the trash, he growls at the
stupid program.
Imagine what his experience would be if the application could communicate with the print driver
and the print driver could communicate with the printer. If the software were smart
enough the print job could easily have been abandoned before the second sheet of paper was
wasted. The printer certainly has a Cancel function — it's just that the software is too
indolent to use it, because its programmers were too indolent to make the connection.

37.6 Considerate Software Is possible

Our software-based products irritate us because they aren't considerate, not because
they lack features. As this list of characteristics shows, considerate software is usually no
harder to build than rude or inconsiderate software. It simply means that someone has to
envision interaction that emulates the qualities of a sensitive and caring friend. None of
these characteristics is at odds with the other, more obviously pragmatic goals of business
computing. Behaving more humanely can be the most pragmatic goal of all.


37.7 Making Software Smarts:

Because every instruction in every program must pass single-file through the CPU,
we tend to optimize our code for this needle's eye. Programmers work hard to keep the
number of instructions to a minimum, assuring snappy performance for the user. What we often
forget, however, is that as soon as the CPU has hurriedly finished all its work, it waits idle,
doing nothing, until the user issues another command. We invest enormous efforts in
reducing the computer's reaction time, but we invest little or no effort in putting it to work
proactively when it is not busy reacting to the user. Our software commands the CPU as
though it were in the army, alternately telling it to hurry up and wait. The hurry up part is
great, but the waiting needs to stop.
The division of labor in the computer age is very clear: The computer does the work, and
the user does the thinking. Computer scientists tantalize us with visions of artificial
intelligence: computers that think for themselves. However, users don't really need much
help in the thinking department. They do need a lot of help with the work of information
management—activities like finding and organizing information — but the actual
decisions made from that information are best made by the wetware — us.
There is some confusion about smart software. Some naive observers think that smart
software is actually capable of behaving intelligently, but what the term really means is
that these programs are capable of working hard even when conditions are difficult and even
when the user isn't busy. Regardless of our dreams of thinking computers, there is a much
greater and more immediate opportunity in simply getting our computers to work harder.
This lecture discusses some of the most important ways that software can work a bit harder to
serve humans better.

37.8 Putting the Idle Cycles to Work

In our current computing systems, users need to remember too many things, such as the
names they give to files and the precise location of those files in the file system. If a
user wants to find that spreadsheet with the quarterly projections on it again, he must
either remember its name or go browsing. Meanwhile, the processor just sits there, wasting
billions of cycles.
Most current software also takes no notice of context. When a user is struggling with a
particularly difficult spreadsheet on a tight deadline, for example, the program offers precisely
as much help as it offers when he is noodling with numbers in his spare time. Software can
no longer, in good conscience, waste so much idle time while the user works. It is time for
our computers to begin to shoulder more of the burden of work in our day-to-day activities.

Wasted cycles

Most users in normal situations can't do anything in less than a few seconds. That is
enough time for a typical desktop computer to execute at least a billion instructions. Almost
without fail, those interim cycles are dedicated to idling. The processor does nothing
except wait. The argument against putting those cycles to work has always been: "We can't
make assumptions; those assumptions might be wrong." Our computers today are so powerful
that, although the argument is stilt true, it is frequently irrelevant. Simply put, it doesn't
matter if the program's assumptions are wrong; it has enough spare power to make
several assumptions and discard the results of the had ones when the user finally makes
his choice.

With Windows and Mac OS X's pre-emptive, threaded multitasking, you can perform
extra work in the background without affecting the performance the user sees. The
program can launch a search for a file, and if the user begins typing, merely abandon
it until the next hiatus. Eventually, the user stops to think, and the program will have time
to scan the whole disk. The user won't even notice.
Every time the program puts up a modal dialog box, it goes into an idle waiting state, doing no
work while the user struggles with the dialog. This should never happen. It would not
be hard for the dialog box to hunt around and find ways to help. What did the user do
last time? The program could, for example, offer the previous choice as a suggestion for
this time.
We need a new, more proactive way of thinking about how software can help people with their
goals and tasks.

Putting the cycles to better use

If your program, Web site, or device could predict what the user is going to do next,
couldn't it provide a better interaction? If your program could know which selections the user
will make in a particular dialog box or form, couldn't that part of the interface be
skipped? Wouldn't you consider advance knowledge of what actions your users take to be an
awesome secret weapon of interface design?
Well, you can predict what your users will do. You can build a sixth sense into your
program that will tell it with uncanny accuracy exactly what the user will do next! All those
billions of wasted processor cycles can be put to great use: All you need to do is give your
interface a memory.

37.9 Giving Software a Memory

When we use the term memory in this context, we don't mean RAM, but rather a
program facility for tracking and responding to user actions over multiple sessions. If
your program simply remembers what the user did the last time (and how), it can use that
remembered behavior as a guide to how it should behave the next time. As we'll see later in
this chapter, your program should remember more than one previous action, but this
simple principle is one of the most effective tools available for designing software
You might think that bothering with a memory isn't necessary; it's easier to just ask
the user each time. Programmers are quick to pop up a dialog box to request any
information that isn't lying conveniently around. But as we discussed, people don't like to be
asked questions. Continually interrogating users is not only a form of excise, but from a
psychological perspective, it is a subtle way of expressing doubt about their authority.
Most software is forgetful, remembering l i t t le or nothing from execution to execution. If our
programs are smart enough to retain any information during and between uses, it is usually
information that makes the job easier for the programmer and not for the user. The program
willingly discards information about the way it was used, how it was changed, where it was
used, what data g it processed, who used it, and whether and how frequently the various
facilities of the program were used. Meanwhile, the program fills initialization files with
driver-names, port assignments, and other details that ease the programmer's burden. It is possible
to use the exact same facilities to dramatically increase the smarts of your software from the
perspective of the user.


37.10 Task Coherence

Does this kind of memory really work? Predicting what a user will do by
remembering what he did -last is based on the principle of task coherence: the idea that our
goals and the way we achieve them (via tasks) is generally the same from day to day. This is not
only true for tasks like brushing our teeth and eating our breakfasts, but it also describes how we
use our word processors, e-mail programs, cell phones, and e-commerce sites.
When a consumer uses your product, there is a high-percentage chance that the functions he
uses and the way he uses them will be very similar to what he did last time he used your
program. He may even be working on the same documents, oral least the same types of
documents, located similar places. Sure, he won't be doing the exact same thing each
time, but it will likely be variant of a small number of repeated patterns. With significant
reliability, you can predict the behavior of your users by the simple expedient of remembering
what they did the last several times they used the program. This allows you to greatly reduce
the number of questions your program must M

Remembering choices and defaults

The way to determine what information the program should remember is with a
simple rule: If it's worth the user entering, it's worth the program remembering.
Any time your program finds itself wi th a choice, and especially when that choice is
being offered to the user, the program should remember the information from run to run.
Instead of choosing a hard-wired default, the program can use the previous setting as the
default, and it will have a much better chance of giving the user what he wanted. Instead of
asking the user to make a determination, the program should go ahead and make the
same determination the user made last time, and let the user change it if it was wrong.
Whatever options the user set should be remembered, so that the options remain in effect
unti l manually changed. If the user ignored facilities of the program or turned them off,
they should not be offered to the user again. The user will seek them out when and if he is
ready for them.
One of the most annoying characteristics of programs without memories is that they are so
parsimonious with their assistance regarding files and disks. If there is one place where the
user needs help, it's with files and disks. A program like Word remembers the last place the user
looked for a file. Unfortunately, if the user always puts his files in a directory called Letters,
then edits a document template stored in the Template directory just one time, all his
subsequent letters will be stored in the Template directory rather than in the Letters
directory. So the program must remember more than just the last place the files were
accessed. It must remember the last place files of each type were accessed.
The position of windows should also be remembered, so if you maximized the document last
time it should be maximized next time. If the user positioned it next to another window, it is
positioned the same way the next time without any instruction from the user. Microsoft Office
applications now do a good job of this.

Remembering patterns

The user can benefit in several ways from a program with a good memory. Memory reduces excise,
the useless effort that must be devoted to managing the tool and not doing the work. A
significant portion of the total excise of an interface is in having to explain things to the
program that it should already know. For example, in your word processor, you might often
reverse-out text, making it white on black. To do this, you select some text and change the font
color to white. Without altering the selection, you then set the background color to black. If

the program paid enough attention, it would notice the fact that you requested two formatting
steps without an intervening selection option. As far as you're concerned, this is effectively a
single operation. Wouldn't it be nice if the program, upon seeing this unique pattern repeated
several times, automatically created a new format style of this type — or better yet, created a
new Reverse-Out toolbar control?
Most mainstream programs allow their users to set defaults, but this doesn't fit the
hill as a memory would. Configuration of this kind is an onerous process for all but
power users, and many users will never understand how to customize defaults to their

37.11 Actions to Remember

Everything that users do should be remembered. There is plenty of storage on our hard
drives/ and a memory for your program is a good investment of storage space. We
tend to think that programs are wasteful of disk space because a big horizontal application
might consume 30 or 40 MB of space. That is typical usage for a program, but not for user
data. If your word processor saved 1 KB of execution notes every time you ran it, it still
wouldn't amount to much. Let's say that you use your word processor ten times every business
day. There are approximately 200 workdays per year, so you run the program 2,000 times a
year. The net consumption is still only 2 MB, and that gives an exhaustive recounting
of the entire year! This is probably not much more than the background image you put on
your desktop.

File locations

All file-open facilities should remember where the user gets his files. Most users
only access files from a few directories for each given program. The program
should remember these source directories and offer them on a combo box on the
File-Open dialog. The user should never have to step through the tree to a given
directory more than once

Deduced information

Software should not simply remember these kinds of explicit facts, but should also
remember useful information that can be deduced from these facts. For example, if the
program remembers the number of bytes changed in the file each time it is opened, it can help
the user with some reasonableness checks. Imagine that the changed-byte-count for a file was
126, 94, 43, 74, 81, 70, 110, and 92. If the user calls up the file and changes 100 bytes,
nothing would be out of the ordinary." But if the number of changed bytes suddenly shoots
up to 5000, the program might suspect that something is amiss. Although there is a chance
that the user has inadvertently done something about which he will be sorry, the probability
of that is low, so it isn't right to bother him with a confirmation dialog. It is, however, very
reasonable for the program to make sure to keep a milestone copy of the file before the 5000
bytes were changed, just in case. The program probably won't need to keep it beyond the
next time the user accesses that file, because the user will likely spot any mistake that
glaring immediately, and he would then demand an undo.

Multi-session undo

Most programs discard their stack of undo actions when the user closes the document or the
program. This is very shortsighted on the program's part. Instead, the program could

write the undo stack to a file. When the user reopens the file, the program could
reload its undo stack with the actions the user performed the last time the program was run
— even if that was a week ago!

Past data entries

A program with a better memory can reduce the number of errors the user makes.
This is simply because the user has to enter less information. More of it will be
entered automatically from the program's memory- In an invoicing program, for
example, if the software enters the date, department number, and other standard fields
from memory, the user has fewer opportunities to make typing errors in these fields.
If the program remembers what the user enters and uses that information for future
reasonableness checks, the program can work to keep erroneous data from being entered.
Imagine a data entry program where zip codes and city names are remembered from run
to run. When the user enters a familiar city name along with an unfamiliar zip code, the
field can turn yellow, indicating uncertainty about the match. And when the user enters
a familiar city name with a zip code already associated wi th another city, the field can
turn pink, indicating a more serious ambiguity. He wouldn't necessarily have to take any
action because of these colors, but the warning is there if he wants it.
Some Windows 2000 and XP applications, notably Internet Explorer, have a facility of
similar nature: Named data entry fields remember what has been entered into them
before, and allow the user to pick those values from a combobox. For security-minded
individuals, this feature can be turned off, but for the rest of us, it saves time and
prevents errors.

Foreign application activities on program files

Applications might also leave a small thread running between invocations. This little
program can keep an eye on the files it worked on. It can track where they go and who reads
and writes to them. This information might be helpful to the user when he next runs the
application. When he tries to open a particular file, the program can help him find it,
even if it has been moved. The program can keep the user informed about what other
functions were performed on his file, such as whether or not it was printed or faxed to
someone. Sure, this information might not be needed, but the computer can easily spare
the time, and it's only bits that have to be thrown away, after all.

37.12 Applying Memory to Your Applications

A remarkable thing happens to the software design process when developers accept the
power of task coherence. Designers find that their thinking takes on a whole new
quality. The normally unquestioned recourse of popping up a dialog box gets replaced
with a more studied process, where the designer asks questions of much greater subtlety.
Questions like: How much should the program remember? Which aspects should be
remembered? Should the program remember more than just the last setting? What
constitutes a change in pattern? Designers start to imagine situations like this: The user
accepts the same date format 50 times in a row, and then manually enters a different format
once. The next time the user enters a date, which format should the program use? The
format used 50 times or the more recent one-time format? How many times must the new
format be specified before it becomes the default? Just because there is ambiguity

here, the program still shouldn't ask the user. It must use its initiative to make a
reasonable decision. The user is free to override the program's decision if it is the wrong one.
The following sections explain some characteristic patterns in the ways people make
choices that can help us resolve these more complex questions about task coherence.

Decision-set reduction

People tend to reduce an infinite set of choices down to a small, finite set of
choices. Even when you don't do the exact same thing each time, you will tend to
choose your actions from a small, repetitive set of options. People unconsciously
perform this decision-set reduction, but software can take notice and act upon it.
For example, just because you went shopping at Safeway yesterday doesn't necessarily
mean that you will be shopping at Safeway exclusively. However, the next time you
need groceries, you will probably shop at Safeway again. Similarly, even though your
favorite Chinese restaurant has 250 items on the menu, chances are that you will usually
choose from your own personal subset of five or six favorites. When people drive to and
from work, they usually choose from a small number of favorite routes, depending on
traffic conditions. Computers, of course, can remember four or five things without breaking a
Although simply remembering the last action is better than not remembering anything, it
can lead to a peculiar pathology if the decision-set consists of precisely two elements. If, for
example, you alternately read files from one directory and store them in another, each
time the program offers you the last directory, it will be guaranteed to be wrong. The
solution is to remember more than just one previous choice.
Decision-set reduction guides us to the idea that pieces of information the program
must remember about the user's choices tend to come in groups. Instead of there being one
right way, there will be several options that are all correct. The program should look for
more subtle clues to differentiate which one of the small set is correct. For example, if you
use a check-writing program to pay your bills, the program may very quickly learn that
only two or three accounts are used regularly. Rut how can it determine from a given
check which of the three accounts is the most likely to be appropriate? If the program
remembers the payees and amounts on an account-by-account basis, that decision would be
easy. Every time you pay the rent, it is the exact same amount! It's the same with a car
payment. The amount paid to the electric company might vary from check to check, but
it probably stays within 10 or 20 percent of the last check written to them. All this
information can be used to help the program recognize what is going on, and use that
information to help the user.

Preference thresholds

The decisions people make tend to fall into two primary categories: important and
unimportant. Any given activity may involve potentially hundreds of decisions, but
only a very few of them are important. All the rest are insignificant. Software
interfaces can use this idea of preference thresholds to simplify tasks for users.
After you decide to buy that car, you don't really care who finances it as long as the terms
are competitive. After you decide to buy groceries, the particular checkout aisle you
select is not important. After you decide to ride the Matterhorn, you don't really care
which toboggan they seat you in.
Preference thresholds guide us in our user interface design by demonstrating that
asking the user for successively detailed decisions about a procedure is unnecessary.

After the user asks to print, we don't have to ask him how many copies he wants or
whether the image is landscape or portrait. We can make an assumption about these
things the first time out, and then remember them for all subsequent invocations. If
the user wants to change them, he can always request the Printer Options dialog box.
Using preference thresholds, we can easily track which facilities of the program the
user likes to adjust and which are set once and ignored. With this knowledge, the
program can offer choices where it has an expectation that the user will want to take
control, not bothering the user with decisions he won't care about.

Mostly right, most of the time

Task coherence predicts what the user will do in the future with reasonable, but not
absolute, certainty. If our program relies on this principle, i t s natural to wonder
about the uncertainty of our predictions. If we can reliably predict what the user will do
80% of the time, it means that 20% of the t ime we wi l l be wrong. It might seem that the
proper step to take here is to offer the user a choice, but this means that the user wi ll be
bothered by an unnecessary dialog 80% of the time, Rather than offering a choice, the
program should go ahead and do what it thinks is most appropriate and allow the user to
override or undo it. If the undo facility is sufficiently easy to use and understand, the user won't
be bothered by it. After all, he will have to use undo only two times out of ten instead of
having to deal with a redundant dialog box eight times out of ten. This is a much better deal for

37.13 Memory Makes a Difference

One of the main reasons our software is often so difficult to use is because its
designers have made rational, logical assumptions that, unfortunately, are very wrong.
They assume that the behavior of users is random and unpredictable, and that users must
be interrogated to determine the proper course of action. Although human behavior
certainly isn't deterministic like that of a digital computer, it is rarely random, and
asking silly questions is predictably frustrating for users.
However, when we apply memory via task coherence to our software, we can realize
great advantages in user efficiency and satisfaction. We would all like to have an assistant who is
intelligent and self-motivated, one who shows initiative and drive, and who demonstrates
good judgment and a keen memory. A program that makes effective use of its memory would
be more like that self-motivated assistant, remembering helpful information and personal
preferences from execution to execution without needing to ask. Simple things can make a
big difference: the difference between a product your users tolerate, and one that they love.
The next time you find your program asking your users a question, make it ask itself one

<Previous Lesson

Human Computer Interaction

Next Lesson>


Lesson Plan


Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Go to Top