Re: Keyboard navigation- outstanding issues

[Calum Benson <calum benson sun com>]

Calum Benson wrote:

> Now that we are (well, Padraig is) finally getting around to
> implementing the long-standing keyboard navigation proposals, for gtk at
> least, the two biggest issues we never really resolved are kind of
> rearing their ugly heads again.

Well, having collated the responses I got on- and off-list, predictably
enough, there was some difference of opinion  :o)  However, here's a
summary of what consensus there was:

Issue 1: Most support was shown for the idea of allowing the developer
to choose whether tab characters should be allowed in individual text
entry fields or not, by means of a flag or similar.  If they're allowed,
Tab key inserts a tab character, and [Shift+]Ctrl+Tab navigates out of
the field.  If they're not allowed, [Shift+]Tab and [Shift+]Ctrl+Tab
both navigate out of the field.  Default should be 'not allowed'.  
(Perhaps should be 'tab characters allowed' for multiline fields?)

Problem: This would presumably mean an unplanned gtk patch :o)

Alternative: Most people wanted unhindered tab navigation where
possible.  So, in single line textfields, have Tab navigate out of the
field, and Ctrl+Tab insert a tab character.  In multiline text fields,
have Tab insert a tab character, Enter insert a newline, and
[Shift+]Ctrl+Tab navigate out of the field.  This way, Tab navigation
works everywhere except for multiline text fields, which occur
comparatively rarely in comparison to single line fields.  (And where
they do, you often don't have to tab out of them anyway, if at all--
e.g. email composer window, word processor).

Issue 2: Most people seemed to prefer the current proposal, i.e. Enter
activates the window's default button unless the focused widget makes
use of Enter itself (e.g. a multiline text field).  A suggested
refinement was that if the default button is currently disabled, Enter
should move focus onto the next control instead.  (For an example of why
you'd ever want the default button to be disabled, see
http://java.sun.com/products/jlf/ed2/book/HIG.Behavior5.html#46941). 
Caveat: This puts the onus on programmers to disable default buttons
when appropriate, and perhaps even not provide a default button for some
dialogs at all.  (An idea which becomes more bearable if we decide to
assign mnemonics to "OK" and "Cancel" buttons, another suggestion that's
been bandied around recently).

I hate to bring another round of arguments about this down around my
head with the following phrase, but here goes:  I await your comments 
:o)  (A decision is getting kind of urgent now, as we've started
implemeting the rest of the keynav proposals...)

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