Do you train Kung Fu?
Or know someone who does?
Then check out KungFuPeople.com
Mobile version of this pageXML header and childNodes
Next:
YSlow grade A (96) but not with doubts
Related blogs
Breaking usability principles for usabilityA jerk with a good website
File attachment widget with Javascript
The Official Dilbert Widget
More productive than Lisp? Really??!
Drop down selects that learn
Related by category
Plone
Interesting lesson learnt on shortcut taking in usability
2nd of August 2007
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:
Comment
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"
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.