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.
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 key is not selected." This error message would appear above the username field to communicate that the user should try logging in again (see 'Logging In' for illustration).
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.
Design Recommendation: If there are no technical reasons to the contrary, then consider putting the username and password fields together in the same dialog.
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. This button should be the active default. We also recommend consulting the proposed guidelines for accessible keyboard navigation.
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.
Design Recommendation: The logout icon relies heavily on elements commonly associated with sleep, a moon and stars, to convey its meaning. A moon and stars can convey night time, but users did not associate night time with the end of the day and logging out. This icon also uses the same computer as the terminal icon, making it difficult to distinguish between the two. We suggest redesigning the icon and removing the moon and stars as well as the computer imagery. Alternate design elements that might communicate "logging out", "leaving", or "exiting" more successfully include arrows and/or doors. We recommend trying to illustrate the physical aspect of "leaving" rather than relying on "sleep" or "nighttime" imagery to imply "the end of a work day or work session". We recommend testing new designs with a wide range of users to ensure that they interpret it correctly.
Design Recommendation: The terminal icon might be more clear if the logout icon is redesigned to not use the same computer imagery (see the logout icon design recommendation). However, we recommend testing a version of the terminal icon that does not have the small GNOME footprint overlaid on the computer. The footprint seemed to confuse users the most. The icon might also be improved by thickening or brightening the color of the small light gray lines on the monitor so there is greater contrast between the lines and the black screen. We recommend testing new designs with a wide range of users to ensure that they interpret it correctly.
Design Recommendation: Consider using the existing application icon for the default browser in the default configuration of the panel. If Mozilla is the default browser, use the application icon for Mozilla in the panel. Likewise, if Netscape is the default browser, use the Netscape application icon in the panel.
Design Recommendation: We recommend redesigning the GNOME Main Menu foot icon so that it is more obvious that clicking it will display a menu. The small arrow above the foot, that indicates a menu is invokable, needs to be made more noticeable. Possible redesigns could include enlarging the arrow or changing the color of the arrow when the user mouses over the foot icon.
Design Recommendation: Most future GNOME users coming from Macintosh or Windows will have no concept of man pages, just Help. Therefore, the emphasis on 'integrated' help will only confuse them. We recommend rewriting this tooltip. Suggestions to user-test, as alternatives to "Integrated help system (info, man, HTML)", could include "GNOME User Guide" or "Online Help". We also recommend following the GNOME Documentation Style Guide and involving 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.
Design Recommendation: We recommend moving the Programs >Utilities >GNOME Search Tool menu item to the top level of the GNOME Main Menu (see 'File Management Tasks' for illustration).
Design Recommendation: We recommend spelling out the terms 'glob' and 'regexp'. For example, instead of 'regexp', we suggest 'regular expression' (see 'File Management Tasks' for illustration). Users should also be able to access online Help that will provide explanations of menu items and how to use the search syntax.
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.
Design Recommendation: Remove the red pencil icon. It is unclear why it appears in the sidebar or what it means. If it does mean the user can't edit a file, then for consistency it should remain in the sidebar when the file is double clicked and opened into a Nautilus viewer.
Design Recommendation: It is important to communicate to users that the system is busy and to provide feedback indicating that the system has received the users' input and is operating on it. During a lengthy search operation, when users must wait until the operation is complete, change the shape of the cursor. Because users are still able to click elsewhere in Nautilus while a search is in progress, we recommend changing the cursor to a combo cursor (arrow + hourglass), such as the combo cursor seen in xalf when an application is launched. However, this combo cursor only applies to the active Nautilus window with a search in progress. If the user clicks elsewhere, for example invokes a terminal or opens the Control Center, the cursor should return to the normal arrow cursor within those applications.
Design Recommendation: We recommend designing a more distinctive Nautilus throbber that provides better visual feedback to the user that the system is busy. To be effective, the inactive state of a throbber must be easily distinguishable from its in-progress state. (see 'File Management Tasks' for examples.)
Design Recommendation: Users expect the ability to click on live links and be taken to the web. We recommend supporting live links and implementing appropriate cursor changes over live links in the Nautilus viewer. The cursor used over a live link in the Nautilus viewer should be the one that Mozilla uses for live links if Nautilus has been compiled with Mozilla support to render its HTML pages, or the cursor that GtkHTML uses if Nautilus has been compiled with GtkHTML support to render its HTML pages. This will ensure that the same cursor is used for live links whether Nautilus is used to look at a text file or a web page.
Design Recommendation: The carriage return symbols are an awkward way to represent line wraps (see screenshot in 'File Management Tasks'). It is fairly standard to just wrap the lines without symbols. We suggest removing the symbols entirely and wrapping lines at word breaks.
Design Recommendation: We recommend providing more visual indication that the user is in viewer mode and cannot edit. One possible approach is to present the file surrounded by a gray border, to imply that the user is not looking at the actual file but at a view of the file. Adobe Acrobat Reader uses a similar approach successfully to indicate that files are read-only. Other possibilities include an explanatory tooltip for the read-only view, or a message box if the user tries to type into the read-only area. Additionally, we recommend adding help text to the top of the view pane and above the Open With... buttons in the Nautilus sidebar. (See 'File Management Tasks' for illustration)
We recommend involving a user interface designer when redesigning how Nautilus views are visually presented. Developers are also encouraged to ask UI design questions or solicit feedback on the usability@gnome.org mailing list or the #usability channel on IRC.
For any on-screen text, we recommend following the GNOME Documentation Style Guide. We encourage developers to involve a technical writer and to ask terminology questions on the gnome-doc-list@gnome.org mailing list or the #docs channel on IRC.
Design Recommendation: There is currently a discussion taking place on the GNOME usability mailing list about applets, gagdets, and panel gagdets. We feel this discussion is going in the right direction towards addressing the issues raised in this usability study around the Applets menu. We recommend referring to and becoming involved in that discussion.
Design Recommendation: We recommend simplifying the Clocks menu by removing some of the clocks. User do not need that many choices. For any clocks that remain in the menu, we suggest renaming them with more meaningful and descriptive names.
Design Recommendation: We strongly recommend implementing submenus so that clicking the menu title does not dismiss the menu. If this is not possible, then we recommend giving the menu titles better visual affordance so it is clear they are not the first selectable items in submenus. Approaches to create greater visual affordance can include displaying menu titles in a bold font, using a thicker line to separate menu titles from menu items, or removing icons that appear beside menu titles.
We also recommend consistently implementing menu titles for every submenu. To be consistent, the Applets menu should be implemented with its own menu title.
Design Recommendation: We suggest duplicating the "Remove from panel" menu item somewhere in addition to contextual menu. Hiding this option behind the right mouse button penalizes users who do not use more than one mouse button. Everything in the contextual menu should be duplicated somewhere accessible without using the right mouse button.
Design Recommendation: When icons are used in menus, it is recommended that all menu items have icons. If an icon does not exist for a particular menu item it is recommended that a generic icon be displayed, rather than no icon at all. It is important to be consistent so that users do not get confused or think there is a bug with the system.
Design Recommendation: The relationship between 'Wallpaper' and 'Color' needs to be presented more clearly. 'Wallpaper' and 'Color' are mutually exclusive, yet they are not presented in a distinct way. One suggestion is add 'Wallpaper' and 'Color' radio buttons to the top of the capplet. This would allow a user to state whether he or she was applying a wallpaper pattern or a color. Currently, if users wants to apply to color they have to first select 'none' in the 'Wallpaper' pulldown. It is not intuitive to go to 'Wallpaper' when the desire is to manipulate 'Color'. Selecting 'none' in the 'Wallpaper' pulldown has the effect of toggling between 'Wallpaper' and 'Color'. It could be more straightforward to pull this step out of the 'Wallpaper' pulldown, where it was confusing and difficult for users to find, and to present it at a higher level using radio buttons.
The confusion in the Background capplet is caused by layout and UI design issues. We recommend involving a user interface designer to redesign how users select and apply wallpaper patterns and colors to the desktop background. Developers are encouraged to ask UI design questions or solicit feedback on the usability@gnome.org mailing list or the #usability channel on IRC.
Design Recommendation: We suggest replacing the text field containing the string of font information with something more intuitive to users in Appearance > Sawfish Window Manager. The current representation looks like the string of code the system uses. This is an example of where the system architecture is getting exposed at the user level and confusing the user. It would be more intuitive to simply say, "Helvetica, medium. 12pt". We recommend looking at the way popular word processing applications display font information.
Design Recommendation: The font information in the Desktop >Theme Selector capplet should be represented the same way it is in Appearance > Sawfish Window Manager capplet. This, the large font button should be removed. We also recommend removing the Use Custom Font checkbox if at all possible because most users did not see it.
Design Recommendation:The Control Center needs a major redesign to address all of these issues. This work is already in progress and those involved need to bear these quotes in mind while creating a new design.
Design Recommendation: 'Halt' is not a very intuitive term and does not clearly indicate that selecting it unintentionally could be harmful. We recommend replacing 'Halt' with a more intuitive term such as 'Suspend' and adding a text string explaining the severity of Halt, such that the checkbox label reads 'Suspend (Halt - stops the processor)'. Also, the placement of 'Halt' between the two other choices makes it very easy for a user to accidentally select it without realizing they have done so. We recommend changing the position of the Halt checkbox, or even separating it from the others, so that it does not appear between two very common choices. (See 'Logging Out' for illustration.)
table of contents | << previous | next >>
Send feedback to Sun-GNOME-HCI@sun.com