Month Validator
Niggle’s recent entry on good design, bad design touches on the usability of drop down date selection. Now, as any web developer who has had to put together a form with date selection will know, it is one of the most difficult things to achieve.
Some (and I do this, too) simply have three inputs — one for year, one for day, and one for month. They might be text boxes or they might be drop-downs. Other times it's an in-page calendar that refreshes every time you click next or previous month. Some even pop open a calendar widget that passes the values back to the form.
Example
In any case, this isn't a full-blown solution but rather a test case for month validation only. Check out the example page and give it a whirl. The functionality is pretty straightforward. I've attached validation to occur when the user leaves the text box (onblur
) and performs a number of different tests to determine what the user prefers.
The validation code is attached onload and is done in an unobtrusive way. All functions and necessary information is attached to the input itself. In doing so, it's a trivial step to attach this behaviour to numerous text boxes and have each behave autonomously.
The other thing I wanted to mention was that — having worked on many bilingual sites — the validation is done in a (hopefully) language-neutral fashion. The only thing that should need to change is the month list that gets attached to the input. Change the list to French or Spanish and the technique should still work the same.
Your ideas
Ultimately, I'd like to get your feedback in hopes of being able to expand on this or drop the idea altogether.
This concept is also inspired by Simon Willison's technique that attempts to solve the date selection problem as a whole (instead of just the month as I've done).
Conversation
I told you already, the suggestions, especially with months above 12 are awesomely well done. Kickass. This is why the DOM exists.
Nice script, can be useful for form validation in general, but why would you want text inputs for a date insertion?
That's some very sexy work. I like the way it works and shows off the capabilities.
The month suggestions are brilliant! The only problem I am still facing is the question whether text input for a month is good enough. The expected input is unclear to the user, even though a lot of variations are properly handled.
Very impressive. I might end up implementing something similar on a clients site soon
Jacob/Jeroen: I think as developers, we rely on
select
to force the user into specifying a date format that is easier to handle on the server side. Also, I find select boxes not as usable. I tend to use the keyboard as my primary way of navigating a form and a common approach to finding an item in a select box is to type the first letter of what I'm looking for.If you had a chance to check out the Basecamp example that Niggle gave, you'll see that to choose June I have to hit a key on the keyboard 6 times to find what I want. Or, go back to using the mouse to more easily find my way.
A textbox gives the user the flexibility to type what they expect.
Jonathan, I see flexibility as a good thing as well, but in this case the intended result is ambiguous.
The Basecamp result is poor indeed, but did you know that you can select entries from a normal
select
by writing the value on your keyboard? I can't imagine it to be not present in other operating systems, but do correct me if I am wrong.Combining a dropdown with your suggestions (and improve the typing of the value usability some way) is my preferred solution right now. I'll see if I can whip something up in my spare time..
Jeroen: There are a couple problems with the typing in a select box:
1. You have to know what's in the select box in order to begin typing. For month selection, maybe month starts with a zero, maybe it doesn't. Maybe it's the month name, maybe it isn't. There's certainly no consistency.
2. Internet Explorer on Windows only compounds the problem by only allowing you to type the first letter.
A trick I have used, much like you're suggesting, is using a text box in combination with a dropdown. Typing in the text box does a string match to the items within the dropdown and limits possibly options. I've only really found this useful for large amounts of data though where, again, the data in the select is predictable.
Well done. One proposal though: perhaps the use of trim() or similar would be nice to make month input less error prone. "ma " doesn't find "March" because of the extra space.
One thing about date entry in input boxes: Over a year ago I implemented a web application where a search using dates was needed. And all I got from the designer was one single input field to work with (which I did not find very usable at first). So I did some (server-side) regex pattern matching using java. That worked out very well, as you could use different types of date input or even date ranges:
15. feb 2001
dez 19ter-15. '01
januar - dezember '04
etc. it's german date formats ;).
It is of course not easily to be seen by users that they can use pretty complex pattern - but since it was a web application that was no problem with some hints next to the input field.
My conclusion would be, that I could see, how this type of date (-range) input could work out well for a blog archive or article search instead of displaying calendars or using 3 text input field as in your simple example.
(what does email notification in your comments form mean at all? *checking*) :p
This is nice, but one question: Why doesn't it return f=february, s=september etc. for months that have singular starting letters? That makes more sense than an error message in those cases.
I'm just being an ass, but I like to spell out the number of the month. How come your system does support that?
Not really, but I do second a trim() function. I have a soft space bar which gets pressed at all the wrong times.
A month array has just 12 options, why not just show all of them in a select list?
gani: I actually debated as to whether I should just default to displaying the month if only one possible month was an option. I decided against it because I felt that if only one character was entered, it might have been by accident. Just a hunch, though.
Jurgen: 12 options is still a lot when you use just a keyboard to navigate. The next time you find a dop down on a site, try using the keyboard to select an option.
Interesting idea... I've seen similar. I can think of no case where adding 4.12 KB to a page would be worth this functionality, save on an Intranet application. I mean, that's a lot of page weight when you could *easily* do the same thing in server side code, and knock a few seconds off your form's load time.
function numSort(a,b) {
a = parseInt(a);
b = parseInt(b);
if(a > b) return 1;
if(b > a) return -1;
return 0;
}
Is simplified to:
function numSort(a,b)
{
a = parseInt(a);
b = parseInt(b);
return (a > b) - (b > a);
}
Wayne: That's fantastic! Thanks for the tip.
beautiful script
Why not simply :
function numSort( a, b )
{
return parseInt( a )-parseInt( b )
}
o__
dropdown with suggestions is key. nice.