21–30 of 97 posts
It's 2022 and input=date should be used instead for date pickers on the Web. https://github.com/alphagov/govuk-design-system-backlog/issu...
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.)
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?
It's 2022 and input=date should be used instead for date pickers on the Web. https://github.com/alphagov/govuk-design-system-backlog/issu...
On iOS choosing year/month is the rolodex interface, as slow and clunky as usual, especially if you’re flipping it for 40~60 years.
On android it moves month by month at most, so it’s even funnier to swipe for decades.
I think the type=number alternative with validation + confirmation text with the month in letters is a better choice.
That was pretty light on details. Why havent they tested a date picker widget or used native date pickers on ios/android?
> 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' ). Just put it in the example below...
[01] [Jan] [1970]
[01]: one- or two-digit day, typed manually
[Jan]: three-letter month, picked from a dropdown
[1970]: four-digit year, typed manually
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.
That was pretty light on details. Why havent they tested a date picker widget or used native date pickers on ios/android?
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.
Earlier quoted context omitted.
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?
If they really cared, they'd do something more exact than asking for date of birth; it's just a "formality" to comply with some law somewhere.
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.