So that’s why DOB fields are dropdowns
A recent project to redesign an online form and create a version for mobiles reminded me, once again, of the importance of user testing.
According to Caroline Jarrett in her (very user-friendly) book Forms That Work, ‘Slot-in answers such as name, address, and date of birth are so well known to us that it is much easier and more natural to type them in directly rather than selecting from the list.’ For instance, she notes that it is difficult to scan options in a ‘Year’ dropdown because they look very similar.
I always find date of birth dropdowns annoying and would be able to type in my date of birth much more quickly, so I completely agreed with Jarrett. Therefore, I made the date of birth fields text fields in the first iteration of the prototype (desktop version), expecting that this would make it easier for participants to provide their date of birth. (Note: I know dropdowns prevent Americans from getting confused with the UK date format, but this form would only be used by UK residents.)
Well, half of the participants agreed with me. However, the other half made formatting errors during the testing session (e.g. D instead of DD). What I, a touch typist, had forgotten was that many people must look down at the keyboard to type and therefore may misinterpret or forget the field labels (YY instead of YYYY) or not notice that they have accidentally tabbed to the next field. These participants, who were less proficient at typing, welcomed dropdowns because they reduced the amount of typing they had to do.
I replaced the text fields with conventional date of birth dropdowns in the second iteration of the prototype (see below) and, surprise surprise, participants didn’t make any errors.
Despite this, for the mobile version of the prototype I had participants try entering date of birth using both text fields and dropdowns because I thought dropdowns might be more fiddly on a mobile device.
I got the same result: all participants preferred using date of birth dropdowns on their devices (smartphones with either touchscreen or QWERTY keypads) because it was much quicker and more accurate for them to select dropdown options than numbers (especially on QWERTY keypads).
So, reading books (and getting a UX person to create the prototype) is no substitute for user testing. And sometimes conventions are there for a reason. Even if they are annoying.
Comments
-
LeeInteresting observations. Did your prototype include any kind of automatic correction on the form though?
For instance with common formatting errors such as the one you mentioned – D instead of DD – the form could easily rectify this automatically without disturbing the participant’s flow through the form.
This would dramatically reduce the kind of errors you mention whilst also speeding up the process for those who prefer not to have to select the drop-downs. In the case of selecting a year, drop-downs can be particularly time-consuming.
-
ShoshannahI see Lee beat me to the question I wanted to ask- if there was any automatic compensation built in to take account for formatting differences (I refuse to call entering D instead of DD an error- both are valid and should be accepted by the form).
As for mobile- I do agree that drop-downs can be easier and quicker than entering numbers.
This is assuming that the target to select the drop down is large enough and that the form is too inflexible to understand dates entered with words like Jul-29-2010 or July 29th 2010. -
antonioRecently i’ve found several site using a mix of the two solutions so drop down for day a and month while type in for year which i personally find very interesting.
-
Phyllis TamThe automatic formatting of D to DD or M to MM is a good idea and could work in many instances. However, one participant entered DD-MM-YY (the field for this form could have automatically added 19 in front of YY. However, other forms might not because YY could be 19 or 20). Another participant entered D-MM-YYYY without looking up but mis-tabbed, so her DOB ended up being DM-MY-YYY.
This error was possible because if ‘hunt and peckers’ knew they could tab to the next field, they often entered their DOB in one go without looking up from the keyboard in between fields. That meant that they did not notice errors (if any) until they had already tabbed to the field below DOB.
So even though dropdowns (especially for year) do take more time for touch typists, they allow hunt and peckers to complete DOB without their eyes leavinig the screen (up to 3 times if they don’t tab).
Antonio, I’ve noticed the mixed format DOB fields too. Once again, for me, I would prefer typing in the year. This could be a good compromise as hunt and peckers would only have to look down for one field (and only have to remember the formatting for one field e.g. YYYY). However, this form had a minimum age requirement, and a year dropdown with limited options support this requirement.
Shoshannah: regarding mobiles, as I said, we tested the form on smartphones. All participants zoomed in until fields were large enough to select, and dropdown options were rendered large enough on Safari, Android and Nokia browsers.
-
smilidonThe textbox- dropdown combo makes more sense to me than the either options. dropdowns for day and month and text field for year would make it easier. Or how abt type in dropdowns that give both the options…
-
DanDeveloping a form that could be typed or use a drop down seems to make sense to me too. But I guess the real moral is to user test. A hybrid form would probably have some users typing then hitting the drop down and loosing what they typed.
-
MihirIts just the validation is more complicated in drop down box.
suppose someone selects date as 31 for a month of february.
People like me use ajax controlled calendars for that purpose.
