Small usability issue - forms

27 Jun 2006 - 1:11pm
7 years ago
20 replies
956 reads
Cindi Thomas
2006

Hi all... I have a small issue I'm looking for a best practice on in
regards to form interaction.

Scenario:

User reaches character limit for any given form input field. Should the
cursor automatically jump to the next field in the sequence, or should
the move to the next field be a conscience, manual, user task?

I see both sides... and am personally annoyed by auto moving cursors,
but that is just me and not necessarily a best practice! :-)

Thoughts?

Cynthia Thomas

Fullhouse <http://www.fullhouseinteractive.com/>

Comments

27 Jun 2006 - 1:34pm
Jack L. Moffett
2005

Cindi,

Automatically moving the cursor from field to field makes sense when
an item of information that the user considers to be a single entry
is broken into multiple fields. For example, a phone number separated
into three fields would benefit from "auto-tabbing" as the user
quickly types in the full number. I've also seen software serial
numbers that work this way, where the long number is chunked into
shorter sections.

It would not make as much sense for fields that aren't closely
connected. Let's say I am entering my street address, and I reach the
character limit. I continue to type in the address, not expecting to
hit a character limit, but the latter part of the address ends up in
the next field.

Another way to look at it is that auto-tabbing makes sense when the
user is expecting a character limit.

Jack

On Jun 27, 2006, at 2:11 PM, Cindi Thomas wrote:

> Scenario:
>
> User reaches character limit for any given form input field. Should
> the
> cursor automatically jump to the next field in the sequence, or should
> the move to the next field be a conscience, manual, user task?
>
> I see both sides... and am personally annoyed by auto moving cursors,
> but that is just me and not necessarily a best practice! :-)

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

The World is not set up to facilitate the best
any more than it is set up to facilitate the worst.
It doesn't depend on brilliance or innovation
because if it did, the system would be unpredictable.
It requires averages and predictables.

So, good deeds and brilliant ideas go against the
grain of the social contract almost by definition.
They will be challenged and will require
enormous effort to succeed.

Most fail.
- Michael McDonough

27 Jun 2006 - 2:02pm
Juan Lanus
2005

Cindi,
As Jack pointed, auto tabbing makes sense in some special scenarios.
Nowadays it tends to disappear.
The scenario I have seen the most is a data entry related form. This
scenarios have a person that fills the same form repeatedly, many
times, with encoded data.
For example the state code, or the telephone area code. Codes are of a
known length, each code is always the same length.
The value added by the auto tabbing is in that the user does not have
to press the tab key.
It can be leveraged only with fixed-size data, and is worthwhile when
it will happen many times, for example thousands of times.
Even in an auto-tabbing form, items that have various lengths like the
street name, must not auto tab.
Actually, in such fields, reaching the size limit (if there is one) is
an error, and the action must be stopped ASAP or else the user will be
typing the last letters of the street name in the following field.
--
Juan Lanus
TECNOSOL
Argentina

27 Jun 2006 - 2:39pm
cfmdesigns
2004

>From: Jack Moffett <jmoffett at inmedius.com>
>
>Automatically moving the cursor from field to field makes sense when
>an item of information that the user considers to be a single entry
>is broken into multiple fields. For example, a phone number separated
>into three fields would benefit from "auto-tabbing" as the user
>quickly types in the full number. I've also seen software serial
>numbers that work this way, where the long number is chunked into
>shorter sections.

I've found this to work fairly well in the 40-digit software serial numbers case, because the user figures out whether the auto-tabbing will occur or not after the first box, and can put that info to use on the next nine. (It's especially usueful if the design also eats hyphens and tabs "correctly" so that a user can type in just the number, or an xxxx-yyyy-... sequence, or tab every four characters and still get the right behavuior.)

On phone numbers, there are usually only two, maybe three boxes (and the "correct" eating of tabs and such is rarely done there), so the ability to identify whether auto-tab is present and make use of it for the next box is minimal. (Often there isn't a next box, or at least auto-tab often doesn't work for exiting phone number to the next box.)

