What really bothers me is that most of time when the date of birth is asked it is done as a way to determine some age criteria. The same could be achieved simply asking "are you older than N years old? [Yes] or [No]".
For example, I want to buy Quake on the Nintendo eShop. The website wants to know my age in order to show me a age restricted game. So it will always ask me the age same question even if I have already answered hundred of times. So does Steam and many other websites. Is this a by-product of some compliance or self-regulatory requirement like ESRB?
If not, it would make much more sense to just ask a yes/no question for the age criteria. Usually this argument is answered with "what about fraud?". Well, asking the birthday is no guarantee at all that the birthday is correct. It only adds friction.
As a small revenge I always use an absurdly old birth date on these forms. This way if they are collecting this data, my input will be discarded or pollute their datasets.
> Is this a by-product of some compliance or self-regulatory requirement like ESRB?
Yes, Steam addressed this an announcement a few years ago:
> Q: Why do you KEEP asking my damn age throughout the store?
> A: We're with you on this. Unfortunately, many rating agencies have rules that stipulate that we cannot save your age for longer than a single browsing session. It's frustrating, but know we're filling out those age gates too.
I can understand the “better safe than sorry” mindset. If I have a 15 year old son who wants to play Resident Evil, I’d be willing to let him play it, despite the “M” rating. But I wouldn’t then want a service to set it so that he’s allowed to view M-rated games in perpetuity, since M-rated games can vary greatly.
> The same could be achieved simply asking "are you older than N years old? [Yes] or [No]".
The term of art seems to be "neutral age gate", and something like a checkbox to indicate you're under 13 is explicitly not OK according to FTC guidance. So where it's to comply with government regulations, this is not enough.
> As a small revenge I always use an absurdly old birth date on these forms. This way if they are collecting this data, my input will be discarded or pollute their datasets.
Or the micro-frauds get detected, linked to your credit card & email address, your identity, and credit rating. Before you know it, your transactions are failing fraud checks, you can't get loans, and BigTechs unilaterally cancel your accounts.
I exaggerate, but I fear we may be heading in that direction.
I always go for January 1st, 1970. It is (nearly) always accepted on the form because it is a perfectly valid date to be born, but I like to imagine that some analyst is pulling their hair out thinking they have a null coalescing bug.
[01]: one- or two-digit day, typed manually
[Jan]: three-letter month, picked from a dropdown
[1970]: four-digit year, typed manually
I think this is a good (the best?) presentation.
By using a manual day entry instead of providing a dropdown, as the programmer you can avoid requiring client-side logic to restrict the number of days displayed in the dropdown based on the chosen month and year (e.g. 31 for Jan., 28/29 for Feb., etc.).
Having the month represented in letters, not numbers, minimizes the chances of user confusion between `dd-mm` and `mm-dd` presentations.
The year presentation matches the one in the OP article.
> I think this is a good (the best?) presentation.
I don't think so. It has problems with i18n. For example, the abbreviation for December is "Dic" in spanish and "Dez" in German, not "Dec" as in english.
The twelve month names for the month dropdown could be localized, unless I'm missing something. The entries don't necessarily have to each be three characters; they can be longer if the localization requires it.
DOB should always be a typed input, all numeric. People know exactly what to enter (the number of their month), have done it before many times (DMV etc.), and will knock it out faster than some ridiculous drop down over complicating the process.
For other dates though maybe, since most wouldn't have all month numbers memorized, but I’d still say typed, only with a variation on month name (you should be able to parse both abbreviated and full, so long as you know their locale) is better all the time.
One thing I always felt was an anti-pattern was in any input where months are numbers they don't explicitly mention in an adjacent label the name of the month. Besides the US/UK order confusion, you'd be surprised how often people think August is the 7th month of the year.
When I registered for Lufthansa FF, the form was just numbers. My birthdate has two single-digit numbers in it, and I ended up with Month-Date backwards (US vs. rest of the world conventions - e.g., 4/8 is either April 8, or Aug 4).
It wasn't an issue, but a minor annoyance to fix it every time I traveled, so that it matched my travel documents.
Until a couple of years ago, when I was traveling back from Germany and the flight crew thought it would be nice to surprise me with a bottle of champagne at midnight on my "birthday".
They were so proud of doing this over the top "random kindness" (it was pretty thoughtful), and couldn't figure out why I was confused and annoyed. I still feel bad for not acting more excited or grateful...
There's an unspoken privilege in being born on a day beyond the 12th of any given month, because you'll get a validation error if you mix up the day and month in a form
I was born on December 9. The doctors wanted to do a C-section for my kid on December 9 but I said to my wife that my kid shouldn't have to share a birthday with me, so they scheduled for December 14 instead. This might have been a better argument than not wanting to share.
Not quite - they're off by two. Historically July and August were Quintilis (fifth) and Sextilis (sixth) before they were renamed in terms of Julius Caesar and Augustus Caesar.
I heard a standup with a very dark joke, something to the effect of, 9/11 had a silver lining because now he could remember what number month September was.
It took me years to figure out that 9/11 was not on the 9th November. I always wondered why there was no snow on the images of the incident. Americans and their correct date system...
Confession: I'm nearly 40 damn years old, and I still second-guess month numbers enough that I usually just count starting from January, ticking them off on my fingers, and going through them one by one, to reach the one I need.
It depends on what the date input is for. If it’s for e.g. a credit card expiry date, then the date is already in numbers, so you may have the August=7 mental conversion errors but in the other direction.
well well, I think you might be on to something. This is going to save me quite a lot of time, not to mention that I might be able to go back to wearing shoes with laces again and not having my productivity totally destroyed.
Usually the best solution is not to ask for date of birth. I guess about one in ten of websites that ask me that actually have a legitimate reason for needing to know.
(In the present case, a UK Government website might well have a legitimate reason.)
If you're verifying (air quotes) something like whether someone is 21, I wonder if it would make better sense to ask the year of their birth, then ask the month and day only if they answered with the year where it mattered. You don't need to be that granular most of the time, so why put people through the hassle?
I tried to help my boss once to log onto Zoom for a meeting. The site asked for date of birth, and not wanting to give any PII I naturally entered some bullshit but plausible date.
Well Zoom locked him out for some time for trying to lie I guess and that meeting had to be moved to Teams.
This is interesting. What triggered them to think this was a lie? Had your boss previously entered a different birthdate, which they remembered and then compared to?
I have no idea what they may have gathered before but now that I think back, I did choose the date really quickly so it may be possible it thought I was a bot.
I’m not familiar with all the ways that is determined but I think it’s far-fetched but who knows.
I find that at least on iOS, selecting a birthdate through that is pretty cumbersome. It's great for dates where you can have a close-ish preset value and where day-of-week matters though.
author here, for known dates like date of birth it's still easier and faster to just type it in. Also type=date has accessibility problems and the design varies a lot, so people might get a decent experience on one browser/OS and a really poor one on another
Still, if many sites use this standard the users will be used to its UI and the vendor has a chance to improve it for everyone when people complain about it.
The problem is that the web didn't make the right separation between form fields (the composite values you submit) and the actual user facing widgets you use to produce those values.
so you're stuck with not great UX if the platform-specific picker sucks for your use-case which for this is absolutely does. If you're born in 1950 on iOS have fun spinning the year wheel for a while instead of just typing in the number.
The cross-browser support and standardisation for `input=date` (and `input=datetime`) has been notoriously poor for years. It's still only listed as 'partially' supported on some browsers on caniuse.
The one I have seen that I think was the best is a combo of both. Not a web developer so not sure the actual name but it was a text field that filters. So when you click in the text field it does the year drop down but also accepts standard text input. If you then type in 197 it then only shows 1970-1979 in the drop down.
Very cool to see author responses on an article from 2013!
I was wondering why you chose to use the placeholder attribute to show labels rather than the (afaik recommended) usage of showing example values. The form shows example values, but outside the input fields. Did you test both ways and this turned out to be better after all, or this was just an implementation which worked fine in testing so it stuck?
I think I just didn't realise how poor placeholders are in general at that point, compared to just having visible labels/examples. Placeholders disappear when you start typing and have poor contrast
The dozenade 2000-2012 will surely make many people confused and many badly designed UIs will let incorrect date to slip through. Myself have one date from this range on one of the documents and have to check twice every time I need to enter somewhere this date.
UK gov development is very impressive when I compare it to the government websites here which have a distinct 90’s scent.
Both in open source projects and these design blogs. Seems like a highly professional software organization
Interestingly, some people have administrative birthdays were they are born on an uncertain day of the month which is registered as day 0. So, somebody could be born the 0th of june 1950.
If there is even less information available the same goes for the month of the year. I have seen passports where people are born on 0-0-1970
Must be a frustrating situation in many software systems.
Different cultures have different standards for ordering day, month, and year. Encountering one that you're not used to throws you off quite hard, especially regarding day & month since they're both often two digits.
Relying on input=date would probably abstract that away at the client side, but as people said, browser support for it still seems to be bad.
Saw one site that had buttons for the decade (e.g. 1960's) that turned into a group of ten year buttons (e.g. 1960, 1961) and a back button. Thought it was a bit faster than the standard drop down. Month / Day did the same thing. Wish I remembered where it was, might have been some conference registration site.
> In this design, we use a text field for day, month and year. So far this has tested well, with the main issue being that some people pause and wonder whether to include a leading zero (for example '01' ).
Or just allow both versions (01 or 1). Edit: this works best if the form is validated client-side, otherwise you still get people wondering what is allowed in the field because there is no immediate response to input.
I'll argue that there's a nontrivial overlap between the users who fail to do this correctly, and those that would cause me support related grief later.
Have you tried this in practice? It is extremely awkward to pick a date of birth using a regular date picker. It is worse than all the options mentioned in the article. It is only appropriate for picking dates close to the current date.
For example, I want to buy Quake on the Nintendo eShop. The website wants to know my age in order to show me a age restricted game. So it will always ask me the age same question even if I have already answered hundred of times. So does Steam and many other websites. Is this a by-product of some compliance or self-regulatory requirement like ESRB?
If not, it would make much more sense to just ask a yes/no question for the age criteria. Usually this argument is answered with "what about fraud?". Well, asking the birthday is no guarantee at all that the birthday is correct. It only adds friction.
As a small revenge I always use an absurdly old birth date on these forms. This way if they are collecting this data, my input will be discarded or pollute their datasets.