[HIG] HIG/GNOME 2 usability comments (long)

[Calum Benson <calum benson sun com>]

Some excellent comments from one of our beta reviewers, should be of
interest to all...

<comments>
Window Management Components

Problem: Dialog windows and message windows can be resized larger 
(minimum size is normal size) even though no additional information is 
visible when the window is resized.
Recommended Fix: A dialog window should be resizable only if more 
information is visible when the window is resized. A message window 
should not be resizable.
 
Problem: Shortcut keys are assigned to all options in the Window menu 
except Shade and those related to workspaces.
Recommended Fix:  A standard shortcut key should be assigned  to Shade. 
This key should be a combination of ALT and one of the F keys (similar 
to the shortcuts assigned to other Control menu options).
  
Problem:  The window frame for a resizable window has the same 
appearance as the window frame for a non-resizable window. The only way 
users can determine if a window can be resized is to place the pointer 
on the frame.  If a window is resizable, the pointer changes shape and 
"dragging" the frame resizes the window; if a window is not resizable, 
the pointer does not change shape and "dragging" the frame moves the 
window.
Recommended Fix: The window frame should be redesigned to distinguish 
between resizable and non-resizable windows.  Users should not have to 
rely on a change in pointer shape to identify the functionality provided
by a window frame.
 
Problem: Double clicking on the Window menu button opens and closes the 
Control menu but does not close the window.
Recommended Fix:  Double clicking on the Window menu button should close
the window.

Problem: When ALT+SPACE is used to display  the Window menu, focus is 
not on the first option in the menu.  Pressing DOWN moves focus to the 
first option.  Other pull-down menus (e.g., in a menu bar) assign focus 
to the first option when a menu is displayed.
Recommended Fix:  The same behavior for keyboard access should be 
available in all pull-down menus.
 
Problem:  If ALT+SPACE is used to display the Window menu and  the 
pointer happens to be placed where the menu opens, focus is assigned to 
that option.  This behavior affects users (e.g., those who are blind) 
who rely on focus being at a consistent location whenever the menu
opens.
Recommended Fix:  The pointer should not be allowed to "capture" focus
in this way.
 
Problem: A window that has been resized and then closed reverts to its 
original size when re-opened.
Recommended Fix: A window that has been resized should remain this size 
when re-opened.

Problem: A window that has been moved and then closed reverts to its 
original location when re-opened.
Recommended Fix: A window that has been moved should remain at this 
location when re-opened.
 
Tasklist Buttons
 
Problem: The order of options in the Window menu for a tasklist button
is different than the order of options in the Window menu for an open 
window.
Recommended Fix:  The same order of options should be used whenever a 
Window menu is displayed.

Problem: A tasklist button has a recessed appearance only when the 
window with the same name as the button has focus.  If a dialog parented
by the window has focus, the button is not recessed.
Recommended Fix: A tasklist button should remain recessed even when a 
dialog has focus so users have an indication of the parent window (or 
application) in the taskbar.

Problem: A tasklist button has the same appearance when the window is 
shaded and does not have focus as when the window is minimized.
Recommended Fix:  There should be different visual cues used to 
distinguish shaded and minimized windows.
 
Problem: When a minimized window is restoredby selecting the Unminimize 
option in the Window menu (using either the pointing device or 
keyboard), focus is not assigned to the restored window.  However, when 
a minimized window is restored by clicking BLeft on the tasklist button,
focus is assigned to the restored window.
Recommended Fix:  The same behavior should occur (i.e., the window 
should receive focus) regardless of the method used to perform the 
action.
 
Pull-Down Menus

Problem: When F10 is used to activate a menu bar and display a pull-down
menu, the menu title appears to have focus (i.e., has a raised 
appearance).  However, when the mnemonic for the menu title is used to 
display the menu, both the menu title and first option in the menu 
appear to have focus (i.e., have a raised appearance).
Recommended Fix: The same behavior should occur regardless of the 
keyboard method used to interact with menus.
 
Pop-Up Menus
 
Problem: When the keyboard is used to display a pop-up menu, the menu is
positioned under the hotspot of the pointer, regardless of where the 
pointer is located on the screen; for example, the pointer can be 
outside the window containing the object with focus, and the menu is 
displayed at the pointer location.
Recommended Fix: If the keyboard is used to display a pop-up menu, the 
menu should be placed to the right of the object, rather than at the 
pointer location.
 
Problem:  When the pointing device is used to display a pop-up menu, the
first menu option has focus because the menu is place under the upper 
left corner of the pointer.  By contrast, when SHIFT+F10 is used to 
display a pop-up menu, the first option does not have focus even though 
it is placed at the same location as when the pointing device is used.
Recommended Fix:  The same behavior should occur without regard to the
input device used.

Submenus

