BEHAVIOR & FORM: ELIMINATING EXCISE, NAVIGATION AND INFLECTION

<< POSTURES FOR THE WEB, WEB PORTALS, POSTURES FOR OTHER PLATFORMS, FLOW AND TRANSPARENCY, ORCHESTRATION

EVALUATION PARADIGMS AND TECHNIQUES >>

Human Computer Interaction (CS408)

Lecture

Lecture 28. Behavior & Form Part III

Learning Goals

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

Eliminating Excise

28.1

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

260

Human Computer Interaction (CS408)

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.

261

Human Computer Interaction (CS408)

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

262

Human Computer Interaction (CS408)

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 e-

tailor 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.

Navigation and Inflection

28.2

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

263

Human Computer Interaction (CS408)

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

264

Human Computer Interaction (CS408)

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

265

Human Computer Interaction (CS408)

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

266

Human Computer Interaction (CS408)

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

267

Human Computer Interaction (CS408)

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.

268

Human Computer Interaction (CS408)

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

269

Human Computer Interaction (CS408)

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 fre-

quently 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.

270

Table of Contents: