←back to thread

Pikaday: A friendly guide to front-end date pickers

(pikaday.dbushell.com)
286 points mnemonet | 3 comments | 11 Nov 25 14:58 UTC | HN request time: 0s | source
Show context
abanana ◴[11 Nov 25 21:59 UTC] No.45893468[source]▶
A few years ago I wrote a mobile app for use by patients of local doctors' surgeries. This meant a higher-than-average proportion of older, less tech-savvy users.

There was a flood of complaints about the OS-native date pickers, along the lines of: "There's no way to set the year! To get to my birth year, I had to tap the previous-month arrow 720 times!" (It seems people actually did this.)

This is what happens in the real world when Flat Design takes over UI controls. On both iOS and Android (a few years back, I don't know whether they've been improved now), the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element.

Now that mobile OS UI decisions are seemingly led entirely by aesthetics, instead of being run by a seasoned UX researcher like Don Norman, using an OS-native datepicker leaves the usability of our apps entirely at the mercy of what they choose to mess up next.

I used Pikaday on a few websites years ago. We're told these tools are now obsolete - I wish that were true.

(Changing the app to use textbox-dropdown-textbox for date-monthname-year - this is in the UK - stopped any further such complaints.)

replies(5): >>45893504 #>>45893624 #>>45899065 #>>45902020 #>>45903234 #
padjo ◴[11 Nov 25 22:15 UTC] No.45893624[source]▶
Why were you using a calendar picker for a date of birth?
replies(1): >>45893751 #
abanana ◴[11 Nov 25 22:27 UTC] No.45893751[source]▶
Could you explain what you mean? We're talking about the OS-native datepicker, which pops up when a user clicks on an HTML <input type="date">.
replies(2): >>45894468 #>>45897754 #
padjo ◴[12 Nov 25 08:34 UTC] No.45897754{3}[source]▶
Using a calendar picker to input dates that users have memorised and are in the distant past is an awful experience. This is a pet peeve of mine.
replies(1): >>45898687 #
1. abanana ◴[12 Nov 25 11:00 UTC] No.45898687{4}[source]▶
I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for <input type="date">. Their purpose is to enter a date. That's why their use in this way is absolutely standard (far more so than the term "calendar picker" as far as I'm aware. The user's not choosing a calendar, they're choosing a date). That doesn't mean the choice of input method can't be improved, but highlighting it as a pet peeve won't make it happen at scale. What do you suggest instead?

The answer shouldn't be "create something custom for entering dates that don't happen to be in the current year", it should be "fix the datepicker so it's fit for purpose".

replies(2): >>45898941 #>>45899409 #
2. badestrand ◴[12 Nov 25 11:40 UTC] No.45898941[source]▶
I am so glad that so many people in this thread confirm how bad the native date pickers are; i thought I was alone.

Just picking the year is so difficult already on both Android and iOS as well as desktop Chrome, so a custom widget is immediately 100x better.

Yes, in theory it would be best to display the native picker because in theory it has a great UX, but in practice the native browsers' implementations are mostly just really, really bad, for whatever reason.

That's what I really dislike about the linked article - it doesn't even check the native implementations for their quality but just argues as if they are great.

3. padjo ◴[12 Nov 25 12:37 UTC] No.45899409[source]▶
Ideally there would be an input type for this, month comes close to the correct UI on iOS but has lots of problems. I don’t think the calendar picker style will ever work well for entering birthdays and such, so yeah the answer is build your own thing or use a library.