Safari's date-picker is the cause of 1/3 of our customer support issues

safari.md

Safari's date-picker is the cause of 1/3 of our customer support issues

...and obviously we're building a workaround. But I'm absolutely flabbergasted that a standard <input type="date"> HTML field, in a standard browser, from a company that bases its reputation good design, could be so dreadful.

The context

I'm the developer for a startup that sells a genetic test to recommend medications for high blood pressure. For medical reasons we need to know our customers' birth date. Most of our customers are in their 60s or older. We've found that many of them use iPads or iPhones. And they're the ones who complain to our customer support that our site is unusable.

The problem

This is what pops up when you tap on a date field. Not bad... unless you're trying to pick your birth date, which happens to be in 1945.

There is no option to manually enter the correct date. The only obvious path forward is to tap the left arrow button 924 times to get back to 1945. The not-obvious path forward -- which our elderly users cannot find -- is to tap "December 2022", which pops open this rolodex-type thing:

This is also confusing because:

• You can't pick the day
• The months counterintuitively move independently of the year
• The need to swipe up and down on the "rollers" is not obvious to those who weren't born during the Digital Age

Our fix

Our fix was to spend a surprising amount of time fiddling with custom Django fields and widgets (ask me how I feel about Django/Python some time) to split the date field into three separate <input type="number"> fields:

It's not fancy, but it works. In fact, it works because it's not fancy.

UPDATE: Our fix, v2:

Thanks for the great feedback! Based on everyone's comments, here's how I've updated the date field:

That is: the month field is now a dropdown. Here are my thoughts:

• Use 3 separate inputs
  • Using a single text input with a required pattern, e.g. mm/dd/yyyy, would require our users to enter punctuation. That can be tricky on mobile devices, especially for nontechnical users like many of our customers. Also, it wouldn't really address the issue of people potentially confusing the mm/dd and dd/mm formats.
• For the month, use a <select> dropdown instead of a numeric input:
  • Differences in date formats (m/d/y vs d/m/y vs y/m/d) make it hard to distinguish numeric inputs for date and month, and a dropdown removes that ambiguity
  • There are only 12 options for months
  • Nobody really thinks of months as numbers anyway
• For the day, use <input type="number">:
  • Using a dropdown requires a JavaScript library to figure out which options are valid for which month, which IMO is unnecessary complexity in this case because our back-end will reject invalid inputs with a helpful error message
  • A great argument was made for using <input type="text" inputmode="numeric">. However, I'm going to continue with type="number" because:
    • The article largely addresses non-incremental numbers that are not "strictly speaking a number", e.g. phone numbers or credit card numbers. Days and years are incremental numbers.
    • This approach doesn't provide max and min. It does provide pattern, but semantically that is less correct when considering dates
• For the year, use <input type="number">
  • A dropdown here would require the users to scroll through 100+ choices. In this case, I think just typing it out is easier
  • Some users suggested setting a default value of e.g. 1960. However, I think that needing to delete that value and/or change it to the user's actual birth year would be an additional obstacle for our non-technical users.

Conclusion

I've heard that "Safari is the new IE", and don't personally care for the iOS UI. But I chalked up the "New IE" stuff to annoying little CSS issues, and expected that devices recommended specifically for the elderly would be usable by the elderly.

We haven't lost millions, or even thousands on this. If we were in a position to be losing that much we'd also be in a position to buy robust usability testing services, which probably would have caught this issue early. But small-biz developers should be able to be confident that usability testing for built-in web browser functionality is a nice-to-have, not a need-to-have.

I don't think punctuation is tricky at all. If a user owns or operates a "smart" phone they already use the functionality. We are just talking about two (2) dashes or forward slashes or even just space characters.

I'm not trying to disrespect the elderly here, but...have you ever actually watched an older person use a smartphone?

Furthermore, this suggestion introduces a wider margin of error, even without the dashes. What happens when a user accidentally mixes up month/day? Or an individual is from a region where days come before months?

What happens when a user starts trying to type out the actual month name or abbreviation and can't understand why they can't?

I think the current solution is the ideal...it restricts selections to specific data ranges and formats with almost no margin for error, and no ambiguity, while maintaining as much accessibility as possible.

Setting a default year is a problem—how would you be able to validate the field? If they just forgot to update it then the form would validate but with the wrong year. Leaving it blank is the only way to prevent form submission without a correct year.

And setting it to something closer to the expected years for the users doesn’t actually make it easier to use if it’s a number filed anyway, so they would still have to type the whole year regardless of how close the default value is—that would only help if it were a select.

I suppose you could pre-fill the “19” so they would only have to type the last two, but that just seems likely to cause a different kind of confusion, and then you’d run into a Y2K-style problem in a few years (not to mention it would mean nobody under 22 could use the service now).

What you came up with seems like a good workaround — certainly better than Safari’s which I’ll admit took me a bit if trial and error to understand fully, and I’m “young” and very technical.

As a person approaching "old" I can tell you it is a pain to have to spin back to 1954 just to prove I am over 21 for some reason. In many cases, it would suffice to have a checkbox to say, "I am over 21." Punctuation is possible on cell phones, but the marks are in different places from on desktop keyboards, just to confuse things. They are clearly labeled, but in 4 point type I can't see. And interfaces should always make it clear when something is a button. Just give me a hint! There is far too much weight given to design at the expense of function. If the app will be used by older people, make the interface larger.

Do you really need the day of birth? Do you even really need the month? One field for the year. Easy.

Nobody really thinks of months as numbers anyway

No. In many Asian cultures, months are simply named after the numbers in their native languages. To have to translate the months into their English names before selecting is more counter-intuitive to these people. If the target audience are people from these cultures, number inputs may be more intuitive. The same can be said about the native order of day, month and year in these cultures.

Fully agree @glsee. But more generally, assuming that people use anything some certain way is likely not going to work for a large number of users. Software allows for hyper scale/leverage, so making blanket assumptions is almost surely a recipe for disaster for many users (and the support team).

Also, almost surely is a probability joke for those travelers versed in the field.

I'm not trying to disrespect the elderly here, but...have you ever actually watched an older person use a smartphone?

Yes.

If they don't want a smart phone they'll get and use a flip phone. If an individual has a smart phone and do not know how to use it, just to input 6 to 8 digits they should not be filling out forms on that device whatsoever.

Furthermore, this suggestion introduces a wider margin of error, even without the dashes. What happens when a user accidentally mixes up month/day? Or an individual is from a region where days come before months?

The same as above applies.

If people are too incompetent to fill out a form on a specific device they have no business filling out the form on their device.

The very simple solution for online is just use three (3) inputs.

Conspicuously put your phone number on the site for individuals to call and verify with an actual human.

This link might be of interest if you haven’t already seen it.

I'm a big fan of 3 auto-complete inputs, implemented with https://selectize.dev/

Screen.Recording.2023-01-08.at.09.38.41.mp4

Now I see why auto-filling of forms does not work. Fancy controls! 😈

We have a standard format for dates, ISO-8601, why people keep coming up with new (old) formats?