In Plone 2.1 (don't know about other versions) the default date input used by the CalendarWidget uses 5 dropdowns (year, month, day, hour, minute) plus a little popup calendar which you can use to avoid flipping the dropdowns. When the underlying value is not set the dropdowns look like this:
2007/--/-- [#] --:--where the little [#] is the popup calendar widget. The year 2007 is preselected because they assume that most of the cases you'll just be selecting a month and a day since is highly likely that the year will be that of today's year. So far so good.
The problem is that people get confused. Where I'm doing some consulting work at the moment two people have "complained" that news items expire because the year is set to 2006 or 2007 or whatever is today's year. I assured them that it's built like that to save you (in most cases) the additional click of selecting the year. But even if I could convince these people of the motorical economics of the default year, they still found it confusing and so much on behalf of other people who might end up thinking the same thing.
So we decided to change the default to be just:
----/--/-- [#] --:--and I must admit that this looks cleaner and makes it more immediately obvious that the date hasn't been set.
Lesson learnt: Don't take too many shortcuts just to save a few clicks. Stand back and think about what impressions a widget can give visually about it's functionality and value.
Before:
After:
Comments
Drop downs dates are always evil anyway! A text input with Javascript validation is better for everyone -- you can copy and paste (and some people have been known to be accurate typists), and still use a widget for constrained input.
Ian, I agree that a textfield input is much more plain and usefull, but there are a few little problems with it, for example, what date is "06/07/08"? It might be obvious for some companies, but for a company working in Greece with customers coming (amongst others) from the USA and UK, good luck. I'm also a bit cautious on JavaScript, we still get too many problems with that, at least to depend on it. Even with those reservations, our current approach is just what you describe, a text field with a JS calendar popup and some JS code to parse dates, because there is no good solution.
I guess Peter's point is something else though: Taking the shortcut may take longer.
I solved that problem once with a "clever date input" field where they could basically type anything they like and my parsed just did the best it could. Here were some possible formats: "1st Jan", "june", "2005/1/2", "14 september 2006" etc.
However, this was a UK only site and if a US person would use it she'd have to accept the UK standard but you could treat ambiguous formats just like you'd have to treat impossible ones like "34 dec 2007"