The state of date & time pickers: 5 use cases and 3 ways to implement date & time selection

With the release of iOS 14 Apple has changed their iconic date & time picker. This matters because back in 2007 – with the release of the first iPhone – a new way of picking dates and times has emerged that set the standard for the industry.
Change is good and it should improve things, but it seems like people either love it or hate it…

After 13 years, as of iOS 14 there is no scrollable date and time picker with dials. At least, not how it used to be …

Table of Contents:
Date selection
Apple has decided to move from a date scroller to a calendar view. While the month & year navigation still uses a two wheel scroller, the actual interface for picking a date is totally different.

Having a calendar instead of a scrollable list has its advantages:
- The selection can be seen in context of the week and month.
- It is a component that is universal and easily understood by anyone.
Is it better than a scroller though? That depends on the job of the picker.
Let’s take two distinct examples:
1. Scheduling an event
The selection will usually fall in the current or upcoming couple of months. Having a calendar as a grid is an advantage because people can see the days of the week, find dates quickly and select with a tap rather than having to scroll through a bunch of values.

Horizontally slidable calendars on touch screens and clear navigation with arrows is essential for great usability (the Mobiscroll calendar supports both). Providing means to quickly change the month and year helps people to easily get around.
2. Selecting date of birth
People will probably need to go “back in time”, select a different year and probably a different month too. In case of a calendar view the flow would look something like this: tapping the month and year will bring up the scrollers, then scrolling through each, tapping to go back and then selecting a day from the calendar.

Compare that to the scroller, where it will be up to a total of 3 interactions, scroll the day, the month and the year. Does the calendar add any value compared to scrollers? Not really… you don’t need to know if you were born on a Monday or a Saturday.

From a UX perspective the winner for scheduling is the calendar and for picking the date of birth it is the scroller component.
Time selection
Another big change is the time picker from a scroller component to a hybrid solution that consists of an input field with scrollable digits and a numeric keypad for value entry. The same UI is used in both iOS 14 and iPad OS 14 (where the latter shows up in a popover, rather than at the bottom of the screen).

Numeric keypad
We’ve already seen this on android, but they have moved on to a different approach with a draggable dial. As a rule of thumb, quicker is better so being able to simply type in a time is nice. If it has a smart validation, and people understand how to use it, errors will be minimal. If you only take speed into account, you have to enter a lot of values and you know what you are doing, the numeric keypad might be the quickest.
Combine that with scrolling
This might not be obvious at first, but the time input actually supports scrolling. It is useful for small adjustments, but doesn’t really provide the real estate for convenient interaction. The touch areas are small, plus it is not obvious what it really means.
The feature is hidden from the user and can only be discovered by accident through dragging on the values rather than tapping on them.
It saves space, it can be combined with the date picker, but the interaction is not obvious on first glance. And in UX the rule of thumb is “obvious always wins”.
Let’s take a look at a couple of use cases:
1. Setting event times
Tapping on the time field then typing away is quick and easy. For selecting an end time, the field can be auto-populated and you have the option of dragging on the hour to adjust it, or retype if needed.

2. Setting up alarms
It is similar to picking a time for an event, a pretty straight forward task and using the keypad is easy. While creating a new alarm automatically opens the keypad it does close and you’ll need to tap the field again to open up the entry.

Because there is enough space on-screen an inline or embeddable component – like a scroller – would be preferable (Mobiscroll components support directly embeddable pickers).
3. Setting appointments
When you have to schedule an appointment or make a structured adjustment, the keypad falls short because it lets you enter any combination of digits (in theory it could be handled with a complex validation logic).

This is when picking from a list of possible values is the way to go. That list could be laid out as a grid or as a scrollable list with hour, minute and AM/PM wheels.
Putting the available spots front and center and making values that are not available disabled or hidden improves on it even more. For example, appointments for every 30 minutes representing pick-up- and return- times for rentals. (Mobiscroll has sophisticated ways to disable and hide values)
Native components changed, and how it affects the mobile web
If the standard system components change, they not only change in applications that ship with the OS – like the Calendar or Alarm app. It happens on the standard tooling level for native development and it trickles down to web browsers as well.

This means that the native inputs of type=“date”
, “time”
and “datetime”
implement the new components rather than the old ones. The native pickers have and had their limitations in browsers – since the API only supports minimal customization options – and this change brings on new interaction models and challenges.
Different scenarios require different approaches
Luckily there are tools like Mobiscroll that provide different ways for picking dates, times with calendars, keypads and scrollers (yes, we still have it). At the end of the day you’ll need to consider what is the best approach in your context. Give it a go and put these tips to test.
Illustrations from this post use resources by Icons8.