Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pikaday: A friendly guide to front-end date pickers

pikaday.dbushell.com

Post reply on HN
Print view View original

101–110 of 146 posts

Re: Pikaday: A friendly guide to front-end date pickers

#101

Post by badestrand »

mattmanser wrote: post #84
Telaneo wrote: post #69

Earlier quoted context omitted.

> ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking. Why is this the case? Is it some time zone shenanigans?

Timezones change, more frequently than you realize. Some countries even used to change when summer time started regularly. It's got better than it used to be afaik. Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location. Book me a table at 8, means book me a table in Berlin time at 8, not in San…

This has nothing to with the dates being in the future and only with convention and labeling the field correctly.

And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.

Re: Pikaday: A friendly guide to front-end date pickers

#102

Post by HugoTea »

abanana wrote: post #38

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 th…

The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date... Ultimately they found the best experience was three text boxes, day, month and year. They also have this "pattern" for helping with implementation https://design-system.service.gov.uk/patterns/dates/

Re: Pikaday: A friendly guide to front-end date pickers

#104

Post by sedatk »

1718627440 wrote: post #96
sedatk wrote: post #83

Earlier quoted context omitted.

I don’t think there’s a browser setting that lets you use the locale the web site’s language in, is there?

You set all the language you want with priorities and the webserver knows it's own language and serves you the intersection with the highest priority. Or do I misunderstand your question?

I mean the locale, not the language. Many web sites are in a single language and target a specific culture. I want that to be respected by the browser for input type=date and other similar elements based on web site’s language, not the other way around. That’s my preference.

Re: Pikaday: A friendly guide to front-end date pickers

#105

Post by padjo »

abanana wrote: post #95
padjo wrote: post #87

Earlier quoted context omitted.

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.

I think your point is just emphasizing how bad these native datepickers are. They are specifically used by the browsers for . 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 highlig…

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.

Re: Pikaday: A friendly guide to front-end date pickers

#106

Post by 1718627440 »

sedatk wrote: post #104
1718627440 wrote: post #96

Earlier quoted context omitted.

You set all the language you want with priorities and the webserver knows it's own language and serves you the intersection with the highest priority. Or do I misunderstand your question?

I mean the locale, not the language. Many web sites are in a single language and target a specific culture. I want that to be respected by the browser for input type=date and other similar elements based on web site’s language, not the other way around. That’s my preference.

What your browser calls a language, is in fact a locale. You specify en_US, not English.

That would be equivalent to no setting a preferred locale or adding all the available locales.

Re: Pikaday: A friendly guide to front-end date pickers

#108

Post by abanana »

HugoTea wrote: post #102
abanana wrote: post #38

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 th…

The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date... Ultimately they found the best experience was three text boxes, day, month and year. They also have this "pattern" for helping with implementation https://design-system.service.gov.uk/patterns/dates/

They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.

Re: Pikaday: A friendly guide to front-end date pickers

#109

Post by tlamponi »

padjo wrote: post #88
tlamponi wrote: post #75

Earlier quoted context omitted.

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.

That is called input assistance, confusing it with validation is the source of millions of security problems.

No, it's not. And if that's what confuses one, it will not be the actual source of these problems.

Re: Pikaday: A friendly guide to front-end date pickers

#110

Post by joelanman »

abanana wrote: post #108
HugoTea wrote: post #102

Earlier quoted context omitted.

The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date... Ultimately they found the best experience was three text boxes, day, month and year. They also have this "pattern" for helping with implementation https://design-system.service.gov.uk/patterns/dates/

They don't appear to have tested a dropdown for the month name, with text boxes for date and year. I've read elsewhere in UX research that the month name should be preferred, for clarity, over entering another number. So it's unfortunate that that page's research isn't complete ("we will continue our testing") and doesn't appear to have ever been followed up.

(I worked on this pattern) Our guidance is to accept both names and numbers in the back end so people can enter either. In our testing, text inputs (with a numeric keyboard on mobile) is better than selects. Some people struggle with using selects, we don't see those issues in text inputs. That guidance maybe be about people not knowing the order of the inputs (DD MM YY, MM DD YY) but our pattern is clearly labeled for each input so we don't get that issue.

We did continue our testing which resulted in the pattern in the design system which is linked.

Post reply on HN