|
Several rules can be invoked. First, these buttons should consistently
appear either at the bottom of the screen
or on the right across all windows in an application and not
switch from window to window. (The bottom is usually best, since users
finish "reading" the screen at the bottom.) Second, within the
bottom or side, the buttons should always have the same physical positions,
and not "move" from window to window as other options are added.
For example, [OK] [Cancel] might appear together in the middle of the
bottom row in one screen. However, this layout becomes spatially inconsistent
with another window that may have the additional options, resulting in
a row like [OK] [Search] [Add] [Delete All] [Cancel]. To eliminate such
"wandering buttons" we recommend placing the OK or default button
on the far left and the Cancel button on the far right. Other buttons
can come and go, but these elements remain consistent. Why do this? It's
based on the "method of loci" as follows.
Note that you probably prefer keeping items in fixed locations (in your
desk, in your home). This regularity of habit lets you devote your mind
to other, more interesting activities. We particularly experience this
when driving and talking. If the rules of the road suddenly changed, such
as "drive on the left side for this next mile," you would reduce
your conversation drastically for a while. Using this penchant for fixed
location, you can memorize a list of groceries (or reasons for salary
increases) quite easily. The 5th century BC Greek poet Simonides taught
his students to associate each item in a list with the pieces of furniture
located in their bedroom, living room, or elsewhere. It was then easy
to recall the list in sequence. The student only had to recall the clockwise
position of the furniture located in the room! Thus, the technique is
called the "method of loci." And yes, we tap into the same mental
process when we fix the position of the default button (e.g., OK) and
the Cancel button. We can extend this design approach to more challenging
tasks, such as accessing numerous historical records for a telephone customer
(see Figure 3).
|
|
Reduce Memory Work
Issue: Jumping back and forth between keyboard and mouse
costs time and effort. People who type rapidly will loose more keystrokes
than slow typists. We estimate it costs three to eight keystrokes for
each jump. Cryptoclick design will fool users into reaching for the mouse
when they should stay on the keyboard to maintain efficient input speed
(see the left side of Figure 3). Users must
do extra memory work to remember how to keep the fingers on the keyboard
(use down arrow to select "terminate"). Even then, users get
penalized with extra keystrokes compared to the better solution, next.
Solution: The objects used for a screen design must
match the task. If the task requires fingers to be on the keyboard to
enter characters, then choose objects to support keyboard entry like the
drop down list box (see Figure 3, right).
Further reduce memory requirements by using list boxes that are always
"open." The user can see the choices immediately. Use drop down
lists only when space on the window is extremely tight.
Note that list boxes should support "autocomplete" by immediately
displaying the best match to the keystrokes entered (as found in Quicken
or Lotus cc:mail). Windows 3.1 allowed a match only on the first letter.
Better yet, Win95 allows a match on all keystrokes typed within the time
limit. Research shows that autocomplete speeds data entry by 100% or more
for expert users.
|
