Keyboard navigation bugs (long)

[Calum Benson <calum benson sun com>]

Calum Benson wrote:
> 
> Havoc Pennington wrote:
> > The thing to do there is post a mail summarizing each issue with
> > pros/cons and see if we can hash it out, I guess.
> 
> I still need to do this, I'll get onto it in the next day or so.

So, here we go.  These are the faintly niggling issues that I think we
need to clear up once and for all before we attack the gtk keynav bugs.

Behaviour of default button in dialogs
--------------------------------------
I think we pretty much decided in favour of never changing the
pre-determined default button as you tabbed through a dialog even when
another button gains focus, because it makes things more confusing for
people relying on assistive technologies.  If I'm mis-remembering this
one or anyone has another objections, please remind me.

The main issue is how you activate the default button.  Current proposal
is that Enter should activate it regardless of which control has focus,
unless that control happens to swallow Enter for its own purposes (e.g.
a multi-line text field, or a list/tree).  

The most common objection to this has been that people often
instinctively hit Enter after typing into a single-line text field, only
for the dialog to disappear before they'd finished with it, and
therefore Enter should actually move focus on to the next control
instead.  

Similarly, because Enter is regarded as an "action button", people might
well try to use it to change the state of the currently-focused checkbox
or radio button in a dialog, resulting in the window closing instead. 
(Spacebar is the proposed shortcut for changing the state of such a
control).

Also, assuming that we stick with the concept of never changing which
button is the default once the window is open, this means that when a
non-default button has focus, pressing Space will activate that button,
and pressing Enter will activate a different button.  This is guaranteed
to catch people out.

So, possible solutions:

1. Stick to the proposal: Enter always activates the default button,
unless the widget with focus uses Enter for something itself. 
(Multi-line text widget, list control etc.).  

Advantage: reasonable (but not complete) consistency.  
Disadvantage: easy to dismiss dialog by mistake.

2. Pick a different shortcut for "Activate the default button" that you
wouldn't hit in error, such as Ctrl+Enter.  Enter can then effectively
be used to duplicate Tab as a navigation key, except in cases where the
currently-focused widget uses Enter for something itself.  (Multi-line
text widget, list control etc.).  

Advantage: Complete consistency whichever control has focus, hard to
dismiss dialog by mistake.  
Disadvantage: Not as convenient as just pressing Enter.

3. Ensure none of the other widgets use Enter for their own purposes. 
This is a bit of a non-starter, really.


Behaviour of Tab and Enter in entry controls
--------------------------------------------
The current proposal is that Tab should insert a tab character into an
entry control, and Enter should insert a newline (in the case of
multiline entry fields).  Some people have commented that this means you
can't use Tab alone to navigate through any dialog box that includes an
entry field-- which probably accounts for most dialog boxes ever
designed.  Instead, whenever focus hits an entry field, you have to use
Ctrl+Tab to move focus on to the next control.

Possible solutions:

1.  Stick to the proposal, and force people to use Ctrl+Tab to navigate
out of every entry field.  

Advantage: easier to input formatted data into multi-line text fields.  
Disadvantage: Inconsistent navigation through dialog, easy to
insert/overtype Tab character into a text field by mistake while tabbing
through dialog.

2.  Don't allow Tab characters to be inserted into single or multiple
entry fields by default, but provide a simple means (creation-time
flag?) of overriding this for specific instances.  This way, the
Ctrl+Tab trick is only required to get out of fields into which you can
actually insert a tab character, which isn't actually a very common
requirement.  

Advantage: easier/more consistent navigation through some dialogs.  
Disadvantage: no way of telling when you tab into an entry field which
key combination will get you back out again.

3. In an entry field, have Ctrl+Tab and Ctrl+Enter insert a tab/newline
character instead, and leave Tab and Enter alone to perform their usual
navigation functions around the dialog.

Advantage: Complete consistency of navigation, unmodified Tab key will
take you through the whole dialog.
Disadvantage: Less convenient to enter formatted data into text fields. 
(Ctrl+Enter would also interfere with the "activate default button"
proposal mentioned earlier, if we went with that).


Toolbars
--------

Current proposal is that a toolbar in a window should be part of the
normal Tab sequence for that window, however, it's not entirely clear to
me how this would work in practice.  Most likely, e.g. in a typical
document-based app like a text editor, you would have to press Ctrl+Tab
to move focus out of the document and up to the "higher level" of
controls-- toolbars, menu bar, and possibly status bar.  Once you've
done that, it's not clear how you get focus back "down" to the document
level again-- the document could just be the last navigational element
in that "higher level" chain, but that feels like a slightly broken
mental model.  Maybe it would work, though.

Alternative proposal: Just as F10 gives focus to the menu bar in a
window, we could specify a shortcut that would cycle focus through each
toolbar in the current context-- such as Ctrl+F10.  Once a toolbar had
focus, it would be navigable with the Tab key and arrow keys (in the
case of button groups), as per the current proposal.  

Advantages: Mental model makes more sense, to me at least!
Disadvantage: Another keyboard shortcut for people to remember, and
another one taken out of the pool of available ones for app developers
to use.


Er... that's it.  I'll probably think of more once I've gone home, but
that's enough to be getting stuck into, I think...

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