Tab Shortcut behavior

[nightz]

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!

Sincerely,
Rômulo Fernandes.


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Calum Benson]

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@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Alexey Rusakov-2]

В Пнд, 27/07/2009 в 13:18 +0100, Calum Benson пишет:

> 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.

It may as well be beep-and-wrap, without stopping; this behaviour is

already implemented in many mobile phones.

>  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.
>

--
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Dokuro-2]

support +1 to the beep and wrap together

2009/7/28 Alexey Rusakov <ktirf@...>

В Пнд, 27/07/2009 в 13:18 +0100, Calum Benson пишет:

> 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.

It may as well be beep-and-wrap, without stopping; this behaviour is
already implemented in many mobile phones.

>  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.
>

--

 Alexey "Ktirf" Rusakov
 GNOME Project
 ALT Linux Team

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Florian Ludwig-2]

On Sun, 2009-07-26 at 19:54 -0300, Romulo wrote:

> 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.

For the record:
keyboard short cut (ctrl+Page[up/down]) does cycle but mouse-wheel does
not cycle. Epiphay, gnome-terminal, nautiulus and gedit do it this way.

As mousewheels not always are precise enough this might be good though
inconsistent.


--
Florian Ludwig <dino@...>


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Allan Day-2]

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




_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Calum Benson]

On 31 Jul 2009, at 18:46, Allan Day wrote:

> Calum Benson wrote:
>> 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.

A third option that was mentioned later in the thread was to beep but  
wraparound anyway, which also sounds like a potentially reasonable  
compromise...

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[nightz]

On Mon, Aug 3, 2009 at 6:17 PM, Calum Benson <Calum.Benson@...> wrote:

On 31 Jul 2009, at 18:46, Allan Day wrote:

Calum Benson wrote:

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.

A third option that was mentioned later in the thread was to beep but wraparound anyway, which also sounds like a potentially reasonable compromise...

Yeah im more familiar with the third option, wich beeps and wraparound.

_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability