<Previous Lesson

Human Computer Interaction

Next Lesson>

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.

<Previous Lesson

Human Computer Interaction

Next Lesson>

Home

Lesson Plan

Topics

Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Topics
Home
Go to Top