I would say that the value imparted to the user is low enough in the phone number case that you shouldn't bother. Unless there's some visual UI (Icon? A happy magic AJAX widget?) to cue the user that "these fields act in a useful way because we can predict what should go in them" and thus how they will behave. Any examples of that cueing out there?

-- Jim Drew
Seattle, WA

27 Jun 2006 - 2:43pm
Josh Galban
2005

Cindi,

In addition to Jack's and Juan's comments, here are a couple of other
observations about auto-tabbing:

1. It should be easy to edit a field that uses auto-tabbing. For example, if
I mistype the last digit of my phone number, I should be able to easily
backtab into the field, delete the last digit and type a new one. Usually,
this will require disabling the auto-tab feature when certain keyboard
characters are pressed-- for example: tab, shift-tab, cursor keys. The codes
that identify the characters will vary by web browser.

2. If a field such as phone number is split into multiple segments, it will
break the ability to copy that data from another location and paste it into
the field. Having a single field that allows for copy-and-paste may be very
useful in some contexts.

--Josh

27 Jun 2006 - 3:32pm
Jeff Howard
2004

Hi Cindi,

The only place I've seen auto-advance implemented in a useful way has been
in registration dialogs for software installation. Those are generally
long arbitrary (from the user's point of view) chunks of numbers that need
to be transcribed precisely from a secondary source. That means that the
user's eyes are going back and forth from the screen to the keyboard to
the paper.

> User reaches character limit for any given form input field.

I'd venture that "any given form field" shouldn't have an arbitrary
character count. Most are unknowable and very few other instances exist
where the input needs to be so highly regimented ALONG with the
circumstance of the user transcribing the information.

For example, in a traditional contact or billing form, you might consider
state abbreviations, zip codes or phone numbers to each have a set number
of characters. Even if they did (and I don't believe that's the case),
most people know that information by heart, and can key it in without
looking away from the computer, making it fairly easy to tab to the next
field, especially if that's what they've been doing for the rest of the
form. Adding auto-advance in that case is unnecessary at best.

The one exception might be credit card numbers. But if it's a one-time
entry in the middle of a form that doesn't use auto advance, then I'd axe
it.

// jeff

27 Jun 2006 - 7:30pm
Oleh Kovalchuke
2006

Cindi wrote: "Should the cursor automatically jump to the next field in the
sequence, or should the move to the next field be a *conscience*, manual,
user task? I ... am personally annoyed by auto moving cursors, but that is
just me..."

Hello Cindi,

Two comments:
First, you are not alone, we are with you...

Second, usually manual tabbing is *un*conscious (sic), automatic user
task. And so your annoyance is justified because introducing
auto-tabbing violates expectations, flow, consistency of function (different
terms from different sources) - you have to break to ponder why automated
field is not automatic like the rest of the form.

On more fundamental level your question illustrates the subtle, and often
misconstrued (in design) difference between two meanings of the
word automatic: one - operated without external control, two - operated
without conscious control. The well known example of this misunderstanding
is none other but that paragon of annoyance - Clippie.

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

On 6/27/06, Cindi Thomas <cthomas at fullhouseinteractive.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hi all... I have a small issue I'm looking for a best practice on in
> regards to form interaction.
>
>
>
> Scenario:
>
> User reaches character limit for any given form input field. Should the
> cursor automatically jump to the next field in the sequence, or should
> the move to the next field be a conscience, manual, user task?
>
>
>
> I see both sides... and am personally annoyed by auto moving cursors,
> but that is just me and not necessarily a best practice! :-)
>
>
>
> Thoughts?
>
>
>
> Cynthia Thomas
>
> Fullhouse < http://www.fullhouseinteractive.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
>

28 Jun 2006 - 7:34am
ldebett
2004

> Cindi wrote: "Should the cursor automatically jump to the next field in
> the
> sequence, or should the move to the next field be a *conscience*, manual,
> user task? I ... am personally annoyed by auto moving cursors, but that is
> just me..."
>
>
Hi Cindi,

