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]

koray wrote:

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
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.
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.
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)
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?
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.
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

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/
la**********@la chy.id.au.updat e.virus.scanners

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

[Jukka K. Korpela]

Lachlan Hunt <la**********@l achy.id.au.upda te.virus.scanne rs> wrote:

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.

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]

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

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. [ ... ] "

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]

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

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. [ ... ] "

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

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]

Brian <us*****@juliet remblay.com.inv alid> writes:

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

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. [ ... ] " 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).

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.

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

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]

On 15 Jul 2004 15:27:25 +0100, Chris Morris <c.********@dur ham.ac.uk>
wrote:

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.

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]

"Brian" <us*****@juliet remblay.com.inv alid> wrote in message
news:10******** *****@corp.supe rnews.com...

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

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. [ ... ] "
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).

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.

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.

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.

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]

koray wrote:

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?

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/
la**********@la chy.id.au.updat e.virus.scanners

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

[Brian]

Harlan Messinger wrote:

Brian wrote...

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

I suppose. But a database can sort on a name, whether first + last or
last only.

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?

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.

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>.
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.
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?
from other countries, and indiscriminatel y applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

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/