Bad Interfaces – Getting Dates Wrong


Large yellow sculpture 09 - outside NAB, docklands in Melbourne

When you use an interface it’s the little things that help make it either a pain or just outstanding.

Sadly, too often we have to put up with the bad interfaces.

In light of this I will from time to time be producing a few articles focusing on specifics of bad interface design and implementation practices.

First one off the ranks is date fields and calendar pickers.

This interface element never really seems to work the way you want it to.  Making the overall experience very frustrating.

Date Format

To often you will see the required format for a date field indicated (dd/mm/yyyy).

Now this is good in that you now know which way to put the day and the month, but that’s about it.

What if you want to put in a date as – 1/5/11 or maybe 1.05.11 or 1-12-2011.

All of these are valid notations for a date.  But for a poorly designed website they produce an error message.

How easy would it be for a developer to just allow for these other formats.

Or better yet allow for a freeform written date as well like – 1st May 2011, Nov 2 2011, or 21 December 2011.

Again a little more work on the programming side of things,  but the ease of use would be outstanding.

Commonwealth bank online form showing restrictive date format use.

Commonwealth bank online form showing restrictive date format use.

Restricting the Input

If you really must restrict the input then take a look at the airline industry.  They will often use select lists of the possible dates, this makes it easy to pick the date from the list without any confusion, still not as fast as typing in the date however.

An example of restricting the calendar picker without pain.

An example of restricting the date field format without pain.

Forced use of a Calendar Picker

Now I can understand that calendar pickers are great idea when you aren’t sure of the date in a relational sense.

However there is nothing worse than being forced to use a calendar picker to fill in a field, especially when you know how to type in the date, you even know the date in question.

Yet it’s assumed you need assistance to find the date.  This is like escorting an able bodied person across the road.

It’s a very bad idea to treat your customer as idiots.

Activation Buttons for Calendar Pickers

The way we active a calendar picker needs to be obvious.  However too often the way they are designed is with no consideration for the general community.

The activation buttons can be way too small, obscure or just make us unsure what they do.  As is the case in the calendar picker from the Public Sector Commission.

A bad example of presentation of the calendar picker launch button

PSC calendar picker launch button, indicated by arrow, very obscure as to what they all do.

Launch Window for Calendar Pickers

It’s very important a calendar picker is launched  nearby to the date field it will populate.

From an accessibility view point it is extremely critical a new window is NOT launched for a calendar picker.  As this will disorientate the screen reader or maybe invisible (off screen) for a screen enlargers.

However it seems time and time again we are seeing calendar pickers launch in new windows, often over on the other side of our screens.  Often to get lost below the windows we have open.

In this modern age of web development why can’t a modal box just appear within a page in the right place.

Commonwealth Bank hiding the popup calendar picker

Calendar pickers, shouldn't use a new window.

Clear Large Buttons on Calendar Picker

When you use a calendar picker you want it to be very clear what those arrows on the picker are for.  Do they move the month back and forwards a month, year or a quarter.  If there are multiple buttons what do they all do.  The intent of the buttons needs to be very clear.

Never assume for example that you know the two arrows together means back/forwards a year .

Still even if you a have the buttons labeled well, you need to ensure they aren’t too small to use.    Sure the 20somethings building the site might be able to use them, but can the site’s audience.

Use of larger buttons and dates on the calendars  would make it easier for the ageing members of the community to use the calendar picker too.   The example below is just a little too small.

Example of good navigation, however the buttons are a little small.

Example of good navigation, however the buttons are a little small.

Smart Logic

Any calendar picker should follow the business logic of the application or form it’s supporting.

For example if you are dealing with a reporting function you generally don’t need to be able to navigate future dates.   If there is a restriction to 60 days in the past, then this needs to be implemented into the calendar picker as well.

A little smart logic can go an long way.  For example of you are using a  start and end date, once the start date has been picked, restrict the end date to being after the start date.

Yes all this seems logical, pity it’s not being done.

Example form for report generation, but future end date is possible

Example form for report generation, but future end date is possible

The Key to it All

To often people are being forced into series of rules or procedures that just go against the way they normally think and operate.

This should not be happening. We aren’t operating in the age of 3270 green screen terminals and mainframes. The interface should not be restricted.

The reason for all these problems are happening comes down to:

  • Lack of any interaction design at the beginning of the design process.
  • Lack of thinking through the way real people are going to use the system.
  • Lack of real users (not developers) testing a system.
  • Lazy development, taking the quick easy way to build an interface.
  • Designing and building for easy development, not easy use.

So next time you are implementing or designing  a calendar picker or date fields, take a moment and think about how people will use it, not the way you want it to be used.

Tags: , , , , , , , ,


  1. Airline booking systems reveal the best and the worst of this.

    Many sites enforce the use of a picker. Not only that, they (1) do not link the two fields, and (2) default to the present date. An example from the other day: its April and I’m trying to book a flight in December. I have to click once to activate the picker, click “next” 8 times to advance the month from April to December and then click on the date from the December calendar. Then I have to repeat the whole rigmarole to set the end date. Twenty (!!!!) clicks later I am feeling distinctly annoyed.

    I like it when the UI copies the start date to the end date, and then allows you amend it as required. It also helps to remember the last start date when returning to the page.

  2. One of the problems with allowing people to input dates in an arbitrary format (like ‘1/5/11’) is that you’re then stuck trying to interpret whatever they entered. Can you tell me what ‘6.7.8’ means? Is it 2006-07-08, 2008-07-06, 2008-06-7? Dealing with this problem has a bunch of solutions but they all suck pretty badly. Telling the user which format to use is, IMHO, the least sucky option.

    If you actually care about date fields I think you’re pretty much stuck with enforcing a format or using a bunch of heuristics and confirming your interpretation with the user (as some systems with street and postal addresses).

  3. @thomas

    Granted on the totally freeform date, but say you put in a mask dd/mm/yyyy and I input 5.4.11 no zeros or the full year, you should at least take this as valid and convert it to 05/04/2011. It’s this lack of application of a little assumed heuristics that treats the user like an idiot.


    Yes not all the airline sites have it right, in fact very few sites do all of the date fields and pickers right. It’s very frustrating for such simple programming.

  4. Great points, Gary. Localisation/globalisation/internationalisation are also issues here, as @Thomas points out. I think 9/5-11 is 9 May 2011, and not the 5th of September. Someone out there thinks the opposite. This issue must be considered.

    Oh, and thanks for pointing out my pet peeve. When giving a date range, I am annoyed when I have to click through all the months again for the second date. Can’t it figure out that if my first date is in October 2011, the second date won’t be earlier than that? (Unless they sell time travel, of course. Then it’s OK.)

  5. If I may add my pet peeve: telephone numbers. I hate it when sites don’t tell you what format they expect (ie area code in parentheses, spaces allowed, hyphens allowed) and then don’t tell you what you’ve done wrong. Just a message that there is an error. In red text. Not accessible or usable.

  6. Hi Kerry

    Yes I hate that too, issue with phone numbers is there are a lot of ways to write them, but at the end of the day you just want the string of numbers. I see no issue in removing the non numbers and applying a format mask later when the information is retrieved. This is classically how programming should work. People have just got lazy over the years.

    Don’t get me started on Credit Card numbers. 🙂

  7. I thought there was an specific date format for English based websites… For Spanish, we have a defined date format, probably it is a common mistake while using dates in your website….

  8. Hi Manuel

    Sadly no. There are basically two styles of date day month year and month day year. These come form the long form of the date, example 18th day of November 2011 or November 18th 2011. Makes for a good deal of confusion unless one has a date format mask presented.

Comments are now closed, move along, nothing to see here.