For many people who "fat finger" their keyboard to type, it can often come
too late that they discover that an character limit has been reached,
exceeded, and overflowed into the next field. This is because they are
spending more time looking at the keyboard than they are at the screen. So
if, in the case where the two fields are unrelated, this may force the user
to go back and figure out how to handle the extra text they've typed in. It
could be nice, as many software apps do, if when the character limit is
reached to play a tone and show a visual indicator (some have a character
count down reaching zero, etc.), the user will be alerted to look at the
screen and immediatly discover the problem.

Cheers,
Lisa deBettencourt

28 Jun 2006 - 10:12am
AlokJain
2006

> Cindi wrote: "Should the cursor automatically jump to the next field in
> the
> sequence, or should the move to the next field be a *conscience*, manual,
> user task? I ... am personally annoyed by auto moving cursors, but that is
> just me..."
>
>

Cindi,

>From an affordance perspective it does not communicate to the user that
certain feilds in forms have auto tabbing and correcting those fields is
further nightmare.

However if it is a task that user does often and if efficiency aspect of
usability is more important then intutiveness, then such a model still
offers some value.

Regards
Alok Jain
http://www.iprincipia.com

29 Jun 2006 - 8:40am
Cindi Thomas
2006

The scenario I am referring to is an age verification "form" on a web
site where the user is required to enter month/day/year of their birth
date to enter the site. It seems the sentiment of the feedback (thank
you by the way!) is that if the form or data entry is a standard one for
the user, or the data fields are related (which these are) auto-tabbing
can be useful. My question then becomes... is an age verification as a
stand alone something that a user would be familiar enough with to fall
under a "standard?" It's not like most sites have these types entry
points, so it's not a standard practice that someone would use every
day. So in this scenario, is it more of a hindrance than a help?

________________________________

From: Lisa deBettencourt [mailto:ldebett at gmail.com]
Sent: Wednesday, June 28, 2006 7:34 AM
To: discuss at ixda.org
Cc: Cindi Thomas
Subject: Re: [IxDA Discuss] Small usability issue - forms

Cindi wrote: "Should the cursor automatically jump to the next
field in the
sequence, or should the move to the next field be a
*conscience*, manual,
user task? I ... am personally annoyed by auto moving cursors,
but that is
just me..."

Hi Cindi,

For many people who "fat finger" their keyboard to type, it can often
come too late that they discover that an character limit has been
reached, exceeded, and overflowed into the next field. This is because
they are spending more time looking at the keyboard than they are at the
screen. So if, in the case where the two fields are unrelated, this may
force the user to go back and figure out how to handle the extra text
they've typed in. It could be nice, as many software apps do, if when
the character limit is reached to play a tone and show a visual
indicator (some have a character count down reaching zero, etc.), the
user will be alerted to look at the screen and immediatly discover the
problem.

Cheers,
Lisa deBettencourt

29 Jun 2006 - 10:43am
adamya ashk
2004

Cindi,

I followed this thread with interest (auto-tabbing created headaches
in projects past) and your last e-mail has shed more light on the
issue.

For dates and phone numbers, I am a big fan of using javascript to
format the response 'on the fly'. The most successful example that I
can think of right now is Turbotax; there is only one field for date
which formats into a mm/dd/yyyy scheme as you type.
An example of the script used to create this is at:
http://javascript.internet.com/forms/format-date.html

If the date field loads with the suggestion 'mm/dd/yyyy', which clears
on focus, all the better. This provides a soft fail for users with
javascript disabled.

We've used a similar technique for phone numbers with good success.

hth,

-Adamya Ashk

On 6/29/06, Cindi Thomas <cthomas at fullhouseinteractive.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> The scenario I am referring to is an age verification "form" on a web
> site where the user is required to enter month/day/year of their birth
> date to enter the site. It seems the sentiment of the feedback (thank
> you by the way!) is that if the form or data entry is a standard one for
> the user, or the data fields are related (which these are) auto-tabbing
> can be useful. My question then becomes... is an age verification as a
> stand alone something that a user would be familiar enough with to fall
> under a "standard?" It's not like most sites have these types entry
> points, so it's not a standard practice that someone would use every
> day. So in this scenario, is it more of a hindrance than a help?

