Worst UI Ever? - Date Entry

Those of you who have read my other "Worst UI Ever" posts may recognize that this one comes from the same application as my last post on the topic. I don't mean to pick on this one application. Its just that I use it so frequently that I notice these problems.

Here's a screen shot of what happens when you try to submit an expense report with dates entered in the "wrong" format. Why's "wrong" in quotes? The real questions is "wrong to who?" From a system perspective, a developer would likely thing that all dates should be entered in a particular format. Sounds familiar? The reality is though, that the "right" format for date entry is the one that the user things is correct. If I, for example, live in the US then I might be used to something like 11/12/2007. However in another part of the world I might use 12/11/2007. So how should any system handle this since both of those could be interpreted as valid dates, albeit incorrect ones. If the system doesn't know what format the user wants to use then it is ambiguous.

Just Getting Picky
So what is a designer or developer to do? Enter the "Date Picker" control. This little gem has been the solution to this problem for quite a while. So no more problems with date formats because now you don't enter one at all, you simply "pick" one. If you are reading some sarcasm in the tone of this, you are not imagining it.

The date picker control is a handy little calendar that pops up when you try to enter a date into an input. The calendar, usually defaults to the current month. It has to default to something, so why not? The problem is that thought really needs to be put into the use of these things. Imagine for a moment that you are entering your birthdate and the calendar defaults to this month. Unless you were "born yesterday" this will probably cause a lot of extra navigation to enter the date that is really on the tip of your tounge, or fingers. If only you could just type it in.

Does it ever make sense to use a date picker? Of course. For example, in a scheduling application where people might be interested in setting up a meeting for next thursday, it might be nice to allow the user to choose that date rather than enter it. The difference is in how the user thinks of the particular date in mind. If the user thinks "I was born on February 1, 1970" then that is different than a user thinking "Two weeks from this past monday". This difference in mental model, should drive a difference in the UI.

So we have dispensed with the date picker for the application in question. Luckily, the application actually allows date entry as well as date picking. However, in the screenshot, the date entry is what caused my "error". The problem is really that the application doesn't do a good job of accepting the format I intended to enter. It also doesn't even do a good job of telling me what format it expects. If you look in the screenshot, it is displayed as a TIP. Now to me, a tip would be something helpful but not crucial to me using the application. It turns out that the format really was crucial given that my mistake lead to 4 separate error messages indicating that the format was incorrect, without once suggesting the format it expected.

The one thing this application does do well is when it gives you the suggested format, it shows you today's date. I have seen many applications which do something like this "(MM/DD/YYYY)" This format is very familiar to developers but would all your typical users understand this. I have even seen some that say "DD-MON-YYYY". Clearly the MON means moth, but why should users have to decode that. Showing "05-Nov-2007" (It was November 5th when I captured the screen) is much better since the context of the date is at least in the user's frame of mind. Most people at least know what month and year they are currently in.

The Bottom Line

• If at all possible let the user enter the date in the format they want
• If you can't, give the user a clear indication of the expected format using the current date as the example
• Use date pickers for dates that user's don't know by date such as "next tuesday"
• Don't tell the user they made an error if the software can't figure out what they meant. It is never a good idea to tell the user that what they enterd as "11/05/2007" is an "invalid" date when it obviously is.