Picking a distant date from a calendar is expensive
Aliases: date picker paging · birthday calendar · month arrows
What it is
A popped month grid shows one month (or week) at a time. The farther the target from “today,” the more pages to turn: a birthday, an ID expiry, a contract ten years out. Cost grows linearly with distance. Distant-date calendar cost is using a browsing tool for a recall task—reaching a known date far from the current month by walking cells. The issue is paging burden from distance, not whether typing is allowed, and not whether start and end can be seen together.
Why it happens
A month grid answers “which of these nearby days”: the cells are in view and the comparison is among neighbors. A distant date usually already exists in working memory as a year-month-day (July 1998); the job is to externalize that structure, not to stroll a timeline. Each page moves one month; ten years is a hundred and twenty turns, plus checks that you have not overshot. Some widgets offer a year dropdown and turn linear paging into two choices, which cuts cost, but many people never find the year control and keep hitting arrows. The cost curve is near zero for “tomorrow, next Friday” and steep for “date of birth”; one widget must not pretend the two tasks are equally dear.
Studying it
Have people pick “tomorrow,” “a day next month,” and “a birthday twenty years back” on the same calendar. Record page turns, time, and switches to typing. Factors: a year control, which month opens by default, which weekday starts the week. Outcomes: time to arrival, overshoot-and-return. Do not test only near dates; that verdicts the calendar “fast.” Eye tracking can show whether people hunt a year dropdown or mash arrows.
Where it stops holding
Booking the next few days has no distant cost; the grid is the right tool because cells show availability, and typing would need a separate lookup. Lunar calendars, fiscal years, and academic terms are not Gregorian months; paging those months does not help. A read-only history (a timeline) is not a picker; a different body carries the paging. Keyboard users who can edit the year digits can erase paging cost on the typing channel—that is no longer a pure calendar path.
Applying it
- Keep the month grid for near dates and “which day is free”; do not make birth dates and ID dates the primary path.
- If a calendar must cover the distant past or future, provide a discoverable jump to year (and month); do not leave only a pair of arrows.
- Open on a sensible default (today or an existing value), not somewhere near year one.
- Verify by picking “tomorrow” and one’s own birthday. If the latter takes dozens of arrow clicks, distant cost is still on the user.