[whatwg] Re: several messages

[Christoph Päper]

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