29 Jun 2006 - 11:08am
jbellis
2005

Cyndi and all,
Before seeking to be understood, I'd like to understand a little more. Would those on the list be so kind as to report all situations where they have ACTUALLY seen *either* auto-advancing or segmented fields?

We've already had reports of the first two, below:
1. Phone numbers
2. License serial numbers
3. Dates (Multi-part fields where the segments are not identical constitute a gray area. I'm adding dates to forestall this issue.)

I'm not asking for heuristic info or field types that you *think* warrant it... only cases where the technique has in fact been used. I'm asking to hear about segmented fields, too, because I will be making the case that the issues are inseparable.

I'm hypothesizing that we will not get a long list of fields from public applications, though business apps may surprise me.

Thanks, Jack

----- Original Message -----
From: "Cindi Thomas" <cthomas at fullhouseinteractive.com>
To: <discuss at ixda.org>
Sent: Tuesday, June 27, 2006 2:11 PM
Subject: [IxDA Discuss] Small usability issue - forms

am personally annoyed by auto moving cursors,
> but that is just me and not necessarily a best practice! :-)

29 Jun 2006 - 12:54pm
Cindi Thomas
2006

Here's the example that triggered my question in the first place...

http://www.millerhighlife.com/millerhighlife/ageverify.aspx

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
jackbellis.com
Sent: Thursday, June 29, 2006 11:08 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] Small usability issue - forms

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

Cyndi and all,
Before seeking to be understood, I'd like to understand a little more.
Would those on the list be so kind as to report all situations where
they have ACTUALLY seen *either* auto-advancing or segmented fields?

We've already had reports of the first two, below:
1. Phone numbers
2. License serial numbers
3. Dates (Multi-part fields where the segments are not identical
constitute a gray area. I'm adding dates to forestall this issue.)

I'm not asking for heuristic info or field types that you *think*
warrant it... only cases where the technique has in fact been used. I'm
asking to hear about segmented fields, too, because I will be making the
case that the issues are inseparable.

I'm hypothesizing that we will not get a long list of fields from public
applications, though business apps may surprise me.

Thanks, Jack

----- Original Message -----
From: "Cindi Thomas" <cthomas at fullhouseinteractive.com>
To: <discuss at ixda.org>
Sent: Tuesday, June 27, 2006 2:11 PM
Subject: [IxDA Discuss] Small usability issue - forms

am personally annoyed by auto moving cursors,
> but that is just me and not necessarily a best practice! :-)
________________________________________________________________
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

29 Jun 2006 - 2:00pm
Oleh Kovalchuke
2006

Any Cooper's fan would be quick to point out that this script provides
rather nasty interaction example of handling input errors.

"Good butller" automation would be:

1. Make a suggestion of prefered format for the entry.
2. Let user enter the date in any way they want.
3. Try to make sense of what user entered and reformat the date in machine
friendly format.
4. If designer failed to interpret user's input, save and show the
input, highlight the percieved error, ask to correct the error only.

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

