HTML Version |
Updates |
Reader Feedback
Don Gentner, September 1999
Introduction
Attention to the details of navigation and flow can make the
difference between an application that is clumsy to use and one that
"just feels right". This note examines how to design a smooth flow of
interaction, using the example of a simple password dialog.
Sweating the Details
As a human interface designer, you must do more than just assemble
the proper interface components in a window. You also have to lay out
the components in a way that helps users understand their tasks and
fosters a natural activity flow through the tasks. Often a good
interface design will go practically unnoticed by the users because
everything works as they expect. They will only notice the difference
when they have to use a poorly designed interface that puts a number
of little irritants in their way. Thought, attention to detail, and
testing with real users are the only ways to polish out those
irritants.
We will illustrate some of these details by describing the
interaction flow in the simple password dialog shown in Figure 1.
Although this seems to be a trivially simple dialog, it highlights a
number of usability issues and shows how careful attention to design
details can make a significant difference in the user experience.
|
Figure 1.
The password dialog as it is initially posted, with keyboard
focus in the first text field, allows the user to
immediately begin typing their login name. Note that the
Log In
button is inactive because this application requires that
the user enter a login name and password.
|
|
Initial Focus
The password dialog shown in Figure 1 is for a hypothetical e-mail
application. This particular application requires the user to enter
both a login name and a password. When the dialog is first posted,
the Login Name and Password fields are empty and keyboard focus is
placed in the Login Name field, which is normally the first place
where the user would enter data. The Log In button is inactive
because the application requires a login name and password, and those
fields are currently empty. Whenever possible, you should prevent the
user from making errors; in this case, we make a button inactive when
we know that pressing it would result in an error.
Navigation
|
Figure 2.
This dialog is designed with a normal tab traversal order.
The keyboard focus starts in the Login Name text field,
progresses to the Password field, then to the buttons in the
command button row, and finally loops back to the first text
field. (The Log In button is automatically dropped from the
traversal order when it is inactive.)
|
|
Users can navigate through the dialog with the mouse, with Tab
(moving forward through the components) and Shift-Tab (moving
backward), or with the mnemonics. Interaction with login dialogs soon
become automated for most users, and we need to ensure that the
keyboard navigation works smoothly because many users will want to
log in using the keyboard only. Our dialog is designed with a normal
tab traversal order, shown in Figure 2. The typical sequence for most
users will be to type their login name, press Tab to advance focus to
the Password field, type their password, and then press return to
activate the Log In button. This sequence will work fine if we
make the Log In button the default button. But making the
Log In button the default button causes a problem initially.
Some users, particularly in password dialogs, are in the habit of
pressing Return or Enter to advance to the next text field. In a quick
usability study we did with this dialog, about 25% of the users
pressed Enter after typing their login name. Therefore, if the user
types Return or Enter in the Login Name field, we advance keyboard
focus to the Password field. Although this is not the standard
function of Return and Enter, in this case it allows for very smooth
use by the minority of users who want to type their login name,
press Enter, type their password, press Enter, and be logged in, and it does not
interfere with the normal use of the Tab key by most users.
If the Log In button had been the default button, pressing
Enter after typing their login name would activate the Log In
button and cause an error because the user had not entered a
password. Once again, by making the Log In button inactive
unless there is text in both the Login Name and Password fields and
keyboard focus is outside the Login Name field, we prevent the user
from making an error.
Password Field
As soon as the both the Login Name and Password fields contain
text and focus is outside the Login Name field, we make the Log
In button the default button (Figure 3). The user can now press
Enter or Return to activate the Log In button. Note that to
give our dialog a more distinctive look, we used a multiplication
sign (Unicode 00D7) as the echo character in the password field,
rather than the default asterisk (*).
|
Figure 3.
When the user has typed a login name and the first character
in the Password field, the Log
In button is made a default
button, so that pressing a Return or Enter activates the
Log In
button.
|
|
If your application allows null passwords, the situation is a
little more complex. In that case, the Log In button should be
made active as soon as the user enters a character in the Login Name
field (Figure 4), so that the user can attempt to log in without
entering a password. But note that the Log In button should
not be made the default button until the keyboard focus moves to the
Password field. Because there is no default button while focus is in
the Login Name field, the user who presses Enter to move to the
Password field will not activate the Log In button by mistake.
Instead the focus moves harmlessly to the Password field (at
which point the Log In button becomes the default button), so
users can type in a password, if any, and then press Enter to
activate the Log In button.
|
Figure 4.
If the application did not necessarily require a password,
then the Log In button should be made active after the first
character is typed into the Login Name field and be made the
default button when keyboard focus enters the Password
field.
|
|
Status Messages
You probably noticed that there were more than the recommended 17
pixels between the Password field and the command button row. That
extra space is used for displaying status messages, such as the
progress notification shown in Figure 5.
|
Figure 5.
A status message is displayed with a label while the system
is verifying the login attempt. Dots are added to the label
at about 1 dot per second to indicate that the system is
still working.
|
|
That same area is used for short error messages, for example, if
the login attempt fails, as shown in Figure 6. Of course you could
display such error messages in a normal error alert, but the status
area in the Password dialog itself provides a simple and clear
alternative that doesn't require the user to dismiss a separate
dialog, as long as the error message can be brief. Also note that the
text in the Login Name field was automatically selected when the
login failed, allowing the user to easily type in a new login name or
else press Tab, Enter, or Return to move on to the Password field.
|
Figure 6.
An error message displayed in the status area. Note that the
Log In
button is not the default button while keyboard focus is in
the Login Name field, thus allowing the user to press Enter
or Return to navigate to the Password field.
|
|
The user will normally be attending to the status area during the
login attempt and an error message posted there should be easily
seen, especially with the accompanying graphic. Nonetheless, you
should also play a sound when the error message is posted. The sound
will help the distracted user as well as the visually impaired user.
Be sure to allow users to turn off the sounds if they wish.
Entering a Filled Text Field
When keyboard focus enters a text field (unless it does so because
of a mouse click in the field), any existing text in the field should
be selected and the insertion point placed at the end of the text, as
shown in Figure 7. Users can then start typing characters that
will replace the existing text or they can press TAB to move on to the
next field, leaving the original text intact. When the text is selected,
pressing the left or
right arrow keys deselects the text and moves the insertion point
(if possible), allowing
the user to correct the text using only the keyboard. Of course if
the user clicks in a text field, the insertion point should just be
placed as close to the click point as possible, without selecting
text. The user also has the option of selecting a range of text with
a drag. In some cases, as in our password dialog example, you may
also wish to have Return and Enter function like the TAB key in text
fields.
|
Figure 7.
If the user returns keyboard focus to one of the text fields
by tabbing there or by using a mnemonic, any text in the
field is selected. Any characters typed replace the
selected text, but pressing Tab, Enter or Return will deselect
the text and leave it as it was before moving the focus to
the Password field. If the text in the Password field had
been selected, pressing Tab would deselect the text and move
keyboard focus to the Log
In button, whereas pressing Enter
or Return would activate the Log
In button.
|
|
The Subtlety of Good Design
This note illustrates how a good user interface design may appear
simple, but requires great attention to the details of user
interaction. In fact, a better design often attracts less notice
because our job is to shape the environment so that the user moves
smoothly through their task without having to consciously "figure out"
how to operate the interface. When using this password dialog, most
people do not notice that the Log In button is initially
inactive, and later becomes the default button. It just works!
Print-friendly Version
