What's the best way to present date of birth form fields?

Question

I am building a form that requires users to enter in their DOB. What is the best practice for this? I have identified 3 basic options:

• Free Text Field Users are able to enter day, month and year in a free text field. During UT, I noticed that this caused some minor issues with users entering "81" instead of "1981" or users tended to look at the keyboard when entering data and not the screen so tended to enter in all fields then look up and notice that only the day field has been entered.

• Drop down menu Users can select the day, month and year from a series of drop down menus. So drop down one is a list of 1 to 31, dropdown two is January through to December. This seems easier although the number of years in the final drop down is very long - 1920 to 1994

• Date Picker Not really an option but I could present a date picker with a calendar icon where users can scroll through the months and years to select their date of birth.

So, which one is the best approach or are their any other ideas?

Answer 1

We use a simple, single text field with an example instruction, just like Bennett suggests.

Date of birth |________| (example: 31/5/1970)

However, we also add another element onto the page, which we call a Field Reflection pattern. The form takes whatever they entered into the field, and then dynamically parses and interprets it, and reflects the information back in a slightly different form. For dates, this means taking "31/5/70" and displaying "Sunday, 31st May, 1970".

Calculating the day of week is a small delighter we add in there just for fun. We have found that putting the day of week did result in more people paying attention to the display, and thus catching any errors more often.

Answer 2

A free text field with an example is clear, and quick and easy for people to use.

               ________
Date of birth |________| (example: 31/5/1970)

Dropdowns could be all right for day and month, but not year. It's probably easier to type a four-digit year rather than scroll all the way down to 1950-whatever. The only real benefit of dropdowns is that they enforce the ordering of day and month. But they are a little clunky to use compared to typing.

Answer 3

One more way is the text field which is smart enough to understand different formats. User may type in "21 apr 1981" or "4/21/1981" or "21.04.81" or something else. Usually it's not so hard to parse. As an example WolframAlpha understands all this correctly. Of course sometimes you may face an ambiguity (like 01.02.1981 -- is it February 1 or January 2?). In this case you may give user options to choose from or automatically choose one and display a warning.

And I'd recommend to take a look at some other questions about date picking:

• DD/MM/YYYY - do people know what that means?
• Should I include the month name in my select list for credit card expiration month?

Answer 4

The one that I consider to be most accurate (i.e. no user mistakes but still easy to complete) is: - Date free text - Month drop down (January, February...) - Year free text (accepting either 2 or 4 digits)

Now, I realise this flies in the face of "don't mix your mouse and keyboard" but honestly after years of testing web forms with users this works best. And that old rule becomes less relevant anyway as people move away from mouses. Date pickers are great for dates close to today; full drop downs are an ugly compromise; full free text leaves you open to user error.

Answer 5

When using a datepicker, you can tune it a bit based on your users. If your site requires at least age 18, you could have the datepicker start a [currentyear-18], making it easier for a good percentage to choose the right year.

If you use a single textfield (maybe combined with a datepicker), you can apply a mask to help the user enter the right format. Something like the masked input plugin: http://digitalbush.com/projects/masked-input-plugin/

Answer 6

The problem with free text fields is they are very easy for users to make mistakes with. Like you say, they may enter 81 instead of 1981. If your site is being used in different countries, then some users will write the day first, others the month first, etc.

I would think a date picker would require way too much navigation for the user to find their dob and would take too long (most frustrating). Date pickers work best for finding recent dates.

Drop down menus are what you see most often on web registration forms. They are generally less error prone as the user is limited by the available options in the drop down list. They take slightly longer to complete than free text fields but prevent more errors from being made. Remember that if you go with this option, it is best to state something like 'day' 'month' and 'year' within each field.

Answer 7

Actually there are three valid options, and you can choose the right one for your audience by a simple AB/C Test. (it really depends only on your users)

I saw many tests in which results pointed to one of the three options below, and as long as you remember to keep the dd/yyyy as simple input fields (any other solution will bring up challenges and problems for your users) you can't go wrong.

This example illustrates the right order of fields only for some countries*

Answer 8

I'm constantly impressed with the date entry field on the www.rememberthemilk.com site. It's a single field, you can enter the date in almost any method you can think of and it translates it for you. (15/12/2011, "15th December 2011", 12/15/2011, "next friday", "fri 15th december"...) and on entering it will translate what you've entered into a readable format "Fri 16 Dec 11" so you can confirm it's correct.

