[HIG] HIG Review

["Kathleen Fernandes" <fernande spawar navy mil>]

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.