Re: [Usability]HIG/GNOME 2 usability comments (long)

[Havoc Pennington <hp redhat com>]

Hi,

This list says "government" all over it (even if it's not). ;-)

Anyway it needs to land in bugzilla.

On Thu, Dec 19, 2002 at 11:20:19AM +0000, Calum Benson wrote: 
> 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.

Right now this is a per-app per-dialog fix,
gtk_window_set_resizable(FALSE) needs to be called.  So bugs
per-dialog...

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

Someone has to tell me which F key is available and not normally used
for something else.

> Problem:  The window frame for a resizable window has the same 
> appearance as the window frame for a non-resizable window. 

This is a theme bug in Crux. Nobody file it against metacity, 
I only want patches to themes. ;-)
  
> 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.

Nah, we decided that was dumb. It is pretty dumb.
  
> 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.

Extremely complicated to fix, see wm-spec-list archives.

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

Ditto, same wm-spec-list archive threads.

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

Not true, afaict. They are using an old version.

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

And also when you focus a window with a dialog it should focus the
dialog.

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

I can't think of anything here, as far as appearance to use.

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

True, and sort of surprising too.
  
> 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.

This is most likely specific to some menu the person is trying, I
think it would vary by popup menu.
 
> 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.

Works fine here.
 
> 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).

Recommended fix: noneditable combo boxes should not be used.  We only
use combos when the text box is editable, in which case clicking it
can't drop down the list.
 
> 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.

Well they certainly are managed in some windows, this needs to be
given as a bug report on a specific window or windows.
 
> 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).

I have no idea what this means - they certainly always focus something
when I use them.

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

What do they mean by "family"?
 
> 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.

Um, the columns aren't resizable in that window. ;-)
 
> 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.

Works fine here.

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

Recommended fix: destroy crappy GtkCombo
 
> 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.

I'm not sure I believe this one. GTK would have to contain some funky
code to do that. Maybe it does...
 
> 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.

There's already a bug open to add undo/revert.

Havoc