So hard to have a date: js calendars review. New jquery calendar-picker(roberto.open-lab.com)
roberto.open-lab.com
So hard to have a date: js calendars review. New jquery calendar-picker
http://roberto.open-lab.com/2010/03/23/so-hard-to-have-a-date/
19 comments
The problem with all the date pickers that take text input is that they can't differentiate between 03-05-2010 being in March or May. I worked on some software for a company doing federal compliance consulting for employee hiring processes and requirements. We found that most people don't read (MM-DD-YYYY) type notifiers most of the time and immigrants were most likely to write dates as DD-MM-YYYY where as those born/raised in the US would write MM-DD-YYYY. When dealing with hiring issues getting those things wrong can lead to fines for the employer, incorrect eligibility for benefits for employees and other issues. What we ended up doing was having the date picker automatically show up and start moving to the date as it was typed in. If you entered 03-05-2010 and you meant May 5th 2010 you would see the calendar on March and then most users would switch to the date picker widget to correct the error.
Localized date pickers such as datejs don't solve this particular problem because all that happens is the assumption about what format the date will be entered in changes. So an American in Germany might enter MM-DD-YYYY and the date picker will just assume that it's DD-MM-YYYY because that's the format specified in the de-DE.js file.
I agree that flexible text entry fields are preferable, but I've seen several business cases for preventing the user from being able to enter the date any way they want due to the ambiguity in date formats.
Localized date pickers such as datejs don't solve this particular problem because all that happens is the assumption about what format the date will be entered in changes. So an American in Germany might enter MM-DD-YYYY and the date picker will just assume that it's DD-MM-YYYY because that's the format specified in the de-DE.js file.
I agree that flexible text entry fields are preferable, but I've seen several business cases for preventing the user from being able to enter the date any way they want due to the ambiguity in date formats.
Did you test about asking the people to enter the date as ISO yyyy-mm-dd ? I'm not raised in the US and am usually confused of the meaning of some dates, however stating the year first makes it always understandable.
Most people ignored any note about what format the date needed to be entered in. We also found that many people were confused by the ISO format, or were simply irritated by it. The solution presented above has eliminated the most errors and seen the least number of complaints for us.
A possible fix for ambiguous dates: When you detect an ambiguous date, prompt the user for the one they intended before allowing them to continue filling out the form.
That would be 12 days per month, about a third of all dates would result in a blocking prompt. Eek.
If the final date you will get is displayed to the user, then the user has the opportunity to fix those errors.
The end user will only know there is an error if you reformat the date to say something like "March 5, 2010." We are essentially filling out federal forms which require the date to be entered MM/DD/YYYY and council advised that the user must be presented with what is essentially an electronic version of the form for validation. That means they have to be presented with a format, that if they didn't read the instructions, would be wrong still. We already determined that the users were not reading the format prompts so this doesn't actually work.
I type rather fast as well, but I find dates awkward in ways that a picker solves. First, the mechanics of typing dates requires slashes.
But also, it requires knowledge, like "what the hell is today" so I can then work out "what is the date of next saturday". Date pickers do all that work for you.
Fuzzy text is fun, and can solve some of those problems as well, but is less intuitive (what is accepted, what isn't).
But also, it requires knowledge, like "what the hell is today" so I can then work out "what is the date of next saturday". Date pickers do all that work for you.
Fuzzy text is fun, and can solve some of those problems as well, but is less intuitive (what is accepted, what isn't).
The interface I generated lets you type in "next saturday" and offers to autocorrect it to the right format for submission. You are responsible for the final version being right.
That struck me as a reasonable compromise.
That struck me as a reasonable compromise.
Thanks for the link. That's useful.
jQuery.ui ones supports keyboard!
What problems does this new approach solve? I see one that it creates: I can't see the whole month at once, so I have to take extra action to get to a date. I completely lose the spatial view of the grid which, among other things, helps me find a date when I don't know the day, and find a day when I don't know the date.
13 jquery calendars reviewed
+1 new cool component
Why, if I may ask, would you have one account to submit the story with and then another to reply to the story with? :)
I'm curious!
I'm curious!
I type faster than I use the mouse. But everyone wants me to use a mouse. :-(