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

On Thu, 08 Jul 2004 16:52:29 -0400, Matthew Raymond
<mattraymond at earthlink.net> 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)

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

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

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

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.

> > So these date pickers will not be stylable / suggestable by designers?
> >  (what about in future specifications?)
> 
>    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?

> > A tiny fractional load improvement, and is offset by having  the extra
> > load of having to process the dates in more complicated ways from
> > legacy clients, in fact from non-legacy ones too potentially.
> 
>    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?  This means my server must deal with a random date entry.

> 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

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

> > (parsing a free form text element is a lot more complicated than
> > parsing 2 select boxes such as Open Skies do.
> 
>    It is my understanding that for security reasons you have to
> validate  the input anyway, regardless of the source control. 

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

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

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

Jim.

Received on Thursday, 8 July 2004 16:05:02 UTC