usability of tab focus

[Simon Asselbergs]

[Please voluntarily trim replies to include only relevant quoted material.]

Hi All,

Some expert coorperate users want to have a lot of fields on a form so they can input large amounts of data at once, in a specific flow. They like to use the Tabkey to put focus on a field. Should all fields  using tabfocus events, or only the most used input pattern? What is the best practice?

Example:
Imagine you have to design usability for one form with the fields: A,B,C,D,E,F,G
The average input pattern would be A,B,D,F.

Should I have a tab order like this

[TabIndex, field]
1. A
2. B
3. C
4. D
5. E
6. F
7. G

or like this

[TabIndex, field]
1. A
2. B
3. D
4. F
other fields don't respond to the tabfocus event.


Cheers,

Simon

--
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Alok Jain]

[Please voluntarily trim replies to include only relevant quoted material.]

>> Should all fields  using tabfocus events, or only the most used input
pattern? What is the best practice?

Have Tab index for all fields, for following reasons:

1. The users who use tab are going to ofcourse rely on keyboards , hence
having tab index for selected fields would require them to change input
devices in case any other field has ot be selected, this breaks flow. You
can take this oportuity to rationalize the form and may be remove fields
that are there for wrong reasons
2. It makes the form unpredictable, as they would not know what next tab
index would do
3. Non-sighted users cannot use pointing device like mouse, but rely on
devices like keyboard,they would have no way to access other form fields.

- Alok
http://www.iprincipia.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Simon Asselbergs]

[Please voluntarily trim replies to include only relevant quoted material.]

> >> Should all fields  using tabfocus events, or only the most used input
> pattern? What is the best practice?
>
> Have Tab index for all fields, for following reasons:
>
> 1. The users who use tab are going to ofcourse rely on keyboards , hence
> having tab index for selected fields would require them to change input
> devices in case any other field has ot be selected, this breaks flow. You
> can take this oportuity to rationalize the form and may be remove fields
> that are there for wrong reasons

It is not that the users rely only on keyboard, they also have a mouse. I can't narrow down the number of fields in this case. There are also fields that edit a table, such as Male, Female, Unknown. This will almost never need to be editted. But these must be present on the form. If you have all fields tabindexed, it becomes 26 [Tab]-key clicks.

The user where the application is targeted at is not a consumer, but an employee. They have to be able to have fast input times for their most regular input patterns. So I thought if reducing the number of fields is not an option, than excluding seldom used fields fomr the tab focus is.


> 2. It makes the form unpredictable, as they would not know what next tab
> index would do

True, but that is a problem that could be fixed easily with visual aids.


> 3. Non-sighted users cannot use pointing device like mouse, but rely on
> devices like keyboard,they would have no way to access other form fields.
 
The application already doesn't take care of Non-sighted users. They aren't included in our target group.

Has anyone have experience with the same kind of situation?

--
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[jackbellis.com]

[Please voluntarily trim replies to include only relevant quoted material.]

Simon,
You describe software, not a "web page." I support the perspective that the
best software is all things to all people, and eventually the software that
does so becomes the leader. As such, the default should include every
"control." Given that you've described an expert (heads-down/business
user/transactional type) system, the best system would enable the user, once
experienced, to actually configure the controls included in the tab
sequence.

Many people malign this level of customization, citing MS Word's maze of
options as proof. Not I. I'm bothered only by some of their choices for
defaults and their now-antiquated absence of perfectly accurate, embedded
descriptions. As a writer, I immediately make certain key customizations to
Word every time I deal with a new instance of it.

This entire line of reasoning is completely void for other requirement
scenarios, such as an ecommerce shopping cart. Again, I'm describing
ultimate software, a matter unrelated to the ideal balance between
development cost, time, training, and "visitor" conversion.
-Jack
www.workathomewednesday.com

----- Original Message -----
From: "Simon Asselbergs" <interaction-designer@...>
To: <discuss@...>
Sent: Saturday, June 17, 2006 7:22 PM
Subject: [IxDA Discuss] usability of tab focus


