[HIG] My comments on HIG draft

[Kathy Fernandes <fernande spawar navy mil>]

All,

I don't have a CVS account and so am submitting my comments here.  I
hope this does not create any inconvenience.  I will be unable to
participate in the 11 Oct review.

Kathy Fernandes


2.0 Menus and Toolbars

2.1.1 Drop-Down Menus - The statement “Applications may possess a
menu bar…” presumes that there is only one menu bar in an
application.  Recommend that this statement be worded to be less
limiting (e.g., to allow applications to contain multiple primary
windows, each with a menu bar) and to indicate that it is a window that
“possesses” a menu bar, not the application per se.

2.1.4 Naming Conventions - Recommend changing the statement “Most menu
items will be labelled with verbs or adjectives” to “verbs and nouns”
since a menu such as View or Insert generally contains options that refer
to the object or entity to which the verb in the menu title 
applies.

2.2.1.1 File Access - (1) Recommend deleting docname from the Close menu
option. If, as indicated in the draft, the action applies to the current
document, then this document is the one with focus, and including docname
is unnecessary since the Close action is executed against the document
with focus. (2) Recommend that this option be moved toward the end of the
menu (next to Close All) and not included as part of the “Save” actions.
Close should be grouped with other “negative” actions so it is less
likely to be selected inadvertently if users overshoot one of the “save”
actions in the menu. 

2.2.1.3 Quitting - (1) Recommend deleting appname from the Quit menu
option for the same reason docname is unnecessary with Close. (2)
Recommend using Exit instead of Quit, given that Exit is generally
accepted as the term used to end an application.   

2.2.2.2 Clipboard Access and Deletion - Recommend moving the Delete
option outside the Cut/Copy/Paste group to minimize the opportunity for
inadvertent selection if users overshoot the Paste option.  At a
minimum, there should be a separator between Paste and Delete to provide
additional space between the two options and reduce the opportunity for
user error.

3.0 Dialogs

3.1.2 Dialog Box Layout - Nonconcur with the push button order
described in this section. This order conflicts with what is (or has
been) used in Motif, Windows, and Macintosh and has come to be expected
by most users. In addition, this order conflicts with normal scanning
order (for left-to-right languages), where users expect to see the most
important or frequently selected actions first (i.e., at the left end of
the row). Finally, if users are relying on the Tab and arrow keys for
navigation, this order forces them to tab through multiple buttons before
encountering the action button they are most likely to select. Recommend
a button order where OK is placed first, followed by Cancel, and then the
other buttons in the group and Help (if this action is included in the
window).

4.0 Controls

4.6 Combo Boxes - Recommend deleting the latter part of the second
sentence so that it reads: “Selecting one of the pre-defined values from
the menu should update the contents of the text field to that
value.”  The possibility that selecting an item in a combo box “may
also perform the action that would be performed if the user pressed the
Return key in that text field” should not be allowed, since this type of
list box is used only to select an option and not to cause an action to
occur.

5.0 Layout

5.4.1 Capitalization - The section on buttons indicates that “button
labels should have the first letter of the first word and of any
significant words capitalised.” However, Table 1 indicates that command
button labels should use sentence capitalization.  Recommend using
book capitalization, as indicated in the section on buttons.

6.0 Integrating Applications with the Desktop

6.1 Placing Entries in the Panel Menu - This section indicates that
“creation of new categories should be done cautiously to avoid the
confusing proliferation of menu items.”  Recommend that you consider
rewording this restriction to address those domains that will be using
GNOME but provide capabilities/applications in categories other than the
ones you list.  Also, you need to address conditions under which you
would “allow” a system to delete one or more of the default categories
(e.g., Games) in the Panel Menu.
 
6.1.2 Menu Entry Captions - Recommend you examine the specifics of the
guidance in this section in light of how it would be applied (both
correctly and incorrectly) in a variety of domains where the capabilities
desired do not necessarily fit the default categories in the Panel
Menu.

8.0 Keyboard Interaction Basics

9.1.1 Keyboard Navigation Examples - Nonconcur with the navigation
examples described in this section for the following reasons: (1) I
assume that GNOME follows the same keyboard selection model that was used
in Motif (i.e., tabbing to a radio button only moves focus to it; users
have to press Space to select the button). If this is true, then
recommend that when users tab into a group of radio buttons, focus should
be assigned to the first available button in the group, not to the
currently selected button. The behavior you advocate means that increases
the likelihood that users will have to perform a navigation action (if
they are using the keyboard) to change the current selection. If focus is
assigned to the first available button, there is a 1/n-1 chance that the
button that receives focus will also be the one they want to select (so
all they have to do is press Space and can move on to their next
selection/action in the window). (2) The five states described in the
examples provide a complicated and non-intuitive set of navigation
actions for users.  Recommend that Tab be used to move focus into a
tab group and the arrow keys be used for navigation within the group.
Users should use Down to move forward to the next radio button in the
group. Up should move focus backward to the previous radio button in the
group. If focus is on the currently selected radio button, Right should
move focus to the dependent control associated with the radio button, and
Left should move focus back to the parent radio button.  If focus is
on a radio button that is not selected, the dependent control should be
unavailable and Right should have not effect.

9.1.2 Mnemonics - Recommend continuing to map Enter to the OK button and
Esc to the Cancel button. 

9.1.3 Standard Application Mnemonics and Shortcuts - (1) Recommend
against assigning a shortcut key to Quit (or whatever term is used for
the action that ends the application) in order to minimize the likelihood
that users are able to press an incorrect key (Q is located near W and A
which are assigned to Close and Select All) and inadvertently quit the
application. (2) Recommend using Deselect All rather than Select None and
using Ctrl+letter for shortcuts, rather than an F-based system.