<Previous Lesson

Human Computer Interaction

Next Lesson>

Lesson#26

BEHAVIOR and FORM-1

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

26.1 Software Posture

Most people have a predominant behavioral stance that fits their working role on the
job: The soldier is wary and alert; the toll-collector is bored and disinterested; the
actor is flamboyant and bigger than life; the service representative is upbeat and
helpful. Programs, too, have a predominant manner of presenting themselves to the
user.
A program may be bold or timid, colorful or drab, but it should be so for a specific,
goal-directed reason. Its manner shouldn't result from the personal preference of its
designer or programmer. The presentation of the program affects the way the user
relates to it, and this relationship strongly influences the usability of the product.
Programs whose appearance and behavior conflict with their purposes will seem
jarring and inappropriate, like fur in a teacup or a clown at a wedding. I
The look and behavior of your program should reflect how it is used, rather than an
arbitrary standard. A program's behavioral stance — the way it presents itself to the
user — is its posture. The look and feel of your program from the perspective of
posture is not an aesthetic choice: It is a behavioral choice. Your program's posture is
its behavioral foundation, and whatever aesthetic choices you make should be in
harmony with this posture.
The posture of your interface tells you much about its behavioral stance, which, in
turn, dictates many of the important guidelines for the rest of the design. As an
interaction designer, one of your first design concerns should be ensuring that your
interface presents the posture that is most appropriate for its behavior and that of your
users. This lecture explores the different postures for applications on the desktop.

26.2 Postures for the Desktop

Desktop applications fit into four categories of posture: sovereign, transient,
daemonic, and auxiliary. Because each describes a different set of behavioral
attributes, each also describes a different type of user interaction. More importantly,
these categories give the designer a point of departure for designing an interface. A
sovereign posture program, for example, won't feel right unless it behaves in a
"sovereign" way. Web and other non-desktop applications have their own variations
of posture.

235

Sovereign posture

Programs that are best used full-screen, monopolizing the user's attention for long
periods of time, are sovereign posture application. Sovereign applications offer a large
set of related functions and features, and users tend to keep them up and running
continuously. Good examples of this type of application are word processors,
spreadsheets, and e-mail applications. Many vertical applications are also sovereign
applications because they often deploy on the screen for long periods of time, and
interaction with them can be very complex and involved. Users working with
sovereign programs often find themselves in a state of flow. Sovereign programs are
usually used maximized. For example, it is hard to imagine using Outlook in a 3x4 inch
window — at that size it's not really appropriate for its main job: creating and viewing
e-mail and appointments (see Figure).
Sovereign programs are characteristically used for long, continuous stretches of time.
A sovereign program dominates a user's workflow as his primary tool. PowerPoint,
for example, is open full screen while you create a presentation from start to finish.
Even if other programs are used for support tasks, PowerPoint maintains its sovereign
stance.

The implications of sovereign behavior are subtle, but quite clear after you think
about them. The most important implication is that users of sovereign programs are
intermediate users. Each user spends time as a novice, but only a short period of time
relative to the amount of time he will eventually spend using the product. Certainly a
new user has to get over the painful hump of an initial learning curve, but seen from
the perspective of the entire relationship of the user with the application, the time he
spends getting acquainted with the program is small.

236
From the designer's point of view, this means that the program should be designed for
optimal use by perpetual intermediates and not be aimed primarily for beginners (or
experts). Sacrificing speed and power in favor of a clumsier but easier-to-learn idiom
is out of place here, as is providing only nerdy power tools. Of course, if you can offer
easier idioms without compromising the interaction for intermediate users; that is
always best.
Between first-time users and intermediate users there are many people who use
sovereign applications only on occasion. These infrequent users cannot be ignored.
However, the success of a sovereign application is still dependent on its intermediate,
frequent users until someone else satisfies both them and inexperienced users.
WordStar, an early word processing program, is a good example. It dominated the
word processing marketplace in the late 70s and early 80s because it served its
intermediate users exceedingly well, even though it was extremely difficult for
infrequent and first-time users. WordStar Corporation thrived until its competition
offered the same power for intermediate users while simultaneously making it much
less painful for infrequent users. WordStar, unable to keep up with the competition,
rapidly dwindled to insignificance.

