The other day we were filling out some online paperwork for my daughter, and there it was. The worst designed input of all time, asking for my date of birth. It made me rage inside:

Ugh, Horrible. I dislike it even more than Android’s scrolling date flicker. More, even, than how Excel cells handle date entry!

Ok, Ok. I've gone too far, nothing’s quite as bad as Excel's date handling. I’m sorry, I’m just so worked up!

To be fair, dealing with dates can get quite complicated: Who's doing the data entry? Are there multiple dates to enter or just one? Do they know the date before they pick it, or are they choosing a date based on some criteria? Is the date in the past or the future? What date spans are legitimate entries? Is it a leap year?

Today we're going to take our little example of a 3-part scrolling date picker and use it to explore a few things about form design.

Let me describe our example a little. It’s a date picker consisting of three dropdown menus, one for the day, one for the month, and one for the year. Each drop-down is a list of whole numbers representing the three components (yes, the month is represented by a number), and each defaults to the lowest number in the list.

The interface is designed to be navigated by a mouse - forcing you to move your hands away from the keyboard - though usually you can press the 'tab' key to jump between each in order. In this case if you start to type anything else, it’ll go to the first entry starting with that character and stay there.

Why would the form designer choose something like this for a date entry? First of all, it approximates date fields in many paper government forms - a grey box for each part of the date. So the form would be, on the surface, familiar to its users I guess. And most people have encountered a drop-down-list of numbers. No training necessary, hopefully.

It also ensures that the government always gets the date in a consistent format. There’s certainly no way to

the date in anything but day, month and year, though that doesn't do anything to avoid the user's confusion if they accidentally mix up the date and the month. Notice that the hint as to which is expected is only visible when the drop-down list is open!

Ok, the 'good' parts, such as they are. Possibly familiar-looking to the user, and strict control over what can be passed in as data. Beyond that, though, we find some real problems with this design - I would even go as far as to call it user-hostile and error prone.

1) This is a form where you're typing in lots of details. This input pulls the user away from the rest of the data entry, forcing them to leave the keyboard and use their mouse to navigate around

for a date _they already know.

2) The user needs to click on each field, open a drop-down, and then mouse-scroll, down-arrow or finger-drag a billion times to the correct entry. If you’re on a touch screen it’s even worse, as you have to try to drag around the scrolling part without accidentally activating the wrong date or scrolling the whole screen.

3) You need to do this 3 times for what is actually one piece of data - tripling the chances of input error.

4) There is no quick way to navigate to the correct date: you can’t type in a partial date - it defaults to the first occurrence - and there's no quick way to navigate by decade. So for example typing ‘2’ takes you to 2000 and stops there, making you arrow-down or reach for the mouse anyway. Remember, this is a form asking for a parent’s birthday, so wherever it starts from is pretty much guaranteed to be far away from the needed value.

5) The number picking is imprecise - while you’re scrolling it’s easy to pick the wrong entry, and it's not obvious outside of mouse interaction whether you need a

, space, single or double tap or whatever to actually choose the entry.

So while they’ve managed to ensure they always get the right format for the data they’re expecting, they’ve made it slow, cumbersome, and most likely increased the error rates.

The worst thing is that

- for example, are they even storing the date in year-month-date format in the database? Interestingly, even if they were (which would go against industry practice and various standards), behind the scenes they would still have to convert three integers (the computer's representation of those whole numbers for each calendar portion) returned by the input into whatever date format they store under the hood.

It would have been much easier and more familiar to their users to go with something standard, like the date pickers available by default in many applications and are otherwise easy to find and add to a web form. Calendar pickers, combo date inputs, even the scrolling android flip-thing.

But mostly, I'm not a huge fan simply for the reason that they tend to be mouse-only and break the data input flow, without providing any real guarantees of the correctness of the data input.

In industrial and laboratory settings we’re not usually designing forms for one-time form fillers from the random public. Most of the forms we design are for repetitive data entry tasks by

.

What’s the difference?

easy-to-learn, discover-able and visually appealing are all great attributes if you're trying to sell something to a new customer.

We need data entry elements that allow for the experienced user to be lazy and use the least amount of effort to get the correct data into the system.

Well, that depends. First and foremost, a date input for

should be very different from one where you are

Similarly,

has different considerations over

.

If you're entering dates as part of a repetitive, mixed data entry activity, here are the features that I would favour:

Yes, it takes some thought and design, though good quality components have this stuff built in along with accessibility features. But that’s the point - you front-load the effort to save time and improve quality every time it’s used. And you know what? You can do versions of most of these things with your paper forms too.

Truthfully, though, I've seen some great designs where you're browsing for a date and picking date ranges - the hotel and airline booking industry have really put lots of thought into that and it shows. But for plain data entry? Perhaps

just hasn't been invented yet.

Thanks for reading. Until next time!

– Brendan

p.s. Do you have form-led processes that are taking too much time and effort, or are producing noisy or error-prone data? Do you want to increase the efficiency and quality of your workflows? I can help. Visit

.

​