[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working

[Matthew Raymond]

Jim Ley wrote:
> Matthew Raymond wrote:
>>Jim Ley wrote:
>>>Could you point me to some studies that show users are confused about
>>>picking dates on websites now?
>>
>>   Rather than simply dismissing this question, I decided to actually
>>spend a little time searching the Internet for a study on date pickers.
>>I couldn't find a study that says anything about it either way. 
> 
> So we should really disregard the first reason mentioned why datetime
> is appropriate as there's nothing to actually substantiate it.  (until
> someone turns it up)

    Logically, once a user understands a control, its repeated use does 
not cause further confusion. Therefore, if there is even one case of 
confusion regarding the many different date selection schemes you admit 
exist and even use as an argument against a canned date picker, then my 
argument is valid. Why dismiss an argument on such weak statistical 
grounds? If you want to use statistics, it would make more sense to say 
that I have no proof that the confusion justifies a new control, which 
is an argument I'd be much more willing to entertain.

>>   You are describing a UI problem with a specific date picker. UAs are
>>free to use their own custom date picker implementations. 
> 
> No, I'm suggesting that a single date picker will always be a bad
> choice for one of the options, until I see a date picker UI that works
> well for both entering dates whilst knowing the date you want to enter
> and is very different today (like your birthday) and browsing when
> would be a good date to fly somewhere on holiday.
 >
> I simply don't think the two tasks can be sovled by a single UI.

    So what you're say is that you oppose the inclusion of a date picker 
in WF2 because you can't personally envision a control that meets with 
your approval.

>>It seems like
>>this is really only a problem if UA developers make poor design choices.
> 
> Could you point to me something that you consider a good UI for the 2 tasks?

    A combo box. It allows you to both select from a list and enter 
text. In fact, there are Javascript-based date pickers that are very 
similar to a combo box.

    Actually, now that I think of it, if there are two controls that are 
actually needed, then a date picker would actually be two controls with 
a simple one-click toggle.

>>   Who's to say a date picker can't be made that allows you to both
>>easily enter a date manually and easily select it through a UI. Are we
>>going to deny the use of a canned control because we don't think browser
>>developers can build a better date picker?
> 
> Well I want to see the evidence, I don't want to deny it, I just want
> to be confident that it's worth speccing because at the moment I'm
> sure I wouldn't want the windows datepicker anywhere near choosing my
> birthday or my credit card expiry date or ...

    Why can't controls specific to these cases be coded by UA developers 
based on the |pattern| and |precision| attributes? Nothing says they 
can't provide different controls based on these values.

 > and if we don't
> provide clear guidelines on what the user is likely to see and use
> we're going to struggle to convince authors to use these properties.

    By the time we submit WF2 to a standards organization, we'll already 
have implementations, so authors will know exactly if they want to use 
it or not.

    I suggest that you use this time to define what you think are the 
best and worst cases of date pickers and why you feel that way so that 
vendors will have a better idea of how to design their own controls.

> I've said before that even good designers who accept the flexible
> rendering and styling on the web, also know that most people don't
> change settings so there's good value in optimising appearance and
> usability for that environment assuming it doesn't compromise other
> environments.  So they need to know the user experience of these
> controls, and to a certain extent control it.

    They can do this with the aforementioned attributes, and also...

>>   You can always use CSS 
> 
> right, how do you imagine CSS applying to a date picker - say the UA
> wants to give me a large date picker with full month view, and I give
> it an explicit height of 10em - that'll work reasonably, but what
> about a different  UA that wants to give me 3 select boxes - how does
> the 10em height suggestion make sense?      What exactly CSS
> properties did you have in mind for styling date pickers?

    If necessary, CSS properties can be developed specifically for the 
date picker and other controls. It was done for lists, and it was done 
for tables with the "display" property.

    However, what you're really talking about here is poor UI decisions 
