RE: [Usability] Keyboard navigation- outstanding issues

["Jeff Henrikson" <jehenrik yahoo com>]

> This is one of the two biggest points of contention left that we need
> some agreement on.  The options (as I see it) are either:
>
> [list of choices 1), 2), 3), 4)]

I think the primary principle here should be to optimize the common case.  Most text widgets in dialogs are single line widgets,
and inserting a tab character in a single line widget happens once in a blue moon.  Note that even if built in support for
inserting a tab is not available, a sophisticated user will notice a workaround: copy paste a tab charater from elsewhere.  This
makes a second "trick" like ctrl+tab for tab insert seem possibly unecessary, if you concede that this is a very uncommon
operation.

Some MS apps actually go so far as to prohibit the tab character in a single line box.  That seems Nazi to me.

Multiline dialogs are a different issue.  Tabs are common (email editing, whatever) and I think designers who make a dialog boxes
should understand that relying on tab anywhere in the box is going to be problematic.  Alt+letter shortcuts are much better in that
case.  And if you really need to mix single and multiline controls in one box, it might be a good idea to ask yourself why.

Hmm, my MS outlook client (sorry) accepts shift+tab to reverse navigate up to the subject cc and to entries.  But all such things
also have alt+letter shortcuts.

Generally I vote for 3), of course excepting multiline fields.

While on this subject, I would like to suggest that before general recommendations on key navigation be made, that some certain
higher level GUI patterns be worked out.  In particular, here is a 24k diatribe I sent to gtk-list a week ago:

http://mail.gnome.org/archives/gtk-list/2001-September/msg00149.html

I have gotten only one content free "I'll check it out" kind of response to this latest one.  While I was previously preferring to
do discourse on this point in English, I don't seem to be getting my point across, so I wrote a 400 line C program to demonstrate.

The outstanding issues are: does an entry widget reclaim focus if tabbed out of with invalid content?  Clicked out to another
control or window?  Clicked or otherwise switched to another application?

The focus reclamation seems to be broken in GTK 1.3.  I would love it if somebody could explain why.

This sort of issue (API nonobviousness) can make _every_ application do the wrong thing, not just ones for whom the UI designers
were slack.  Due caution should be paid for this issue in particular, and I'd like to generalize.  I made some high fuzzy sweeping
content-free generalizations on this list a while ago, and that seemed to be beyond the threshold of "realistic" as I got no
responses.  But I've made this concrete, so check this out for starters and generalizations can follow.


Jeff Henrikson