Not a Fan of Date-picker Controls!

I am not a fan of the typical 'date-picker' approach to entering dates in web applications. I believe in many situations date-pickers slow down interaction with an interface, and that even if providing a date-picker is a good option to provide, it should not necessarily be the only or even primary approach to entering dates on a web form. Rather, I prefer using a text input for more efficient and usable date collection.


If you are not familiar with what I mean by a date-picker, you probably aren't a web (or any other kind) of interface developer. But I guarantee you that you have seen them before. Here are some examples from around the web:

Date Picker from Google Calendar

Date Picker from my local bank

Date Picker from Facebook

And you can find out more about the date-picker at any number of sites.

Getting Real, an electronic and hardcopy book from 37 Signals I have blogged about before, encourages web developers to be opinionated. The Cluetrain Manifesto encourages company and individuals to be authentic, so I do not mind going out on a limb in speaking out against what is perhaps an orthodoxy.

What is wrong with datepickers? Firstly, although many datepickers support keyboard interaction, the most common, natural and intuitive use of a datepicker is using a mouse. If you are filling in a web form using the keyboard - tabbing between fields where required - a date picker is one element of the form that users will take their hands off the keyboard to interact with. This slows them down and makes them less efficient.

Secondly, for many applications shifting to a calendar view to find a desired date is jarring. Except for dates the user already has in mind, they typically need to work out where they are in the current month, understand use the weekdays to understand the date they need, and find the correct month, and then row, and then weekday, of the date-picker before they can enter a date. This is a lot of cognitive overhead.

Some date decisions are complex enough that understanding the relationship of the date in calendar view helps. But what if you only really need to find tomorrow, or today, or yesterday, or next week, or next month? The combined overhead of taking your hands off the keyboard AND finding a relative date in a calendar representation is excessive.

And what if you already know precisely what date you require? Using a date-picker in this instance may require the user to point their mouse to open the date-picker, click three times to move the month forward three times, find the known date (whose location on the calendar will move from month to month), click it and then re-engage with the rest of the web form's elements.

There ARE certain situations where a date picker really assists the user determine a date in the future that they have not decided yet, but I would argue in many other situations the user knows the date (either as an absolute day or relative to their own) where a date picker just gets in the way.

I believe that date pickers are not only popular on web sites because they are known convention, but also  because web developers want a lazy way to ensure dates are returned in a known format. But there certainly enough date-parsing and date mask validation plugins and libraries available now that this laziness is not justified.

How should dates be collected then? I prefer a free form text input, which can accept a wide variety of date formats and relative dates (like 'tomorrow').

There are a few of requirements however:

• The interface should provide some examples or otherwise give the user permission to enter a date (something many will no longer be used to!) and to show just how wide their options are. 
• A supporting and entirely optional date-picker should be present to help with those situations where a user really does need to see a calendar to make up their mind. 
• All entry in the text input should be a validated on-the-fly, giving the user valuable feedback as they type to let them know their chosen input format will be understood.

In my application, My Web Brain, I allow the user to enter an action due date using text input:

Using a text input for date entry in My Web Brain

The examples are there to encourage the user to start typing naturally. The links below the input text populate the text input not with a date but with the linked word itself, letting the user know that the next time they complete the web form they can use these words (eg. 'today') if it is more convenient to keep their hands on the keyboard.

My Web Brain does not yet have a supporting date-picker or on-the-fly validation, so I do not quite pass my own test - these are things I will add in the future. 

This approach of emphasizing text input over a date picker is in my view a good idea, but it makes particular sense in applications like My Web Brain that lend themselves to relative date entry and have a repetitively used form whose speed and efficiency is important to day to day usability. 

I am not a fan of the date-picker. The picker has a role in collecting dates for an application but not an exclusive one. Re-evaluating the way your web form collects dates may improve the user experience.

PS. Is it date picker, date-picker or datepicker? Sorry about the inconsistency in spelling this term in the post. I do not think the internet has made up its mind about this word yet.