Most active commenters
  • padjo(4)
  • abanana(3)

←back to thread

Pikaday: A friendly guide to front-end date pickers

(pikaday.dbushell.com)
286 points mnemonet | 16 comments | 11 Nov 25 14:58 UTC | HN request time: 0.002s | source | bottom
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 #
1. 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 #
2. 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 #
3. folmar ◴[11 Nov 25 23:45 UTC] No.45894468[source]▶
This is the place where the date picker does not help the user at all. It's easier to type the, presumably memorized, date, than to look it up in the calendar no matter how nice and handy the calendar is. Sure it does solve validation problem. Or maybe not correctly, don't ask about locales and date adjustments.
replies(2): >>45894690 #>>45894825 #
4. nozzlegear ◴[12 Nov 25 00:10 UTC] No.45894690{3}[source]▶
Doesn't the browser automatically a handle locales when using the HTML5 input=date?
replies(1): >>45895355 #
5. dotancohen ◴[12 Nov 25 00:26 UTC] No.45894825{3}[source]▶
Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.
replies(1): >>45896811 #
6. folmar ◴[12 Nov 25 01:28 UTC] No.45895355{4}[source]▶
Even if, that does not help. When asked for a birthday I need validation of the date in country when I was born, not the country I'm in, not the locale I'm using for display and not the locale server/requesting company is in.
replies(1): >>45903259 #
7. tlamponi ◴[12 Nov 25 05:58 UTC] No.45896811{4}[source]▶
Obviously, but additionally, providing validation on the frontend can help UX a lot. Doing that can provide much quicker feedback compared to an error thrown at the user only after submitting a form, which can get especially annoying if the latter loses (some of) its values due to submission. And one solution for that problem can be using a native picker.
replies(1): >>45897760 #
8. padjo ◴[12 Nov 25 08:34 UTC] No.45897754[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 #
9. padjo ◴[12 Nov 25 08:36 UTC] No.45897760{5}[source]▶
That is called input assistance, confusing it with validation is the source of millions of security problems.
replies(2): >>45898678 #>>45899634 #
10. __jonas ◴[12 Nov 25 10:58 UTC] No.45898678{6}[source]▶
That’s an interesting suggestion, but it is not, it’s called (client side) form validation

https://html.spec.whatwg.org/multipage/forms.html#client-sid...

I definitely see your reasoning for wishing it had a different name though.

replies(1): >>45900836 #
11. abanana ◴[12 Nov 25 11:00 UTC] No.45898687{3}[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 #
12. badestrand ◴[12 Nov 25 11:40 UTC] No.45898941{4}[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.

13. padjo ◴[12 Nov 25 12:37 UTC] No.45899409{4}[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.
14. tlamponi ◴[12 Nov 25 13:03 UTC] No.45899634{6}[source]▶
No, it's not. And if that's what confuses one, it will not be the actual source of these problems.
15. johnisgood ◴[12 Nov 25 14:43 UTC] No.45900836{7}[source]▶
I do understand what "client-side" validation is, but I wish it had a different name, because people think they can just validate client-side and they do not bother doing it on the server... for some reason, I do not know. It should be obvious though, right? Yet it is not.
16. jrochkind1 ◴[12 Nov 25 17:50 UTC] No.45903259{5}[source]▶
I am thinking about locale of how a date/time is formatted for display/input. Including language-specific month names etc.