Optimise for near dates

[airblade]

I think the vast majority of dates which crop up in webapps fall into two categories:

• near dates: within a year of the current date and usually within a few weeks;
• far dates: more than a year away; e.g. an adult's date of birth.

These categories pull the UI in different directions. For example, for a near date it's better to have only previous-month and next-month buttons. There's no need to have a month dropdown or a year dropdown. For a far date, you probably want some kind of decade chooser, and after the user has chosen a decade something like the current datepicker with a year dropdown covering the decade.

A datepicker which tries to cover both near and far dates is not going to be great at either. This is the datepicker at the moment.

The main benefit of a datepicker is the presentation of dates in a calendar. This is useful for near dates when the target date probably has some relation to the current date, and the day of the week is probably relevant. A calendar is not nearly as useful for a far date, where you most probably don't know or care about the day of the week, nor need to click through previous and next months.

Therefore it makes sense for a datepicker to optimise for near dates. If the user needs to enter a far date, they should be given simple year, month, and day dropdowns, or a text input which can parse what they enter (which this datepicker can do 😉).

Therefore I plan to replace the month and year dropdowns with static values.

It could be argued that the month and year dropdowns are working fine, and provide some flexibility for jumping to different months or years, and don't complicate the UI much. But I'd rather the datepicker were really good at one thing (near dates) than quite good at near dates and OK at medium (not near and not far) dates.

[airblade]

Related:

• Safari's date-picker is the cause of 1/3 of our customer support issues
• Asking users for dates (gov.uk design system)
• Asking for a date of birth (gov.uk again)