On 6/29/06, adamya ashk <adamya at gmail.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Cindi,
>
> I followed this thread with interest (auto-tabbing created headaches
> in projects past) and your last e-mail has shed more light on the
> issue.
>
> For dates and phone numbers, I am a big fan of using javascript to
> format the response 'on the fly'. The most successful example that I
> can think of right now is Turbotax; there is only one field for date
> which formats into a mm/dd/yyyy scheme as you type.
> An example of the script used to create this is at:
> http://javascript.internet.com/forms/format-date.html
>
> If the date field loads with the suggestion 'mm/dd/yyyy', which clears
> on focus, all the better. This provides a soft fail for users with
> javascript disabled.
>
> We've used a similar technique for phone numbers with good success.
>
> hth,
>
> -Adamya Ashk
>
> On 6/29/06, Cindi Thomas <cthomas at fullhouseinteractive.com > wrote:
> > [Please voluntarily trim replies to include only relevant quoted
> material.]
> >
> > The scenario I am referring to is an age verification "form" on a web
> > site where the user is required to enter month/day/year of their birth
> > date to enter the site. It seems the sentiment of the feedback (thank
> > you by the way!) is that if the form or data entry is a standard one for
> > the user, or the data fields are related (which these are) auto-tabbing
> > can be useful. My question then becomes... is an age verification as a
> > stand alone something that a user would be familiar enough with to fall
> > under a "standard?" It's not like most sites have these types entry
> > points, so it's not a standard practice that someone would use every
> > day. So in this scenario, is it more of a hindrance than a help?
> ________________________________________________________________
> 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
>

29 Jun 2006 - 2:02pm
Oleh Kovalchuke
2006

There is no major problem with auto-tabbing per se in this particular
example (except for logistics of the month field). However I can see
potential for major user annoyance with discarding user input; as well as an
opportunity for saving a bit of user time.

Here's suggested interaction (I assume age verification is for legal
purposes only):

Show disabled "Enter Site" button and the field for year of birth only. If
user enters 1985 (this will be dynamic number to add up to the current age
of 21), show month and day, otherwise either let user to proceed by visually
enabling "Enter site" button or display "come back in x years" message.
Update "come back..." message for month and day, if needed.

If user makes numeric mistake or enters two-letter month abbreviation, try
to translate it in machine-friendly format. If you fail at the last task,
_preserve_ user input and highlight difficult field entry for user to
correct. When field is put into focus (regardless of the method -
autotabbing or mouse click), preserve user input (currently the input is
discarded - that is annoying indeed).

Incidentally user still has to tab manually, when instead of "04" for April,
they enter "4" - perfectly legitimate input from human perspective. You need
to solve this issue as well.

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

On 6/29/06, Cindi Thomas <cthomas at fullhouseinteractive.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Here's the example that triggered my question in the first place...
>
> http://www.millerhighlife.com/millerhighlife/ageverify.aspx
>
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> jackbellis.com
> Sent: Thursday, June 29, 2006 11:08 AM
> To: discuss at ixda.org
> Subject: [IxDA Discuss] Small usability issue - forms
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Cyndi and all,
> Before seeking to be understood, I'd like to understand a little more.
> Would those on the list be so kind as to report all situations where
> they have ACTUALLY seen *either* auto-advancing or segmented fields?
>
> We've already had reports of the first two, below:
> 1. Phone numbers
> 2. License serial numbers
> 3. Dates (Multi-part fields where the segments are not identical
> constitute a gray area. I'm adding dates to forestall this issue.)
>
> I'm not asking for heuristic info or field types that you *think*
> warrant it... only cases where the technique has in fact been used. I'm
> asking to hear about segmented fields, too, because I will be making the
> case that the issues are inseparable.
>
> I'm hypothesizing that we will not get a long list of fields from public
> applications, though business apps may surprise me.
>
> Thanks, Jack
>
> ----- Original Message -----
> From: "Cindi Thomas" <cthomas at fullhouseinteractive.com>
> To: <discuss at ixda.org>
> Sent: Tuesday, June 27, 2006 2:11 PM
> Subject: [IxDA Discuss] Small usability issue - forms
>
>
> am personally annoyed by auto moving cursors,
> > but that is just me and not necessarily a best practice! :-)
> ________________________________________________________________
> 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
> ________________________________________________________________
> 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
>

29 Jun 2006 - 2:12pm
cfmdesigns
2004

>The scenario I am referring to is an age verification "form" on a web
>site where the user is required to enter month/day/year of their birth
>date to enter the site. It seems the sentiment of the feedback (thank
>you by the way!) is that if the form or data entry is a standard one for
>the user, or the data fields are related (which these are) auto-tabbing
>can be useful. My question then becomes... is an age verification as a
>stand alone something that a user would be familiar enough with to fall
>under a "standard?" It's not like most sites have these types entry
>points, so it's not a standard practice that someone would use every
>day. So in this scenario, is it more of a hindrance than a help?

