Auto-forwarding of Cursor

9 Dec 2005 - 5:31pm
8 years ago
17 replies
706 reads
Paul Trumble
2004

We've been having a friendly discussion at work about using a script to
advance the users cursor in a web form when we have a text box with an entry
of denfinate length, such as a phone number or Social Security Number.
(Sorry to be US-centric, but it's a form for U.S. residents.) Both of these
controls are implemented as three separate boxes.

I'm not a fan of this, as I feel it makes it difficult for the user to keep
track of where the cursor is whether they are advancing with the tab key or
their mouse, and it can only be done on a minority of fields. On the other
hand, there is some benefit for the user if they don't lose track of the
cursor, since there is less work.

I'm just interested in the groups opinions on this.

Paul Trumble

Comments

11 Dec 2005 - 9:18am
Baldo
2005

> I'm not a fan of this, as I feel it makes it difficult for the user to keep
> track of where the cursor is whether they are advancing with the tab key or
> their mouse, and it can only be done on a minority of fields. On the other
> hand, there is some benefit for the user if they don't lose track of the
> cursor, since there is less work.

Since only a minority of "inputs" will have the "automatic advance"
feature, I fear that this feature will confuse People: the focus seems
to move randomly.

People that are confident with web forms will "tab" after the
completion of input and result is a double "tab" (1 automatic via
JavaScript, 1 from keyboard). So I think you are complicating a simple
task.

11 Dec 2005 - 9:23am
Tom George
2004

It's not clear to the user that auto-advance is going to happen until
you hit Tab and find you're in the wrong field or hit Delete and are
perplexed because your last character is not deleted. In addition, on
a number of browsers (Safari for one), some auto-advance and
validation code can lock up the field and prevent the user from
entering data or moving on the form.

Is it better/easier/more effective for the user? I don't really think
so. I think that auto-advancing and other coercive validation
techniques are about putting the onus on the user so that developers
won't have to worry about parsing, validation and/or data cleansing.

-Tom

On Dec 9, 2005, at 05:31 PM, Paul Trumble wrote:

> We've been having a friendly discussion at work about using a
> script to
> advance the users cursor in a web form when we have a text box with
> an entry
> of denfinate length, such as a phone number or Social Security Number.

11 Dec 2005 - 10:03am
Shep McKee
2005

The context of the task and the user's proficiency with the task need
to be considered. There's a discussion in the archives...
http://tinyurl.com/dl227

My thoughts:

In ALL situations, it's not clear whether auto-tabbing has been
enabled or not. Most user's will learn this over time, but only after
the advantage has been negated by errors (slips or mistakes) in data
entry. Slips are annoying, because you've all time-savings gained by
the auto-tabbing, and most probably interrupted the user's workflow.
With mistakes in data-entry, the skies the limit. If the user
completely misses their error, what are the consequences down the road?

Auto-tabbing should only be used for extensive data entry tasks (eg:
long forms where the length of the input is predetermined), or
repetitive data entry tasks (eg: forms that are filled out many times
by the same user). Even in these cases, test to make sure that, over
time, there is some benefit to the users; hopefully: decreased task
time with no increase in errors.

shep

On Dec 9, 2005, at 5:31 PM, Paul Trumble wrote:
>
> We've been having a friendly discussion at work about using a
> script to
> advance the users cursor in a web form when we have a text box with
> an entry
> of denfinate length, such as a phone number or Social Security Number.
> (Sorry to be US-centric, but it's a form for U.S. residents.) Both
> of these
> controls are implemented as three separate boxes.

11 Dec 2005 - 10:06am
Taneem Talukdar
2005

Here are some ideas I had:

I think the problem with automatically shifting the focus is that this is a
feature that only saves a user time if they are using your form multiple
times - e.g. for data entry. Then the user learns after the first couple of
times that the form will do this for him/her and so save themselves clicking
or tabbing from then on. However Im guessing that your form is to collect
information from users who will use it maybe once. Thus they will go through
extra hassle and confusion because it's the first time they're using it, and
they'll never actually properly benefit from it :)

That being said...

1. One way you might supplement the hard to see blinking cursor jumping from
box to box is if you highlight the new textfield that the cursor has jumped
to. That way when the user looks up to the screen after punching in the
first 3 numbers, they'll see the focus has shifted because the adjacent
textfield is now highlighted red or whatever.

2. A second option is to initially only show one textfield that says
"please enter the first 3 digits of your phone number [social security
number or whatever]"

User looks down, types in the digits, looks up and sees a new second field
has appeared adjacent to the first one, highlighted with "please enter the
next three digits..." and so on ... so this way the user is never going to
try and tab across because there are no textfields to tab across. Of course
with this you now have to decide how exactly to determine when you display
the next textfield...

Regards,

Taneem Talukdar

On 12/9/05, Paul Trumble <paultrumble at gmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> We've been having a friendly discussion at work about using a script to
> advance the users cursor in a web form when we have a text box with an
> entry
> of denfinate length, such as a phone number or Social Security Number.
> (Sorry to be US-centric, but it's a form for U.S. residents.) Both of
> these
> controls are implemented as three separate boxes.
>
> I'm not a fan of this, as I feel it makes it difficult for the user to
> keep
> track of where the cursor is whether they are advancing with the tab key
> or
> their mouse, and it can only be done on a minority of fields. On the
> other
> hand, there is some benefit for the user if they don't lose track of the
> cursor, since there is less work.
>
> I'm just interested in the groups opinions on this.
>
>
> Paul Trumble
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> 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 at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

11 Dec 2005 - 11:51am
ErikaOrrick
1969

Auto-tab is one of my biggest pet peeves ever. It is generally not
expected, so users are going to mess up the first time, and they may or
may not learn from their mistakes.

Shep makes some potentially good points below, but I just want to give
my experience to the contrary:

"Auto-tabbing should only be used for extensive data entry tasks (eg:
long forms where the length of the input is predetermined), or
repetitive data entry tasks (eg: forms that are filled out many times
by the same user). Even in these cases, test to make sure that, over
time, there is some benefit to the users; hopefully: decreased task
time with no increase in errors."

I work with a Windows software application with extensive data entry
done over and over by the same person. My users don't even look at the
screen most of the time, they just copy the information from the form
and automatically hit tab without looking up in between. If some fields
auto-tab and others do not, we have made the form inconsistent and
increased the users' cognitive load because they must decide whether or
not the app is going to tab for them or whether they need to do it. If
they choose wrong, they may or may not know it before they have messed
up quite a bit of data entry since they rarely look at the screen
between fields. So auto-tabbing would actually lengthen the time to
fill in forms, not shorten. The only exception I can think of is if
somehow the data supports *every* field autotabbing so there isn't that
decision point.

This is all theoretical, of course, I doubt I will be able to convince
the developers to enable autotab just so I can prove it is bad....we are
behind enough as it is :)