on the part of a specific UA. Considering this standard will first be 
implemented on three of the best browsers in the world by people who 
have been in the business for years, I don't see UA vendors suddenly 
coming up with totally different date picker schemes that are harder to 
work into a web page. Even if they do, it is likely that they will 
simply loose marketshare to a user agent with a better implementation. 
Since both Mozilla and Opera have offerings on small devices either 
available or in development, poor implementation of WF2 would not be 
wise on the part of small device browser vendors.

>>   The cost of legacy clients is related to the cost of the legacy
>>markup you use.
> 
> What do you mean?  if I use <input type="datetime"> I don't get the
> option of legacy markup I just get a text input, or am I misreading
> something?

    With regard to this, we were originally talking about server load. 
You stated that the WF2 date input would somehow increase bandwidth or 
markup. You can argue functionality, but that's not what you were 
originally talking about.

 > This means my server must deal with a random date entry.

    You are attempting to argue that <select> controls eliminate the 
need for server-side validation. This, and others have pointed out in 
other threads, is false. All values submitted by the client should be 
validated.

>>How can that markup be greater when using WF2, where a
>>single control returns a single UTC date to the server, and that control
>>degrades into another single control?
> 
> Simply because we now have a random date format to deal with the users
> could enter absolutely anything ( 3/4/02 - what does that mean, and
> that's likely valid input?)  the current method of constraining input
> with select element simplifies the server implementation hugely

    Months have varying numbers of days, and a time range that one may 
wish to use in a date picker does not necessarily begin on January 1st 
and end on December 31st. Therefore, <select> elements are just as 
capable of giving non-date or out-of-bounds values. The only solution 
for this is Javascript, which can also be used as a solution for 
validating the date in a text box. However, since we've already pointed 
out that the server still needs to validate the data anyway, this isn't 
really a serious problem even with Javascript disabled.

>>   Also remember that for companies already using a text box for date
>>input, the WF2 date type has virtually no development cost.
> 
> I don't normally see many companies using a text box for date input,
> and I couldn't even find one in a quick search, certainly none of the
> airlines, or banking systems I use regularly do it.

    Lexmark uses it in its job application forms.

> I didn't mention validation, I mentioned parsing, particular things
> like 3/5/4 - what does that mean in the context of a date?

    It's the same problem as with phone numbers, social security numbers 
and other formatted numerical date, and it has the same solution: post 
an example format. Example: MM/DD/YYYY. This is common throughout the 
web. I've even seen popup error messages showing format examples.

>>   Javascript functions for determining if a string is a date are
>>available for free on the Internet. Here's one of many I found doing a
>>simple search on Google:
> 
> Which is unfortunately gibberish, (create a date and then check if the
> returned result is a number...  for example it'll return a valid date
> on the input
> -5.32432432e12  do you really think the user meant that date? )

    Thank you for completely ignoring the following text I included in 
my last message: "I'm not suggesting this is the best solution, BTW. I'm 
just making a point." I did, in fact, see better examples of date format 
checkers, but they were longer and I didn't want to take up an 
unnecessary amount of space in the message just to post something 
someone could easily find using Google.

>>In order to do ranged
>>input with this setup, you need scripting to validate the entered date
>>with respect to valid input ranges. If you're going to do that, you
>>might as well just validate the date from a text box.
>
> I'd love to see some code that does it in less than 10 lines (yet
> rejects the number above as I don't reckon the user meant some time in
> 1801) ... compared to the trivial stuff script that's used with select
> boxes - and selecting 31st of Feb is not much of a validation risk -
> users rarely do it.

    First of all, there is more than one month that has only 30 days, 
and to be honest, I haven't memorized exactly which ones those are. 
Second, it would probably take more than 10 lines of code to both 
determine how many days are in a single month in a single year AND 
change the values in the day drop-down to reflect that.

    I do see where you're going with this. In theory, the text box 
validation could take more code than the <select> validation. This is, 
of course, part of a larger point that <input type="date"> can't degrade 
into the perfect solution for all circumstances.

    However, is the fact that text box isn't always the PERFECT 
degradable solution really so significant that it offsets the benefits 
of a date picker for WF2-compliant UAs? I doubt it, and your examples of 
better control schemes will only serve as the blueprint for the date 
input's implementation.