> "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
~ Douglas Adams
Pikaday: A friendly guide to front-end date pickers
121–130 of 146 posts
Re: Pikaday: A friendly guide to front-end date pickers
#122A 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 year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element.
IT IS TAPPABLE???
Re: Pikaday: A friendly guide to front-end date pickers
#123Earlier 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.
They did some research elsewhere on dropdowns and found a lot of users do not realise they can scroll through the list and would get confused, might be why they ruled out dropdowns entirely for date pickers.
Re: Pikaday: A friendly guide to front-end date pickers
#124Earlier 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'm always confused by the anglocentrism of these kinds of ux "standards" because for example in mandarin we call days (三號）, weekdays （星期二 / 禮拜二）, months （二十月）, and years by numbers... And in Japanese they have similar I believe but also have non numbers for weekdays. I imagine other languages have similar flukes, wouldn't be surprised if there was one out there that had special words for the first couple days of the month or something.
Re: Pikaday: A friendly guide to front-end date pickers
#125Earlier quoted context omitted.
That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain. Take the UK for another example. The daylight savings dates are actually set by act of parliament…
ISO 8601 only allows timezones as offsets, not as locations. If it allowed "Africa/Cairo" instead of "+0200" that would be fine. > they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all. That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
There's an extension to ISO8601 that fixes this and is starting to become supported in libraries:
2019-12-23T12:00:00-02:00[America/Sao_Paulo]
Re: Pikaday: A friendly guide to front-end date pickers
#126It is refreshing to see a date picker that the user knows how to enter date with their keyboard. Defaulting to custom UI for date/time pickers is so bizarre. My favorite (/s) is when you're using an android and you get the web mocked version of an iOS time picker where you have to rotate wheels???
Re: Pikaday: A friendly guide to front-end date pickers
#127A 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/
> Ultimately they found the best experience was three text boxes, day, month and year
This is what we found was most acceptable for our banking users. They were coming from terminal interfaces. This is a UI/UX flow that we just had to go with. We experimented with fancy date pickers (i.e., ) and it lasted about a month before we were forced to refactor. We kept a date picker icon (exempt from tab order) for novice / younger employees who prefer the tap-tap-tap bs.
If you are replacing a mainframe app with something on the web, the least you can do is make a half-ass attempt to keep the # of physical fields the same and place them in the same tab order. This can make or break your pitch in a competitive B2B SaaS environment. We sold to the users, not to the business. The users then sold to the business for us. You cannot get end users to help sell for you if they don't like the UX. They know they'll have to live with it every day if they successfully advocate for it.
Re: Pikaday: A friendly guide to front-end date pickers
#128It's funny to talk about internationalization but only support Western date format.
If you are managing hospital admissions in Nepal, you have to be able to provide the date in Nepalese calendar and in the common one. And believe me, the Nepalese calendar is a complex one.
In Ethiopia, you'll have to support 13 months but they'll be close enough to common dates that people will manage mentally. But imagine that you have to handle a quarter of 4 months, one of which is 5 or 6 days long.
If someone has a good reference for a properly international picker, I'm all ears.
Re: Pikaday: A friendly guide to front-end date pickers
#129A 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…
I feel like I have had trouble figuring out how to jump years in those too!
Re: Pikaday: A friendly guide to front-end date pickers
#130Earlier quoted context omitted.
Doesn't the browser automatically a handle locales when using the HTML5 input=date?
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.
I am thinking about locale of how a date/time is formatted for display/input. Including language-specific month names etc.