Erika

11 Dec 2005 - 12:01pm
Todd Warfel
2003

Depends on the audience. In our research, we've found that it's more
common for advanced users to tab through form fields, whereas more
novice and average users tend to use the mouse (a lot).

On Dec 9, 2005, at 5:31 PM, Paul Trumble wrote:

> I'm not a fan of this, as I feel it makes it difficult for the user
> to keep
> track of where the cursor is whether they are advancing with the
> tab key or
> their mouse, and it can only be done on a minority of fields. On
> the other
> hand, there is some benefit for the user if they don't lose track
> of the
> cursor, since there is less work.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | designing and usability consulting
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

11 Dec 2005 - 12:02pm
Peter Bagnall
2003

On 9 Dec 2005, at 22:31, Paul Trumble wrote:
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> We've been having a friendly discussion at work about using a script to
> advance the users cursor in a web form when we have a text box with an
> entry
> of denfinate length, such as a phone number or Social Security Number.
> (Sorry to be US-centric, but it's a form for U.S. residents.) Both of
> these
> controls are implemented as three separate boxes.

You could avoid the issue by implementing the SS and phone number input
as single fields, and just strip out spaces, dashes, and any other
punctuation that people put in later. That would avoid having to tab,
without being confusing.

Cheers
--Pete

----------------------------------------------------------
Never doubt that a small group of thoughtful, committed people
can change the world. Indeed, it is the only thing that ever has.
- Margaret Mead

Peter Bagnall - http://people.surfaceeffect.com/pete/

11 Dec 2005 - 12:59pm
niklasw
2005

I use this banking service where there is auto-advance at very first
log in prompt but nowhere else in the service, including paying bills
and such. SEB in Sweden. Maybe there are SEB people on the list who
can back up this choice with evaluation data?

After learning it it works well for me. Probably based on many of the
facts discussed here. My feeling is that mixing both in a normal user
interface will just mess things up.

Would implementing some kind of "Auto tab advance" option in a
personal settings page be asking for to much?

--N

> I'm just interested in the groups opinions on this.
>

11 Dec 2005 - 1:35pm
Robert Hoekman, Jr.
2005

Auto-advancing the cursor should make things easier, as there's no
tabbing to do.

The problem with this approach, however, is that it's not a standard,
and since a form on a site is not used very often (well, less
frequently than every day), I tend to forget very quickly which forms
do this and which do not. The only time I really expect to see it is
in product installers, on the screen where you enter the parts of a
serial number into multiple input fields. As a result, I finy myself
tabbing even when I don't need to. I've seen others do this as well.

The other issue is that, in most cases, the technique can't work. Full
Name, for example, is never going to be a set number of characters, so
using an auto-advance cursor in another section of the form (say, for
Phone Number) creates inconsistent behavior within the form. So the
user has to Tab on some fields and not on others.

I think if you're going to use the auto-advance, you should do
something extra to ensure the jump is clear, like change the highlight
color of the input field once it has focus. The input field highlight
is typically blue, so changing it to red could help make it jump out
and become noticed, so that users realize the cursor has moved.

-r-

On 12/9/05, Paul Trumble <paultrumble at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> We've been having a friendly discussion at work about using a script to
> advance the users cursor in a web form when we have a text box with an entry
> of denfinate length, such as a phone number or Social Security Number.
> (Sorry to be US-centric, but it's a form for U.S. residents.) Both of these
> controls are implemented as three separate boxes.
>
> I'm not a fan of this, as I feel it makes it difficult for the user to keep
> track of where the cursor is whether they are advancing with the tab key or
> their mouse, and it can only be done on a minority of fields. On the other
> hand, there is some benefit for the user if they don't lose track of the
> cursor, since there is less work.
>
> I'm just interested in the groups opinions on this.
>
>
> Paul Trumble
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> 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 at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

11 Dec 2005 - 2:08pm
Austin Govella
2004

On 12/11/05, Peter Bagnall <pete at surfaceeffect.com> wrote:
> You could avoid the issue by implementing the SS and phone number input
> as single fields, and just strip out spaces, dashes, and any other
> punctuation that people put in later. That would avoid having to tab,
> without being confusing.

I was always under the imprssion that this was the best practice: let
users enter data however they want, and cean it up on the server.

For data like SSNs, phone numbers, and account numbers that can have
several visual formats, it's easy to strip out unwanted characters and
store it correctly.

--
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin.govella at gmail.com

11 Dec 2005 - 4:13pm
Jeff Howard
2004

I just wanted to concur with Peter and Austin. Do the phone and SSN fields really need to be
broken up into three separate fields? It makes it easier for the database, but it's not how we
necessarily think about those datatypes. Phone numbers are chunked, sure, but it's still
essentially one unit. People ask for your phone number, not your area code, prefix and
number. And SSN for sure should be easy to parse on the back end (we don't even have
names for those chunks).

Another reason to go with a single field is that it makes filling the data via copy/paste easier.
Entering a phone number becomes two steps rather than six. Depending on where the data is
coming from, that could be an issue.

If copy/paste is a possibility, then you want to be particularly careful about being too strict
about requiring a certain format. For example, Photoshop has a field in its color picker for
hexadecimal input. But if you copy a value from an HTML file, and it happens to have a
leading "#" sign, Photoshop won't allow it to be pasted into the field. Six characters only, or
you're out of luck. Given latitude, people are going to enter phone numbers in potentially
crazy ways. Parenthesis around the area code, hyphens, the occassional slash, nospaces,
none of the above... You can give guidance in the input label but the moral is, don't be a
validation nazi.

// jeff

Jeff Howard
Interaction Designer
Smart Design SF

On 10 Dec 2005, at 22:31, Peter Bagnall wrote:
> You could avoid the issue by implementing the SS and phone number input
> as single fields, and just strip out spaces, dashes, and any other
> punctuation that people put in later. That would avoid having to tab,
> without being confusing.

11 Dec 2005 - 6:05pm
Robert Hoekman, Jr.
2005

> You could avoid the issue by implementing the SS and phone number input
> as single fields, and just strip out spaces, dashes, and any other
> punctuation that people put in later. That would avoid having to tab,
> without being confusing.

This wouldn't really negate the question. Social secutiry numbers are
still a fixed number of characters, in which case the cursor could
auto-advance to the next field.

-r-

11 Dec 2005 - 6:28pm
Peter Bagnall
2003

>> You could avoid the issue by implementing the SS and phone number
>> input
>> as single fields, and just strip out spaces, dashes, and any other
>> punctuation that people put in later. That would avoid having to tab,
>> without being confusing.
>
> This wouldn't really negate the question. Social secutiry numbers are
> still a fixed number of characters, in which case the cursor could
> auto-advance to the next field.

The original problem was auto-forwarding between fields that were part
of the same logical entry. So it does solve that problem. Automatically
moving focus to the next part of a form seems problematical, for all
the reasons mentioned already, so I would recommend against using
auto-focusing for things like SS number and replace it with single
field entry, and just not bother with it for moving between the other
fields.

Cheers
--Pete

----------------------------------------------------------
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
- Benjamin Franklin, 1706 - 1790

Peter Bagnall - http://people.surfaceeffect.com/pete/

12 Dec 2005 - 12:20am
Austin Govella
2004

On 12/11/05, Robert Hoekman, Jr. <mmbeta at gmail.com> wrote:
> This wouldn't really negate the question. Social secutiry numbers are
> still a fixed number of characters, in which case the cursor could
> auto-advance to the next field.

Actually, SSNs can have 9 or 11 characters, depending on whether or
not there are hyphens.

And if you're thinking copy and paste, double-click and copy from Word
often adds a space character at the end of the selected string, so you
could theoretically have up to 12 characters.

Phone numbers suffer from a similar range of possibilities. (Though I
think country codes should be pre-populated based on country
selection, and you only have them enter the local number with area
code.)

--
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin.govella at gmail.com

12 Dec 2005 - 2:29am
Edwin van de Bo...
2005

We had this discussion a few years ago while working on an insurance
website. At this moment it uses auto-advance for the license number of cars
(2-2-2) and date fields. (D-M-Y).

As we had all the similar discussions, I always thought there was a simple
solution (next to the coloring of the second field which I thought was a
good adding): When auto-advancing to the second field, one can make the form
ignore the first keyboard-tab.

So it'll look like this:

User fills out first field.
System advances to second field.
User hits 'tab' on keyboard. System 'ignores' this tab.
User looks up at screen, and finds him/herself in the second field (ok).
And so on.

Or:

User fills out first field, second field and third field, without tabbing ->
ok.
User fills out first field, doesn't look up, hits tab, fills out second
field, and so on -> ok.

I can understand the discussion moving towards: why do we offer multiple
fields at all, but in the case of the car-license, users in our country
think of it as 2 characters - 2 characters - 2 characters and visually in
the form it looks like a license-plate as well. Gives a nice added on
experience. (regards to the designer, it wasn't me).

-----Oorspronkelijk bericht-----
Van: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] Namens Austin
Govella
Verzonden: maandag 12 december 2005 6:21
Aan: Robert Hoekman, Jr.
CC: discuss at ixda.org
Onderwerp: Re: [IxDA Discuss] Auto-forwarding of Cursor

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

On 12/11/05, Robert Hoekman, Jr. <mmbeta at gmail.com> wrote:
> This wouldn't really negate the question. Social secutiry numbers are
> still a fixed number of characters, in which case the cursor could
> auto-advance to the next field.

Actually, SSNs can have 9 or 11 characters, depending on whether or not
there are hyphens.

And if you're thinking copy and paste, double-click and copy from Word often
adds a space character at the end of the selected string, so you could
theoretically have up to 12 characters.

Phone numbers suffer from a similar range of possibilities. (Though I think
country codes should be pre-populated based on country selection, and you
only have them enter the local number with area
code.)

--
Austin Govella
Thinking & Making: IA, UX, and IxD
http://thinkingandmaking.com
austin.govella at gmail.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org 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 at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

12 Dec 2005 - 9:47am
Jack L. Moffett
2005

> Another reason to go with a single field is that it makes filling
> the data via copy/paste easier.
> Entering a phone number becomes two steps rather than six.
> Depending on where the data is
> coming from, that could be an issue.

Not only copy/paste, but browsers' auto-fill features as well.

Jack L. Moffett
Interaction Designer
inmedius
412.690.2360 x219
http://www.inmedius.com

To design is much more than simply
to assemble, to order, or even to edit;
it is to add value and meaning,
to illuminate, to simplify, to clarify,
to modify, to dignify, to dramatize,
to persuade, and perhaps even to amuse.

- Paul Rand

***********************************************************************
Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and contains confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this email or its contents in any way.
***********************************************************************

12 Dec 2005 - 4:52pm
mariaromera
2005

Sorry to throw out an idea without a reference -- but here you go...

Although I can't find it presently, I know there are specifications for formatted text in a browser (WAP I think-- I came across this working on text entry for mobile devices). This uses "static characters" to help show the user the expected entry and/or prepopulated a field with the desired delimiter characters.

For example, you could specify the phone number to be xxx-xxx-xxxx. Using a single field, you can give the formata and specify the "-" as static characters. The user would see the cursor in the first position and it would update with each entry. After 3 digits have been entered the cursor moves to the right of the first "-"... etc.

Because there is only one field there is no tabbing. Because the formatting characters ("-") are there to begin with the user can see the expected format (and does not need to enter them).

I suppose even without the reference you could discuss this with your engineering team. Hope it helps.

Cheers,
Maria Romera

---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping

Syndicate content Get the feed