Re: [Usability] Tab Shortcut behavior

[Calum Benson <Calum Benson Sun COM>]

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.

Unfortunately, as you've noticed, in practice there's a great deal of  
inconsistency in what apps actually do.  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. 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.

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            OpenSolaris Desktop Team
http://blogs.sun.com/calum             +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems