date format in forms?

[koray]

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
but i don't want user to use tabs while typing. for example s/he
should simply type 280104 but 28/01/04 must appear.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

[Lachlan Hunt]

Re: date format in forms?

koray wrote:[color=blue]
> hi everyone,
>
> in my form i have to take some date information in dd-mm-yy format.[/color]

You should at least use a four digit year, to make it less ambiguous,
but I recommend you use the international standard (ISO 8601) which is
the format YYYY-MM-DD. There are also other variations, but that seems
the most appropriate for your needs.
[color=blue]
> but i don't want user to use tabs while typing. for example s/he
> should simply type 280104 but 28/01/04 must appear.[/color]

Then just use one text field, and write a description of the format you
would like it to be in, in the fields label. But then the server side
processing and validation becomes slightly harder.

On the server, you can use a regex to parse the string, so if you
were expecting the date in dd-mm-yy, but you also want to allow the user
to enter ddmmyy or dd/mm/yy, then use a regex like this. (I don't
recommend using a / as the delimter because it's not used in the 8601
standard for that purpose, but it is commonly used by many people)

/([0-9]{2})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/

When executed on the string, that will return an array, each cell
with 2 characters, which you can then convert to numbers. Then it's
just a matter of checking that each field is within range. Also, if
your interested, and would like to use the ISO 8601 format, then use
this regex.

/([0-9]{4})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/
this allows
YYYY-MM-DD
YYYY/MM/DD
YYYYMMDD
(as well as incorrect versions like YYYY/MM-DD, but that doesn't really
matter, as long as it supports the correct versions)
[color=blue]
> what can i do for that?
> should i use three input tags? but then, how can i make the cursor
> jump to the next field when typing in current field is done?[/color]

If you want to use three input fields, then you could use javascript
to detect when they have written 2 digits, but I be careful of this. If
done incorrectly, it may make it difficult to the user to make
corrections because of the cursor unexpectidly jumping to the next field.
[color=blue]
> or if i use one input tag, how can i keep '/' signs in the field fixed
> when user types the date?[/color]

Don't worry about it, just write a server side script that can handle it
however they enter it, but if your really worried about them entering it
absolutely correctly, then just modify the regexs above and return an
error message to them if they got it wrong.

--
Lachlan Hunt

http://www.lachy.id.au/

lachlan.hunt@la chy.id.au.updat e.virus.scanners

Remove .update.virus.s canners to email me,
NO SPAM and NO VIRUSES!!!

[Jukka K. Korpela]

Re: date format in forms?

Lachlan Hunt <lachlan.hunt@l achy.id.au.upda te.virus.scanne rs> wrote:
[color=blue]
> If you want to use three input fields, then you could use
> javascript
> to detect when they have written 2 digits, but I be careful of this.
> If done incorrectly, it may make it difficult to the user to make
> corrections because of the cursor unexpectidly jumping to the next
> field.[/color]

And even when made the best possible way, it confuses people.

As Nielsen writes:

"Splitting what users see as a single piece of information into multiple
fields means that users must waste time moving the cursor around. A
typical example is when forms ask users for their first and last names as
two items, rather than simply letting users enter their full name in a
single field, which is much faster to type. Another example is
[a collection of three fields for a telephone number]."

http://www.useit.com/alertbox/20031222.html point 9
(Too bad Nielsen doesn't put id attributes into his heading
elements, to allow referring to them with URI references.)

Even if we managed to save some of (most) users' time by using JavaScript
to automagically move to the next field, users easily get confused. They
are not used to "automoving ", and it's more difficult to recognize
something as a single entity when it has been split into several fields.

In principle, the server-side script should accept any format that can be
unambiguosly recognized. I would say that this means that no format with
a two-digit denotation should be accepted. Even though 01-02-03 is has a
single interpretation according to ISO 8601, we should not expect people
to know that meaning - actually most people mean something different.
Here we must accept the minor incovenience to users, I'd say, of forcing
them to type a year in four digits. But on the Web I think we need to go
farther and be rather restrictive about it, since 2/3/2001 isn't
absolutely clear either - it's probably meant to be interpreted the
American way, but it _could_ some day be meant to be read as
day/month/year. So this seems to boil down to accepting basically just
2001-02-03.

That's external to HTML of course. But the HTML implication is that a
single text input field is normally the best way to let the user enter a
date. I would use size="10" maxlength="10" as a hint, with an explanation
that says that date(s) be entered as year-month-day, with the year in
four digits.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Andreas Prilop]

Re: date format in forms?

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:
[color=blue]
> And even when made the best possible way, it confuses people.
>
> As Nielsen writes:
>
> "Splitting what users see as a single piece of information into multiple
> fields means that users must waste time moving the cursor around. A
> typical example is when forms ask users for their first and last names as
> two items, rather than simply letting users enter their full name in a
> single field, which is much faster to type. [ ... ] "[/color]

What's the "last name" of Jukka Korpela?
What's the "last name" of Mao Zedong?

I think it is a good idea to have two different fields and let the user
clarify what's his family name and what's his given name(s).

--
Top-posting.
What's the most irritating thing on Usenet?

[Brian]

Re: date format in forms?

Andreas Prilop wrote:[color=blue]
> On Thu, 15 Jul 2004, Jukka K. Korpela wrote:
>[color=green]
>> As Nielsen writes:
>>
>> "[...] A typical example is when forms ask users for their first
>> and last names as two items, rather than simply letting users
>> enter their full name in a single field, which is much faster to
>> type. [ ... ] "[/color]
>
> What's the "last name" of Jukka Korpela?
> What's the "last name" of Mao Zedong?
>
> I think it is a good idea to have two different fields and let the
> user clarify what's his family name and what's his given name(s).[/color]

Strange conclusion. If it's unclear how the user's name should be
represented, shouldn't there be a single name field? Let the user type
it in as they see fit. If the family name should be first, they'll
type it that way. If it should be last, so it will appear in posted data.

I think addresses would be much easier that way, too. Where does the
postal code go? After the city (and state), like in the US, or before
it, like in France? How many digits are there? In the end, splitting
the address up into 5 or 6 fields (address1, address2, city,
state/province, postal code, country) is harder for the user, and
harder for the server-side programmer. It's probably better to put a
textarea in the form, and let people type in the address just like
they were typing a mailing label. I think most people can be counted
on to know how their address should look.

--
Brian (remove ".invalid" to email me)

http://www.tsmchughs.com/

[Chris Morris]

Re: date format in forms?

Brian <usenet3@juliet remblay.com.inv alid> writes:[color=blue]
> Andreas Prilop wrote:[color=green]
> > On Thu, 15 Jul 2004, Jukka K. Korpela wrote:
> >[color=darkred]
> >> As Nielsen writes:
> >> "[...] A typical example is when forms ask users for their first
> >> and last names as two items, rather than simply letting users
> >> enter their full name in a single field, which is much faster to
> >> type. [ ... ] "[/color]
> > What's the "last name" of Jukka Korpela?
> > What's the "last name" of Mao Zedong?
> > I think it is a good idea to have two different fields and let the
> > user clarify what's his family name and what's his given name(s).[/color]
>
> Strange conclusion. If it's unclear how the user's name should be
> represented, shouldn't there be a single name field? Let the user type
> it in as they see fit. If the family name should be first, they'll
> type it that way. If it should be last, so it will appear in posted data.[/color]

Also, there's no requirement to have both a given and family name. I
know of at least one person with only a single name.
[color=blue]
> I think addresses would be much easier that way, too. Where does the
> postal code go? After the city (and state), like in the US, or before
> it, like in France? How many digits are there? In the end, splitting
> the address up into 5 or 6 fields (address1, address2, city,
> state/province, postal code, country) is harder for the user, and
> harder for the server-side programmer. It's probably better to put a
> textarea in the form, and let people type in the address just like
> they were typing a mailing label. I think most people can be counted
> on to know how their address should look.[/color]

Agreed.

The exception, IMO, to Neilsen's advice, is for date/time fields,
where making sure users enter dates in the unambiguous numeric format
yyyy-mm-dd is, I think, unfriendlier than having three <select>s for
day, month and year.

Though where the year might be outside a small-ish range, obviously
that needs to be a text input, and then do all three become text
inputs for consistency?

Anyway, I think in some circumstances at least multiple inputs is a
better way to do date/time.

--
Chris

[Neal]

Re: date format in forms?

On 15 Jul 2004 15:27:25 +0100, Chris Morris <c.i.morris@dur ham.ac.uk>
wrote:
[color=blue]
> Also, there's no requirement to have both a given and family name. I
> know of at least one person with only a single name.[/color]

A name field is filled in by the user with their name in their preferred
form, so one field is fine.

Dates, though, have other uses. You might want to order things
chronologically , or see if more responses came in in September than July,
or in 2003 than 2004. Three fields is acceptable here. And I find most
sites use select boxes to choose a date, a spelled-out month, and a year.
Not that this makes it the best way, but clearly users are going to be
familiar with this way of doing it.

[Harlan Messinger]

Re: date format in forms?


"Brian" <usenet3@juliet remblay.com.inv alid> wrote in message
news:10fd4mooad gscbc@corp.supe rnews.com...[color=blue]
> Andreas Prilop wrote:[color=green]
> > On Thu, 15 Jul 2004, Jukka K. Korpela wrote:
> >[color=darkred]
> >> As Nielsen writes:
> >>
> >> "[...] A typical example is when forms ask users for their first
> >> and last names as two items, rather than simply letting users
> >> enter their full name in a single field, which is much faster to
> >> type. [ ... ] "[/color]
> >
> > What's the "last name" of Jukka Korpela?
> > What's the "last name" of Mao Zedong?
> >
> > I think it is a good idea to have two different fields and let the
> > user clarify what's his family name and what's his given name(s).[/color]
>
> Strange conclusion. If it's unclear how the user's name should be
> represented, shouldn't there be a single name field? Let the user type
> it in as they see fit. If the family name should be first, they'll
> type it that way. If it should be last, so it will appear in posted data.[/color]

Forms don't split up entry of people's names just for fun. The essential
need behind split entry of the user's name is to be able to sort
alphabetically on family name. Reproducing each person's name in the order
particular to the person's culture is secondary and usually non-critical.
[color=blue]
>
> I think addresses would be much easier that way, too. Where does the
> postal code go? After the city (and state), like in the US, or before
> it, like in France? How many digits are there? In the end, splitting
> the address up into 5 or 6 fields (address1, address2, city,
> state/province, postal code, country) is harder for the user, and
> harder for the server-side programmer. It's probably better to put a
> textarea in the form, and let people type in the address just like
> they were typing a mailing label. I think most people can be counted
> on to know how their address should look.[/color]

The requirements of most applications require the address data to be split.
I don't know about other countries, but U.S. organizations, to get favorable
postage rates, need to be able to print mailing labels in order by ZIP
(postal) code. Organizations in general need to be able to filter
user/customer/member data by state (or province or whatever), city, and
postal code for a variety of purposes.

It's really hard to build a parser that knows all the rules necessary for
international commerce, but in spite of your suggestion to the contrary I
think most people can be counted on to know which part of their address is
the street, which is the city, which is the state, and so on. Have you ever
heard of anybody who gave up trying to order a book from Amazon because he
wasn't sure which part of his address was the city? The only time there's
confusion is when a site that is likely to receive international visitors
doesn't anticipate them with generic labels ("State, province, etc." versus
"State"; "ZIP Code" versus "Postal Code"), provides a drop-down list for
selecting the state without providing an alternate entry method for users
from other countries, and indiscriminatel y applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

There *are* applications where the address is entered solely for
reproduction as is, and where there is no need to extract the components of
the address. I have built such applications, and in those cases I have made
"address" a single piece of data, with a multi-line entry field.

