GNOME Usability Study Report :: Logging In
July 2001table of contents | << previous | next >>
Logging In
Participants' first interaction was with the GNOME login dialog. They were told that a new computer was installed on their desk at work and they were asked to log in to the new system. They were told that their username was Pat and they were given the password.
Login Dialog.
Participants' comments centered around lack of feedback as well as unfamiliar dialog layout and terminology. Comments revealed that the users' mental model was based on experience with stand-alone systems, versus networked environments.
Login Dialog Field Labels:
-
Relevant Usability Principle: Match between system and the real world.
-
When discussing the login dialog, users repeatedly used the word "username" instead of "login". We heard the following comment,
-
Design Recommendation: The term 'login' is unclear, as it is both a noun and a verb. We recommend that the field labeled 'Login' be relabeled 'Username' as depicted in the following illustration.
"When I see 'login' I think "password"." (P8)
Login dialog with 'Username'.
We recommend following the GNOME Documentation Style Guide. We also recommend developers to involve a technical writer in the review of any terminology, error messages, or other on-screen text delivered into GNOME. Developers are encouraged to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.
- Relevant Usability Principle: Feedback.
- Several users tried to enter the username "Pat" but their entry was not accepted because their cursor was not over the login dialog. The default requires users' cursors to be inside the dialog for it to be active. We heard several comments along the following line:
-
Design Recommendation: We recommend that the login dialog be made active by default. No matter where the cursor is, the user's entry should go into the text field. The text field should also be in focus by default. It should not be possible for the dialog to become inactive or the text field to lose focus. If it simply is not possible to implement this solution, then feedback, both audio and visual, must be provided if the user tries to type while the cursor is outside the dialog.
"It's not responding when I type in the field." (Participants 8 and 9)One user entered her username while window was not active and thought her entry was accepted and but not shown in the text field for security reasons. This user sat there waiting, thinking the system was working, while nothing was actually happening. (P9)
The only action a user can take at this point is to log in, so it should be as easy as possible for them to accomplish this task. There should minimal opportunity for a user to make an error here.
- Relevant Usability Principle: Feedback.
- We saw more than one user experience confusion over the lack of feedback when incorrect login information was entered. If they made error while typing in the login information (either the username or password) the system did not provide feedback that the user had made an error. Instead, it simply returned to the beginning of the cycle and displayed the username field again.
-
Design Recommendation: Provide brief yet clear feedback to the user that communicates what went wrong, why, and what the user can do about it. We recommend providing error feedback within the login dialog itself. For example, the following text string could appear in the login dialog when users enter incorrect login information: "The username or password you entered in incorrect. Letters must be typed in the correct case. Be sure the caps lock key is not selected." This error message would appear above the username field to communicate that the user should try logging in again. The is illustrated below:
"I expected a dialog saying 'Wrong Username or Password'." (P3)With no feedback from the system, users were confused about why they were unsuccessful at logging in or where they made a mistake. Users also had trouble discerning what to do next and some did not recognize that they were brought back to the username field.
Login dialog with 'Username' and error feedback.
We also recommend following the GNOME Documentation Style Guide. We also recommend developers to involve a technical writer in the review of any terminology, error messages, or other on-screen text delivered into GNOME. Developers are encouraged to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.
-
Relevant Usability Principle: Consistency and standards.
-
We heard comments from four participants (Pilot, P4, P8, P10) that they were accustomed to and would prefer the username and password fields to appear on the same dialog. This, however, did not prevent the users from successfully logging in.
-
Design Recommendation: If there are no technical reasons to the contrary, then consider putting the username and password fields together in the same dialog.
-
Relevant Usability Principles: Feedback. Direct manipulation.
-
Currently there are no command buttons on the login dialog and users must hit enter to send their input to the system. One user, confused after typing in her login information, commented:
-
Design Recommendation: We recommend supporting users who are more mouse-oriented as well as those comfortable navigating with the keyboard. To support mouse-oriented users, we recommend adding an 'OK' button on both the username and password screens.
"There was no indication of what else to do. I am used to a 'continue' button". (P9)
It is standard to include a button to apply users' commands. Users should not have to guess what to do next. Just as it is recommended that that everything one can do with a mouse should be accessible through the keyboard, everything accessible through the keyboard should be supported for the mouse.
Login dialog with 'Username' and 'OK' button.
This button should be the active default. We also recommend consulting the proposed guidelines for accessible keyboard navigation.
-
Relevant Usability Principle: Match between system and the real world.
-
When asked, users (P1, P8) did not know what "marge-hci" was in the login dialog. Because there was no label, such as "hostname", "machine name" or "computer name", users did not recognize that they were logging into a machine named "marge-hci". Many future GNOME users will transition from a world of stand-alone machines. They will not come equipped with a mental model of a networked environment or the concept of logging in to different machines from a single machine; the basis of UNIX. We saw this confusion again at the end of the study when we asked users to log out. See Logging Out.
-
Design Recommendation: Not knowing what "marge-hci" was did not hinder users from successfully completing the task. However, novice GNOME users' confusion did highlight an opportunity for us to provide more assistance. To support new GNOME users we suggest including a Help button or menu in the login dialog. Selecting this button or menu should invoke Help with information about the elements and terminology found in the dialog. Again, we recommend following the GNOME Documentation Style Guide. We encourage developers to involve a technical writer in the review of any terminology, error messages, or other on-screen text delivered into GNOME. Developers are encouraged to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.
table of contents | << previous | next >>
Send feedback to Sun-GNOME-HCI@sun.com