TAKE THE PIXELS

Because the user's interaction with a sovereign program dominates his session at the
computer, the program shouldn't be afraid to take as much screen real estate as
possible. No other program will be competing with yours, so expect to take advantage
of it all. Don't waste space, but don't be shy about taking what you need to do the job.
If you need four toolbars to cover the bases, use four toolbars. In a program of a
different posture, four toolbars may be overly complex, but the sovereign posture has
a defensible claim on the pixels.
In most instances, sovereign programs run maximized. In the absence of explicit
instructions from the user, your sovereign application should default to maximized
(full-screen) presentation. The program needs to be fully resizable and must work
reasonably well in other screen configurations, but it must optimize its interface for
full-screen instead of the less likely cases.
Because the user will stare at a sovereign application for long periods, you should
take care to mute the colors and texture of the visual presentation. Keep the color
palette narrow and conservative. Big colorful controls may look really cool to
newcomers, but they seem garish after a couple of weeks of daily use. Tiny dots or
accents of color will have more effect in the long run than big splashes, and they
enable you to pack controls together more tightly than you could otherwise. Your user
will stare at the same palettes, menus, and toolbars for many hours, gaining an innate
sense of where things are from sheer familiarity. This gives you, the designer,
freedom to do more with fewer pixels. Toolbars and their controls can be smaller than
normal. Auxiliary controls like screen-splitters, rulers, and scroll bars can be smaller
and more closely spaced.

RICH VISUAL FEEDBACK

Sovereign applications are great platforms for creating an environment rich in visual
feedback for the user. You can productively add extra little bits of information into
the interface. The status bar at the bottom of the screen, the ends of the space

237
normally occupied by scroll bars, the title bar, and other dusty corners of the
program's visible extents can be filled with visual indications of the program's status,
the status of the data, the state of the system, and hints for more productive user
actions. However, be careful: While enriching the visual feedback, you must be
careful not to create an interface that is hopelessly cluttered.
The first-time user won't even notice such artifacts, let alone understand them,
because of the subtle way they are shown on the screen. After a couple of months of
steady use, however, he will begin to see them, wonder about their meaning, and
experimentally explore them. At this point, the user will be willing to expend a little
effort to learn more. If you provide an easy means for him to find out what the
artifacts are, he will become not only a better user, but a more satisfied user, as his
power over the program grows with his understanding. Adding such richness to the
interface is like adding a variety of ingredients to a meat stock — it enhances the
entire meal.

RICH INPUT

Sovereign programs similarly benefit from rich input. Every frequently used aspect of
the program should be controllable in several ways. Direct manipulation, dialog
boxes, keyboard mnemonics, and keyboard accelerators are all appropriate. You can
make more aggressive demands on the user's fine motor skills with directmanipulation
idioms. Sensitive areas on the screen can be just a couple of pixels
across because you can assume that the user is established comfortably in his chair,
arm positioned in a stable way on his desk, rolling his mouse firmly across a resilient
mouse pad.
Go ahead and use the corners and edges of the program's window for controls. In a jet
cockpit, the most frequently used controls are situated directly in front of the pilot;
those needed only occasionally or in an emergency are found on the armrests,
overhead, and on the side panels. In Word, Microsoft has put the most frequently used
functions on the two main toolbars.

238
They put the frequently used but visually dislocating functions on small controls to
the left of the horizontal scroll bar near the bottom of the screen. These controls
change the appearance of the entire visual display — Normal view, Page layout view
and Outline view. Neophytes do not often use them and, if accidentally triggered, they
can be confusing. By placing them near the bottom of the screen, they become almost
invisible to the new user. Their segregated positioning subtly and silently indicates
that caution should be taken in their use. More experienced users, with more confidence
in their understanding and control of the program, will begin to notice these
controls and wonder about their purpose. They can experimentally select them when
they feel fully prepared for their consequence. This is a very accurate and useful
mapping of control placement to usage.
The user won't appreciate interactions that cause a delay. Like a grain of sand in your
shoe, a one- or two-second delay gets painful after a few repetitions. It is perfectly
acceptable for functions to take time, but they should not be frequent or repeated
procedures during the normal use of the product. If, for example, it takes more than a
fraction of a second to save the user s work to disk, the user quickly comes to view
that delay as unreasonable. On the other hand, inverting a matrix or changing the entire

