3

I am developing a very simple web app where, apart from other functions a user will see date and time in a small widget like so:

Time/Date widget

A user is also allowed to change the time and date. I looked at lots of (Angular based) Date/Time pickers and still can find a good design that works on both, web on desktop and web on mobile.

I currently ended up on using just an input field with an input mask. When a user hovers with the mouse over the time/date it will get underlined. But this might not be the best way for mobile.

To sum that up: Is there a better generic design for date/time pickers than using an input mask in an input control that works on both, desktop & mobile?

1

For the date, it depends on the context of what sort of dates people will be entering. If the date is around the present or near future, you can't go wrong with the tried and tested calendar picker. It's a widely used convention on iOS and Android.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

However, the potential range of dates could be much larger. For example, the user may need to enter their birthday, which could be many decades in the past. You haven't mentioned this as a requirement, but if it is, then an input field (masked appropriately) is the better choice for this. Using the date picker to choose a date many years in the past becomes very frustrating for the user.

For the time selection, again, input fields are probably the most easily understandable method. Just ensure to make the touch targets large enough on mobile - they could be a little small on the mockup you've provided above.

  • Regarding the date, this is a very good point. Actually, the dates that will probably selected are more in the near future. So a standard date picker should work here, right? I also find it very interesting to have different input methods for date and time. I didn't think of this. – Stephan Sep 17 '16 at 17:16
  • If the date is in the near future (say one year or less), then the calendar style picker should work fine. They work best when the user may not be exactly sure what date to enter - for example 'sometime in two weeks'. Another use case is when the day of the week is important - e.g. '2 Fridays from now'. Very easy with a picker. However, pickers are not as useful if the user knows exactly what date they want to enter (such as their birthday). The further back in the past this is, the more annoying this becomes. So, in answer to your question, like so many things in UX - it really depends! – Paj Sep 19 '16 at 15:56
  • Took me a while to decide what I'm doing. You explanation helped me a lot – Stephan Nov 1 '16 at 15:19
0

A variation on the (EDIT: stock calendar) date picker can reduce tedium enough to be usable: change the year independently, e.g.

< 2016 >
< August >

  • Could you please tell me what "stock date picker" is? Couldn't find a reference for that. Splitting up the year and month is a good idea I think. But there is also the day. Not sure if it is good to have 4 input fields available. Or did I misunderstood what you meant? – Stephan Sep 17 '16 at 17:13
  • Sorry, I mean the one illustrated by Paj. It's fairly standard, now. But the granularity is month-by-month, so it takes 12 clicks to go to the same month one year forward or back, which isn't good for far-ranging dates. But making the year a separate control means only 1 click per year is required. As far as input fields go, you'd only add 2 more buttons, and their use would be obvious. The nice thing about the calendar widget is that it only requires recognition, which is much cheaper than other cognitive operations. – MMacD Sep 18 '16 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.