[HIG] My comments on HIG draft


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. 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. 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. 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.

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