formatting style of a document can take a few seconds without causing irritation
because the user can plainly see what a big job it is. Besides, he won't invoke it very
often.


239

DOCUMENT-CENTRIC APPLICATIONS

The dictum that sovereign programs should fill the screen is also true of document
windows within the program itself. Child windows containing documents should
always be maximized inside the program unless the user explicitly instructs otherwise.
Many sovereign programs are also document-centric (their primary functions involve
the creation and viewing of documents containing rich data), making it easy to
confuse the two, but they are not the same. Most of the documents we work with are
8½-by-l1 inches and won't fit on a standard computer screen. We strain to show as
much of them as possible, which naturally demands a full-screen stance. If the document
under construction were a 32x32 pixel icon, for example, a document-centric
program wouldn't need to take the full screen. The sovereignty of a program does not
come from its document-centricity nor from the size of the document — it comes
from the nature of the program's use.
If a program manipulates a document but only performs some very simple, single
function, like scanning in a graphic, it isn't a sovereign application and shouldn't
exhibit sovereign behavior. Such single-function applications have a posture of their
own, the transient posture.

Transient posture

A transient posture program comes and goes, presenting a single, high-relief function
with a tightly restricted set of accompanying controls. The program is called when
needed, appears, performs its job, and then quickly leaves, letting the user continue
his more normal activity, usually with a sovereign application.
The salient characteristic of transient programs is their temporary nature. Because
they don't stay on the screen for extended periods of time, the user doesn't get the
chance to become very familiar with them. Consequently, the program’s user
interface needs to be unsubtle, presenting its controls clearly and boldly with no
possibility of mistakes. The interface must spell out what it does: This is not the place
for artistic-but-ambiguous images or icons — it is the place for big buttons with
precise legends spelled out in a slightly oversized, easy-to-read typeface.
Although a transient program can certainly operate alone on your desktop, it usually
acts in a supporting role to a sovereign application. For example, calling up the
Explorer to locate and open a file while editing another with Word is a typical
transient scenario. So is setting your speaker volume. Because the transient program
borrows space at the expense of the sovereign, it must respect the sovereign by not
taking more space on screen than is absolutely necessary. Where the sovereign can
dig a hole and pour a concrete foundation for itself, the transient program is just on a
weekend campout. It cannot deploy itself on screen either graphically or temporally. It
is the taxicab of the software world.

BRIGHT AND CLEAR

Whereas a transient program must consent the total amount of screen real estate it
consumes, the controls on its surface can be proportionally larger than those on a
sovereign application. Where such heavy-handed visual design on a sovereign
program would pall within a few weeks, the transient program isn't on screen long
enough for it to bother the user. On the contrary, the bolder graphics help the user to
orient himself more quickly when the program pops up. The program shouldn't
restrict itself to a drab palette, but should instead paint itself in brighter colors to help

240
differentiate it from the hosting sovereign, which will be more appropriately shaded in
muted hues. Transient programs should use their brighter colors and bold graphics to
clearly convey their purpose — the user needs big, bright, reflective road signs to
keep him from making the wrong turn at 100 kilometers per hour.
Transient programs should have instructions built into their surface. The user may
only see the program once a month and will likely forget the meanings of the choices
presented. Instead of a button captioned Setup, it might be better to make the button
large enough to caption it Setup User Preferences. The meaning is clearer, and the
button more reassuring. Likewise, nothing should be abbreviated on a transient
program —everything should be spelled out to avoid confusion. The user should be
able to see without difficulty that the printer is busy, for example, or that the audio is
five seconds long.

KEEP IT SIMPLE