One of the values in this particular case is that many people (are trained to) think of their birth date as a single string of numbers -- 41663, rather than 4, 16, 63 -- so the ability to enter them in a swell foop may be of use. I think there's something less of that mental model with telephone numbers -- I tend to think of them as at least area code/number, if not as areas code/prefix/number -- and thus less usefulness in the autotabbing.

Is it familiar enough to be a standard? Maybe not, but maybe it could become one. The first time I encountered auto-tabbing in a useful context, I had a little user "cool" moment. The more places the feature shows up, even with marginal utility, the more people will come to anticipate, then desire, then expect it, which could drive to a standard. Someone has to lead the charge; go beer!

-- Jim
Seattle

29 Jun 2006 - 2:31pm
adamya ashk
2004

The intention in providing the link was to illustrate dynamic
formatting and not error handling. Turbotax requires a login...

The steps you mention are generally followed when this solution is
implemented, although the exact nature varies based on the validation;
whether it's is being done locally, server-side and whether AJAX
technologies are available.

The way we indicate dates is culture specific and so 2/7/06 and 7/2/06
can be the same date. In your steps, step 3 should attempt to display
it in culturally relevant format. So for a system that is
multicultural it should be unambiguous i.e. "7 July 2006". However,
that is tough to do in practice, the script/code becomes complicated.

-Adamya

> Any Cooper's fan would be quick to point out that this script provides
> rather nasty interaction example of handling input errors.
>
> "Good butller" automation would be:
1. Make a suggestion of prefered format for the entry.
2. Let user enter the date in any way they want.
3. Try to make sense of what user entered and reformat the date in
machine friendly format.
4. If designer failed to interpret user's input, save and show the
input, highlight the percieved error, ask to correct the error only.

29 Jun 2006 - 2:45pm
Oleh Kovalchuke
2006

You are right about step 3 - users should see culturally relevant format,
the same as that suggested in the step 1. I have seen it done, but don't
recall where at the moment.
I have described back end processing in the step 3.

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

On 6/29/06, adamya ashk <adamya at gmail.com> wrote:
>
> The intention in providing the link was to illustrate dynamic
> formatting and not error handling. Turbotax requires a login...
>
> The steps you mention are generally followed when this solution is
> implemented, although the exact nature varies based on the validation;
> whether it's is being done locally, server-side and whether AJAX
> technologies are available.
>
> The way we indicate dates is culture specific and so 2/7/06 and 7/2/06
> can be the same date. In your steps, step 3 should attempt to display
> it in culturally relevant format. So for a system that is
> multicultural it should be unambiguous i.e. "7 July 2006". However,
> that is tough to do in practice, the script/code becomes complicated.
>
> -Adamya
>
> > Any Cooper's fan would be quick to point out that this script provides
> > rather nasty interaction example of handling input errors.
> >
> > "Good butller" automation would be:
> 1. Make a suggestion of prefered format for the entry.
> 2. Let user enter the date in any way they want.
> 3. Try to make sense of what user entered and reformat the date in
> machine friendly format.
> 4. If designer failed to interpret user's input, save and show the
> input, highlight the percieved error, ask to correct the error only.
>

29 Jun 2006 - 3:14pm
Katie Albers
2005

>One of the values in this particular case is that many people (are
>trained to) think of their birth date as a single string of numbers
>-- 41663, rather than 4, 16, 63 -- so the ability to enter them in a
>swell foop may be of use. I think there's something less of that
>mental model with telephone numbers -- I tend to think of them as at
>least area code/number, if not as areas code/prefix/number -- and
>thus less usefulness in the autotabbing.
>
>Is it familiar enough to be a standard? Maybe not, but maybe it
>could become one. The first time I encountered auto-tabbing in a
>useful context, I had a little user "cool" moment. The more places
>the feature shows up, even with marginal utility, the more people
>will come to anticipate, then desire, then expect it, which could
>drive to a standard. Someone has to lead the charge; go beer!
>
>-- Jim
> Seattle

