Re: [Usability] Keyboard navigation- outstanding issues

[Christian Rose <menthos menthos com>]

Michael Rogers wrote:
> Left and right arrow keys are used instead of Tab and Shift+Tab. ONLY
> left and right, not up or down, because navigating around a dialog using
> four arrow keys is a nightmare.
>
> If we only use left and right then we
> can chain the widgets together in a fairly obvious order. (Moving from
> top left to bottom right in rows is a familiar order for people who read
> left-to-right, and probably not awful for people who read right-to-left.
> In any case it won't be any worse than Tab/Shift+Tab, and it'll be
> better than four arrow keys.)
> 
> Within a text field, left and right move you through the text until you
> reach the end. Then they move you to the next widget. Tab enters a Tab
> character. The space bar enters a space. Enter starts a new line (or
> does nothing in a single-line field). Rationale: it is better to be
> surprised by nothing happening than to be surprised by something
> unintended happening. The special 'default button' border is removed
> from the default button when a text field has focus, as a clue that it
> will not be activated by pressing Enter.

I think this would navigating through controls with the keyboard a very
unpleasant task. Text fields are not uncommon, and even rather small
text fields usually allow for something like 20 characters of input. Add
a couple of normally sized tezt fields to a dialog and you will easily
end up in more than a hundred presses on the right arrow key to move
completely through the dialog.

Also, using the key repeat feature is no solution to this but introduces
another problem: When moving through the characters of a text field, the
movement would appear as very slow, while on the other hand, as soon as
we are past the last character, the focus would move forward between
controls again, at something that is percieved as a much higher speed
because of the much bigger sizes of controls compared to single text
field characters. These differences in speed makes it very difficult to
actually try to end up with focus on the right control, i.e. to know
when to release the button.


> Outside of a text field, Enter activates the default button. The space
> bar has the same effect as left-clicking on the currently selected
> widget. Pressing Tab or Shift+Tab causes a tooltip to appear, explaining
> that the left and right arrow keys can be used to navigate around the
> dialog, and the space bar can be used to activate things. (A tooltip is
> less intrusive than an info box.)

On the other hand, if we expect the user to press Tab to move to another
control, why not just do as the user wants, instead of using a tooltip
to tell him that he did WRONG in expecting it to work that way?

Think about it:
1) We KNOW that some users will be expecting Tab to move forward. Else
we wouldn't have this discussion of "preventive measures when user
presses Tab" in the first case.
2) We use this knowledge to tell the user something to the effect of
"you did WRONG, you should do something else" when he does this, when we
could just as easily have let him do this and make it work like he
expects. Why just as easily? Because we have shown that we knew he would
expect it to work this way (1) and we have shown that this shortcut was
indeed available in this case since we decided to bind it to the "you
did WRONG" tooltip (2).

I think such behavior in general is dangerously close to get people
really violent when using a computer and cursing developers. I know I
would be, given the scenario above and the "use this instead tooltip"...
:)


Christian