In
The Curse of the Despicable Dialogs
Mr Ed (sigh... sometimes it's too hard to find people's full names) gives a number of concrete suggestions about dialogs. They are
mostly fine, but one of the suggestions really annoys me. For date
input he suggests that of the three examples pictured, the third is
the best (i.e., better to do date input with three select boxes).
Maybe this wouldn't be quite so bad off the web, where you
can allow both text input and drop-down entries. But having entered
my birthyear several times in the last couple days using select box,
this is just an incredibly stupid UI decision.
When I see select boxes in this context, I feel the programmer is being lazy and depending on the widgets do error detection. A similar situation is with phone-number fields, where people sometimes put in three text boxes for area code, phone number prefix, and then the last four numbers.
In both cases, this isn't how people think of the data. A date is a single point in time, even though it is represented by three values (day, month, year). When you are entering a date the entire value should be entered, even if it that value is encoded in a structured manner. When you edit a date, it seldom works out that you'll only edit one of these fields.
Besides programmer laziness, this is also a condescension upon the user. Can the user not read the instructions next to the input and figure out the format? Is the user incapable of writing a check or signing a document in real life, and they cannot be expected to have date-writing skills on computers?
And while a calendar widget is ideal, the calendar widget should be like a filename widget -- you get a text box (which like a commenter said, supports copy-and-paste) and a "..." button for accessing the widget. (This is the default behavior for the oddly-named Coolest DHTML Calendar [demo -- the real site is down right now])
As I deal with more complex forms, especially related to data entry and databases, I feel more and more like free text is the best option, and that users should develop conventions and not try to encode every convention into the UI and data model. Often those conventions are short-sighted -- like the phone number fields, which won't support international numbers. If you have conscientious users and on-screen suggestions (like including mm/dd/yyyy next to your date input) you're doing your users a service.
That reminds me I should be adding that ability to Formulator some day when I have time. :)
# Martijn Faassen
I completely agree with your points about the date combo - its an awful way to enter a date.
We recently ditched a PHP/Javascript driven popup calendar in favour of a simple text box in a comercial web application of ours.
The REAL benifit of the textbox is being able to allow your user to enter "english dates" (parsed using PHP's strtotime() function). Now our users can set appoints for "2pm next thursday" and search for items entered "last week" - much more intuative than having to dig around in a calendar for the right date.
How about an objective comparison of the UIs? A reasonable standard (though not the only possible one) is to measure the number of actions a user must take to enter a value. Let's count them:
First, your favorite:
Date [22/07/2004] (dd/mm/yyyy)
1. Tab into the field.
2. Type "2".
3. Type "2".
4. Type "/".
5. Type "0".
6. Type "8". (this is a typo... hey, nobody's perfect)
7. Realize mistake; type "Backspace".
8. Type "7".
9. Type "/".
10. Type "2".
11. Type "0".
12. Type "0".
13. Type "4".
Now Mr Ed's preference:
Day [22]V Month [July]V Year [2004]V
1. Tab into field.
2. Click on day dropdown.
4. Move mouse to scrollbar.
5. Drag down the scrollbar.
6. Move mouse back up scrollbar.
7. Drag down the scrollbar again.
8. Click on "22".
9. Click on month dropdown.
10. Move mouse to scrollbar.
11. Drag down the scrollbar.
12. Click on "August". (drat! I hate making mistakes!
13. Click on month dropdown.
14. Move mouse to scrollbar.
15. Drag down the scrollbar.
16. Click carefully on "July".
17. Click on the year dropdown.
18. Move mouse to scrollbar.
19. Drag down scrollbar.
20. Click on "2004".
Notice a difference? But really, I'm cheating here because when the UI professionals do this, they count "muscle movements", and so "Drag down scrollbar" would actually be three steps: "Press down on button; move mouse; let up on button". Which more accurately reflects the relative speed and ease of typing versus mousing. But then I'd have had to add at least 10 more steps and I was getting tired of typing.
And if the text entry box were ever so slightly flexible it might suggest a "dd/mm/yyyy" format but *accept* single digits for month and day ("7" instead of "07") and two digit years ("04" instead of 2004", with reasonable defaults for the century). Then the textbox would be only 8 muscle movements (or 10 with the "mistake").
Don't use dropdowns for entering dates. Just don't. Really.
-- Michael Chermside# Michael Chermside
[reading Michael Chermside's comment]
Looks like somebody's been reading Raskin's _Humane Interface_ :)# Robert Brewer
I think muscle movements also include a movement for key down and key up, so they both would actually have double that steps (though certainly that's a dull thing to write out). But having tried to use Raskin's LEAP, which he analytically justifies using these kind of metrics, I become highly suspicious of the metrics themselves; subjectively LEAP is crazy-hard to use.# Ian Bicking
Your comment about phone number validation is spot on. I have had to resort to typing in random numbers to get past a screen that insisted on a US format number. In all probability if the organisation was going to phone me it would be a real person doing the dialing, so there is no need to have any form of validation. I have yet to see a validation routine that can handle:
"(+44)207 123 4567 ext. 1234 during UK office hours only, or (+44) 7901 2345 6789
the rest of the time", but experienced phone users would have no problem.
# Dave Kirby
Using plain text entry widgets in addition to a popup calendar also has the benefit of letting you copy and paste dates.
In both cases, this isn't how people think of the data. A date is a single point in time, even though it is represented by three values (day, month, year).
Three values isn't quite how people think of a date either, to specify a date we also think of time differences (I'm going on holiday in two days), imminent days (tomorrow, next tuesday), and how often do you think "oh-two-slash-oh-one-slash-two-oh-oh-four"? A plain text box should support things like "January 1st, 3rd Feb" and be able to jump to a reasonable date.
And that's besides the fact that in many cases people don't have a particular date in mind. Maybe we could have a "vague date" that could also hold nonspecific times like "next week", "before friday", "christmas", "in august" and so on. (But is that string really worth validating as a date then?)
Simon Willison made a Javascript immitation of PHP's strtotime, see here. It's a big improvement to be able to write "next tue" without having to work out manually what date that is.