[HIG] HIG Review

General Comments

1.  Window management functions

(a) Identify the full set of these functions (e.g., start from the list in Table 10.12) and then indicate which ones are present/absent for each type of window (in Chapter 3). The omission of a function implies that it is not (or should not be) available in a window (see specific comments below).

(b) Ensure that the same functions are present in a given type of window. Recommend the HIG indicate which of the functions are "required" and "optional" and provide a table listing the functions that are present/absent/optional for the various types of windows.

(c) Address the topic of window families and parent/child relationships among the windows in a family. For example, define the action performed by Minimize (i.e., does it minimize only the window in which the function is present, or does it minimize the window and all of its children that are open?). This information is important if the decision is made to make Minimize available in every window (which appears to be the direction the HIG is moving).

(d) Ensure that the text matches the examples in the graphics (see specific comments below).

2.  Mapping keys to actions

Several HIG sections allow multiple keys to perform the same action in certain windows. In particular, both Tab and Return move focus between text fields when the dialog contains "several fields that are usually filled out in order." Recommend that the HIG not support the use of Return for navigation; in general, the HIG should ensure that only one action is assigned to a given key.

While user performance may be improved in the windows where two keys support the same action, performance is likely to be affected negatively in all of the other windows where these keys support different actions. In most dialogs with text fields, Tab navigates between the fields and Return executes the default action. If users encounter a dialog where Return moves focus between text fields, they will begin to generalize the use of this key to other dialogs that contain text fields. Given that a dialog containing "unrelated" text fields does not differ in appearance from one containing "related" fields, users have no way to distinguish between the dialogs and are likely to press Return in an "unrelated" dialog, expecting to move focus between text fields but instead (inadvertently) closing the window before completing their input.

The HIG indicates that using Return to navigate between text fields will "help prevent the user from accidentally closing the window before they have entered all the information they wanted to." While this may be true in the dialog that supports this behavior, it is also likely to increase the opportunity for users to make this error in the other dialogs that do not support this behavior.

The HIG indicates that the default action in a dialog should not be available until all required user input is complete. The HIG should support this method for minimizing user error, rather than recommending the use of Return for navigation in certain dialogs.

3.  Push button order in dialogs (yet another comment)

Some of us rely on a combination of native and cross-platform applications to deliver functionality across multiple platforms. In doing so, we present users with a mix of windows built using different toolkits (e.g., Gtk+, Java, OpenMotif) and designed in accordance with different HCI guidelines (usually those provided with the toolkit). One of the significant areas where the guidelines diverge is the order of push buttons in dialogs. If these toolkits are or will be "theme-able," the users' task (i.e., select the "correct" button quickly and accurately) becomes more difficult because dialogs that are otherwise identical differ in button order.

Previous comments indicating that users will learn the GNOME button order quickly presume that the desktop is populated only with GNOME applications. I have not seen any discussion about the impact of button order on usability in the "mixed" environment described here.

Chapter 3:  Parts of Windows and System Interaction

4. "Give every window a title (with the exception of alerts and toolboxes)." Disagree; all windows, including alerts and toolboxes, should have titles.

Chapter 3:  Primary Windows

5. "For document-based applications, use Document Name as the window title." Disagree; the application name needs to be included in the title so users can link each window to its application, especially when multiple windows are open.

6.  "Window commands:  Close, Maximize/Restore, Minimize, Roll-
up/Unroll."  What about Move, Resize, Raise/Lower?

Chapter 3:  Property Windows and Preference Windows

7. "Window commands: Close, Minimize, Roll-up/Unroll." Why support Minimize? These windows are normally used for short-term interactions and do not need to be minimized.

Chapter 3:  Toolboxes

8. The text indicates that a toolbox supports Close and Roll-up/Unroll, but the graphic shows Minimize and Close buttons. Which is correct?

Chapter 3:  Information Alerts

9. "Window commands: Roll-up/Unroll, Minimize (if the alert has no parent window), Close." Why support Minimize if the alert is nonmodal?

Chapter 3:  Error Alerts

10.  "Window commands: Roll-up/Unroll."  What about Close?

Chapter 3:  Confirmation Alerts

11.  "Window commands:  Roll-up/Unroll."   What about Close?

Chapter 3:  Dialog Boxes

12. "Window commands: Minimize, Roll-up/Unroll." What about Close (which is shown in the graphic)?

Chapter 3:  Assistants

13. The text indicates that an assistant supports Close, Minimize/Unminimize, and Roll-up/Unroll, but the graphic shows only a Close button. Which is correct?

Chapter 4:  Menus

14. "Provide an access key for every menu item." What about menus whose contents exceed the number of characters available to serve as access keys? Also, how does the interface behave if the same access key is assigned to more than one menu item?

Chapter 4:  Drop-Down Menus

15. "A menu is activated from keyboard using Return." Why limit activation to only Return? What about also supporting Down and Space?

Chapter 4:  Submenus

16. "A submenu is displayed when the user clicks its title." In GNOME 1.4, moving focus to the title automatically displays the submenu (without having to click on the title). Which behavior is correct?

Chapter 6:  Tabbed Notebooks

17. "Do not assign access keys to tab labels, as this means you cannot use those access keys for any control on any of the tabs. Assign an access key to every other control on each page, however." Why can access keys be used for controls on tabs that are not visible? This is not behavior in other GUIs where only the controls in the tab on top can receive focus. Also, does using the access key for a control that is not visible raise the tab containing the control to the front? If not, then it is possible for users to perform actions related to controls they do not see -- and adds to opportunity of user error.

Chapter 10.  Keyboard Interaction

18. This chapter indicates (a) "include keyboard access to all toolbars, menus, links and buttons" and (b) "give all labelled components an access key (underlined letter), with the exception of toolbar control which would use up too many access key combinations." However, the Checklists chapter indicates "confirm that all functions listed on the toolbar can be performed using the keyboard." The tables later in this chapter identify keys for keyboard navigation but do not indicate how to navigate to/within a toolbar. If access keys are not used in toolbars, the HIG needs to identify how keyboard navigation is done.
Chapter 10.  Standard Application Shortcut Keys

19. Ctrl-U is assigned to both Duplicate (see Table 10.6) and Underline (see Table 10.10). Recommend that Duplicate be assigned Ctrl-D and Underline Ctrl-U and that Add Bookmark (which is Ctrl-D in Table 10.8) be assigned to Ctrl-M.

20. Ctrl-I is assigned to both Invert Selection (see Table 10.6) and Italic (in Table 10.10). Recommend that Invert Selection be assigned Shift-Ctrl-I and Italic Ctrl-I.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]