As for people's names, there are plenty of situations where they *don't*
need to be sorted, and in those cases, again, a single data item and a
single entry field suffice. This is especially true for names of people
other than the person on whose behalf a form is being completed. These
include data with labels like "Name of Spouse", "Name of Beneficiary", "Name
of Emergency Contact", and so forth.

[Lachlan Hunt]

Re: date format in forms?

koray wrote:
[color=blue]
> hi everyone,
>
> in my form i have to take some date information in dd-mm-yy format.
> but i don't want user to use tabs while typing. for example s/he
> should simply type 280104 but 28/01/04 must appear.
>
> what can i do for that?
> should i use three input tags? but then, how can i make the cursor
> jump to the next field when typing in current field is done?
> or if i use one input tag, how can i keep '/' signs in the field fixed
> when user types the date?[/color]

Here's a better idea for you. Use client side script to provide a
date widget that replaces a single text field (used for the fallback)
and let the user pick the date graphically. I've started working on
scripts to do this a few weeks ago during my spare time (though I
haven't updated it for a little while). It's still very much under
development, and much of it will change and actually become functional,
but it's a reasonable demonstration of how to at least generate a date
widget.

At the moment, it uses the built in javascript date object to parse a
date in the format: D MMMM YYYY (eg. 16 July 2004), but there's the
start of a script to parse an ISO 8601 date. It then generates the
calendar and highlits the current system date, and the date in the form
contol Feel free to experement with it. and if you like, send me any
changes.

The script, example form and some documentation are available for
viewing here:

http://www.lachy.id.au/script/examples/datetime/

http://www.lachy.id.au/xhtml/examples/forms/datetime/

The individual files should not yet be considered stable, and may be
modified, renamed or removed, but these directories will contain the
latest changes as I write and publish them (when I eventually find more
time to think about doing it).

--
Lachlan Hunt

http://www.lachy.id.au/

lachlan.hunt@la chy.id.au.updat e.virus.scanners

Remove .update.virus.s canners to email me,
NO SPAM and NO VIRUSES!!!

[Brian]

Re: date format in forms?

Harlan Messinger wrote:
[color=blue]
> Brian wrote...
>[color=green]
>> If it's unclear how the user's name should be represented,
>> shouldn't there be a single name field? Let the user type it in
>> as they see fit.[/color]
>
> Forms don't split up entry of people's names just for fun. The
> essential need behind split entry of the user's name is to be able
> to sort alphabetically on family name.[/color]

I suppose. But a database can sort on a name, whether first + last or
last only.
[color=blue][color=green]
>> I think addresses would be much easier that way, too. Where does
>> the postal code go? After the city (and state), like in the US,
>> or before it, like in France?[/color]
>
> The requirements of most applications require the address data to
> be split. I don't know about other countries, but U.S.
> organizations, to get favorable postage rates, need to be able to
> print mailing labels in order by ZIP (postal) code.[/color]

In that case, I might go for 2 fields: a mailing label <TEXTAREA>, and
a postal code for sorting. Of course, that raises the potential
problem that people might then not put the code in the <TEXTAREA>.
[color=blue]
> It's really hard to build a parser that knows all the rules
> necessary for international commerce, but in spite of your
> suggestion to the contrary I think most people can be counted on to
> know which part of their address is the street, which is the city,
> which is the state, and so on.[/color]

My point wasn't that users would get confused. My point was twofold:
(1) users can enter their address more easily in a textarea compared
to 6 input type=text elements. (2) it's not the users who will get
confused, it's the organization. It's hard for a commerce site to know
the proper address format for the US, France, China, Tanzania, etc.
Once they collect the city and postal code in separate inputs, how
will they know how to lay them out on their mailing labels?
[color=blue]
> from other countries, and indiscriminatel y applies locale-specific
> validation rules for postal codes, phone numbers, and so forth.[/color]

Again, for telephone numbers, one should be "liberal in what you
accept": allow 0 or 1 at the beginning, allow space and formatting
characters ()-, and allow a variable amount of digits. This assumes
international visitors. For a site restricted to a country, a more
restrictive format may be appropriate.

--
Brian (remove ".invalid" to email me)

http://www.tsmchughs.com/

[Harlan Messinger]

Re: date format in forms?


"Brian" <usenet3@juliet remblay.com.inv alid> wrote in message
news:10fd7irems rge83@corp.supe rnews.com...[color=blue]
> Harlan Messinger wrote:
>[color=green]
> > Brian wrote...
> >[color=darkred]
> >> If it's unclear how the user's name should be represented,
> >> shouldn't there be a single name field? Let the user type it in
> >> as they see fit.[/color]
> >
> > Forms don't split up entry of people's names just for fun. The
> > essential need behind split entry of the user's name is to be able
> > to sort alphabetically on family name.[/color]
>
> I suppose. But a database can sort on a name, whether first + last or
> last only.[/color]

Except in Iceland and some other countries, the need is to sort on family
name, so first + last is inadequate, and unknown order is worse.
[color=blue]
>[color=green][color=darkred]
> >> I think addresses would be much easier that way, too. Where does
> >> the postal code go? After the city (and state), like in the US,
> >> or before it, like in France?[/color]
> >
> > The requirements of most applications require the address data to
> > be split. I don't know about other countries, but U.S.
> > organizations, to get favorable postage rates, need to be able to
> > print mailing labels in order by ZIP (postal) code.[/color]
>
> In that case, I might go for 2 fields: a mailing label <TEXTAREA>, and
> a postal code for sorting. Of course, that raises the potential
> problem that people might then not put the code in the <TEXTAREA>.[/color]

Then you're asking people to enter the same information twice. And it still
leaves state and city unavailable.
[color=blue]
>[color=green]
> > It's really hard to build a parser that knows all the rules
> > necessary for international commerce, but in spite of your
> > suggestion to the contrary I think most people can be counted on to
> > know which part of their address is the street, which is the city,
> > which is the state, and so on.[/color]
>
> My point wasn't that users would get confused. My point was twofold:
> (1) users can enter their address more easily in a textarea compared
> to 6 input type=text elements. (2) it's not the users who will get
> confused, it's the organization. It's hard for a commerce site to know
> the proper address format for the US, France, China, Tanzania, etc.[/color]

Right, and it's a two-edged sword, because the address is needed for two
basic purposes: (1) mailing, and (2) data processing. You are correct that,
given the components of arbitrary addresses around the world, it is
challenging to put them back into the correct order for mailing. And on the
other hand, if the user enters the address in a single block, it is
challenging to break it up into the needed components.
[color=blue]
> Once they collect the city and postal code in separate inputs, how
> will they know how to lay them out on their mailing labels?[/color]

I *think* that fewer problems arise if a package winds up being shipped to

55 Avenue des Paradisiers
Brussels, Brabant 1160
BELGIUM

instead of

Avenue des Paradisiers, 55
1160 Brussels
BELGIUM

than arise if the software thinks 1160 is the city and Brussels is the state
and therefore never sends the requested material at all.
[color=blue]
>[color=green]
> > from other countries, and indiscriminatel y applies locale-specific
> > validation rules for postal codes, phone numbers, and so forth.[/color]
>
> Again, for telephone numbers, one should be "liberal in what you
> accept": allow 0 or 1 at the beginning, allow space and formatting
> characters ()-, and allow a variable amount of digits. This assumes
> international visitors. For a site restricted to a country, a more
> restrictive format may be appropriate.[/color]

[Brian]

Re: date format in forms?

Harlan Messinger wrote:
[color=blue]
> Brian wrote...[color=green]
>>
>> In that case, I might go for 2 fields: a mailing label
>> <TEXTAREA>, and a postal code for sorting.[/color]
>
> Then you're asking people to enter the same information twice. And
> it still leaves state and city unavailable.[/color]

It's trivial to look up a city/state by zip code.

--
Brian (remove ".invalid" to email me)

http://www.tsmchughs.com/

[Jukka K. Korpela]

Re: date format in forms?

Neal <neal413@yahoo. com> wrote:
[color=blue]
> A name field is filled in by the user with their name in their
> preferred form, so one field is fine.[/color]

It depends. The point that Andreas made is a good one when further
processing requires a given name and a surname (if they exist) to be
recognized. We cannot really recognize them from a name alone, without
further information.

But quite a many forms, if not most, that prompt for a name will use it
as an atomic unit only, e.g. to be printed in an envelope, and stored
into a data base for that purpose only. (If you need to identify
customers, you really need unique customer identifiers assigned by you,
instead of unique personal names.)
[color=blue]
> Dates, though, have other uses. You might want to order things
> chronologically , - -[/color]

Yes, and most use of dates requires a separation of year, month, day of
month. But how you achieve that is a different thing. Maybe I'm strange,
but I find it more comfortable to type 2004-07-15 or 2004 07 15 or
whatever needs to be typed than to type 2004 followed by 07 followed by
15 in three different fields, _even if_ there's "auto-tabbing" (i.e., the
cursor automatically moves to the second field after I have typed in four
digits into the first one) and even though I know well the idea behind
that. A date is a unit of information to me. So is my name, but I find it
much more natural to use different fields for the different components of
the name.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Harlan Messinger]

