|
|
|
|
|
|
Lesson#42
|
COMMUNICATING USERS
|
|
|
|
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 how to eliminate error messages
Learn how to eliminate notifiers and confirmatory messages
42.1 Eliminating Errors
Bulletin dialog boxes are used for error messages, notifiers,
and confirmations, three
of the most abused components of modern GUI design. With proper
design, these
dialogs can all but be eliminated. In this lecture, we'll
explore how and why.
Errors Are Abused
There is probably no more abused idiom in the GUI world than the
error dialog. The
proposal that a program doesn't have the right — even the duty —
to reject the user's
input is so heretical that many practitioners dismiss it
summarily. Yet, if we examine
this assertion rationally and from the user's — rather than the
programmer's — point
of view, it is not only possible, but quite reasonable.
Users never want error messages. Users want to avoid the
consequences of making
errors, which is very different from saying that they want error
messages. It's like
saying that people want to abstain from skiing when what they
really want to do is
avoid breaking their legs. Usability guru Donald Norman (1989)
points out that users
frequently blame themselves for errors in product design. Just
because you aren't
getting complaints from your users doesn't mean that they are
happy getting error
messages.
Why We Have So Many Error Messages
The first computers were undersized, underpowered, and
expensive, and didn't lend
themselves easily to software sensitivity. The operators of
these machines were whitelab-
coated scientists who were sympathetic to the needs of the CPU
and weren't
offended when handed an error message. They knew how hard the
computer was
working. They didn't mind getting a core dump, a bomb, an
"Abort, Retry, Fail?" or
the infamous "FU" message (File Unavailable). This is how the
tradition of software
treating people like CPUs began. Ever since the early days of
computing,
programmers have accepted that the proper way for software to
interact with humans
403
was to demand input and to complain when the human failed to
achieve the same
perfection level as the CPU.
Examples of this approach exist wherever software demands that
the user do things its
way instead of the software adapting to the needs of the human.
Nowhere is it more
prevalent, though, than in the omnipresence of error messages.
What's Wrong with Error Messages
Error messages, as blocking modal bulletins must stop the
proceedings with a modal
dialog box. Most user interface designers — being programmers —
imagine that their
error message boxes are alerting the user to serious problems.
This is a widespread
misconception. Most error message boxes are informing the user
of the inability of the
program to work flexibly. Most error message boxes seem to the
user like an
admission of real stupidity on the program's part. In other
words, to most users, error
message boxes are seen not just as the program stopping the
proceedings but, in clear
violation of the axiom: Don't stop the proceedings with idiocy.
We can significantly
improve the quality of our interfaces by eliminating error
message boxes.
People hate error messages
Humans have emotions and feelings: Computers don't. When one
chunk of code
rejects the input of another, the sending code doesn't care; it
doesn't scowl, get hurt, or
seek counseling. Humans, on the other hand, get angry when they
are flatly told they
are idiots.
When users see an error message box, it is as if another person
has told them that they
are stupid. Users hate this. Despite the inevitable user
reaction, most programmers
just shrug their shoulders and put error message boxes in
anyway. They don't know
how else to create reliable software.
Many programmers and user interface designers labor under the
misconception that
people either like or need to be told when they are wrong. This
assumption is false in
several ways. The assumption that people like to know when they
are wrong ignores
human nature. Many people become very upset when they are
informed of their
mistakes and would rather not know that they did something
wrong. Many people
don't like to hear that they are wrong from anybody but
themselves. Others are only
willing to hear it from a spouse or close friend. Very few wish
to hear about it from a
machine. You may call it denial, but it is true, and users will
blame the messenger
before they blame themselves.
The assumption that users need to know when they are wrong is
similarly false. How
important is it for you to know that you requested an invalid
type size? Most
programs can make a reasonable substitution.
We consider it very impolite to tell people when they have
committed some social
faux pas. Telling someone they have a bit of lettuce sticking to
their teeth or that their
fly is open is equally embarrassing for both parties. Sensitive
people look for ways to
bring the problem to the attention of the victim without letting
others notice. Yet
programmers assume that a big, bold box in the middle of the
screen that stops all the
action and emits a bold "beep" is the appropriate way to behave.
Whose mistake is it, anyway?
Conventional wisdom says that error messages tell the user when
he has made some
mistake. Actually, most error bulletins report to the user when
the program gets
404
confused. Users make far fewer substantive mistakes than
imagined. Typical "errors"
consist of the user inadvertently entering an out-of-bounds
number, or entering a
space where the computer doesn't allow it. When the user enters
something
unintelligible by the computer's standards, whose fault is it?
Is it the user's fault for
not knowing how to use the program properly, or is it the fault
of the program for not
making the choices and effects clearer?
Information that is entered in an unfamiliar sequence is usually
considered an error by
software, but people don't have this difficulty with unfamiliar
sequences. Humans
know how to wait, to bide their time until the story is
complete. Software usually
jumps to the erroneous conclusion that out-of-sequence input
means wrong input and
issues the evil error message box.
When, for example, the user creates an invoice for an invalid
customer number, most
programs reject the entry. They stop the proceedings with the
idiocy that the user
must make the customer number valid right now. Alternatively,
the program could
accept the transaction with the expectation that a valid
customer number will
eventually be entered. It could, for example, make a special
notation to itself
indicating what it lacks. The program then watches to make sure
the user enters the
necessary information to make that customer number valid before
the end of the
session, or even the end of the month book closing. This is the
way most humans
work. They don't usually enter "bad" codes. Rather, they enter
codes in a sequence
that the software isn't prepared to accept.
If the human forgets to fully explain things to the computer, it
can after some
reasonable delay, provide more insistent signals to the user. At
day's or week's end the
program can move irreconcilable transactions into a suspense
account. The program
doesn't have to bring the proceedings to a halt with an error
message. After all, the
program will remember the transactions so they can be tracked
down and fixed. This
is the way it worked in manual systems, so why can't
computerized systems do at least
this much? Why stop the entire process just because something is
missing? As long as
the user remains well informed throughout that some accounts
still need tidying, there
shouldn't be a problem. The trick is to inform without stopping
the proceedings.
If the program were a human assistant and it staged a sit-down
strike in the middle of
the accounting department because we handed it an incomplete
form, we'd be pretty
upset. If we were the bosses, we'd consider finding a
replacement for this analretentive,
petty, sanctimonious clerk. Just take the form, we'd say, and
figure out the
missing information. The experts have used Rolodex programs that
demand you enter
an area code with a phone number even though the person's
address has already been
entered. It doesn't take a lot of intelligence to make a
reasonable guess at the area
code. If you enter a new name with an address in Menlo Park, the
program can
reliably assume that their area code is 650 by looking at the
other 25 people in your
database who also live in Menlo Park and have 650 as their area
code. Sure, if you
enter a new address for, say, Boise, Idaho, the program might be
stumped. But how
tough is it to access a directory on the Web, or even keep a
list of the 1,000 biggest
cities in America along with their area codes?
Programmers may now protest: "The program might be wrong. It
can't be sure. Some
cities have more than one area code. It can't make that
assumption without approval of
the user!" Not so.
If we asked a human assistant to enter a client's phone contact
information into our
Rolodex, and neglected to mention the area code, he would accept
it anyway,
expecting that the area code would arrive before its absence was
critical.
Alternatively, he could look the address up in a directory.
Let's say that the client is in
405
Los Angeles so the directory is ambiguous: The area code could
be either 213 or 310.
If our human assistant rushed into the office in a panic
shouting "Stop what you're
doing! This client's area code is ambiguous!" we'd be sorely
tempted to fire him and
hire somebody with a greater-than-room-temperature IQ. Why
should software be any
different? A human might write 213/310? into the area code field
in this case. The
next time
we call that client, we'll have to determine which area code is
correct, but in the
meantime, life can go on.
Again, squeals of protest: "But the area code field is only big
enough for three digits!
I can't fit 213/310? into it!" Gee, that's too bad. You mean
that rendering the user
interface of your program in terms of the underlying
implementation model — a
rigidly fixed field width — forces you to reject natural human
behavior in favor of
obnoxious, computer-like inflexibility supplemented with
demeaning error messages?
Not to put too fine a point on this, but error message boxes
come from a failure of the
program to behave reasonably, not from any failure of the user.
This example illustrates another important observation about
user interface design. It
is not only skin deep. Problems that aren’t solved in the design
are pushed through the
system until they fall into the lap of the user. There are a
variety of ways to handle the
exceptional situations that arise in interaction with software —
and a creative designer
or programmer can probably think of a half-dozen or so off the
top of her head — but
most programmers just don't try. They are compromised by their
schedule and their
preferences, so they tend to envision the world in the terms of
perfect CPU behavior
rather than in the terms of imperfect human behavior.
Error messages don't work
There is a final irony to error messages: They don't prevent the
user from making
errors. We imagine that the user is staying out of trouble
because our trusty error
messages keep them straight, but this is a delusion. What error
messages really do is
prevent the program from getting into trouble. In most software,
the error messages
stand like sentries where the program is most sensitive, not
where the user is most
vulnerable, setting into concrete the idea that the program is
more important than the
user. Users get into plenty of trouble with our software,
regardless of the quantity or
quality of the error messages in it. All an error message can do
is keep me from
entering letters in a numeric field — it does nothing to protect
me from entering the
wrong numbers — which is a much more difficult design task.
Eliminating Error Messages
We can't eliminate error messages by simply discarding the code
that shows the actual
error message dialog box and letting the program crash if a
problem arises. Instead,
we need to rewrite the programs so they are no longer
susceptible to the problem. We
must replace the error-message with a kinder, gentler, more
robust software that
prevents error conditions from arising, rather than having the
program merely
complain when things aren't going precisely the way it wants.
Like vaccinating it
against a disease, we make the program immune to the problem,
and then we can toss
the message that reports it. To eliminate the error message, we
must first eliminate the
possibility of the user making the error. Instead of assuming
error messages are
normal, we need to think of them as abnormal solutions to rare
problems — as
surgery instead of aspirin. We need to treat them as an idiom of
last resort.
406
Every good programmer knows that if module A hands invalid data
to module B,
module B should clearly and immediately reject the input with a
suitable error
indicator. Not doing this would be a great failure in the design
of the interface
between the modules. But human users are not modules of code.
Not only should
software not reject the input with an
error message, but the software designer must also reevaluate
the entire concept of
what "invalid data" is. When it comes from a human, the software
must assume that
the input is correct, simply because the human is more important
than the code.
Instead of software rejecting input, it must work harder to
understand and reconcile
confusing input. The program may understand the state of things
inside the computer,
but only the user understands the state of things in the real
world. Ultimately, the real
world is more relevant and important than what the computer
thinks.
Making errors impossible
Making it impossible for the user to make errors is the best way
to eliminate error
messages. By using bounded gizmos for all data entry, users are
prevented from ever
being able to enter bad numbers. Instead of forcing a user to
key in his selection,
present him with a list of possible selections from which to
choose. Instead of making
the user type in a state code, for example, let him choose from
a list of valid state
codes or even from a picture of a map. In other words, make it
impossible for the user
to enter a bad state.
Another excellent way to eliminate error messages is to make the
program smart
enough that it no longer needs to make unnecessary demands. Many
error messages
say things like "Invalid input. User must type xxxx." Why can't
the program, if it
knows what the user must type, just enter xxxx by itself and
save the user the tonguelashing?
Instead of demanding that the user find a file on a disk,
introducing the
chance that the user will select the wrong file, have the
program remember which files
it has accessed in the past and allow a selection from that
list. Another example is
designing a system that gets the date from the internal clock
instead of asking for
input from the user.
Undoubtedly, all these solutions will cause more work for
programmers. However, it
is the programmer's job to satisfy the user and not vice versa.
If the programmer
thinks of the user as just another input device, it is easy to
forget the proper pecking
order in the world of software design.
Users of computers aren't sympathetic to the difficulties faced
by programmers. They
don't see the technical rationale behind an error message box.
All they see is the
unwillingness of the program to deal with things in a human way.
One of the problems with error messages is that they are usually
post facto reports of
failure. They say, "Bad things just happened, and all you can do
is acknowledge the
catastrophe." Such reports are not helpful. And these dialog
boxes always come with
an OK button, requiring the user to be an accessory to the
crime. These error message
boxes are reminiscent of the scene in old war movies where an
ill-fated soldier steps
on a landmine while advancing across the rice paddy. He and his
buddies clearly hear
the click of the mine's triggering mechanism and the realization
comes over the
soldier that although he's safe now, as soon as he removes his
foot from the mine, it
will explode, taking some large and useful part of his body with
it. Users get this
feeling when they see most error message boxes, and they wish
they were thousands
of miles away, back in the real world.
407
42.2 Positive feedback
One of the reasons why software is so hard to learn is that it
so rarely gives positive
feedback. People learn better from positive feedback than they
do from negative
feedback. People want to use their software correctly and
effectively, and they are
motivated to learn how to make the software work for them. They
don't need to be
slapped on the wrist when they fail. They do need to be
rewarded, or at least
acknowledged, when they succeed. They will feel better about
themselves if they get
approval, and that good feeling will be reflected back to the
product.
Advocates of negative feedback can cite numerous examples of its
effectiveness in
guiding people's behavior. This evidence is true, but almost
universally, the context of
effective punitive feedback is getting people to refrain from
doing things they want to
do but shouldn't: Things like not driving over 55 mph, not
cheating on their spouses,
and not fudging their income taxes. But when it comes to helping
people do what they
want to do, positive feedback is best. Imagine a hired ski
instructor who yells at you,
or a restaurant host who loudly announces to other patrons that
your credit card was
rejected.
Keep in mind that we are talking about the drawbacks of negative
feedback from a
computer. Negative feedback by another person, although
unpleasant, can be justified
in certain circumstances. One can say that the drill sergeant is
at least training you in
how to save your life in combat, and the imperious professor is
at least preparing you
for the vicissitudes of the real world. But to be given negative
feedback by software
— any software — is an insult. The drill sergeant and professor
are at least human
and have bona fide experience and merit. But to be told by
software that you have
failed is humiliating and degrading. Users, quite justifiably,
hate to be humiliated and
degraded. There is nothing that takes place inside a computer
that is so important that
it can justify humiliating or degrading a human user. We only
resort to negative
feedback out of habit.
Improving Error Messages: The Last Resort
Now we will discuss some methods of improving the quality of
error message boxes,
if indeed we are stuck using them. Use these recommendations
only as a last resort,
when you run out of other options.
A well-formed error message box should conform to these
requirements:
Be polite
Be illuminating
Be helpful
Never forget that an error message box is the program reporting
on its failure to do its
job, and it is interrupting the user to do this. The error
message box must be
unfailingly polite. It must never even hint that the user caused
this problem, because
that is simply not true from the user's perspective. The
customer is always right.
The user may indeed have entered some goofy data, but the
program is in no position
to argue and blame. It should do its best to deliver to the user
what he asked for, no
matter how silly. Above all, the program must not, when the user
finally discovers his
silliness, say, in effect, "Well, you did something really
stupid, and now you can't
recover. Too bad." It is the program's responsibility to protect
the user even when he
takes inappropriate action. This may seem draconian, but it
certainly isn't the user's
responsibility to protect the computer from taking inappropriate
action.
408
The error message box must illuminate the problem for the user.
This means that it
must give him the kind of information he needs to make an
appropriate determination
to solve the program's problem. It needs to make clear the scope
of the problem, what
the alternatives are, what the program will do as a default, and
what information was
lost, if any. The program should treat this as a confession,
telling the user everything.
It is wrong, however, for the program to just dump the problem
on the user's lap and
wipe its hands of the matter. It should directly offer to
implement at least one
suggested solution right there on the error message box. It
should offer buttons that
will take care of the problem in various ways. If a printer is
missing, the message box
should offer options for deferring the printout or selecting
another printer. If the
database is hopelessly trashed and useless, it should offer to
rebuild it to a working
state, including telling the user how long that process will
take and what side effects it
will cause.
Figure shows an example of a reasonable error message. Notice
that it is polite,
illuminating, and helpful. It doesn't even hint that the user's
behavior is anything but
impeccable.
42.3 Notifying and Confirming
Now, we discuss alert dialogs (also known as notifiers) and
confirmation dialogs, as
well as the structure of these interactions, the underlying
assumptions about them, and
how they, too, can be eliminated in most cases. ?
42.4 Alerts and Confirmations
Like error dialogs, alerts and confirmations stop the
proceedings with idiocy, but they
do not report malfunctions. An alert notifies the user of the
program's action, whereas
a confirmation also gives the user the authority to override
that action. These dialogs
pop up like weeds in most programs and should, much like error
dialogs, be
eliminated in favor of more useful idioms.
409
Alerts: Announcing the obvious
When a program exercises authority that it feels uncomfortable
with, it takes steps to
inform the user of its actions. This is called an alert. Alerts
violate the axiom: A
dialog box is another room; you should have a good reason to go.
Even if an alert is
justified (it seldom is), why go into another room to do it? If
the program took some
indefensible action, it should confess to it in the same place
where the action occurred
and not in a separate dialog box.
Conceptually, a program should either have the courage of its
convictions or it should
not take action without the user's direct guidance. If the
program, for example, saves
the user's file to disk automatically, it should have the
confidence to know that it is
doing the right thing. It should provide a means for the user to
find out what the
program did, but it doesn't have to stop the proceedings with
idiocy to do so. If the
program really isn't sure that it should save the file, it
shouldn't save the file, but
should leave that operation up to the user.
Conversely, if the user directs the program to do something —
dragging a file to the
trash can. for example — it doesn't need to stop the proceedings
with idiocy to
announce that the user just dragged a file to the trashcan. The
program should ensure
that there is adequate visual feedback regarding the action; and
if the user has actually
made the gesture in error, the program should silently offer him
a robust Undo facility
so he can backtrack.
The rationale for alerts is that they inform the user. This is a
desirable objective, but
not at the expense of smooth interaction flow.
Alerts are so numerous because they are so easy to create. Most
languages offer some
form of message box facility in a single line of code.
Conversely, building an
animated status display into the face of a program might require
a thousand or more
lines of code. Programmers cannot be expected to make the right
choice in this
situation. They have a conflict of interest, so designer: must
be sure to specify
precisely where information is reported on the surface of an
application The designers
must then follow up to be sure that the design wasn't
compromised for the sake of
rapid coding. Imagine if the contractor on
a building site decided unilaterally not to add a bathroom
because it was just too much
trouble to deal with the plumbing. There would be consequences.
Software needs to keep the user informed of its actions. It
should have visual
indicators built into its main screen to make such status
information available to the
user, should he desire it. Launching an alert to announce an
unrequested action is bad
enough. Putting up an alert to announce a requested action is
pathological.
Software needs to be flexible and forgiving, but it doesn't need
to be fawning and
obsequious. The dialog box shown in Figure below is a classic
example of an alert
that should be put out of our misery. It announces that it added
the entry to our phone
book. This occurs immediately after we told it to add the entry
to our phone book,
which happened milliseconds after we physically added the entry
to what appears to
be our phone book. It stops the proceedings to announce the
obvious.
410
It's as though the program wants approval for how hard it
worked: "See, dear, I've
cleaned your room for you. Don't you love me?" If a person
interacted with us like
this, we'd suggest that they seek counseling.
Confirmations S
When a program does not feel confident about its actions, it
often asks the user for
approval with a dialog box. This is called a confirmation, like
the one shown in Figure
below. Sometimes the confirmation is offered because the program
second-guesses
one of the user's actions. Sometimes the program feels that is
not competent to make a
decision it faces and uses a confirmation to give the user the
choice instead.
Confirmations always come from the program and never from the
user. This means
that they are a reflection of the implementation model and are
not representative of
the user's goals.
Remember, revealing the implementation model to users is a
sure-fire way to create
an inferior user interface. This means that confirmation
messages are inappropriate.
Confirmations get written into software when the programmer
arrives at an impasse in
his coding. Typically, he realizes that he is about to direct
the program to take some
bold action and feels unsure about taking responsibility for it.
Sometimes the bold
action is based on some conciliation the program detects, but
more often it is based on
a command the user issues. Typically, confirmation will be
launched after the user
issues a command that is either irrecoverable whose results
might cause undue alarm.
Confirmations pass the buck to the user. The user trusts the
program to do its job, and
the program should both do it and ensure that it does it right.
The proper solution is to
make the action easily reversible and provide enough modeless
feedback so that the
user is not taken off-guard.
As a program's code grows during development, programmers detect
numerous
situations where they don't feel that they can resolve issues
adequately. Programmers
411
will unilaterally insert buck-passing code in these places,
almost without noticing it.
This tendency needs to be closely watched, because programmers
have been known to
insert dialog boxes into the code even after the user interface
specification has been
agreed upon. Programmers often don't consider confirmation
dialogs to be part of the
user interface, but they are.
THE DIALOG THAT CRIED, "WOLF!"
Confirmations illustrate an interesting quirk of human behavior:
They only work
when they are unexpected. That doesn't sound remarkable until
you examine it in
context. If confirmations are offered in routine places, the
user quickly becomes
inured to them and routinely dismisses them without a glance.
The dismissing of
confirmations thus becomes as routine as the issuing of them.
If, at some point, a truly
unexpected and dangerous situation arises — one that should be
brought to the user's
attention — he will, by rote, dismiss the confirmation, exactly
because it has become
routine. Like the fable of the boy who cried, "Wolf," when there
is finally real danger,
the confirmation box won't work because it cried too many times
when there was no
danger.
For confirmation dialog boxes to work, they must only appear
when the user will
almost definitely click the No or Cancel button, and they should
never appear when
the user is likely to click the Yes or OK button. Seen from this
perspective, they look
rather pointless, don't they?
The confirmation dialog box shown in Figure below is a classic.
The irony of the
confirmation dialog box in the figure is that it is hard to
determine which styles to
delete and which to keep. If the confirmation box appeared
whenever we attempted to
delete a style that was currently in use, it would at least then
be helpful because the
confirmation would be less routine. But why not instead put an
icon next to the names
of styles that are in use and dispense with the confirmation?
The interface then
provides more pertinent status information, so one can make a
more informed
decision about what to delete.
412
42.5 ELIMINATING
CONFIRMATIONS
Three axioms tell us how to eliminate confirmation dialog boxes.
The best way is to
obey the simple dictum: Do, don't ask. When you design your
software, go ahead and
give it the force of its convictions (backed up by user
research). Users will respect its
brevity and its confidence.
Of course, if the program confidently does something that the
user doesn't like, it must
have the capability to reverse the operation. Every aspect of
the program's action must
be undoable. Instead of asking in advance with a confirmation
dialog box, on those
rare occasions when the programs actions were out of turn, let
the user issue the Stopand-
Undo command.
Most situations that we currently consider unprotectable by Undo
can actually be
protected fairly well. Deleting or overwriting a file is a good
example. The file can be
moved to a suspense directory where it is kept for a month or so
before it is physically
deleted. The Recycle Bin in Windows uses this strategy, except
for the part about
automatically erasing files after a month: Users still have to
manually take out the
garbage.
Even better than acting in haste and forcing the user to rescue
the program with Undo,
you can make sure that the program offers the user adequate
information so that the
he never purposely issues a command that leads to an
inappropriate action (or never
omits a necessary command). The program should use sufficiently
rich visual
feedback so that the user is constantly kept informed, the same
way the instruments
on dashboards keep us informed of the state of our cars.
Occasionally, a situation arises that really can't be protected
by Undo. Is this a
legitimate case for a confirmation dialog box? Not necessarily.
A better approach is to
provide users with protection the way we give them protection on
the freeway: with
413
consistent and clear markings. You can often build excellent,
modeless warnings right
into the interface. For instance, look at the dialog from Adobe
Photoshop in Figure
below, telling us that our document is larger than the available
print area. Why has the
program waited until now to inform us of this fact? What if
guides were visible on the
page at all times (unless the user hid them) showing the actual
printable region? What
if those parts of the picture outside the printable area were
highlighted when the user
moused over the Print button in the toolbar? Clear, modeless
feedback is the best way
to address these problems.
Much more common than honestly irreversible actions are those
actions that are easily
reversible but still uselessly protected by routine confirmation
boxes. There is no
reason whatsoever to ask for confirmation of a move to the
Recycle Bin. The sole
reason that the Recycle Bin exists is to implement an undo
facility for deleted files.
42.6 Replacing Dialogs: Rich
Modeless Feedback
Most computers now in use in the both the home and the office
come with highresolution
displays and high-quality audio systems. Yet, very few programs
(outside
of games) even scratch the surface of using these facilities to
provide useful
information to the user about the status of the program, the
users' tasks, and the
system and its peripherals in general. It is as if an entire
toolbox is available to
express information to users, but programmers have stuck to
using the same blunt
instrument — the dialog — to communicate information. Needless
to say, this means
that subtle status information is simply never communicated to
users at all, because
even the most clueless designers know that you don't want
dialogs to pop up
constantly. But constant feedback is exactly what users need.
It's simply the channel
of communication that needs to be different.
In this section, well discuss rich modeless feedback,
information that can be provided
to the user in the main displays of your application, which
don't stop the flow of the
program or the user, and which can all but eliminate pesky
dialogs.
42.7 Rich visual modeless
feedback
Perhaps the most important type of modeless feedback is rich
visual modeless
feedback (RVMF). This type of feedback is rich in terms of
giving in-depth
information about the status or attributes of a process or
object in the current
application. It is visual in that it makes idiomatic use of
pixels on the screen (often
dynamically), and it is modeless in that this information is
always readily displayed,
requiring no special action or mode shift on the part of the
user to view and make
sense of the feedback.
For example, in Windows 2000 or XP, clicking on an object in a
file manager window
automatically causes details about that object to be displayed
on the left-hand side of
the file manager window. (In XP, Microsoft ruined this slightly
by putting the
414
information at the bottom of a variety of other commands and
links. Also, by default,
they made the Details area a drawer that you must open, although
the program, at
least, remembers its state.) Information includes title, type of
document, its size,
author, date of modification, and even a thumbnail or miniplayer
if it is an image or
media object. If the object is a disk, it shows a pie chart and
legend depicting how
much space is used on the disk. Very handy indeed! This
interaction is perhaps
slightly modal because it requires selection of the object, but
the user needs to select
objects anyway. This functionality handily eliminates the need
for a properties dialog
to display this information. Although most of this information
is text, it still fits within
the idiom. |
|
|
|
|