Web page forms and date field best practice

I was prompted to write a quick blog post about entering dates on web forms after a painful experience on an insurance quote site at the weekend. I needed to retrieve my quote by had to enter the reference number, my postcode and my date of birth. I just couldn’t get the site to return my quote, it just kept saying it couldn’t be found. After phoning their helpline and spending 20 minutes listening to their music on hold they just said have are you putting the slash signs in? e.g. 10/08/1966 instead of 10081966. There wasn’t a single clue on the page that that was required.

Dates on webpages which can be accessed from anywhere in the world are a problem due to the way dates are formatted differently around the world. Generally when displaying dates it’s best to avoid any confusion by spelling out the month e.g. 10th August 1966 instead of 10/8/1966 which could also be read by some as 8/10/1966.

When asking for a date of birth I prefer to separate the fields and make it clear to the user what is required as shown in the example below. Even if this page is accessed from a part of the world where the month is traditionally positioned at the start of the date the user won’t be confused about what they need to enter.

Also notice that for Date of Birth we don’t display a date picker / calendar component. Using a date picker for and having to scroll back a number of years would be painful. The lesson is to seriously think about what the date is and why you are asking the user / customer to enter the date. In this example you’ll notice that the year isn’t a drop down box. Displaying a list of 80 or more dates isn’t a great user experience, it’s quicker to just key in four digits.

I love this website and the skill that has gone into making it really easy to use. It’s for a UK hotel chain where people are booking rooms in advance. Note how the form is pre-populated with today’s date (March 17th 2014). This is great from two perspectives. Lots of people leave booking their hotel rooms until the last minute incase their travel plans change so this means that a lot of the time you don’t actually need to enter a date at all. Having the date pre-populated also acts as a visual guide to reenforce subconsciously with the customer how the date should be entered. The date picker is also really well thought through. So many of the off the shelf date pickers are styled with quite a small font, this is big a bright and it’s obvious how to use it. The current date is nicely highlighted. The developer has also taken the time to consider that you can only book a hotel room for future dates, so previous dates are greyed out.

Next time you need to ask a user for a date on a web form:

Think through what the date really represents.
What is a sensible default.
Should it allow dates in the past and the future?
If future dates then how far into the future? For example if you are asking someone to pick a delivery date why not just display the next 7 days and let them pick one of those dates from a drop down?
Is the format of the date clear to an international audience and people from different backgrounds?
Does a date picker make sense? I’d suggest it seldom makes sense on a date of birth for adults but may be if your developing something to record the date of birth for infants it does make sense.

Bonus tip: I’d always encourage good semantic markup but I have noticed that the default rendering on HTML date fields can yield pickers which are not optimised to the context of the date you want the user to enter. Think carefully before you leave this to chance. For now I’d always code 3 input fields like you’ve seen in the above examples.