After the user summons a transient program, all the information and facilities he
needs should be right there on the surface of the program's single window. Keep the
user's focus of attention on that window and never force him into supporting
subwindows or dialog boxes to take care of the main function of the program. If you
find yourself adding a dialog box or second view to a transient application, that's a
key sign that your design needs a review.
Transient programs are not the place for tiny scroll bars and fussy point-click-anddrag
interfaces. You want to keep the demands here on the user's fine motor skills
down to a minimum. Simple push-buttons for simple functions are better. Anything
directly manipulable must be big enough to move to easily: at least twenty pixels
square. Keep controls off the borders of the window. Don't use the window bottoms,
status bars, or sides in transient programs. Instead, position the controls up close and
personal in the main part of the window.
You should definitely provide a keyboard interface, but it must be a simple one. It
shouldn't be more complex than Enter, Escape, and Tab. You might add the arrow
keys, too, but that's about it.
Of course, there are exceptions to the monothematic nature of transient programs,
although they are rare. If a transient program performs more than just a single
function, the interface should communicate this visually. For example, if the program
imports and exports graphics, the interface should be evenly and visually split into
two halves by bold coloration or other graphics One half could contain the controls
for importing and the other half the controls for exporting The two halves must be
labeled unambiguously. Whatever you do, don't add more windows or dialogs.
Keep in mind that any given transient program may be called upon to assist in the
management of some aspect of a sovereign program. This means that the transient
program, as it positions itself on top of the sovereign, may obscure the very
information that it is chartered to work on. This implies that the transient program
must be movable, which means it must have a title bar.
It is vital to keep the amount of management' overhead as low as possible with
transient programs. All the user wants to do is call the program up, request a function,
and then end the program. It is completely unreasonable to force the user to add nonproductive
window-management tasks to this interaction.

241

REMEMBERING STATE

The most appropriate way to help the user with both transient and sovereign apps is to
give the program a memory. If the transient program remembers where it was the last
time it was used, the chances are excellent that the same size and placement will be
appropriate next time, too. It will almost always be more apt than any default setting
might chance to be. Whatever shape and position the user morphed the program into
is the shape and position the program should reappear in when it is next summoned.
Of course, this holds true for its logical settings, too.
On the other hand, if the use of the program is really simple and single-minded, go
ahead and specify its shape — omit the frame, the directly resizable window border.
Save yourself the work and remove the complexity from the program (be careful,
though, as this can certainly be abused). The goal here is not to save the programmer
work — that's just a collateral benefit — but to keep the user aware of as few
complexities as possible. If the program's functions don't demand resizing and the
overall size of the program is small, the principle that simpler is better takes on more
importance than usual. The calculator accessory' in Windows and on the Mac, for
example, isn't resizable. It is always the correct size and shape.
No doubt you have already realized that almost all dialog boxes are really transient
programs. You can see that all the preceding guidelines for transient programs apply
equally well to the design of dialog boxes .

Daemonic posture

Programs that do not normally interact with the user are daemonic posture programs.
These programs serve quietly and invisibly in the background, performing possibly
vital tasks without the need for human intervention. A printer driver is an excellent
example.
As you might expect, any discussion of the user interface of daemonic programs is
necessarily j short. Too frequently, though, programmers give daemonic programs
full-screen control panels that are better suited to sovereign programs. Designing your
fax manager in the image of Excel, for example, is a fatal mistake. At the other end of
the spectrum, daemonic programs are, too frequently, unreachable by the user,
causing no end of frustration when adjustments need to be made.
Where a transient program controls the execution of a function, daemonic programs
usually manage processes. Your heartbeat isn't a function that must be consciously
controlled; rather, it is a process that proceeds autonomously in the background. Like
the processes that regulate your heartbeat, daemonic programs generally remain
completely invisible, competently performing their process as long as your computer
is turned on. Unlike your heart, however, daemonic programs must occasionally be
installed and removed and, also occasionally, they must be adjusted to deal with
changing circumstances. It is at these times that the daemon talks to the user. Without
exception, the interaction between the user and a daemonic program is transient in
nature, and all the imperatives of transient program design hold true here also.
The principles of transient design that are concerned with keeping the user informed
of the purpose of the program and of the scope and meaning of the user's available
choices become even more critical with daemonic programs. In many cases, the user
will not even be consciously (or unconsciously) aware of the existence of the
daemonic program. If you recognize that, it becomes obvious that reports about status