If the date you enter isn't valid (such as entering Friday 15th December) it will take a stab at it for you (in this case setting it to "Thur 15 Dec 11") and you can easily amend it.

It also detects if you've entered it in an obvious US format (12/15/11) and chooses the correct date of 15th December 2011.

It's a really impressive piece of coding there, you actually have to go out of your way to get it to pick a wrong date.

Answer 9

From what I've experienced, it depends on the project. I've had projects where the users had no issue with a standard textbox with a hint or example while I've had projects that tested better with 3 dropdown lists despite the length of the year options.

So ultimately, test if you can.

Beyond that I have came the following starting rules:

1. If data accuracy is critical to the system - dropdown boxes lead to better accuracy at the expense of usability due to long option lists.

2. If users are wary of providing date of birth - use a single textbox with an accessible hint that masks on blur. Alternatively, question the requirement to see month and day are truly required.

3. All others - single textbox with an accessible hint.

Answer 10

A simple text input is the best. The input should be able to parse the data and come up with the most appropriate date. One such I have been using is SlickDate (http://www.mountonetech.com/slickdate)

Answer 11

See the following answer more as an answer to sensitize a problem according to this topic. But if the topic is meant in a general way the answer may more related than you may think.

I think the only suitable solution for this a free text input field, because I've never seen a birthday form where people who don't (fully) know their birthday can enter it.

The german passport law (or exactly said the administrative regulation of it) says that the day and month (in the past even the year) can be written as XX when it's unknown.

So this means that in some passports in Germany the birth of the owner is written like XX.07.2000, XX.XX.2000 or even XX.XX.XXXX (DD.MM.YYYY). Some years ago zeros were used instead of x, so it could also be 00.00.0000 as a valid birthday.

You may said everybody knows his birthday but think about orphans or (quite actual) refugees - especially small children.

To be honest there are many situations, especially since "the digital age", where people are said to use some kind of "default birthdate", like 01.01 of a estimated year (which may be nearly correct). But this brings other problems, because it can't be said if the person was really born on 01.01 or if the person doesn't know its birthday.

I know that it's much more easier to handle correct dates and maybe choosing any date or a default date will fits the needs of most software so this is not a large problem. But if you really need the "passport birthday" (assuming that the user will enter it) you may think about this fact and maybe ad an advise like "If you don't know your birthday choose the 01.01 of any age" or add an "unknown birthday"-checkbox. I don't know how other countries handle the shown problem but I can imagine that they also have (partly) unknown birthdays or use default birthdays.

Answer 12

In our application, we wend for this solution:

The date widget is normal, free-form line edit widget. You can enter anything you want. As soon as what you have typed is somehow recognizable as a date, the found interprettation(s) of the data are displayed in a dropdown-like list under the widget. These interprettations are displayed using full years and full month names, and ordered in order of likelyness. The widget can be constrainded to only suggest specific date ranges. That way if you type 31 as the year for a birthday, 1931 is suggested instead of 2031. The user can click any of the suggestions to choose that interprettation. Inversely, in a widget used to plan a future appointment, the dates in the immediate future would become the likely interprettation.

Of course, the system locale is used to determine what the most likely interprettation of the entered date is, what month names and abbreviations are used and what the acceptable format for displaying the interpretted dates is.

When the focus leaves the date widget, whatever was entered by the user is replaced by the most likely interpretted date, or a cursive message like "No date selected" or "Invalid date". When the focus returns to the widget, the text is again what the user entered there in the first place.

Of course, the rules for interpretting the date are quite loose. Different separators are accepted, as well as not using separators at all. Clues to what field is what are used if they are available (like abbreviating the date to two digits, but using a ' for the century part would hint that that part is a year, or using 'th' 'st' 'nd' or 'rd' behind a number would hint that that part is likely a day number). Months may be given as a number or as a name, optionally abreviated to the shortest unique abbreviation for it.

All in all, this makes for a date entry widget that is very flexible from the users point of view, and is fast to use.

Answer 13

Use inline inputs or drop-down date ranges over calendar UI widgets.

Our eye-tracking UX sessions quickly identified how users don't know how to interact with date pickers.

Answer 14

According to Nielsen Norman, the best way to do it is to use open text fields, as many of the contributors above have said. Here is the link:

https://www.nngroup.com/articles/date-input/