| Java Sun >
Guidelines Home Page > Java Look and Feel Design Guidelines >
Part II: Fundamental Java Application Design >
6: Behavior > Design for Smooth Interaction
As a human interface designer, you do more than assemble the proper interface components in a window. You also lay out the components to help users understand the tasks they face and to foster a natural flow through the activities. Good interface design frequently goes unnoticed because everything works as expected. Users notice a poorly designed application that puts GUI obstacles in their way. Thought, attention to detail, and testing with real users can eliminate these difficulties.
This section examines the interaction flow in a simple login dialog box, showing how careful attention to detail makes a significant difference in the user experience. For more information, see Login Dialog Boxes. For a discussion of password fields, see Password Fields.
The login dialog box in Figure 78 is for MetalManage, a hypothetical management application. This particular application requires users to type both a login name and a password. When the dialog box initially appears, the Login Name and Password fields are empty, and keyboard focus is in the Login Name field, which is typically the first place that users type information. The Log In button is unavailable because the application requires a login name and password, and those fields are currently empty.
Click here to view the corresponding code for Figure 78 (also available on the book's companion CD-ROM).Figure 78 Simple Login Dialog Box in Its Initial Configuration
Whenever possible, design an interaction flow that prevents users from making errors. For instance, make the Log In button unavailable until the text fields of a login dialog box are filled in because pressing the button earlier would result in an error.
This login dialog box is designed with a standard tab traversal order. As shown in the following figure, keyboard focus starts in the Login Name text field, progresses to the Password field, then moves 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 unavailable.) Users can navigate through the dialog box by:
Ensure that keyboard navigation works smoothly in all dialog boxes. Many users want to perform operations such as logging in using only the keyboard.
The typical login sequence for most users involves typing a login name, pressing Tab to advance focus to the Password field, typing a password, and pressing Enter (or Return) to activate the Log In button.
This sequence works work well if the Log In button is the default command button. However, making the Log In button the default button creates a possible annoyance. Some users, particularly in login dialog boxes, habitually press the Enter key to advance to the next text field.
In a quick usability study conducted with this dialog box, about 25 percent of users pressed the Enter key after typing their login names. Therefore, the design was changed so that if users press Enter in the Login Name field, keyboard focus advances to the Password field. Although this behavior is not standard for the Enter key, it allows for very smooth use by the minority of users who want to type their login names, press Enter, type their passwords, and press Enter to get logged in. Furthermore, it does not interfere with the typical use of the Tab key by most users.
If the Log In button had been the default button, pressing Enter after typing a login name would activate the Log In button. An error would occur because the user had not typed in a password. As a result, the new design made the Log In button unavailable until both the Login Name and Password fields contain text.
As soon as both the Login Name and Password fields contain text, the Log In button becomes available and becomes the default button (as shown in the following figure). Users can then press Enter to activate the Log In button.Figure 80 Standard Login Dialog Box With Filled-in Text Fields
If your application allows null passwords, the interaction is a little more complex. In that case, make the Log In button available as soon as users type a character in the Login Name field, so that they can attempt to log in without typing a password. However, do not make the Log In button the default button until keyboard focus moves to the Password field. Then users who press Enter to move to the Password field cannot activate the Log In button by mistake. Instead, move the focus to the Password field and only then make the Log In button the default command button. Users can type in a password, if any, and then press Enter to activate the Log In button.Figure 81 Login Dialog Box With Null Passwords
The login dialog box has 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 the following figure.Figure 82 Status Message in a Login Dialog Box
You can use this same extra space to display short error messages--for example, if the login attempt fails. You could display such error messages in a standard error alert box. However, as long as the error message is brief, as shown in the following figure, the status area in the login dialog box provides a simple alternative that doesn't require users to dismiss a separate dialog box.Figure 83 Error Message in a Login Dialog Box
Note that the text in the Login Name field is automatically selected when the login fails, enabling users to type in a new login name easily or to press Tab or Enter to navigate to the Password field (which then appears with its contents selected).
Users typically observe the status area during the login attempt, so an error message displayed there is easily seen, especially with the accompanying graphic. Nevertheless, it is also advisable to play a sound when the error message appears. The sound helps distracted users as well as visually impaired people. Be sure to offer users the option to turn off the sound.
When keyboard focus enters a text field (unless it does so because of a user click in the field), select any existing text in the field and place the insertion point at the end of the text, as shown in the following figure. Users can then start typing characters to replace the existing text or they can press the Tab key to move to the next field, leaving the original text intact.
When the text is selected, pressing the left or right arrow key deselects the text and moves the insertion point (if possible), enabling users to correct the text using only the keyboard. Of course, if users click in a text field, place the insertion point as close to the click point as possible, without selecting text. For more information on editable text field navigation, see Editable Text Fields.Figure 84 Entering a Filled Text Field
|Java Look and Feel Design Guidelines, second edition.
Copyright 2001. Sun Microsystems, Inc. All Rights Reserved.