4 ms·

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 user

by abanana 11mo ago

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.)

bigfudge 11mo ago
It’s not just old people that suffer. I’m slightly ashamed to admit I started the 100-tap process when I first used that input before realising it was dumb and googling what to do. They really are bad.
padjo 11mo ago
Why were you using a calendar picker for a date of birth?
- abanana 11mo ago
  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">.
  - folmar 11mo ago
    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.
    - nozzlegear 11mo ago
      Doesn't the browser automatically a handle locales when using the HTML5 input=date?
      - folmar 11mo ago
        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.
        jrochkind1 11mo ago
        I am thinking about locale of how a date/time is formatted for display/input. Including language-specific month names etc.
    - dotancohen 11mo ago
      Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.
      - tlamponi 11mo ago
        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.
  - padjo 11mo ago
    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.
    - abanana 11mo ago
      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".
      - badestrand 11mo ago
        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.
      - padjo 11mo ago
        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.
HugoTea 11mo ago
The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/ 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/ https://design-system.service.gov.uk/patterns/dates/
- abanana 11mo ago
  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.
  - joelanman 11mo ago
    (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.
    - hunter2_ 11mo ago
      I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit. The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.
NooneAtAll3 11mo ago
> the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element. IT IS TAPPABLE???
jrochkind1 11mo ago
I feel like I have had trouble figuring out how to jump years in those too!
vintagedave 11mo ago
> a seasoned UX researcher like Don Norman I get a real sense from some UX designers that following what he says is uncool. The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.
- abanana 11mo ago
  Yes, I totally agree. I've seen a few youngish graphic designers calling themselves "UX designers" even though they have zero learning, experience, or apparently knowledge in UX. They're just copying fashions they think are "cool" while genuinely thinking they're doing something clever. They gave me the impression that they simply don't know UX is a discipline of its own with a long history of actual user-centric research. It's a form of arrogance, determined they know best. On the rare occasions that they get to the feedback stage (rather than just rushing on to the next project), they've acted stunned when they realised that people have difficulty using something they designed, and they were absolutely determined that the user in question must be incredibly stupid. Thoughts of the usability of what they've built don't even enter their mind. I'd like to hope these people are in the minority, but when I see poor user interfaces in so many different places, I'm not so sure.

by abanana 11mo ago

bigfudge 11mo ago

It’s not just old people that suffer. I’m slightly ashamed to admit I started the 100-tap process when I first used that input before realising it was dumb and googling what to do. They really are bad.

padjo 11mo ago

Why were you using a calendar picker for a date of birth?

abanana 11mo ago
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">.
- folmar 11mo ago
  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.
  - nozzlegear 11mo ago
    Doesn't the browser automatically a handle locales when using the HTML5 input=date?
    - folmar 11mo ago
      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.
      - jrochkind1 11mo ago
        I am thinking about locale of how a date/time is formatted for display/input. Including language-specific month names etc.
  - dotancohen 11mo ago
    Date picker widgets do not solve any validation problem, because validation happens on the server side and client input is not to be trusted.
    - tlamponi 11mo ago
      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.
- padjo 11mo ago
  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.
  - abanana 11mo ago
    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".
    - badestrand 11mo ago
      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.
    - padjo 11mo ago
      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.

HugoTea 11mo ago

The Gov.uk design team published research around data entry for dates https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/ 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/ https://design-system.service.gov.uk/patterns/dates/

abanana 11mo ago
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.
- joelanman 11mo ago
  (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.
  - hunter2_ 11mo ago
    I'm not sure of every type of trouble folks might have using selects, but for the subset where using a hardware keyboard is required, you can usually type into a focused select just as you can type into a text input. Getting an Android/iOS on-screen keyboard to do this without a special configuration might not be a thing, I'll admit. The only tricky part, for me, is deciding whether I should type a state abbreviation or a few letters of the full state name, which in my case differ enough to be quite annoying.

NooneAtAll3 11mo ago

> the year just looked like a heading. Nothing whatsoever suggested it was a tappable UI element. IT IS TAPPABLE???

jrochkind1 11mo ago

I feel like I have had trouble figuring out how to jump years in those too!

vintagedave 11mo ago

> a seasoned UX researcher like Don Norman I get a real sense from some UX designers that following what he says is uncool. The vibe I get is one of how some people don't want to follow older people, with that 'we will do what we think best' sort of attitude. As thought UX is based on fashion not on concrete principles.

abanana 11mo ago
Yes, I totally agree. I've seen a few youngish graphic designers calling themselves "UX designers" even though they have zero learning, experience, or apparently knowledge in UX. They're just copying fashions they think are "cool" while genuinely thinking they're doing something clever. They gave me the impression that they simply don't know UX is a discipline of its own with a long history of actual user-centric research. It's a form of arrogance, determined they know best. On the rare occasions that they get to the feedback stage (rather than just rushing on to the next project), they've acted stunned when they realised that people have difficulty using something they designed, and they were absolutely determined that the user in question must be incredibly stupid. Thoughts of the usability of what they've built don't even enter their mind. I'd like to hope these people are in the minority, but when I see poor user interfaces in so many different places, I'm not so sure.