> [Please voluntarily trim replies to include only relevant quoted
material.]
>
> Hi All,
>
> Some expert coorperate users want to have a lot of fields on a form so
they can input large amounts of data at once, in a specific flow. They like
to use the Tabkey to put focus on a field. Should all fields  using tabfocus
events, or only the most used input pattern? What is the best practice?
>
> Example:
> Imagine you have to design usability for one form with the fields:
A,B,C,D,E,F,G

> The average input pattern would be A,B,D,F.
>
> Should I have a tab order like this
>
> [TabIndex, field]
> 1. A
> 2. B
> 3. C
> 4. D
> 5. E
> 6. F
> 7. G
>
> or like this
>
> [TabIndex, field]
> 1. A
> 2. B
> 3. D
> 4. F
> other fields don't respond to the tabfocus event.
>
>
> Cheers,
>
> Simon
>
> --
> _______________________________________________
>
> Search for businesses by name, location, or phone number.  -Lycos Yellow

Pages
>
>
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss@...
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists@...
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Oleh Kovalchuke]

[Please voluntarily trim replies to include only relevant quoted material.]

>> 2. It makes the form unpredictable, as they would not know what next tab
>> index would do

>True, but that is a problem that could be fixed easily with visual aids.
Yes, but you will also unnessesarily increase mental load of filling your
form: instead of mindlessly pressing tab twice to skip a field, users will
have to associate the meaning of field highlight with tab order any time
they see the form. Needless to say, this new behavior would be conditioned
by your software only, would go against common experience. Better highlight
the frequently used, "expert" fields and preserve complete tabbing sequence.


Also consider those infrequent occasions when the seldom fields do need to
be filled. We have good memory of rhythm and tabbing blends effortlessly
with keyboard typing. Whenever the user would have to use "infrequent"
fields they would fairly effortlessly change the rhythm from for
example 1-1-3-1-2 to 1-1-1-1-1-2. Consider the alternative:
1-1-mouse-click-keyboard-mouse-click-keyboard-tab-1-2 - do it once every
hour and you'll quickly realiize that you are working too hard (could be
viable option if you have to do it only once a day).

I liked Jack's suggestion of customization initially, but then realized that
it wouldn't work since the fields need to be used from time to time. For the
same reason "show-hide options" interface could become annoying very quickly
if user need to show-n-hide frequently enough.

And so once more the appropriatness of solution will depend on answer to the
simple time question: "How infrequent is seldom?" (hard to get away from the
time aspect in interaction design).

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm


On 6/18/06, Simon Asselbergs <interaction-designer@...> wrote:

>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> > >> Should all fields  using tabfocus events, or only the most used input
> > pattern? What is the best practice?
> >
> > Have Tab index for all fields, for following reasons:
> >
> > 1. The users who use tab are going to ofcourse rely on keyboards , hence
> > having tab index for selected fields would require them to change input
> > devices in case any other field has ot be selected, this breaks flow.
> You
> > can take this oportuity to rationalize the form and may be remove fields
> > that are there for wrong reasons
>
> It is not that the users rely only on keyboard, they also have a mouse. I
> can't narrow down the number of fields in this case. There are also fields
> that edit a table, such as Male, Female, Unknown. This will almost never
> need to be editted. But these must be present on the form. If you have all
> fields tabindexed, it becomes 26 [Tab]-key clicks.
>
> The user where the application is targeted at is not a consumer, but an
> employee. They have to be able to have fast input times for their most
> regular input patterns. So I thought if reducing the number of fields is not
> an option, than excluding seldom used fields fomr the tab focus is.
>
>
> > 2. It makes the form unpredictable, as they would not know what next tab
> > index would do
>
> True, but that is a problem that could be fixed easily with visual aids.
>
>
> > 3. Non-sighted users cannot use pointing device like mouse, but rely on
> > devices like keyboard,they would have no way to access other form
> fields.
>
> The application already doesn't take care of Non-sighted users. They
> aren't included in our target group.
>
> Has anyone have experience with the same kind of situation?
>
> --
> _______________________________________________
>
> Search for businesses by name, location, or phone number.  -Lycos Yellow
> Pages
>
>
> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss@...
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists@...
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Oleh Kovalchuke]

[Please voluntarily trim replies to include only relevant quoted material.]

The elegant solution would be to provide keyboard shortcut to enable/disable
seldom fields (without hiding them) and to simultaneously expand tabbing
order to include the enabled fields.