Problem: When SPACE is used to activate a submenu option, the menu and
submenu are not dismissed.
Recommended Fix: The same behavior should occur when a submenu option is
selected using either RETURN or SPACE; i.e., both the menu and submenu
should be dismissed.

Drop-Down List Boxes

Problem: The text-display box in a drop-down list is insensitive and 
cannot be used to open the list.
Recommended Fix:  Both the text-display box and down arrow should be 
sensitive (and open the list box when users click on them).

Window Design

Problem: The availability of push buttons in a window is not managed to 
minimize user error; e.g., users are able to select push buttons before 
completing the input required  in a window.
Recommended Fix:  Push buttons should be unavailable in a window until
users have completed required input.

Pointing Device Input

Problem:  GNOME does not provide a consistent mapping of actions to 
pointing device buttons.  Examples:
(a)  Clicking BLeft or BMiddle inside a window assigns focus to the 
window.  Clicking BRight inside a window assigns focus to the window and
displays a pop-up menu if one is available.
(b)  Clicking BLeft on a push button, radio button, check box, or 
toolbar button activates or selects it.  Clicking BMiddle or BRight on 
one of these controls moves focus to it but does not activate or select 
it.
(c)  Clicking BLeft, BMiddle, or BRight on an item on a list box selects
it.  In the Appearance "tab" of the Preferences window in Nautilus, 
clicking BLeft on an item in the Theme list selects it and performs an 
"instant apply;" clicking BMiddle or BRight on an item selects it but 
does not perform this action.
(d)  Clicking BLeft or BMiddle in a text box places the text cursor in 
the box.  BRight displays a pop-up menu if one is available.
(e)  Clicking BLeft, BMiddle, or BRight on a list item in a combo box 
selects it.
(f)  Clicking BLeft, BMiddle, or BRight on a page title in a tab control
selects it and raises the page to the foreground.
(g)  Clicking BLeft on an arrow in a scroll bar scrolls one unit in the 
arrow direction.  Clicking BMiddle on an arrow scrolls one large unit in
the arrow direction.  Clicking BRight on an arrow scrolls to the 
top-bottom of the scrollable area.
(h)  Clicking BLeft on the shaft of a scroll bar or scale scrolls one 
large unit.  Clicking BMiddle on the shaft scrolls to where the pointer 
is placed in the shaft.  Clicking BRight on the shaft has no effect.
(i)  Dragging the indicator in a scroll bar or scale using BLeft, 
BMiddle, or BRight moves the indicator in the pointer direction.
(j)  Clicking BLeft on the arrow in a drop-down list box or drop-down 
combo box opens the list; BMiddle and BRight have no effect.  Clicking 
BLeft, BMiddle, or BRight on a list item selects it.  In the Preferred 
Applications window, clicking BMiddle on the text-display box in the 
"Select a Web Browser" drop-down list box moves the location cursor to 
the tab title, and clicking BMiddle on the arrow button displays the 
text cursor at the end of the text in the text-display box.
(k)  Clicking BLeft on an option menu button opens the menu; BMiddle and
BRight have no effect.  Clicking BLeft, BMiddle, or BRight on a menu 
option selects it.
Recommended Fix:  As indicated in the Solaris User Guide, BLeft should 
be used to select and drag objects, BMiddle to paste text and move 
objects, and BRight to display pop-up menus.   If variations are 
supported, they should be documented in the GNOME 2 HIG and Solaris User
Guide.

Problem:  In an icon view of objects in the Nautilus window, 
SHIFT+clicking BLeft on an object performs a disjoint selection, rather 
than a range selection.  CTRL+clicking BLeft on an object also performs 
a disjoint selection.  There is no way to perform or extend a range 
selection using a SHIFT-modified BLeft action.
Recommended Fix:  A range selection should be performed using SHIFT and 
BLeft, and a disjoint selection using CTRL and BLeft.  If variations are
supported, they should be documented in the GNOME 2 HIG and Solaris User
Guide.

Keyboard Input

Problem:  GNOME does not provide a consistent model for performing 
keyboard navigation.  Examples:
(a)  Arrow keys and SHIFT+arrow keys navigate between items in a list 
box.  CTRL+arrow keys move the location cursor between items.
(b)  Arrow keys navigate between list items in a drop-down combo box.  
SHIFT+arrow keys have no effect.  CTRL+arrow keys open/close the list 
box.
(c)  Arrow keys navigate between items in an option menu.  SHIFT+arrow 
keys and CTRL+arrow keys have no effect.
(d)  Arrow keys navigate between radio buttons in a group.  SHIFT+arrow 
keys have no effect.  CTRL+arrow keys jump to another tab group (in an 
unpredictable way).
Recommended Fix:  Navigation should be performed using unmodified arrow 
keys.  If variations are supported, they should be documented in the 
GNOME 2 HIG and Solaris User Guide.