This may not be an issue for any particular audience, but if you're
talking about an international audience you immediately run smack
into the month/day--day/month issue. This can be handled a number of
ways, but simply entering the string of numbers isn't one of them,
unless the interface then displays the date in a format that includes
the month in a text format, allowing the user to make changes if the
date's been translated wrong. There are many ways to handle this at
different levels of the overall interaction (for example, the user
may enter the country first and the date order then orients to their
preferred order or you can have 3 fields, each of which is labelled
and echoes the data input in the form that the computer will
interpret it).

Katie

29 Jun 2006 - 5:42pm
Peter Bagnall
2003

On 29 Jun 2006, at 21:14, Katie Albers wrote:
> This may not be an issue for any particular audience, but if you're
> talking about an international audience you immediately run smack
> into the month/day--day/month issue. This can be handled a number of
> ways, but simply entering the string of numbers isn't one of them,
> unless the interface then displays the date in a format that includes
> the month in a text format, allowing the user to make changes if the
> date's been translated wrong. There are many ways to handle this at
> different levels of the overall interaction (for example, the user
> may enter the country first and the date order then orients to their
> preferred order or you can have 3 fields, each of which is labelled
> and echoes the data input in the form that the computer will
> interpret it).

In theory you should alternatively be able to use the systems
language settings to determine which format is likely to be the
locally accepted one.

If it's application software then the OS provides localization
information, which can (and should) be used. I would expect this to
be more reliable, in fact I'd expect it to be correct in almost all
cases.

Browsers send the server a list of languages they will accept, and
you could use that. For example if it is en-US then you use m/d/y but
if it's en-GB you use d/m/y. This of course assumes that the browser
is correctly configured. It ought to get it's initial config from the
OS, but I'm not certain whether all do or not. One problem I think
may arise is that some non US english systems may default to en-US.
Of course, it would be really nice if the browser told the server its
preferred date format, but of course, it doesn't! The last issue of
course is you need to have a list of language to date format mappings
which is technically easy, but I don't off hand know where you'd find
such a list.

I'd be interested to know if anyone has actually done this sort of
thing on the web though, and if so whether they found it reliable or
not.

Of course, it's never actually that simple. I just discovered that
I'm living in the 26th century... at least by the Buddhist calendar!

Cheers
--Pete

----------------------------------------------------------
Anyone who conducts an argument by appealing to authority is
not using his intelligence; he is just using his memory.
Leonardo da Vinci, 1452 - 1519

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

29 Jun 2006 - 7:05pm
Juan Lanus
2005

I have ran into this problem, many years ago.
This one and the decimal point or comma issue.
For to solve it, the UI has to run a test for to find out how the
client computer is configured.
It can be done in Javascript.
To test the date the program can larse a string, for example
"25/12/2006". In my country this is equal to "2006-12-25" while in the
US is not Christmas but an error.
To tell the decimal point see if the result of parsing "12,34" is 12.34 or 1234.
Then, assume that the data entered by the user is formatted according
to these settings.

For the specific issue of entering dates, open an Excel sheet (or any
other) and try entering dated in different formats. It's really very
good.
I've replicated this functionality in some old programs. Now it's not
necessary: Strings containing dates can be parsed using the
programming platform facilities, wrong dated will return an error and
good dates will return a date value.

But after all this postings, a question: why can't you use a simple
test input labeled "Please enter your age:"?

As of the original question, about auto tabbing, in such a scenario
it's better to avoid it.
Any autotabbing would annoy the user, make him stop and look around
for to find out what happened, and finally waste more time than
without the auto feature.
Notice that many people do not use the tab key but reach for the
mouse, click in the next field, deselect the text if any, delete it
with the backspace key, and then write the data.
--
Juan Lanus
TECNOSOL
Argentina

Syndicate content Get the feed