|
|
|
|
|
|
Lesson#37
|
BEHAVIOR and FORM-5
|
|
|
|
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
344
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
345
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.
346
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.
347
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
another.
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
348
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
rationale.
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
349
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
forgets.
350
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
host's.
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.
351
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
352
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
behavior.
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
software.
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,
353
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
pocket.
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
slightly.
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.
354
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.
355
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.
356
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
behavior.
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.
357
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
358
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
liking
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
359
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
360
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
sweat.
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.
361
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
humans.
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
instead. |
|
|
|
|