<Previous Lesson

Human Computer Interaction

Next Lesson>

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.

<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