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

[Calum Benson <calum benson sun com>]

On Tue, 2002-07-09 at 18:28, Gregory Merchan wrote:
> 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.

Personally I only think the Enter = Close default is bad if there are
text fields in the window that the designer has set the
activates-default property for.  Enter isn't really needed for much else
in a dialog; for toggling checkboxes, activating buttons and suchlike,
Spacebar is the documented keystroke.  (I certainly don't deny that
people will try to use Enter for these things and be frustrated if the
default button has been set, though.)

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

If we're not allowed to make Close the default, then we ought not to
allow OK to be the default either, as the destructive potential is much
the same.  In which case, we might as well not have default buttons at
all, really, which may or may not be a bad thing.

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

Perhaps it would, it's a bit of a no-win situation really.  If you
organise things by purpose, you end up duplicating or cross-referencing
because the same thing can serve different purposes.  If you organise by
means, you can lose sight of what the purpose is :)

The original aim was to provide a description of each control in the
Controls section, and provide more general guidelines and examples of
their usage in a wider context in the Windows and Visual Design
chapters.  As we all know though, both of those chapters are rather
badly lacking at the moment (although Coleen is working hard on
improving the Visual Design chapter).

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

This is kind of what was in the original keynav spec, although we did
still intend to have access keys on the individual controls rather than
on the group label.  But IIRC Owen argued against the tabbing/arrowkey
behaviour and didn't implement it-- I forget whether on technical or
other grounds.  Should be possible to dig out the discussions on this in
bugzilla somewhere though....

Cheeri,
Calum.

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

Any opinions are personal and not necessarily those of Sun Microsystems