Recently I was asked by a client to add a date -time picker for users to provide a time and date as part of a contact form. Initially this feels like one of those requests that shouldn’t be a problem – display a calendar and a selection of times and the user will work out the rest. But spend any time looking at the interface methods and you start to see that while there’s a solution, it’s not as simple as it sounds.
The simple solution
In the HTML spec there’s a custom input type for date, time or date-time.
<input type=“date”> pushes the rendering of a date-time picker over to the browser. By pushing the layout decision on to the browser it allows for a device specific interface to be displayed. Browsers can render the best suited experience for the user based on the size of the screen and the input methods at hand. As you’d expect with anything dubbed as simple, browser support isn’t at 100% yet. Notable exceptions for IE11 as you’d expect, but also for Safari for macOS and Opera Mini not offering any support for the standard.
Considering that IE11 and Safari for macOS are still fairly widely used browsers, it’s time to enter the world of workarounds, polyfills and general compatibility woes. The input type will display what’s best for the devices, but when faced with no browser support we need to specify an input method, and we’ve got a couple of styles to pick from.
The first style is the mini calendar and my first stop on this quest was jQuery UI’s date-picker. A simple implementation makes it a go-to for lots of online date pickers, but if you put that solution on mobile you immediately start to see the flaws. Relatively small touch targets, combined with often layout-breaking (or mind-bending CSS effort to accomodate) styles.
Since this particular client has a more than fair share of use from mobile users, we needed to ensure that any solution was going to offer a great experience on mobile as a priority. Using the specific
date input type shows us the ideal interface, but in general when looking for inspiration for mobile interfaces there’s no better place that going to the settings app in iOS. It’s an app with almost every input method you can think of, combined with a utilitarian feel so you’re not lost in fancy animations and unnecessary style.
Mobile interfaces seem to have this brilliance at being able to handle long lists because of their narrow screens and inertia scrolling, but bringing this interface to desktop and you have an unwieldy list that no amount of mouse scrolling is going to help with. It can work best where you’re picking from perhaps the next seven days, but probably best to avoid this style on the desktop.
Manual typing of dates
Ditching the interface is actually entirely possible, depending on the task at hand. It’s something I considered for the contact form I was tasked with, since it would allow users to type pretty much whatever they wanted, and the end result would be read by a human it didn’t really matter if it was formatted or not. This idea soon became unravelled when our client suggested that he’d like the data input to a calendar for easier management – without the budget for a natural language processing engine we decided to just move on from this idea, but I can still see plenty of occasions where simplicity beats complexity.
The full solution
Given that the browser support for
date input types is fairly strong, the best full solution will be to use that combined with custom inputs for specific browsers – IE11 and Safari for macOS and any other desktop sized devices can be served using a mini-calendar, of which there are many ready made. Other mobile browsers won’t necessarily have support outside of the major browsers, so it’s worth including a work around with select-dropdown for day, month and year as necessary. With both solutions in place, it’s fairly simple to check support for input type and display the necessary input as required.
Of course not everyone wants the default styling, and with the native input types there’s option to style the input fields, so maybe all this is totally pointless and you want to go create a beautiful timepiece that’s going to sit as a proud accomplishment on your site. If that’s the case, I’m sure you already know a thing or two about user interfaces!