- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Thu, 08 Jul 2004 16:52:29 -0400
Jim Ley wrote:
> On Thu, 08 Jul 2004 08:00:04 -0400, Matthew Raymond
> <mattraymond at earthlink.net> wrote:
>
>> It improves it in two ways. First, it allows the UA to present a
>>standard control regardless of what web server is serving it up. This
>>prevents the user from being confused about how a specific site's date
>>picker works.
>
>
> 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. Then
again, perhaps Google isn't the ideal tool for finding such information...
> I've never heard it's a particular
> problem. I find the default windows date picker incredibly well
> designed for certain things, I find it just about useless for others
> taking a huge number of clicks to get anywhere
You are describing a UI problem with a specific date picker. UAs are
free to use their own custom date picker implementations. It seems like
this is really only a problem if UA developers make poor design choices.
> booking flights is
> just one of those scenarios where it's a nightmare. Different date
> picking UI's apply to different date picking needs - if I know an
> exact date it's very different to if I need to browse through dates to
> see which is a saturday for example.
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?
> I think many authors of
> websites know the context that the date picker will be used, there
> isn't a good single generic date picker that works for all uses.
It doesn't have to work well for ALL uses. It has to work well for
MOST uses. For certain specific cases, specific solutions will always be
better.
>>Second, it allows the user to choose a theme or UA that
>>suits them best.
>
> So these date pickers will not be stylable / suggestable by designers?
> (what about in future specifications?)
You can always use CSS or the |pattern| attribute, and for the most
common use cases, that's really all anyone should need. Having a date
picker does not mean giving up custom widgets for special circumstances.
>> This also benefits the web server. By using a standard control, the
>>servers no longer have to worry about serving up additional markup and
>>Javascript for the date picker, which reduces load.
>
> 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. 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?
Also remember that for companies already using a text box for date
input, the WF2 date type has virtually no development cost.
> (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. In fact, I
recall reading a message on this mailing list a short time ago about a
value sent to a server from a <select> element could be altered prior to
reaching the server.
As for two <select> boxes being more appropriate for a specific
application, that's up to the web author. For instance, a web author may
chose a <select>, <input type="number"> or <input type="range"> to get
numerical input in different situations.
>>It also allows the
>>websites of smaller businesses who can't afford large web development
>>budgets to provide a more professional and robust date picker rather
>>than a text box or similar setup.
>
> Except all they're getting on legacy clients is a textbox (unless they
> can afford the shim solution, which is almost certainly more
> expensive)
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:
// This is by some guy by the handle "mikr0s". I'm not suggesting this
// is the best solution, BTW. I'm just making a point.
function myIsDate(mystring)
{//--BOF
var mystring, myresult ;
var mystring = new Date(mystring);
isNaN(mystring)? myresult=false : myresult=true ;
return myresult ;
//--EOF
}
Keep in mind, a simple validation of a text box is not the same as
creating a full-blown date picker using DHTML and Javascript. However,
if WF2-compliant UAs give you a date picker for free just by using
type="date", and you still have a fallback date entry method that works
in legacy UAs, that's pretty easy to cost justify.
> Most dates are 2 or 3 select elements currently, anyone
> can do that and it's well understood, these smaller businesses are not
> currently losing out, so I fail to see this motivation.
The situation you describe does not allow ranged input. (For
instance, how do you handle February 29th on a non-leap year? What if I
try to enter February 31st, for that matter?) 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 recently used a form that uses both a text entry for dates and a
Javascript date picker that inputs the date into the text field for you.
A canned date picker control would replace that solution directly.
It should also be noted that people who use the keyboard as their
primary method of input will probably be able to input a date into a
text box faster than they could select one using three <select>
elements. I'm not saying a date picker that degrades into a text box is
ideal for all situations, but it is not an uncommon way to input a date
on the Internet, and control of how the user enters the data is a poor
excuse for excluding a date picker from WF2.
> Not that I don't see the ability to say I'm expecting a date here is a
> bad thing, I just don't particularly see that that is associated with
> a particular rendering is a good thing, nor is the case proven that
> there are use cases for it on the web.
What rendering are you referring to? The UA chooses how the date
picker is rendered. If the web author wants a custom style for the date
picker that goes beyond what |pattern| or CSS can provide, they can use
conventional methods or wait for Web Controls 2.0.
Received on Thursday, 8 July 2004 13:52:29 UTC