[whatwg] Re: several messages
christoph.paeper at tu-clausthal.de
Mon Feb 7 18:40:19 PST 2005
*Matthew Raymond* <mattraymond at earthlink.net>:
> Ian Hickson wrote:
>> On Fri, 4 Feb 2005, [iso-8859-1] Christoph Päper wrote:
>>>> Indeed. Three <select>s are reasonably good UI,
>>> They are easy for the programmer, but ask any usability expert: he
>>> will (perhaps even strongly) advice against them, because
>>> (alpha-)numerical input into /one/ field in ones accustomed format is
>>> much faster and easier.
Three 'input' are yet another case, btw.
>>> A (very) good online ticketing PoS date/time input thus has to
>>> understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" =
>>> "034" = "first Thursday in February", "next Thursday afternoon",
>>> "2nite", "asap" etc.p.p. (in an English speaking environment;
>>> defaulting to the next possible year, month, week, day, hour).
>> And a mind-reading UI that can tell the user's intent without the user
>> having to explicitly put it into words would presumably be even better.
Sure, the perfect human machine input device. (I'm not sure I would want
to use the output device using a reverse technology.) I actually expect to
see such a thing in my lifetime, although towards the statistical end of
it and not in every home.
>> Authors cannot be expected to implement everything you just described,
At least not everyone by himself, each time.
>> especially because it is in fact impossible to determine the intent
>> sometimes (for example, what date is 05/02/07?).
If it's a form on an English site for an international audience requesting
dates in the future, it's very likely May 2nd, 2007, because I would then
consider USAn style the default when the separator is '/'. In other
_contexts_ it might be just yesterday (in my timezone). Of course you
don't accept ambiguous input data without the user having check and
acknowledge it. '<input type="date">' can help to avoid that step, because
the UA either offers a GUI that produces valid dates only or does the
checking of textual input without the need for author action. The
remaining problem would be HTML UAs.
> First of all, you need to apologize to Christoph for your sarcastic tone.
Actually, I don't mind.
> Second, you missed what he's trying to say. He's saying that people
> use the three select solution not because it's more usable, but because
> it's a pain to deal with input from a textbox.
That is what I was saying.
> However, [webmasters] won't want the fallback to be a textbox because of
> the programming difficulties in specific situations.
A simple 'text' 'input' has the advantage that it generates only one
parameter to be handled by the server (and an optional client-side
validation script), just like the 'date' 'input' does. The most basic
handling would be to reject anything that is not an ISO 8601 conformant
string (in the valid time frame), requiring the user to resubmit. From
there on you can get as complex guessing as you want. Unambiguous, valid
inputs are (silently) accepted, others rejected. Rejection on ambiguity
should include showing the user the guessed likeliest value in an
unambiguous format, so he hopefully just has to accept without further
changing. The lesser advanced the guess script, the more important it is
to inform the user of the expected input style.
From the point of usability I wouldn't want '<input type="date">' to fall
back to anything but '<input type="text">'. Neither from the point of
marking-up and styling. In this case the programmer has to swallow the
bitter pill, IMVHO. After all it's a recurring problem for which he has to
find or write a solution only once (at least in theory).
More information about the whatwg