Problem:  GNOME does not provide a consistent model for performing 
keyboard selection.   Examples:
(a)  A single selection in add mode is performed using CTRL+arrow keys 
to move the location cursor to an object, then using SPACE  to select 
the object.
(b)  Unable to perform or extend a range selection using normal mode.  
For example, CTL+arrow keys move the location cursor to an object (while
retaining the select state and highlight on the first object).  However,
neither SPACE or SHIFT+SPACE performs a select action on the object; 
instead, these keys open the highlighted object.
(c)  Unable to perform a disjoint selection using the keyboard.
Recommended Fix:  A single selection in add mode should be performed 
using the arrow keys and SPACE, a range selection using the arrow keys, 
SHIFT, and SPACE, and a disjoint selection using the arrow keys, CTRL, 
and SPACE.  If variations are supported, they should be documented in 
the GNOME 2 HIG and Solaris User Guide.

Problem:  GNOME does not provide a consistent mapping of actions to keys
on the keyboard.  See examples above and the following:
(a)  In the Pick a Font window, moving the location cursor to the 
"Modify preview phrase" push button and pressing RETURN activates the 
button even though it is not the default.
(b)  In the Panel Preferences window, RETURN selects/deselects a check 
box (there is no default push button defined until focus is on a push 
button).
Recommended Fix:  Whenever possible, a single action should be assigned 
to each key (e.g., SPACE always selects or activates a control, RETURN 
always performs the default action in a window).  The same action should
not be assigned to multiple keys, and different actions should not be 
performed by the same key depending on the control with focus.

Problem:  ALT+ESC and ALT+TAB remove focus from one primary window but 
do not assign it to another primary window.
Recommended Fix:  These shortcut keys should move focus forward among 
primary windows (i.e., between window families).

Problem:  CTRL+F6 and SHIFT+CTRL+F6 do not move focus forward and 
backward among the child windows within a family.
Recommended Fix:  These shortcut keys should be supported.

Multiple-Column List Boxes

Problem:  In the Keyboard Shortcuts window, increasing the width of a 
column by dragging the boundary increases the size of both the column 
and the window.
Recommended Fix:  Resizing a column should affect only the column and 
not the window.


Combo Boxes

Problem:  In the Pick a Font window (accessed from the Font & Colors 
"tab" in the gedit Preferences window), when users tab to the Size combo
box and begin typing, the first character entered is "lost" and only the
second character is displayed (e.g., if the text box contains "10" and 
the user types "12," only "2" is displayed).
Recommended Fix:  All text should be displayed as typed.

Problem:  A combo box appears to be two separate controls (i.e., a text 
box and a list box), rather than a single integrated control.  As a 
result, keyboard navigation using TAB assigns focus to the text box and 
then to the list box, with UP and DOWN navigating between items only 
when the list box has focus.
Recommended Fix:  A combo box should behave as a single control.  When 
focus is assigned to a combo box, the text in the text box and the 
matching list item should highlight; LEFT and RIGHT should move the text
cursor in the text box, and UP and DOWN should move the highlight 
between list items.

Drop-Down Combo Boxes

Note:  The following two items apply to the drop-down combo box in the 
Pick a Font window opened by selecting one of the buttons on the Fonts 
"tab" of the Preferences window in gedit.

Problem:  The list box opened from the Font Size drop-down combo box 
shows all possible font size values (20 total) if the window is placed 
so the full list fits on the workspace when the list opens.  If the 
window is placed so the full list does not fit, the list is sized to fit
on the workspace and contains scroll bars.
Recommended Fix:  The size of the list box should be fixed (e.g., should
display up to eight items) and not vary depending on where it is placed 
on the workspace when opened.

Problem:  Pressing BLeft on the arrow button in the Font Size drop-down 
combo box and then moving the pointer within the arrow button changes 
the currently selected list item to the first item in the list; e.g., if
"12" is the currently selected item, pressing BLeft to open the list and
then "jiggling" the pointer changes the currently selected value to "8."
Recommended Fix:  This behavior should not be supported.

[CB: This one has been fixed recently, right?]

Window Design

Problem:  An "instant apply" window does not provide the capability to 
"undo" a change in settings, forcing users to remember what the original
settings were if they want to revert to what was in effect before they 
made the changes.  Also, in these windows, the action performed by the 
Close button in the title bar differs from what occurs in all other 
windows.  Close normally closes a window without applying any changes to
settings; however, in an "instant apply" window, Close applies the 
changes and closes the window.  Finally, an "instant apply" window does 
not provide any efficiencies in terms of reducing the number of "clicks"
required in the window, given that users have to select the Close push 
button in order to dismiss the window (an "explicit apply" window 
requires users to select OK to apply the changes and dismiss the
window).
Recommended Fix:  The usability problems associated with "instant apply"
windows should be documented in the HIG.  At a minimum, a visual cue 
should be provided in these windows so users can identify them.

</comments>

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            GNOME Desktop Group
http://ie.sun.com                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems