Re: [Usability] Tab Shortcut behavior

[Allan Day <allanpday gmail com>]

Copying in the a11y list...

> On 26 Jul 2009, at 23:54, Romulo wrote:
> 
> > Hi there Gnome Usability people!
> >
> >   My name is Romulo and im actually a gnome lover and a developer.  
> > Some
> > days ago i decided to gave Empathy a try, because i was tired of  
> > pidgin.
> > During the initial hours of use i noticed that when i pressed the  
> > Next Tab
> > shortcut with the last tab selected it didnt cycled to the first  
> > tab, same
> > issue hapenned with the first tab selected (pressing previous tab  
> > shortcut).
> > Since nautilus, gnome-terminal, gvim and gedit (at least in my  
> > Ubuntu 9.04)
> > do that (cycling), i though about the possibility to make it real in  
> > empathy
> > too. It took me some mins to write a patch and attach it to the bug
> > http://bugzilla.gnome.org/show_bug.cgi?id=589263 . Unfortunately it  
> > didnt
> > get a commit because it doesnt look the "standard" or "expected" way  
> > of
> > behavior. After some discussions with dino on #usability we though  
> > that the
> > best way of knowing how to handle it would be asking the usability  
> > people,
> > so here i am. Hope i didnt bothered and im looking forward to have  
> > an answer
> > from you guys. Thanks!
> 
> The HIG's guidance here is that keyboard focus should not generally  
> wrap around any list of objects, whether that's tabs, icons, or items  
> in a treeview, but should instead stop with a warning beep.  This  
> guidance originated from the accessibility team, as wrapping around is  
> a potential source of confusion for assistive technology users who  
> can't necessarily see that any wraparound has occurred.

I personally find that the lack of feedback when you switch from the
last to the first tab can be disorientating. Having some kind of 'stop
point' or signal that you've crossed the end of the tab list would give
the user another valuable kind  of feedback as to where they are in the
list, particularly when quickly switching tabs using the keyboard.

> Unfortunately, as you've noticed, in practice there's a great deal of  
> inconsistency in what apps actually do.

I do like consistency. ;)

> One option would be to  
> implement the stop-with-beep behaviour only when accessibility is  
> turned on, and just wrap around when it is turned off.


> Another would  
> be to always have the stop-with-beep behaviour, but allow it to be  
> overridden with a second keypress in the same direction.

My vote would be for this option. You still get the convenience of being
able to move from the end to the beginning of your tabs, but with better
feedback about where you are in the list.

> Or we could  
> just ignore the stop-with-beep guideline altogether, as to my  
> knowledge, we've had no actual complaints from AT users about the  
> current behaviour.
> 
> But whatever we do, it would be good to do it consistently (which  
> probably means patching various gtk+ widgets as well as some  
> applications that do their own thing), and with input from the  
> accessibility team.

Accessibility team: do you have a view on this? It would be good to try
and come to an agreement on the best way to deal with this.

There's a discussion of this issue in this (old) bug:
http://bugzilla.gnome.org/show_bug.cgi?id=92139

There's also a new related bug against gnome-terminal ('allow cycling
moving tabs'): http://bugzilla.gnome.org/show_bug.cgi?id=590171

Best,

Allan
--
aday on irc.gnome.org
allanpday on GoogleTalk