Is it feasible though?

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm



On 6/18/06, Oleh Kovalchuke <tangospring@...> wrote:

>
> >> 2. It makes the form unpredictable, as they would not know what next
> tab
> >> index would do
>
> >True, but that is a problem that could be fixed easily with visual aids.
>
>  Yes, but you will also unnessesarily increase mental load of filling your
> form: instead of mindlessly pressing tab twice to skip a field, users will
> have to associate the meaning of field highlight with tab order any time
> they see the form. Needless to say, this new behavior would be conditioned
> by your software only, would go against common experience. Better highlight
> the frequently used, "expert" fields and preserve complete tabbing sequence.
>
>
> Also consider those infrequent occasions when the seldom fields do need to
> be filled. We have good memory of rhythm and tabbing blends effortlessly
> with keyboard typing. Whenever the user would have to use "infrequent"
> fields they would fairly effortlessly change the rhythm from for
> example 1-1-3-1-2 to 1-1-1-1-1-2. Consider the alternative:
> 1-1-mouse-click-keyboard-mouse-click-keyboard-tab-1-2 - do it once every
> hour and you'll quickly realiize that you are working too hard (could be
> viable option if you have to do it only once a day).
>
> I liked Jack's suggestion of customization initially, but then
> realized that it wouldn't work since the fields need to be used from time to
> time. For the same reason "show-hide options" interface could become
> annoying very quickly if user need to show-n-hide frequently enough.
>
> And so once more the appropriatness of solution will depend on answer to
> the simple time question: "How infrequent is seldom?" (hard to get away from
> the time aspect in interaction design).
>
> --
>
> Oleh Kovalchuke
> Interaction Design is Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
>
>
>  On 6/18/06, Simon Asselbergs <interaction-designer@...> wrote:
> >
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> > > >> Should all fields  using tabfocus events, or only the most used
> > input
> > > pattern? What is the best practice?
> > >
> > > Have Tab index for all fields, for following reasons:
> > >
> > > 1. The users who use tab are going to ofcourse rely on keyboards ,
> > hence
> > > having tab index for selected fields would require them to change
> > input
> > > devices in case any other field has ot be selected, this breaks flow.
> > You
> > > can take this oportuity to rationalize the form and may be remove
> > fields
> > > that are there for wrong reasons
> >
> > It is not that the users rely only on keyboard, they also have a mouse.
> > I can't narrow down the number of fields in this case. There are also fields
> > that edit a table, such as Male, Female, Unknown. This will almost never
> > need to be editted. But these must be present on the form. If you have all
> > fields tabindexed, it becomes 26 [Tab]-key clicks.
> >
> > The user where the application is targeted at is not a consumer, but an
> > employee. They have to be able to have fast input times for their most
> > regular input patterns. So I thought if reducing the number of fields is not
> > an option, than excluding seldom used fields fomr the tab focus is.
> >
> >
> > > 2. It makes the form unpredictable, as they would not know what next
> > tab
> > > index would do
> >
> > True, but that is a problem that could be fixed easily with visual aids.
> >
> >
> > > 3. Non-sighted users cannot use pointing device like mouse, but rely
> > on
> > > devices like keyboard,they would have no way to access other form
> > fields.
> >
> > The application already doesn't take care of Non-sighted users. They
> > aren't included in our target group.
> >
> > Has anyone have experience with the same kind of situation?
> >
> > --
> > _______________________________________________
> >
> > Search for businesses by name, location, or phone number.  -Lycos Yellow
> > Pages
> >
> >
> > http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss@...
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists@...
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
>
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Anirudha Joshi-2]

[Please voluntarily trim replies to include only relevant quoted material.]

Sure, we need to preserve ALL fields in the tab, but I noticed that no
one actually resorted to a visual design solution. Simon could put the
A, B, D, F fields 'at the top' of the page, followed by the OK (or
Next) button. So the visual order AND the tab order match and ease of
use is achieved for frequent tasks. One more tab, on the OK button,
and the user lands on infrequent buttons, perhaps followed by another
OK button. One could of course divide the infrequent fields with one
or two more OK buttons if desired.

How to group them? This will inevitably be a problem if there are 26
fields. The frequent fields should be grouped together at the top
(particularly if they are less than 7-9).  I am assuming that
contextually, this should take care of 70% cases (if less, then this
strategy needs a review).

