[HIG] Close as default "action", option groups, mnemonics

[Gregory Merchan <merchan phys lsu edu>]

It's bad enough to have Close buttons everywhere, but making them default
action buttons is sadistic. I have not seen any HIG that advises doing this.
The GNOME HIG does not advise this. Yet I see often see bug reports and
patches to make Close a default button.

I recommend that the GNOME HIG expressly forbid making Close a default button.


There is much confusion about toggle, check, and radio buttons.
The "property browser" (strange name) in Nautilus reimplemented radio buttons.
(It's the thing with chits and emblems.) An early version of the Background
capplet also did this. Discussion about fixing the Nautilus property browser
on nautilus-list indicates even more confusion. I would not be surprised
to find many reimplementations of radio buttons throughout GNOME.

A review:

GtkToggleButton -
  A button which holds a binary state and may display this with some indicator.

GtkCheckButton -
  A GtkToggleButton which by default displays an indicator.

GtkRadioButton -
  A GtkCheckButton which can be part of a mutually exclusive group.

Radio buttons are so called because they resemble the buttons on some old
radios. The name describes the function; pushing one in pops another out.

The Gtk+ API does not help here. The function to show or hide the check or
circle indicator is gtk_toggle_button_set_mode(). It would be more helpful
if that were gtk_toggle_button_set_draw_indicator(), since mode could
easily be mistaken for the state the button holds. Also, many people do not
understand the Gtk+ (now GObject) class system. Questions on the mailing lists
and IRC have indicated this for some time. What is often missed is that
the functions which apply to a parent class also apply to the child class.
As mentioned here: a GtkRadioButton is a kind of GtkCheckButton is a kind of
GtkToggleButton and so you the functions and signals of a GtkToggleButton
are also functions and signals for a GtkRadioButton. Even though this is
simple inheritance, people often miss it. That programmers read documentation
less frequently than end-users does not help either.

The GNOME HIG does not help the programmers here. I cannot judge whether it
helps designers. The HIG actually encourages the error which has been
witnessed:

  * Only use toggle buttons in groups, so they are not mistaken for regular
    buttons. Make the group behave like either a group of check boxes where
    none, one or more of the buttons may be set at once, or a group of radio
    buttons, where exactly one button may be set at once, and setting one
    button unsets the others.


Perhaps organising the HIG along the lines of purpose rather than means
would be helpful. Something like:

...
  Presenting a group of related options.
    For normal access or global options (menus)
    For rapid access or document contexts (toolbars)
    For infrequently used options or application settings (dialogs)
      When options are few (check boxes)
      When options are many (a scrollable checklist)
    
  Presenting a group of mutually exclusive options.
    For normal access or global options (menus)
    For rapid access or document contexts (toolbars)
    For infrequently used options or application settings (dialogs)
      When options are few and textual (radio buttons with indicators)
      When options are few and graphical (radio buttons without indicators)
      When options are many (an option menu - i.e., GtkOptionMenu)
...


Access keys - a.k.a., mnemonics
(Note that Microsoft agrees with us and calls them access keys now. ;-)

Providing mnemonic and tab access to a group of exclusive options is less
likely to create key conflicts, faster, and what at least Windows does.

Given something like this:
  +- Option Group ---+
  |                  |
  |  ( ) Option 1    |
  |                  |
  |  ( ) Option 2    |
  |                  |
  |  ( ) Option 3    |
  |                  |
  +------------------+

GNOME uses an access key for each option, tabbing moves within the group, and
arrow keys also move withing the group.  Windows uses an access key on the
label "Option Group", tabbing moves out of the group, and arrow keys move
within the group. IMO, Windows is better here.


Cheers,
Greg Merchan