|
|
|
|
|
|
Lesson#28
|
BEHAVIOR and FORM-3
|
|
|
|
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
28.1 Eliminating Excise
Software too often contains interactions that are top-heavy with
extra work for the
user Programmers typically focus so intently on the enabling
technology that they
don't carefully consider the human actions required to operate
the technology from a
goal-directed point-of-view. The result is software that charges
its users a tax, or
excise, of cognitive and sometimes even physical effort every
time it is used. This
lecture focuses on the nature of this excise, and discusses the
means by which it can
be reduced and even eliminated altogether.
What Is Excise?
When we decide to drive to the office, we must open the garage
door, get in, start the
motor, back out, and close the garage door before we even begin
the forward motion
that will take us to our destination. All these actions are in
support of the automobile
rather than in support of getting to the destination. If we had
Star Trek transporters
instead, we'd dial up our destination coordinates and appear
there instantaneously —
no garages, no motors, no traffic lights. Our point is not to
complain about the
intricacies of driving, but rather to distinguish between two
types of actions we take to
accomplish our daily tasks.
Any large task, such as driving to the office, involves many
smaller tasks. Some of
these tasks work directly toward achieving the goal; these are
tasks like steering down
the road toward your office. Excise tasks, on the other hand,
don't contribute directly
to reaching the goal, but are necessary to accomplishing it just
the same. Such tasks
include opening and closing the garage door, starting the
engine, and stopping at
traffic lights, in addition to putting oil and gas in the car
and performing periodic
maintenance.
Excise is the extra work that satisfies either the needs of our
tools or those of outside
agents as we try to achieve our objectives. The distinction is
sometimes hard to see
because we get so used to the excise being part of our tasks.
Most of us drive so
frequently that differentiating the act of opening the garage
door from the act of
driving towards the destination is difficult. Manipulating the
garage door is something
we do for the car, not for us, and it doesn't move us towards
our destination the way
the accelerator pedal and steering wheel do. Stopping at red
lights is something
261
imposed on us by our society that, again, doesn't help us
achieve our true goal. (In this
case, it does help us achieve a related goal of arriving safely
at our office.)
Software, too, has a pretty clear dividing line between
goal-directed tasks and excise
tasks. Like automobiles, some software excise tasks are trivial,
and performing them
is no great hardship. On the other hand, some software excise
tasks are as obnoxious
as fixing a flat tire. Installation leaps to mind here, as do
such excise tasks as
configuring networks, making backups, and connecting to online
services.
The problem with excise tasks is that the effort we expend in
doing them doesn’t go
directly towards accomplishing our goals. Where we can eliminate
the need for excise
tasks, we make the user more effective and productive and
improve the usability of
the software. As a software designer, you should become
sensitive to the presence of
excise and take steps to eradicate it with the same enthusiasm a
doctor would apply to
curing an infection.
There are many such instances of petty excise, particularly in
GUIs. Virtually all
window management falls into this category. Dragging, reshaping,
resizing,
reordering, tiling and cascading windows qualify as excise
actions.
GUI Excise
One of the main criticisms leveled at graphical user interfaces
by experienced
computer users — notably those trained on command-line systems —
is that getting
to where you want to go is made slower and more difficult by the
extra effort that
goes into manipulating windows and icons. Users complain that,
with a command
line, they can just type in the desired command and the computer
executes it
immediately. With windowing systems, they must open various
folders looking for
the desired file or program before they can launch it. Then,
after it appears on the
screen, they must stretch and drag the window until it is in the
desired location and
configuration.
These complaints are well founded. Extra window manipulation
tasks like these are,
indeed, excise. They don't move the user towards his goal; they
are overhead that the
programs demand before they deign to assist the user. But
everybody knows that
GUIs are easier to use than command-line systems. Who is right?
The confusion arises because the real issues are hidden. The
command-line interface
forces an even more expensive excise budget on the user: He must
first memorize the
commands. Also, he cannot easily configure his screen to his own
personal
requirements. The excise of the command-line interface becomes
smaller only after
the user has invested significant time and effort in learning
it.
On the other hand, for the casual or first-time user, the visual
explicitness of the GUI
helps him navigate and learn what tasks are appropriate and
when. The step-by-step
nature of the GUI is a great help to users who aren't yet
familiar with the task or the
system. It also benefits those users who have more than one task
to perform and who
must use more than one program at a time.
Excise and expert users
Any user willing to learn a command-line interface automatically
qualifies as a power
user. And any power user of a command-line interface will
quickly become a power
user of any other type of interface, GUI included. These users
will easily learn each
nuance of the programs they use. They will start up each program
with a clear idea of
exactly what it is they want to do and how they want to do it.
To this user, the
assistance offered to the casual or first-time user is just in
the way.
262
We must be careful when we eliminate excise. We must not remove
it just to suit
power users. Similarly, however, we must not force power users
to pay the full price
of our providing help to new or infrequent users.
Training wheels
One of the areas where software designers can inadvertently
introduce significant
amounts of excise is in support for first-time or casual users.
It is easy to justify
adding facilities to a program that will make it easy for newer
users to learn how to
use the program. Unfortunately, these facilities quickly become
excise as the users
become familiar with the program — perpetual intermediates.
Facilities added to
software for the purpose of training beginners must be easily
turned off. Training
wheels are rarely needed for extended periods of time, and
training wheels, although
they are a boon to beginners, are a hindrance to advanced
learning and use when they
are left on permanently.
"Pure" excise
There are a number of actions that are excise of such purity
that nobody needs them,
from power users to first-timers. These include most
hardware-management tasks that
the computer could handle itself, like telling a program which
COM port to use. Any
demands for such information should be struck from user
interfaces and replaced with
more intelligent program behavior behind the scenes.
Visual excise
Designers sometimes paint themselves into excise corners by
relying too heavily on
visual metaphors. Visual metaphors like desktops with
telephones, copy machines,
staplers, and fax machines — or file cabinets with folders in
drawers — are cases in
point. These visual metaphors may make it easy to understand the
relationships
between program elements and behaviors; but after these
fundamentals are learned,
the management of the metaphor becomes pure excise. In addition,
the screen space
consumed by the images becomes increasingly egregious,
particularly in sovereign
posture applications. The more we stare at the program from day
to day, the more we
resent the number of pixels it takes to tell us what we already
know. The little
telephone that so charmingly told us how to dial on that first
day long ago is now a
barrier to quick communications.
Transient posture applications can tolerate more training and
explanation excise than
sovereign applications. Transient posture programs aren't used
frequently, so their
users need more assistance in understanding what the program
does and remembering
how to control it. For sovereign posture applications, however,
the slightest excise
becomes agonizing over time.
The second type of visual excise was not a significant issue
before the advent of the
Web: overemphasis of visual design elements to the extent that
they interfere with
user goals and comprehension. The late 90s attracted a large
number of graphic and
new media designers to the Web, people who viewed this medium as
a predominantly
visual one, the experience of which was defined by rich, often
animated, visuals.
Although this might have been (and perhaps still is) appropriate
for brochure-ware
Web sites that serve primarily as marketing collateral, it is
highly inappropriate for
transactional Web sites and Web applications. As we will discuss
more in coming
lectures, these latter types of sites, into which the majority
of e-commerce falls, have
263
far more in common, from a behavioral standpoint, with sovereign
desktop
applications than with multimedia kiosk-ware or brochure-ware.
The result was that many visually arresting, visually innovative
sites were spawned
that ignored the two most critical elements: an understanding of
user goals and a
streamlined behavior that helped users achieve them. A
pre-eminent example of this
was Boo.com, one of the first major implosions of the dot.com
bust. This fashion etailor
made use of hip visuals and flash-based interactive agents, but
didn't seem to
spend much effort addressing user goals. The site was sluggish
due to flash, visually
distracting, confusingly laid out, and difficult to navigate due
to multiple windows
and confusing links. Boo attempted to be high-concept, but its
users' goals were
simply to buy products more quickly, cheaply, and easily on-line
than they could
elsewhere. By the time some of these problems were remedied,
Boo's customers had
abandoned them. One can only wonder how much difference a
goal-directed design
might have made to Boo and many other e-commerce failures of
that time.
Unfortunately, some of these visual excesses are slowly creeping
into desktop
applications, as programmers and designers borrow flashy but
inappropriate idioms
from the Web.
Determining what is excise
Sometimes we find certain tasks like window management, which,
although they are
mainly for the program, are useful for occasional users or users
with special
preferences. In this case, the function itself can only be
considered excise if it is
forced on the user rather than made available at his discretion.
The only way to determine whether a function or behavior is
excise is by comparing it
to the user's goals. If the user needs to see two programs at a
time on the screen in
order to compare or transfer information, the ability to
configure the main windows of
the programs so that they share the screen space is not excise.
If the user doesn't have
this specific goal, a requirement that the user must configure
the main window of
either program is excise.
28.2 Navigation and
Inflection
Desktop applications, Web sites, and devices all have one
particular attribute in
common that, if improperly designed, becomes a critical obstacle
to usability:
navigation. The user must be able to navigate efficiently
through the features and
facilities of a program, Web site, or device. He must also be
able to stay oriented in
the program as he moves from screen to screen.
A user can navigate if he always understands what he has to do
next, knows what
state the program, site, or device is in, and knows how to find
the tools he needs. This
chapter discusses the issues surrounding navigation, and how to
better help users
navigate through interactive products.
Navigation Is Excise
As discussed earlier, the most important thing to realize about
navigation is that, in
almost all cases, it represents pure excise, or something close
to it. Except in games
where the goal is to navigate successfully through a maze of
obstacles, navigating
through software does not meet user goals, needs, or desires.
Unnecessary or difficult
264
navigation thus becomes a major frustration to users. In fact,
it is the authors' opinion
that poorly designed navigation presents the number-one problem
in the design of any
software application or system — desktop, Web-based, or
otherwise. It is also the
place where the programmer's implementation model is made most
apparent to the
user.
Types of Navigation
Navigation through software occurs at multiple levels. The
following list enumerates
the most common types of navigation:
. Navigation between
multiple windows or screens
. Navigation between
panes within a window (or frames in a page)
. Navigation between
tools or menus in a pane
. Navigation within
information displayed in a pane or frame (for example:
scrolling, panning, zooming, following links)
Some students may question the inclusion of some of the bullets
above as types of
navigation. Broad definition of navigation are purposely being
used: any action that
takes the user to a new part of the interface or which requires
him to otherwise locate
objects, tools, or data. The reason for this is simple: When we
start thinking about
these actions as navigation, it becomes clear that they are
excise and should, therefore,
be minimized or eliminated. We'll now discuss each of these
types of navigation in
more detail.
Navigation between multiple windows or pages
Navigation between multiple windows is perhaps the most
disorienting kind of
navigation for users. Navigating between windows involves a
gross shifting of
attention that disrupts the users flow and forces him into a new
context. The act of
navigating to another window also often means that the contents
of the original
window are partly or completely obscured. At the very least, it
means that the user
needs to worry about window management, an excise task that
further disrupts his
flow. If users must constantly shuttle back and forth between
windows to achieve
their goals, their productivity will drop, and their
disorientation and frustration levels
will rise. If the number of windows is large enough, the user
will become sufficiently
disoriented that he may experience navigational trauma: He gets
lost in the interface.
Sovereign posture applications avoid this problem by placing all
main interactions in
a single primary window, which may contain multiple independent
panes.
Navigation between panes
Windows can contain multiple panes, either adjacent to each
other and separated by
splitters or stacked on top of each other and denoted by tabs.
Adjacent panes can solve
many navigation problems by placing useful supporting functions,
links, or data
directly adjacent to the primary work or display area, thus
reducing navigation to
almost nil. If objects can be dragged between panes, those panes
should be adjacent to
each other.
Problems arise when adjacent supporting panes become too
numerous, or when they
are not placed on the screen in a way that matches the user's
workflow. Too many
adjacent panes result in visual clutter and confusion: The user
does not know where to
go to find what he needs. Also, crowding forces the introduction
of scrolling, which is
265
another navigational hit. Navigation within the single screen
thus becomes a problem.
Some Web portals, trying to be everything to everyone, have such
navigational
problems.
In some cases, depending on user workflows, tabbed panes can be
appropriate.
Tabbed panes bring with them a level of navigational excise and
potential for
disorientation because they obscure what was on the screen
before the user navigated
to them. However, this idiom is appropriate for the main work
area when multiple
documents or independent views of a document are required (such
as in Microsoft
Excel).
Some programmers interpret tabs as permission to break complex
facilities into
smaller chunks and place one per pane. They reason that using
these facilities will
somehow become easier if the functionality is simply cut into
pieces. Actually, by
putting parts of a single facility onto separate panes, the
excise increases, whereas the
user's understanding and orientation decrease. What's more,
doing this violates the
axiom: A dialog box (or pop-up window) is another room: have a
good reason to go
there. Most users of most programs simply don't require that
their software tools have
dozens of controls for normal use.
Tabbed panes can be appropriate when there are multiple
supporting panes for a work
area that are not used at the same time. The support panes can
then be stacked, and the
user can choose the pane suitable for his current tasks, which
is only a single click
away. Microsoft Internet Explorer for the Macintosh uses a
variant of these stacked
panes. If no pane is selected (users can deselect by clicking on
the active tab), the
program shuts the adjacent pane like a drawer, leaving only the
tabs visible. This
variant is useful if space is at a premium.
Navigation between tools and menus
Another important and overlooked form of navigation results from
the user's need to
make use of different tools, palettes, and functions. Spatial
organization of these
within a pane or window is critical to minimizing extraneous
mouse movements that,
at best, could result in user annoyance and fatigue, and at
worst, result in repetitive
stress injury. Tools that are used frequently and in conjunction
with each other should
be grouped together spatially and also be immediately available.
Menus require more
navigational effort on the part of the user because their
contents are not visible prior
to clicking. Frequently used functions should be provided in
toolbars, palettes, or the
equivalent Menu use should be reserved only for infrequently
accessed commands.
Adobe Photoshop 6.0 exhibits some annoying behaviors in the way
it forces users to
navigate between palette controls. For example, the Paint Bucket
tool and the
Gradient tool each occupy the same location on the tool palette;
you must select
between them by clicking and holding on the visible control,
which opens a menu that
lets you select between them. However, both are fill tools, and
both are frequently
used. It would have been better to place each of them on the
palette next to each other
to avoid that frequent, flow-disrupting tool navigation.
Navigation of information
Navigation of information, or of the content of panes or
windows, can be
accomplished by several methods: scrolling (panning), linking
(jumping), and
zooming. The first two methods are common: scrolling is
ubiquitous in most software
and linking is ubiquitous on the Web (though increasingly,
linking idioms are being
266
adopted in non-Web applications). Zooming is primarily used for
visualization of 3D
and detailed 2D data.
Scrolling is often a necessity, but the need for it should be
minimized when possible.
Often there is a tradeoff between paging and scrolling
information: You should
understand your users' mental models and workflows to determine
what is best for
them.
In 2D visualization and drawing applications, vertical and
horizontal scrolling is
common. These kinds of interfaces benefit from a thumbnail map
to ease navigation.
Linking is the critical navigational paradigm of the Web.
Because it is a visually
dislocating activity, extra care must be taken to provide visual
and textual cues that
help orient users.
Zooming and panning are navigational tools for exploring 2D and
3D information.
These methods are appropriate when creating 2D or 3D drawings
and models or for
exploring representations of real-world 3D environments
(architectural walkthroughs,
for example). They typically fall short when used to examine
arbitrary or abstract data
presented in more than two dimensions. Some information
visualization tools use
zoom to mean, "display more attribute details about objects," a
logical rather than
spatial zoom. As the view of the object enlarges, attributes
(often textual) appear
superimposed over its graphical representation. This kind of
interaction is almost
always better served through an adjacent supporting pane that
displays the properties
of selected objects in a more standard, readable form. Users
find spatial zoom difficult
enough to understand; logical zoom is arcane to all but
visualization researchers and
the occasional programmer.
Panning and zooming, especially when paired together, create
enormous navigation
difficulties for users. Humans are not used to moving in
unconstrained 3D space, and
they have difficulty perceiving 3D properly when it is projected
on a 2D screen (see
Chapter 24 for more discussion of 3D manipulation).
Improving Navigation
There are many ways to begin improving (eliminating, reducing,
or speeding)
navigation in your applications, Web sites, and devices. Here
are the most effective:
. Reduce the number
of places to go
. Provide signposts
. Provide overviews
. Provide appropriate
mapping of controls to functions
. Inflect your
interface to match user needs
. Avoid hierarchies
We'll discuss these in detail:
Reduce the number of places to go
The most effective method of improving navigation sounds quite
obvious: Reduce the
number of places to which one must navigate. These "places"
include modes, forms,
dialogs, pages, windows, and screens. If the number of modes,
pages, or screens is
kept to a minimum, the user's ability to stay oriented increases
dramatically. In terms
of the four types of navigation presented earlier, this
directive means:
. Keep the number of
pages and windows to a minimum: One full-screen
window with two or three views (maximum) is best. Keep dialogs,
especially
modeless dialogs, to a minimum. Programs or Web sites with
dozens of
267
distinct types of pages, screens, or forms are not navigable
under any
circumstances.
. Keep the number of
adjacent panes in your window or Web page limited to the
minimum number needed for users to achieve their goals. In
sovereign
applications, three panes is a good maximum. On Web pages,
anything more
than two navigation areas and one content area begins to get
busy.
. Keep the number of
controls limited to as few as your users really need to
meet their goals. Having a good grasp of your users via personas
will enable
you to avoid functions and controls that your users don't really
want or need
and that, therefore, only get in their way.
. Scrolling should be
minimized when possible. This means giving supporting
panes enough room to display information so that they don't
require constant
scrolling. Default views of 2D and 3D diagrams and scenes should
be such
that the user can orient himself without too much panning
around. Zooming,
particularly continuous zooming, is the most difficult type of
navigation for
most users so its use should be discretionary, not a
requirement.
Many e-commerce sites present confusing navigation because the
designers are trying
to serve everyone with one generic site. If a user buys books
but never CDs from a
site, access to the CD portion of the site could be
de-emphasized in the main screen
for that user. This makes more room for that user to buy books,
and the navigation
becomes simpler. Conversely, if he visits his account page
frequently, his version of
the site should have his account button (or tab) presented
prominently.
Provide signposts
In addition to reducing the number of navigable places, another
way to enhance the
user's ability to find his way around is by providing better
points of reference —
signposts. In the same way that sailors navigate by reference to
shorelines or stars,
users navigate by reference to persistent objects placed in the
user interface.
Persistent objects, in a desktop world, always include the
program's windows. Each
program most likely has a main, top-level window. The salient
features of that
window are also considered persistent objects: menu bars,
toolbars, and other palettes
or visual features like status bars and rulers. Generally, each
window of the program
has a distinctive look that will soon become instantly
recognizable.
On the Web, similar rules apply. The best Web applications, such
as Amazon.com,
make careful use of persistent objects that remain constant
throughout the shopping
experience, especially the tab bar along the top of the page and
the Search and Browse
areas on the left of the page. Not only do these areas provide
clear navigational
options, but their consistent presence and layout also help
orient customers.
In devices, similar rules apply to screens, but hardware
controls themselves can take
on the role of signposts — even more so when they are able to
offer visual or tactile
feedback about their state. Radio buttons that, for example,
light when selected, even
a needle's position on a dial, can provide navigational
information if integrated
appropriately with the software.
Depending on the application, the contents of the program's main
window may also be
easily recognizable (especially true in kiosks and small-screen
devices). Some
programs may offer a few different views of their data, so the
overall aspect of their
screens will change depending on the view chosen. A desktop
application's distinctive
look, however, will usually come from its unique combination of
menus, palettes, and
268
toolbars. This means that menus and toolbars must be considered
aids to navigation.
You don't need a lot of signposts to navigate successfully. They
just need to be
visible. Needless to say, signposts can't aid navigation if they
are removed, so it is
best if they are permanent fixtures of the interface.
Making each page on a Web site look just like every other one
may appeal to
marketing, but it can, if carried too far, be disorienting.
Certainly, you should use
common elements consistently on each page, but by making
different rooms look
visually distinct, — that is making the purchase page look very
different from the new
account page — you will help to orient your users better.
MENUS
The most prominent permanent object in a program is the main
window and its title
and menu bars. Part of the benefit of the menu comes from its
reliability and
consistency. Unexpected changes to a program's menus can deeply
reduce the user's
trust in them. This is true for menu items as well as for
individual menus. It is okay to
add items to the bottom of a menu, but the standard suite of
items in the main part of
it should change only for a clearly demonstrable need.
TOOLBARS
If the program has a toolbar, it should also be considered a
recognizable signpost.
Because toolbars are idioms for perpetual intermediates rather
than for beginners, the
strictures against changing menu items don't apply quite as
strongly to individual
toolbar controls. Removing the toolbar itself is certainly a
dislocating change to a
persistent object. Although the ability to do so should he
there, it shouldn't be offered
casually, and the user should be protected against accidentally
triggering it. Some
programs put controls on the toolbar that made the toolbar
disappear! This is a
completely inappropriate ejector seat lever.
OTHER INTERFACE SIGNPOSTS;
Tool palettes and fixed areas of the screen where data is
displayed or edited should
also be considered persistent objects that add to the
navigational ease of the interface.
Judicious use of white space and legible fonts is important so
that these signposts
remain clearly evident and distinct.
Provide overviews
Overviews serve a similar purpose to signposts in an interface:
They help to orient the
user. The difference is that overviews help orient users within
the content rather than
within the application as a whole. Because of this, the overview
area should itself be
persistent; its content is dependent on the data being
navigated.
Overviews can be graphical or textual, depending on the nature
of the content. An
excellent example of a graphical overview is the aptly named
Navigator palette in
Adobe Photoshop.
In the Web world, the most common form of overview area is
textual: the ubiquitous
breadcrumb display. Again, most breadcrumbs provide not only a
navigational aid,
but a navigational control as well: They not only show where in
the data structure the
user is, but they give him tools to move to different nodes in
the structure in the form
of links.
269
A final interesting example of an overview tool is the annotated
scrollbar. Annotated
scrollbars are most useful for scrolling through text. They make
clever use of the
linear nature of both scrollbars and textual information to
provide location
information about the locations of selections, highlights, and
potentially many other
attributes of formatted or unformatted text. Hints about the
locations of these items
appear in the "track" that the thumb of the scrollbar moves in,
at the appropriate
location. When the thumb is over the annotation, the annotated
feature of the text is
visible in the display. Microsoft Word uses a variant of the
annotated scrollbar; it
shows the page number and nearest header in a ToolTip that
remains active during the
scroll.
Provide appropriate mapping of controls to functions
Mapping describes the relationship between a control, the thing
it affects, and the
intended result. Poor mapping is evident when a control does not
relate visually or
symbolically with the object it affects. Poor mapping requires
the user to stop and
think about the relationship, breaking flow Poor mapping of
controls to functions
increases the cognitive load for users and can result in
potentially serious user errors.
Inflect your interface to match user needs
Inflecting an interface means organizing it to minimize typical
navigation. In practice,
this means placing the most frequently desired functions and
controls in the most
immediate and convenient locations for the user to access them,
while pushing the
less frequently used functions deeper into the interface, where
the user won't stumble
over them. Rarely used facilities shouldn't be removed from the
program, but they
should be removed from the user's everyday workspace.
The most important principle in the proper inflection of
interfaces is commensurate
efforts. Although it applies to all users, it is particularly
pertinent to perpetual
intermediates. This principle merely states that people will
willingly work harder for
something that is more valuable to get. The catch, of course, is
that value is in the eye
of the beholder. It has nothing to do with how technically
difficult a feature is to
implement, but rather has entirely to do with the user's goals.
If the user really wants something, he will work harder to get
it. If a person wants to
become a good tennis player, for example, he will get out on the
court and play very
hard. To someone who doesn't like tennis, any amount of the
sport is tedious effort. If
a user needs to format beautiful documents with multiple
columns, several fonts, and
fancy headings to impress his boss, he will be highly motivated
to explore the
recesses of the program to learn how. He will be putting
commensurate effort into the
project. If some other user just wants to print plain old
documents in one column and
one font, no amount of inducement will get him to learn those
more-advanced
formatting features.
This means that if you add features to your program that are
necessarily complex to
manage, users will be willing to tolerate that complexity only
if the rewards are worth
it. This is why a program s user interface can't be complex to
achieve simple results,
but it can be complex to achieve complex results (as long as
such results aren't needed
very often).
It is acceptable from an interface perspective to make advanced
features something
that the user must expend a little extra effort to activate,
whether that means searching
270
in a menu, opening a dialog, or opening a drawer. The principle
of commensurate
effort allows us to inflect interfaces so that simple, commonly
used functions are
immediately at hand at all times. Advanced features, which are
less frequently used
but have a big payoff for the user, can be safely tucked away
where they can be
brought up only when needed. In general, controls and displays
should be organized
in an interface according to three attributes: frequency of use,
degree of dislocation,
and degree of exposure.
. Frequency of use
means how often the controls, functions, objects, or displays
are used in typical day-to-day patterns of use. Items and tools
that are most
frequently used (many times a day) should be immediately in
reach. Less frequently
used items, used perhaps once or twice a day, should be no more
than
a click or two away. Other items can be two or three clicks
away.
. Degree of
dislocation refers to the amount of sudden change in an interface or
in the document/information being processed by the application
caused by the
invocation of a specific function or command. Generally
speaking, it's a good
idea to put these types of functions deeper into the interface.
. Degree of exposure
deals with functions that are irreversible or which may
have other dangerous ramifications. ICBMs require two humans
turning keys
simultaneously on opposite sides of the room to arm them. As
with dislocating
functions, you want to make these types of functions more
difficult for your
users to stumble across.
Of course, as users get more experienced with these features,
they will search for
shortcuts, and you must provide them. When software follows
commensurate effort,
the learning curve doesn't go away, but it disappears from the
user's mind — which is
just as good. |
|
|
|
|