Let us assume that after the first round of 7-9 frequent fields, the
frequency difference between fields is not that high. In that case,
group fields semantically and my guess is that the users will not
remember the tab sequence, so they will just use the mouse the
remaining 30% of the time.

On the other hand, assume that there is a second round of 7-9 frequent
fields that takes care of another 25% cases. Well, group them
together. The users will perhaps take a month to get used to the
second group and continue to use the keyboard. The balance fields that
change less than 5% of the time will be used by a mouse (and they
should be).

A true jackpot if the frequency has a close, semantic reason. Then you
get easy infrequent use as well as frequent. (my experience is that it
usually has if we probe enough)

Visually communicate that the two (three, four) OK buttons are all the
same (same colour, similar location, similar affordances etc.)

Anirudha
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Oleh Kovalchuke]

[Please voluntarily trim replies to include only relevant quoted material.]

*Anirudha Joshi* <anirudhaidc@...> wrote:
"...I noticed that no one actually resorted to a visual design solution..."
etc.

Hello Anirudha,

I have called the solution somewhat unfortunately "show-n-hide" interface
(also known as progressive disclosure interface):

"...the fields need to be used from time to time. For the same reason
"show-hide options" interface could become annoying very quickly if user
need to show-n-hide frequently enough.

And so once more the appropriatness of solution will depend on answer to the
simple time question: "How infrequent is seldom?"

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm



On 6/18/06, Anirudha Joshi <anirudhaidc@...> wrote:

>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Sure, we need to preserve ALL fields in the tab, but I noticed that no
> one actually resorted to a visual design solution. Simon could put the
> A, B, D, F fields 'at the top' of the page, followed by the OK (or
> Next) button. So the visual order AND the tab order match and ease of
> use is achieved for frequent tasks. One more tab, on the OK button,
> and the user lands on infrequent buttons, perhaps followed by another
> OK button. One could of course divide the infrequent fields with one
> or two more OK buttons if desired.
>
> How to group them? This will inevitably be a problem if there are 26
> fields. The frequent fields should be grouped together at the top
> (particularly if they are less than 7-9).  I am assuming that
> contextually, this should take care of 70% cases (if less, then this
> strategy needs a review).
>
> Let us assume that after the first round of 7-9 frequent fields, the
> frequency difference between fields is not that high. In that case,
> group fields semantically and my guess is that the users will not
> remember the tab sequence, so they will just use the mouse the
> remaining 30% of the time.
>
> On the other hand, assume that there is a second round of 7-9 frequent
> fields that takes care of another 25% cases. Well, group them
> together. The users will perhaps take a month to get used to the
> second group and continue to use the keyboard. The balance fields that
> change less than 5% of the time will be used by a mouse (and they
> should be).
>
> A true jackpot if the frequency has a close, semantic reason. Then you
> get easy infrequent use as well as frequent. (my experience is that it
> usually has if we probe enough)
>
> Visually communicate that the two (three, four) OK buttons are all the
> same (same colour, similar location, similar affordances etc.)
>
> Anirudha
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss@...
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists@...
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

[Suresh JV-2]

[Please voluntarily trim replies to include only relevant quoted material.]

Oleh Kovalchuke wrote:
>
> The elegant solution would be to provide keyboard shortcut to
> enable/disable
> seldom fields (without hiding them) and to simultaneously expand tabbing
> order to include the enabled fields.
>
> Is it feasible though?
>
>
http://stylephreak.frogrun.com/uploads/source/cssform.php

Here is a CSS/XTHML solution demo that may answer the question. Not sure if
Simon wants to hide or disable the fields, but the tab order is preserved in
either case. [Not sure if it is a web application..] Saving preferences
would be ideal based on usage patterns. I'm assuming the user knows what he
wants to do at the beginning.

You can also assign keyboard shortcut for the same. [Alt+{accceskey}] - CSS
http://www.alistapart.com/articles/accesskeys/  [accesskey="h"]

--
Regards,
Suresh JV.

-----------------------------------------------
Logic takes you from A to B.
Creativity takes you everywhere.
-----------------------------------------------
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss@...
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists@...
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org