|
|
|
|
|
|
Lesson#27
|
BEHAVIOR and FORM-2
|
|
|
|
As the aim of this lecture is to introduce you the study of
Human Computer
Interaction, so that after studying this you will be able to:
. Understand the
narratives and scenarios
. Define requirements
using persona-based design
27.1 Postures for the Web
Designers may be tempted to think that the Web is, by necessity,
different from
desktop applications in terms of posture. Although there are
variations that exhibit
combinations of these postures, the basic four stances really do
cover the needs of
most Web sites and Web.
Information-oriented sites
Sites that are purely informational, which require no complex
transactions to take
place beyond navigating from page to page and limited search,
must balance two
forces: the need to display a reasonable density of useful
information, and the need to
allow first time and infrequent users to easily learn and
navigate the site. This implies
a tension between sovereign and transient attributes in
informational sites. Which
stance is more dominant depends largely on who the target
personas are and what
their behavior patterns are when using the site: Are they
infrequent or one-time users,
or are they repeat users who will return weekly or daily to view
content?
The frequency at which content can be updated on a site does, in
some respects,
influence this behavior: Informational sites with daily-updated
information will
naturally attract repeat users more than a monthly-updated site.
Infrequently updated
sites may be used more as occasional reference (assuming the
information is not too
topical) rather than heavy repeat use and should then be given
more of a transient
stance than a sovereign one. What's more, the site can configure
itself into a more
sovereign posture by paying attention to how often that
particular user visits.
SOVEREIGN ATTRIBUTES
Detailed information display is best accomplished by assuming a
sovereign stance. By
assuming
full-screen use, designers can take advantage of all the
possible space available to
clearly present both the information itself and the navigational
tools and cues to keep
users oriented.
The only fly in the ointment of sovereign stance on the Web is
choosing which fullscreen
resolution is appropriate. In fact, this is an issue for desktop
applications as
well. The only difference between the desktop and the Web in
this regard is that Web
sites have little leverage in influencing what screen resolution
users will have. Users,
however, who are spending money on expensive desktop
productivity applications,
245
will probably make sure that they have the right hardware to
support the needs of the
software. Thus, Web designers need to make a decision early on
what the lowest
common denominator they wish to support will be. Alternatively,
they must code
more complex sites that may be optimal on higher resolution
screens, but which are
still usable (without horizontal scrolling) on lower-resolution
monitors.
TRANSIENT ATTRIBUTES
The less frequently your primary personas access the site, the
more transient a stance
the site needs to take. In an informational site, this manifests
itself in terms of ease
and clarity of navigation.
Sites used for infrequent reference might be bookmarked by
users: You should make
it possible for them to bookmark any page of information so that
they can reliably
return to it at any later time.
Users will likely visit sites with weekly to monthly updated
material intermittently,
and so navigation there must be particularly clear. If the site
can retain information
about past user actions via cookies or server-side methods and
present information
that is organized based on what interested them previously, this
could dramatically
help less frequent users find what they need with minimal
navigation.
Transactional sites and Web applications
Transactional Web sites and Web applications have many of the
same tensions
between sovereign and transient stances that informational sites
do. This is a
particular challenge because the level of interaction can be
significantly more
complex.
Again, a good guide is the goals and needs of the primary
personas: Are they
consumers, who will use the site at their discretion, perhaps on
a weekly or monthly
basis, or are they employees who (for an enterprise or B2B Web
application) must use
the site as part of their job on a daily basis? Transactional
sites that are used for a
significant part of an employee's job should be considered full
sovereign applications.
On the other hand, e-commerce, online banking, and other
consumer-oriented
transactional sites must, like informational sites, balance
between sovereign and
transient stances very similarly to informational sites. In
fact, many consumer
transactional sites have a heavy informational aspect because
users like to research
and compare products, investments, and other items to be
transacted upon. For these
types of sites, navigational clarity is very important, as is
access to supporting
information and the streamlining of transactions. Amazon.com has
addressed many of
these issues quite well, via one-click ordering, good search and
browsing capability,
online reviews of items, recommendation lists, persistent
shopping cart, and tracking
of recently viewed items. If Amazon has a fault, it may be that
it tries to do a bit too
much: Some of the navigational links near the bottom of the
pages likely don't get hit
very often.
27.2 Web portals
Early search engines allowed people to find and access content
and functions
distributed throughout the world on the Web. They served as
portals in the original
sense of the word — ways to get somewhere else. Nothing really
happens in these
navigational portals; you get in, you go somewhere, you get out.
They are used
exclusively to gain access quickly to unrelated information and
functions.
246
If the user requires access via a navigational portal relatively
infrequently, the
appropriate posture is transient, providing clear, simple
navigational controls and
getting out of the way. If the user needs more frequent access,
the appropriate posture
is auxiliary: a small and persistent panel of links (like the
Windows taskbar).
As portal sites evolved, they offered more integrated content
and function and grew
beyond being simple stepping-stones to another place.
Consumer-oriented portals
provide unified access to content and functionality related to a
specific topic, and
enterprise portals provide internal access to important company
information and
business tools. In both cases, the intent is essentially to
create an environment in
which users can access a particular kind of information and
accomplish a particular
kind of work: environmental portals. Actual work is done in an
environmental portal.
Information is gathered from disparate sources and acted upon;
various tools are
brought together to accomplish a unified purpose.
An environmental portal's elements need to relate to one another
in a way that helps
users achieve a specific purpose. When a portal creates a
working environment, it also
creates a sense of place; the portal is no longer a way to get
somewhere else, but a
destination in and of itself. The appropriate posture for an
environmental portal is thus
sovereign.
Within an environmental portal, the individual elements function
essentially as small
applications running simultaneously — as such, the elements
themselves also have
postures:
. Auxiliary elements:
Most of the elements in an environmental portal have an
auxiliary posture; they typically present aggregated sets of
information to
which the user wants constant access (such as dynamic status
monitors), or
simple functionality (small applications, link lists, and so
on). Auxiliary
elements are, in fact, the key building block of environmental
portals. The
sovereign portal is, therefore, composed of a set of auxiliary
posture miniapplications.
. Transient elements:
In addition to auxiliary elements, an environmental
portal often provides transient portal services as well. Their
complexity is
minimal; they are rich in explanatory elements, and they are
used for short
periods on demand. Designers should give a transient posture to
any
embedded portal service that is briefly and temporarily accessed
(such as a todo
list or package-tracking status display) so that it does not
compete with the
sovereign/auxiliary posture of the portal itself. Rather it
becomes a natural,
temporary extension of it.
When migrating traditional applications into environmental
portals, one of the key
design challenges is breaking the application apart into a
proper set of portal services
with auxiliary or transient posture. Sovereign, full-browser
applications are not
appropriate within portals because they are not perceived as
part of the portal once
launched.
27.3 Postures for Other
Platforms
Handheld devices, kiosks, and software-enabled appliances each
have slightly
different posture issues. Like Web interfaces, these other
platforms typically express a
tension between several postures.
247
Kiosks
The large, full-screen nature of kiosks would appear to bias
them towards sovereign
posture, but there are several reasons why the situation is not
quite that simple. First,
users of kiosks are often first-time users (with the exception,
perhaps, of ATM users),
and are in most cases not daily users. Second, most people do
not spend any
significant amount of time in front of a kiosk: They perform a
simple transaction or
search, get what information they need, and then move on. Third,
most kiosks employ
either touchscreens or bezel buttons to the side of the display,
and neither of these
input mechanisms support the high data density you would expect
of a sovereign
application. Fourth, kiosk users are rarely comfortably seated
in front of an optimally
placed monitor, but are standing in a public place with bright
ambient light and many
distractions. These user behaviors and constraints should bias
most kiosks towards
transient posture, with simple navigation, large controls, and
rich visuals to attract
attention and hint at function.
Educational and entertainment kiosks vary somewhat from the
strict transient posture
required of more transactional kiosks. In this case, exploration
of the kiosk
environment is more important than the simple completion of
single transactions or
searches. In this case, more data density and more complex
interactions and visual
transitions can sometimes be introduced to positive effect, but
the limitations of the
input mechanisms need to be carefully respected, lest the user
lose the ability to
successfully navigate the interface.
Handheld devices
Designing for handheld devices is an exercise in hardware
limitations: input
mechanisms, screen size and resolution, and power consumption,
to name a few. One
of the most important insights that many designers have now
realized with regard to
handheld devices is that handhelds are often not standalone
systems. They are, as in
the case of personal information managers like Palm and Pocket
PC devices, satellites
of a desktop system, used more to view information than perform
heavy input on their
own. Although folding keyboards can be purchased for many
handhelds, this,
inessence, transforms them into desktop systems (with tiny
screens). In the role of
satellite devices, an auxiliary posture is appropriate for the
most frequently used
handheld applications — typical PIM, e-mail, and Web browsing
applications, for
example. Less frequently or more temporarily used handheld
applications (like
alarms) can adopt a more transient posture.
Cellular telephones are an interesting type of handheld device.
Phones are not satellite
devices: they are primary communication devices. However, from
an interface posture
standpoint, phones are really transient. You place a call as
quickly as possible and
then abandon the interface to your conversation. The best
interface for a phone is
arguably non-visual. Voice activation is perfect for placing a
call; opening the flip lid
on a phone is probably the most effective way of answering it
(or again using voice
activation for hands-free use). The more transient the phones
interface is, the better.
In the last couple of years, handheld data devices and handheld
phones have been converging. These convergence devices run the
risk of making phone operation too complex and data manipulation
too difficult, but the latest breed of devices like the
Handspring Treo has delivered a successful middle ground. In
some ways, they have made the phone itself more usable by
allowing the satellite nature of the device to aid in the input
of information to the phone: Treos make use of desktop contact
information to synchronize the device's phonebook, for example,
thus removing the previously painful data entry step and
reinforcing the transient posture of the phone functionality. It
is important, when designing for these devices, to recognize the
auxiliary nature of data functions and the transient nature of
phone functions, using each to reinforce the utility of the other. (The
data dialup should be minimally transient, whereas the data
browsing should be auxiliary
248
Appliances
Most appliances have extremely simple displays and rely heavily
on hardware buttons
and dials to manipulate the state of the appliance. In some
cases, however, major
appliances (notably washers and dryers) will sport color LCD
touch screens allowing
rich output and direct input.
Appliance interfaces, like the phone interfaces mentioned in the
previous section,
should primarily be considered transient posture interfaces.
Users of these interfaces
will seldom be technology-savvy and should, therefore, be
presented the most simple
and straightforward interfaces possible. These users are also
accustomed to hardware
controls. Unless an unprecedented ease of use can be achieved
with a touch screen,
dials and buttons (with appropriate audible feedback, and visual
feedback via a viewonly
display or even hardware lamps) may be a better choice. Many
appliance makers
make the mistake of putting dozens of new — and unwanted —
features into their
new, digital models. Instead of making it easier, that "simple"
LCD touchscreen
becomes a confusing array of unworkable controls.
Another reason for a transient stance in appliance interfaces is
that users of appliances
are trying to get something very specific done. Like the users
of transactional kiosks,
they are not interested in exploring the interface or getting
additional information;
they simply want to put the washer on normal cycle or cook their
frozen dinners.
One aspect of appliance design demands a different posture:
Status information
indicating what cycle the washer is on or what the VCR is set to
record should be
provided as a daemonic icon, providing minimal status quietly in
a corner. If more
than minimal status is required, an auxiliary posture for this
information then
becomes appropriate.
27.4 Flow and Transparency
When people are able to concentrate wholeheartedly on an
activity, they lose
awareness of peripheral problems and distractions. The state is
called flow, a concept
first identified by Mihaly Csikszentmihalyi, professor of
psychology at the University
of Chicago, and author of Flow: The Psychology of Optimal
Experience
(HarperCollins, 1991).
In Peopleware: Productive Projects and Teams (Dorset House,
1987), Tom DeMarco
and Timothy Lister, describe flow as a “condition of deep,
nearly meditative
involvement.” Flow often induces a “gentle sense of euphoria”
and can make you
unaware of the passage of time. Most significantly, a person in
a state of flow can be
extremely productive, especially when engaged in
process-oriented tasks such as
"engineering, design, development, and writing." Today, these
tasks are typically
performed on computers while interacting with software.
Therefore, it behooves us to
create a software interaction that promotes and enhances flow,
rather than one that
includes potentially flow-breaking or flow-disturbing behavior.
If the program
consistently rattles the user out of flow, it becomes difficult
for him to regain that
productive state.
If the user could achieve his goals magically, without your
program, he would. By the
same token, if the user needed the program but could achieve his
goals without going
through its user interface, he would. Interacting with software
is not an aesthetic
experience (except perhaps in games, entertainment, and
exploration-oriented
249
interactive systems). For the most part, it is a pragmatic
exercise that is best kept to a
minimum.
Directing your attention to the interaction itself puts the
emphasis on the side effects
of the tools rather than on the user's goals. A user interface
is an artifact, not directly
related to the goals of the user. Next time you find yourself
crowing about what cool
interaction you've designed, just remember that the ultimate
user interface for most
purposes is no interface at all.
To create flow, our interaction with software must become
transparent. In other
words, the interface must not call attention to itself as a
visual artifact, but must
instead, at every turn, be at the service of the user, providing
what he needs at the
right time and in the right place. There are several excellent
ways to make our
interfaces recede into invisibility. They are:
1. Follow mental models.
2. Direct, don't discuss.
3. Keep tools close at hand.
4. Provide modeless feedback.
We will now discuss each of these methods in detail.
Follow mental models
We introduced the concept of user mental models in previous
lectures. Different users
will have different mental models of a process, but they will
rarely visualize them in
terms of the detailed innards of the computer process. Each user
naturally forms a
mental image about how the software performs its task. The mind
looks for some
pattern of cause and effect to gain insight into the machine's
behavior.
For example, in a hospital information system, the physicians
and nurses have a
mental model of patient information that derives from the
patient records that they are
used to manipulating in the real world. It therefore makes most
sense to find patient
information by using names of patients as an index. Each
physician has certain
patients, so it makes additional sense to filter the patients in
the clinical interface so
that each physician can choose from a list of her own patients,
organized
alphabetically by name. On the other hand, in the business
office of the hospital, the
clerks there are worried about overdue bills. They don't
initially think about these bills
in terms of who or what the bill is for, but rather in terms of
how late the bill is (and
perhaps how big the bill is). Thus, for the business office
interface, it makes sense to
sort first by time overdue and perhaps by amount due, with
patient names as a
secondary organizational principle.
Direct don't discuss
Many developers imagine the ideal interface to be a two-way
conversation with the
user. However, most users don't see it that way. Most users
would rather interact with
the software in the same way they interact with, say, their
cars. They open the door
and get in when they want to go somewhere. They step on the
accelerator when they
want the car to move forward and the brake when it is time to
stop; they turn the
wheel when they want the car to turn.
This ideal interaction is not a dialog — it's more like using a
tool. When a carpenter
hits nails, he doesn't discuss the nail with the hammer; he
directs the hammer onto the
nail. In a car, the driver — the user — gives the car direction
when he wants to
change the car's behavior. The driver expects direct feedback
from the car and its
250
environment in terms appropriate to the device: the view out the
windshield, the
readings on the various gauges on the dashboard, the sound of
rushing air and tires on
pavement, the feel of lateral g-forces and vibration from the
road. The carpenter
expects similar feedback: the feel of the nail sinking, the
sound of the steel striking
steel, and the heft of the hammer's weight.
The driver certainly doesn't expect the car to interrogate him
with a dialog box.
One of the reasons software often aggravates users is that it
doesn't act like a car or a
hammer. Instead, it has the temerity to try to engage us in a
dialog — to inform us of
our shortcomings and to demand answers from us. From the user's
point of view, the
roles are reversed: It should be the user doing the demanding
and the software doing
the answering.
With direct manipulation, we can point to what we want. If we
want to move an
object from A to B, we click on it and drag it there. As a
general rule, the better, more
flow-inducing interfaces are those with plentiful and
sophisticated direct manipulation
idioms.
Keep tools close at hand
Most programs are too complex for one mode of direct
manipulation to cover all their
features. Consequently, most programs offer a set of different
tools to the user. These
tools are really different modes of behavior that the program
enters. Offering tools is a
compromise with complexity, but we can still do a lot to make
tool manipulation easy
and to prevent it from disturbing flow. Mainly, we must ensure
that tool information
is plentiful and easy to see and attempt to make transitions
between tools quick and
simple. -Tools should be close at hand, preferably on palettes
or toolbars. This way,
the user can see them easily and can select them with a single
click. If the user must
divert his attention from the application to search out a tool,
his concentration will be
broken. It's as if he had to get up from his desk and wander
down the hall to find a
pencil. He should never have to put tools away manually.
Modeless feedback
As we manipulate tools, it's usually desirable for the program
to report on their status,
and on the status of the data we are manipulating with the tool.
This information
needs to be clearly posted and easy to see without obscuring or
stopping the action.
When the program has information or feedback for the user, it
has several ways to
present it. The most common method is to pop up a dialog box on
the screen. This
technique is modal: It puts the program into a mode that must be
dealt with before it
can return to its normal state, and before the user can continue
with her task. A better
way to inform the user is with modeless feedback.
Feedback is modeless whenever information for the user is built
into the main
interface and doesn't stop the normal flow of system activities
and interaction. In
Word, you can see what page you are on, what section you are in,
how many pages
are in the current document, what position the cursor is in, and
what time it is
modelessly just by looking at the status bar at the bottom of
the screen.
If you want to know how many words are in your document,
however, you have to
call up the Word Count dialog from the Tools menu. For people
writing magazine
articles, who need to be careful about word count, this
information would be better
delivered modelessly.
251
Jet fighters have a heads-up display, or HUD, that superimposes
the readings of
critical instrumentation onto the forward view of the cockpit's
windscreen. The pilot
doesn't even have to use peripheral vision, but can read vital
gauges while keeping his
eyes glued on the opposing fighter.
Our software should display information like a jet fighter's
HUD. The program could
use the edges of the display screen to show the user information
about activity in the
main work area of applications. Many drawing applications, such
as Adobe
Photoshop, already provide ruler guides, thumbnail maps, and
other modeless
feedback in the periphery of their windows.
27.5 Orchestration
When a novelist writes well, the craft of the writer becomes
invisible, and the reader
sees the story and characters with clarity undisturbed by the
technique of the writer.
Likewise, when a program interacts well with a user, the
interaction mechanics
precipitate out, leaving the user face-to-face with his
objectives, unaware of the
intervening software. The poor writer is a visible writer, and a
poor interaction
designer looms with a clumsily visible presence in his software.
To a novelist, there is no such thing as a "good" sentence.
There are no rules for the
way sentences should be constructed to be transparent. It all
depends on what the
protagonist is doing, or the effect the author wants to create.
The writer knows not to
insert an obscure word in a particularly quiet and sensitive
passage, lest it sound like a
sour note in a string quartet. The same goes for software. The
interaction designer
must train his ears to hear sour notes in the orchestration of
software interaction. It is
vital that all the elements in an interface work coherently
together towards a single
goal. When a program's communication with the user is well
orchestrated, it becomes
almost invisible.
Webster defines orchestration as "harmonious organization," a
reasonable phrase for
what we should expect from interacting with software. Harmonious
organization
doesn't yield to fixed rules. You can't create guidelines like,
"Five buttons on a dialog
box are good" and "Seven buttons on a dialog box are too many."
Yet it is easy to see
that a dialog box with 35 buttons is probably to be avoided. The
major difficulty with
such analysis is that it treats the problem in vitro. It doesn't
take into account the
problem being solved; it doesn't take into account what the user
is doing at the time or
what he is trying to accomplish.
Adding finesse: Less is more
For many things, more is better. In the world of interface
design, the contrary is true,
and we should constantly strive to reduce the number of elements
in the interface
without reducing the power of the system. In order to do this,
we must do more with
less; this is where careful orchestration becomes important. We
must coordinate and
control all the power of the product without letting the
interface become a gaggle of
windows and dialogs, covered with a scattering of unrelated and
rarely used controls.
It's easy to create interfaces that are complex but not very
powerful. They typically
allow the user to perform a single task without providing access
to related tasks. For
example, most desktop software allows the user to name and save
a data file, but they
never let him delete, rename, or make a copy of that file at the
same time. The dialog
leaves that task to the operating system. It may not be trivial
to add these functions,
252
but isn't it better that the programmer perform the non-trivial
activities than that the
user to be forced to? Today, if the user wants to do something
simple, like edit a copy
of a file, he must go through a non-trivial sequence of actions:
going to the desktop,
selecting the file, requesting a copy from the menu, changing
its name, and then opening
the new file. Why not streamline this interaction?
It's not as difficult as it looks. Orchestration doesn't mean
bulldozing your way
through problems; it means finessing them wherever possible.
Instead of adding the
File Copy and Rename functions to the File Open dialog box of
every application,
why not just discard the File Open dialog box from every
application and replace it
with the shell program itself? When the user wants to open a
file, the program calls
the shell, which conveniently has all those collateral file
manipulation functions builtin,
and the user can double-click on the desired document. True, the
application's File
Open dialog does show the user a filtered view of files (usually
limited to those
formats recognized by the application), but why not add that
functionality to the shell
—filter by type in addition to sort by type?
Following this logic, we can also dispense with the Save As ...
dialog, which is really
the logical inverse of the File Open dialog. If every time we
invoked the Save As ...
function from our application, it wrote our file out to a
temporary directory under
some reasonable temporary name and then transferred control to
the shell, we'd have
all the shell tools at our disposal to move things around or
rename them.
Yes, there would be a chunk of code that programmers would have
to create to make
it all seamless, but look at the upside. Countless dialog boxes
could be completely
discarded, and the user interfaces of thousands of programs
would become more
visually and functionally consistent, all with a single design
stroke. That is finesse!
Distinguishing possibility from probability
There are many cases where interaction, usually in the form of a
dialog box, slips into
a user interface unnecessarily. A frequent source for such
clinkers is when a program
is faced with a choice. That's because programmers tend to
resolve choices from the
standpoint of logic, and it carries over to their software
design. To a logician, if a
proposition is true 999,999 times out of a million and false one
time, the proposition
is false — that's the way Boolean logic works. However, to the
rest of us, the
proposition is overwhelmingly true. The proposition has a
possibility of being false,
but the probability of it being false is minuscule to the point
of irrelevancy. One of the
most potent methods for better orchestrating your user
interfaces is segregating the
possible from the probable.
Programmers tend to view possibilities as being the same as
probabilities. For
example, a user has the choice of ending the program and saving
his work, or ending
the program and throwing away the document he has been working
on for the last six
hours. Mathematically, either of these choices is equally
possible. Conversely, the
probability of the user discarding his work is, at least, a
thousand to one against; yet
the typical program always includes a dialog box asking the user
if he wants to save
his changes.
The dialog box is inappropriate and unnecessary. How often do
you choose to
abandon changes you make to a document? This dialog is
tantamount to your spouse
telling you not to spill soup on your shirt every time you eat.
253
Providing comparisons
The way that a program represents information is another way
that it can obtrude
noisily into a user's consciousness. One area frequently abused
is the representation of
quantitative, or numeric, information. If an application needs
to show the amount of
free space on disk, it can do what the Microsoft Windows 3.x
File Manager program
did: give you the exact number of free bytes.
In the lower-left corner, the program tells us the number of
free bytes and the total
number of bytes on the disk. These numbers are hard to read and
hard to interpret.
With more than ten thousand million bytes of disk storage,
it-ceases to be important to
us just how many hundreds are left, yet the display rigorously
shows us down to the
kilobyte. But even while the program is telling us the state of
our disk with precision,
it is failing to communicate. What we really need to know is
whether j or not the disk
is getting full, or whether we can add a new 20 MB program and
still have sufficient
working room. These raw numbers, precise as they are, do little
to help make sense of
the facts.
Visual presentation expert Edward Tufte says that quantitative
presentation should
answer the question, "Compared to what?" Knowing that 231,728 KB
are free on your
hard disk is less useful than knowing that it is 22 percent of
the disk's total capacity.
Another Tufte dictum is, “Show the data,” rather than simply
telling about it textually
or numerically. A pie chart showing the used and unused portions
in different colors
would make it much easier to comprehend the scale and proportion
of hard disk use. It
would show us what 231,728 KB really means. The numbers
shouldn't go away, but
they should be relegated to the status of labels on the display
and not be the display
itself. They should also be shown with more reasonable and
consistent precision. The
meaning of the information could be shown visually, and the
numbers would merely
add support.
In Windows XP, Microsoft's right hand giveth while its left hand
taketh away. The
Pile Manager is long dead, replaced by the Explorer dialog box
shown in Figure.
254
This replacement is the properties dialog associated with a hard
disk. The Used Space
is shown in blue and the Free Space is shown in magenta, making
the pie chart an
easy read. Now you can see at a glance the glad news that
GranFromage is mostly
empty.
Unfortunately, that pie chart isn't built into the Explorer's
interface. Instead, you have
to seek it out with a menu item. To see how full a disk is, you
must bring up a modal
dialog box that, although it gives you the information, takes
you away from the place
where you need to know it. The Explorer is where you can see,
copy, move, and
delete files; but it's not where you can easily see if things
need to be deleted. That pie
chart should have been built into the face of the Explorer. In
Windows 2000, it is
shown on the left-hand side when you select a disk in an
Explorer window. In XP,
however, Microsoft took a step backwards, and the graphic has
once again been
relegated to a dialog. It really should be visible at all times
in the Explorer, along with
the numerical data, unless the user chooses to hide it.
Using graphical input
Software frequently fails to present numerical information in a
graphical way. Even
rarer is the capability of software to enable graphical input. A
lot of software lets
users enter numbers; then, on command, it converts those numbers
into a graph. Few
products let the user enter a graph and, on command, convert
that graph into a vector
of numbers. By contrast, most modern word processors let you set
tabs and
indentations by dragging a marker on a ruler. The user can say,
in effect, "Here is
255
where I want the paragraph to start," and let the program
calculate that it is precisely
1.347 inches in from the left margin instead of forcing the user
to enter 1.347.
"Intelligent" drawing programs like Microsoft Visio are getting
better at this. Each
polygon that the user manipulates on screen is represented
behind the scenes by a
small spreadsheet, with a row for each point and a column each
for the X and Y
coordinates. Dragging a polygon's vertex on screen causes the
values in the
corresponding point in the spreadsheet represented by the X and
Y values, to change.
The user can access the shape either graphically or through its
spreadsheet
representation.
This principle applies in a variety of situations. When items in
a list need to be
reordered, the user may want them ordered alphabetically, but he
may also want them
in order of personal preference; something no algorithm can
offer. The user should be
able to drag the items into the desired order directly, without
an algorithm interfering
with this fundamental operation.
Reflecting program status
When someone is asleep, he usually looks asleep. When someone is
awake, he looks
awake. When someone is busy, he looks busy: His eyes are focused
on his work and
his body language is closed and preoccupied. When someone is
unoccupied, he looks
unoccupied: His body is open and moving, his eyes are questing
and willing to make
contact. People not only expect this kind of subtle feedback
from each other, they
depend on it for maintaining social order.
Our programs should work the same way. When a program is asleep,
it should look
asleep. When a program is awake, it should look awake; and when
it's busy, it should
look busy. When the computer is engaged in some significant
internal action like
formatting a diskette, we should see some significant external
action, such as the icon
of the diskette slowly changing from grayed to active state.
When the computer is
sending a fax, we should see a small representation of the fax
being scanned and sent
(or at least a modeless progress bar). If the program is waiting
for a response from a
remote database, it should visually change to reflect its
somnolent state. Program state
is best communicated using forms of rich modeless feedback.
Avoiding unnecessary reporting
For programmers, it is important to know exactly what is
happening process-wise in a
program. This goes along with being able to control all the
details of the process. For
users, it is disconcerting to know all the details of what is
happening. Non-technical
people may be alarmed to hear that the database has been
modified, for example. It is
better for the program to just do what has to be done, issue
reassuring clues when all
is well, and not burden the user with the trivia of how it was
accomplished.
Many programs are quick to keep users apprised of the details of
their progress even
though the user has no idea what to make of this information.
Programs pop up dialog
boxes telling us that connections have been made, that records
have been posted, that
users have logged on, that transactions were recorded, that data
have been transferred,
and other useless factoids. To software engineers, these
messages are equivalent to the
humming of the machinery, the babbling of the brook, the white
noise of the waves
crashing on the beach: They tell us that all is well. They were,
in fact, probably used
while debugging the software. To the user, however, these
reports can be like eerie
lights beyond the horizon, like screams in the night, like
unattended objects flying
about the room.
256
As discussed before, the program should make clear that it is
working hard, but the
detailed feedback can be offered in a more subtle way. In
particular, reporting
information like this with a modal dialog box brings the
interaction to a stop for no
particular benefit.
It is important that we not stop the proceedings to report
normalcy. When some event
has transpired that was supposed to have transpired, never
report this fact with a
dialog box. Save dialogs for events that are outside of the
normal course of events.
By the same token, don't stop the proceedings and bother the
user with problems that
are not serious. If the program is having trouble getting
through a busy signal, don't
put up a dialog box to report it. Instead, build a status
indicator into the program so
the problem is clear to the interested user but is not obtrusive
to the user who is busy
elsewhere.
The key to orchestrating the user interaction is to take a
goal-directed approach. You
must ask yourself whether a particular interaction moves the
user rapidly and directly
to his goal. Contemporary programs are often reluctant to take
any forward motion
without the user directing it in advance. But users would rather
see the program take
some "good enough" first step and then adjust it to what is
desired. This way, the
program has moved the user closer to his goal.
Avoiding blank slates
It's easy to assume nothing about what your users want and
rather ask a bunch of
questions of the user up front to help determine what they want.
How many programs
have you seen that start with a big dialog asking a bunch of
questions? But users —
not power users, but normal people — are very uncomfortable with
explaining to a
program what they want. They would much rather see what the
program thinks is
right and then manipulate that to make it exactly right. In most
cases, your program
can make a fairly correct assumption based on past experience.
For example, when
you create a new document in Microsoft Word, the program creates
a blank document
with preset margins and other attributes rather than opening a
dialog that asks you to
specify every detail. PowerPoint does a less adequate job,
asking you to choose the
base style for a new presentation each time you create one. Both
programs could do
better by remembering frequently and recently used styles or
templates, and making
those the defaults for new documents.
Just because we use the word think in conjunction with a program
doesn't mean that
the software needs to be intelligent (in the human sense) and
try to determine the right
thing to do by reasoning. Instead, it should simply do something
that has a statistically
good chance of being correct, then provide the user with
powerful tools for shaping
that first attempt, instead of merely giving the user a blank
slate and challenging him
to have at it. This way the program isn't asking for permission
to act, but rather asking
for forgiveness after the fact.
For most people, a completely blank slate is a difficult
starting point. It's so much
easier to begin where someone has already left off. A user can
easily fine-tune an
approximation provided by the program into precisely what he
desires with less risk
of exposure and mental effort than he would have from drafting
it from nothing.
Command invocation versus configuration
Another problem crops up quite frequently, whenever functions
with many
parameters are invoked by users. The problem comes from the lack
of differentiation
between a function and the configuration of that function. If
you ask a program to
257
perform a function itself, the program should simply perform
that function and not
interrogate you about your precise configuration details. To
express precise demands
to the program, you would request the configuration dialog. For
example, when you
ask many programs to print a document, they respond by launching
a complex dialog
box demanding that you specify how many copies to print, what
the paper orientation
is, what paper feeder to use, what margins to set, whether the
output should be in
monochrome or color, what scale to print it at, whether to use
Postscript fonts or
native fonts, whether to print the current page, the current
selection, or the entire
document, and whether to print to a file and if so, how to name
that file. All those
options are useful, but all we wanted was to print the document,
and that is all we
thought we asked for.
A much more reasonable design would be to have a command to
print and another
command for print setup. The print command would not issue any
dialog, but would
just go ahead and print, either using previous settings or
standard, vanilla settings. The
print setup function would offer up all those choices about
paper and copies and fonts.
It would also be very reasonable to be able to go directly from
the configure dialog to
printing.
The print control on the Word toolbar offers immediate printing
without a dialog box.
This is perfect for many users, but for those with multiple
printers or printers on a
network, it may offer too little information. The user may want
to see which printer is
selected before he either clicks the control or summons the
dialog to change it first.
This is a good candidate for some simple modeless output placed
on a toolbar or
status bar (it is currently provided in the ToolTip for the
control, which is good, but
the feedback could be better still). Word's print setup dialog
is called Print. . . and is
available from the File menu. Its name could be clearer,
although the ellipsis does,
according to GUI standards, give some inkling that it will
launch a dialog.
There is a big difference between configuring and invoking a
function. The former
may include the latter, but the latter shouldn't include the
former. In general, any user
invokes a command ten times for every one time he configures it.
It is better to make
the user ask explicitly for configuration one time in ten than
it is to make the user
reject the configuration interface nine times in ten.
Microsoft's printing solution is a reasonable rule of thumb. Put
immediate access to
functions on buttons in the toolbar and put access to
function-configuration dialog
boxes on menu items. The configuration dialogs are better
pedagogic tools, whereas
the buttons provide immediate action.
Asking questions versus providing choices
Asking questions is quite different from providing choices. The
difference between
them is the same as that between browsing in a store and
conducting a job interview.
The individual asking the questions is understood to be in a
position superior to the
individual being asked. Those with authority ask questions;
subordinates respond.
Asking users questions makes them feel inferior.
Dialog boxes (confirmation dialogs in particular) ask questions.
Toolbars offer
choices. The confirmation dialog stops the proceedings, demands
an answer, and it
won't leave until it gets what it wants Toolbars, on the other
hand, are always there,
quietly and politely offering up their wares like a
well-appointed store, offering you
the luxury of selecting what you would like with just a flick of
your finger.
Contrary to what many software developers think, questions and
choices don't
necessarily make the user feel empowered. More commonly, it
makes the user feel
258
badgered and harassed. Would you like soup or salad? Salad.
Would you like cabbage
or spinach? Spinach. Would you like French, Thousand Island, or
Italian? French.
Would you like lo-cal or regular? Stop! Just bring me the soup!
Would you like
chowder or chicken noodle?
Users don't like to be asked questions. It cues the user that
the program is:
. Ignorant
. Forgetful
. Weak
. Lacking initiative
. Unable to fend for
itself
. Fretful
. Overly demanding
These are qualities that we typically dislike in people. Why
should we desire them in
software? The program is not asking us our opinion out of
intellectual curiosity or
desire to make conversation, the way a friend might over dinner.
Rather, it is
behaving ignorantly or presenting itself with false authority.
The program isn't
interested in our opinions; it requires information — often
information it didn't really
need to ask us in the first.
Worse than single questions are questions that are asked
repeatedly and unnecessarily.
Do you want to save that file? Do you want to save that file
now? Do you really want
to save that file? Software that asks fewer questions appears
smarter to the user, and
more polite, because if users fail to know the answer to a
question, they then feel
stupid.
In The Media Equation (Cambridge University Press, 1996),
Stanford sociologists
Clifford Nass and Byron Reeves make a compelling case that
humans treat and
respond to computers and other interactive products as if they
were people. We should
thus pay real attention to the "personality" projected by our
software. Is it quietly
competent and helpful, or does it whine, nag, badger, and make
excuses?
Choices are important, but there is a difference between being
free to make choices
based on presented information and being interrogated by the
program in modal
fashion. Users would much rather direct their software the way
they direct their
automobiles down the street. An automobile offers the user
sophisticated choices
without once issuing a dialog box.
Hiding ejector seat levers
In the cockpit of every jet fighter is a brightly painted lever
that, when pulled, fires a
small rocket engine underneath the pilot's seat, blowing the
pilot, still in his seat, out
of the aircraft to parachute safely to earth. Ejector seat
levers can only be used once,
and their consequences are significant and irreversible.
Just like a jet fighter needs an ejector seat lever, complex
desktop applications need
configuration facilities. The vagaries of business and the
demands placed on the
software force it to adapt to specific situations, and it had
better be able to do so.
Companies that pay millions of dollars for custom software or
site licenses for
thousands of copies of shrink-wrapped products will not take
kindly to a program's
inability to adapt to the way things are done in that particular
company. The program
must adapt, but such adaptation can be considered a one-time
procedure, or something
259
done only by the corporate IT staff on rare occasion. In other
words, ejector seat
levers may need to be used, but they won't be used very often.
Programs must have ejector seat levers so that users can —
occasionally — move
persistent objects in the interface, or dramatically (sometimes
irreversibly) alter the
function or behavior of the application. The one thing that must
never happen is
accidental deployment of the ejector seat. The interface design
must assure that the
user can never inadvertently fire the ejector seat when all he
wants to do is make some
minor adjustment to the program.
Ejector seat levers come in two basic varieties: those that
cause a significant visual
dislocation (large changes in the layout of tools and work
areas) in the program, and
those that perform some irreversible action. Both of these
functions should be hidden
from inexperienced users. Of the two, the latter variety is by
far the more dangerous.
In the former, the user may be surprised and dismayed at what
happens next, but he
can at least back out of it with some work. In the latter case,
he and his colleagues are
likely to be stuck with the consequences. |
|
|
|
|