242
from that program can be quite dislocating if not presented in an appropriate context.
Because many of these programs perform esoteric functions — like printer drivers or
communications concentrators — the messages from them must take particular care
not to confuse the user or lead to misunderstandings.
A question that is often taken for granted with programs of other postures becomes
very significant with daemonic programs: If the program is normally invisible, how
should the user interface be summoned on those rare occasions when it is needed?
One of the most frequently used methods is to represent the daemon with an on-screen
program icon found either in the status area (system tray) in Windows or in the far
right of the Mac OS menu bar. Putting the icon so boldly in the user's face when it is
almost never needed is a real affront, like pasting an advertisement on the windshield
of somebody's car. If your daemon needs configuring no more than once a day, get it
off of the main screen. Windows XP now hides daemonic icons that are not actively
being used. Daemonic icons should only be employed permanently if they provide
continuous, useful status information.
Microsoft makes a bit of a compromise here by setting aside an area on the far-right
side of the taskbar as a status area wherein icons belonging to daemonic posture
programs may reside. This area, also known as the system tray, has been abused by
programmers, who often use it as a quick launch area for sovereign applications. As
of Windows XP, Microsoft set the standard that only status icons are to appear in the
status area (a quick launch area is supported next to the Start button on the taskbar),
and unless the user chooses otherwise, only icons actively reporting status changes
will be displayed. Any others will be hidden. These decisions are very appropriate
handling of transient programs.
An effective approach for configuring daemonic programs is employed by both the
Mac and Windows: control panels, which are transient programs that run as
launchable applications to configure daemons. These give the user a consistent place
to go for access to such process-centric applications.

Auxiliary posture

Programs that blend the characteristics of sovereign and transient programs exhibit
auxiliary posture. The auxiliary program is continuously present like a sovereign, but
it performs only a supporting role. It is small and is usually superimposed on another
application the way a transient is. The Windows taskbar, clock programs,
performance monitors on many Unix platforms, and Stickies on the Mac are all good
examples of auxiliary programs. People who continuously use instant messaging
applications are also using them in an auxiliary manner. In Windows XP's version of
Internet Explorer, Microsoft has recognized the auxiliary role that streaming audio
can play while the user is browsing the Web. It has integrated its audio player into a
side pane in the browser.
Auxiliary programs are typically silent reporters of ongoing processes, although some,
like Stickies or stock tickers, are for displaying other data the user is interested in. In
some cases, this reporting may be a function that they perform in addition to actually
managing processes, but this is not necessarily true. An auxiliary application may, for
example, monitor the amount of system resources either in use or available. The
program constantly displays a small bar chart reflecting the current resource
availability.

243
A process-reporting auxiliary program must be simple and often bold in reporting its
information. It must be very respectful of the pre-eminence of sovereign programs
and should be quick to move out of the way when necessary.
Auxiliary programs are not the locus of the user's attention; that distinction belongs to
the host application. For example, take an automatic call distribution (ACD) program.
An ACD is used to evenly distribute incoming calls to teams of customer-service
representatives trained either to take orders, provide support, or both. Each
representative uses a computer running an application specific to his or her job. This
application, the primary reason for the system's purchase, is a sovereign posture
application; the ACD program is an auxiliary application on top of it. For example, a
sales agent fields calls from prospective buyers on an incoming toll-free number. The
representative's order entry program is the sovereign, whereas the ACD program is
the auxiliary application, riding on top to feed incoming calls to the agent. The ACD
program must be very conservative in its use of pixels because it always obscures
some of the underlying sovereign application. It can afford to have small features
because it is on the screen for long periods of time. In other words, the controls on the
auxiliary application can be designed to a sovereign's sensibilities.

<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