Re: date format in forms?


"Brian" <usenet3@juliet remblay.com.inv alid> wrote in message
news:10fdadh251 itr99@corp.supe rnews.com...[color=blue]
> Harlan Messinger wrote:
>[color=green]
> > Brian wrote...[color=darkred]
> >>
> >> In that case, I might go for 2 fields: a mailing label
> >> <TEXTAREA>, and a postal code for sorting.[/color]
> >
> > Then you're asking people to enter the same information twice. And
> > it still leaves state and city unavailable.[/color]
>
> It's trivial to look up a city/state by zip code.[/color]

Well, that's true--if the business has invested in a postal database and
keeps it up to date--and does the same for every country from which business
might be coming in.

[Dr John Stockton]

Re: date format in forms?

JRS: In article <ONqJc.1900$K53 .1445@news-server.bigpond. net.au>, seen
in news:comp.infos ystems.www.authoring.html, Lachlan Hunt <lachlan.hunt @
lachy.id.au.upd ate.virus.scann ers> posted at Thu, 15 Jul 2004 07:57:34 :[color=blue]
>koray wrote:[/color]
[color=blue]
> Also, if
>your interested, and would like to use the ISO 8601 format, then use
>this regex.
>
>/([0-9]{4})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/
>this allows
>YYYY-MM-DD
>YYYY/MM/DD
>YYYYMMDD
>(as well as incorrect versions like YYYY/MM-DD, but that doesn't really
>matter, as long as it supports the correct versions)[/color]

It is easy enough, IIRC, to use a back-reference to force the second
delimiter to match the first.
[color=blue][color=green]
>> what can i do for that?
>> should i use three input tags? but then, how can i make the cursor
>> jump to the next field when typing in current field is done?[/color][/color]

Drop-downs or multiple text fields are reasonable, perhaps desirable,
for casual visitors and/or management staff. For data-entry staff
entering multiple dates routinely, ISTM best to require the order YMD,
and to allow any delimiting whatsoever; a RegExp /(\d+)\D+(\d+)\D +(\d+)/
will pick out the fields. You could also allow /(\d\d\d\d)(\d\d )(\d\d)/
or /(\d+)(\d\d)(\d\ d)/ and use whichever matches.

As may have been noted, I am not a professional typist. Yet I can enter
a date by typing 8-10 characters in about half the time I need for using
three drop-downs.

Automatic insertion of delimiters needs careful programming to allow for
backspace & pasteing.

For javascript date input and validating, see via below; note first what
the FAQ has to say on the subject.

The shortest and the fastest code are both short enough to be deployed
client-side.

P.S. If the application is not international, then it is reasonable to
stipulate the locally-preferred Y M D order, if native staff are being
used.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.