[whatwg] Re: several messages

[Rimantas Liubertas]

<...>
Looks like Cristoph really does know this stuff (I mean usability),
and I am with him
on this one.

> I disagree that that is the reason <select>s are used for date input.
> 
> I disagree with the assertion that text input is more accessible and
> usable than three <select>s. Indeed, if it was, I wouldn't be worried
> about the fact that type="date" has poor fallback, since by that argument
> it would in fact have good fallback.

I have seen enough recommendations "use drop-down list to prevent
invalid date entries",
to believe, that this is main reason for using <select>.
As user I hate those triplets, they require too much manipulation and
I am afraid even to think how does it feel for someone with motoric
disabilities.

To enter some date you must: Click on the year drop-down. Scroll to
the right item. Click on it (and be sure not to miss). Repeat for the
month. Repeat for the day.
I am unfortunate to be born at the end of the year so I almost always
forced to scroll those lists. Text field does not require any
jumping/tabbing/scrolling/clicking.

> A simple text box is IMHO hard to use because, without a suggested format,
> the user has no guidance as to what to enter. Since users have been
> conditioned to only provide data in the Correct Format, the user is more
> likely to be confused by an empty text field than by three clear drop-down
> widgets containing what are obviously days, months and years.

User obviously does know what date he want to enter, so why to be
afraid of text box?
What IS confusing is to guess which is the Correct Format. There is no
de facto standard
on this, so forcing some format on the user will break the main
usability principle: "don't make me think" (or do not make me feel
stupid). Hints like DD-MM-/YYYY (and especially MM/DD/YY ones) are not
of much help, because you still have to decipher and parse them in
your head (that is - think).
 
> > Webmasters will want to move to a datepicker because it provides better
> > usability than the three <select> elements while offering similar
> > usability to a textbox.
> > However, they won't want the fallback to be a textbox because of the
> > programming difficulties in specific situations.
> 
> Handling free-form input for dates isn't that hard if you are willing to
> reject anything that doesn't match a given format. You can even suggest
> one format and accept a number of other popular formats, assuming that you
> only accept unambiguous formats.

To quote Donald Norman (http://www.jnd.org/GoodDesign.html):
---
Hurrah for Microsoft! Too many companies force you to enter dates in
their preferred format (and often they only tell you after you do it
wrong. In Outlook calendar, you can type almost anything, and it is
interpreted properly. For example, "tomorrow," "day after tomorrow,"
"next day," Wednesday," Wed." Oct. 24, 24 Oct, 14/10, 10/14, etc.
Kudos to Microsoft
---
 
> It is extremely hard to do, however, if you are not willing to reject
> data, since then you have to be able to determine the meaning of dates
> like 05-02-07 (this is an actual date).

Cristoph has suggested how to deal with this: next possible date,
context depended, of course.

If you buy a ticket to the cinema online, if would be 2005-02-07,
cause you cannot buy tickets to the cinema in year 2002, or 2007,
2005-07-02 does not make much sense either.
Sure, there will be tough cases, but "probability vs. possibility"
principle still does apply.

>From the usability point of view my vote would be text box with
capabilities which Norman describes (so you can just type 'tonight')
and date-picker component beside.(like
http://www.dynarch.com/demos/jscalendar/).

Regards,
Rimantas
--
http://rimantas.com/