So I'm not the only one.<p>It's not just limited to Safari. Any and every date picker that doesn't allow text input of the date is ridiculous, those of you that design these things that call yourselves designers should find a new career path, I recommend selling cologne out of your trunk at a gas station, and if you're involved in this blatant and hostile devolution of interface I hate your guts. This particular one is my number one hated trend in UX, by a high margin. It is the most absurd set of design decisions I have ever seen, I can't see how it would not be malicious, it shows disdain for your users and you should be ashamed of yourselves. Fix this one and then we can talk about the others.
Date widgets are almost universally bad. Most I encounter are unintuitive or outright buggy.<p>However, OP complaining about usability and the providing three text fields with the MM and DD being placeholders is terrible. Normally placeholder-only labels are a bad idea, but this is especially true when the month and day fields have different order depending on the region. The moment you've got [1] [4] [1980], you no longer know which is month and which is day.<p>And do they swap these placeholders and entered values if you change the country from US to an EU country?<p>The lack of progress in the tech world in making consistent user interface standards is disappointing. We should not be still struggling with these topics (and as users we should not be suffering). Tax time, trying to fetch reports from banks/exchanges is one of the worst recurring experiences...
Even if safari had the greatest date picker ever conceived, don't use date pickers for date of births. They will never be better or faster than typing your DOB. Pickers are best for choosing dates that aren't known ahead of time, or where you need to know how a date relates to week days / week numbers etc.<p>The proposed solution of using number inputs is also not great, since they have a host of accessibility issues [0] You want a regular text input with inputmode="numeric" and a pattern attr. This will give the correct numeric keyboard on mobile, and work just as well in desktop, without any of the associated issues.<p>I've built several date pickers, I know how hard they can be to get right. But they shouldn't bbw blindly used for any date value, they should be a deliberate choice<p>[0] <a href="https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/" rel="nofollow">https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-des...</a>
This is a curse of web design - you have to guess if it's clickable. You're not allowed to have boxes, or lines, or raised buttons. It's almost a dark pattern. It seems to be a holdover from mobile, where unmarked buttons were a thing, but the buttons were bigger and the UIs simpler. Now they've migrated to busier interfaces and become smaller.<p>Date pickers are terrible if not near the current date. Ones for long-term data sets where you set the start and end date are a huge pain. Like getting inflation data starting in 1960, or coronavirus data starting in 2019.
I have story about this one too. When I went to take a covid test ~1 year ago, they had an iPad for self registration near the reception. I filled it out, noticed this issue and sat down. An elderly lady came up and started going month-by-month back to her birthday year. I had to get up and help her.<p>It's crazy Apple hasn't fixed this.
The worst is when the date picker won’t let you select a date in the future, like a birthday, and so it’ll rubber-band your selection back to a valid date.<p>That’s all fine, except it does this validation on every change, rather than when the user has finished entering data. So if today is 27th Dec, and I wanted to enter 1 Jan 2000, I have to first change the year and only then is it save to change the day and month fields!<p>What’s worse is the year appears last/right hand side, so as we work from left to right the first thing the UI has you pick is the day, not the year. I simply cannot understand how these issues weren’t addressed before release.
I once developed an unusually complex HTML5 Offline app, and found that Safari even had <i>regressions</i> on some basic standard behavior that I needed.<p>I know there's good faith work around WebKit, etc., by smart and genuine people. But it was easy to wonder (especially with the anger that comes from being existentially threatened) whether some element at Apple wanted to make Web apps work badly, to keep the proprietary App Store party going.<p>(I did pull it off successfully, but only with much heroics.)
It took me a few seconds to parse the calendar view, but my first guess about where to tap was correct. And I expected the month and year rollers to move separately, which the article says is counterintuitive. But I don't own any devices that run Safari, so maybe it's inconsistent with the usual expectations of the interface?
Now it seems the date picker, like the Safari one, is just meant to let you pick a recent date; for a faraway date like DOB, the weekday does not actually matter, so it is easier to ask the user to type. Just some quick thoughts after reading the article and comments.
If you think Safari is the new IE, you have definitely forgotten (or not experienced) how bad things were with IE6.<p>They didn’t just have a few bugs in their browser implementation or were slow to implement new features.<p>Basic, crucial CSS features were broken. Microsoft didn’t add any new features to the browser about a decade, basically holding the entire web back to the standards of circa year 2001 until it was finally safe to drop support for it almost a decade later.<p>And furthermore, Microsoft weren’t pushing users to upgrade to the latest version, so we had to support older versions of IE long after their replacements were released.<p>I understand wishing that Safari would be better, but luckily the Safari team is much more on the ball than the IE team ever was.
I think there's a hidden issue there: it's 2022, almost 2023, and we still don't have standardized auto-fill forms. Browser auto-fillers somewhat work, but because every website is implemented so differently, I always end up having to type my address number or birthdate again.<p>I can't see why there isn't an standard semantic web standard for this. We shoukd standardise how common fields should be named and their datatypes set once and for all. Example: set on a field for month AND a field for day. No more MM/DD vs DD/MM issues. One-click and it's unambiguously filled by the browser. Seriously, what's preventing this from happening?
People remember their birthdate as a string of numbers.<p>So why use a date picker for this and not go with 3 number inputs which would be a lot easier to enter your birthdate in.
Date pickers are one of the worst interfaces on the web. Everyone seemingly has a wildly different design and they're almost always hard to use and unintuitive. And forget about if you're picking a date _range_
Call me an old curmudgeon, but the only place where date pickers make sense is in scheduling applications.<p>It is nice to see a calendar when picking a date for an Airbnb booking.<p>Picking a date for a future event is an entirely different use case than choosing a date in the past. The former is more of an exploratory activity; you are interested in things like the day of the week, proximity to holidays, availabilities, and all kinds of information, whereas a visual depiction of a calendar conveys valuable information, information that is entirely superfluous when picking a date in the past.<p>But registering dates is slow and cumbersome, more so if those dates are removed a few years ago, like DOBs and other similar kinds of dates.<p>Also, anything past the current month is a chore; manual input is usually faster and less error-prone.
The most straightforward solution I can think of is to split date inputs by context. Create an `<input type="dob">` that is tailored for picking a date of birth from 1900-today. "date" is too vague of a context to create an UX that works well in all the different contexts. It'll always be bad in some contexts, if it's trying to solve all the use cases.
Here's how the UK government website's design team recommends doing it: <a href="https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/" rel="nofollow">https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...</a>
The UK Design System, who is known to have high standards on accessibility, does it like this:<p>- Pattern: <a href="https://design-system.service.gov.uk/patterns/dates/" rel="nofollow">https://design-system.service.gov.uk/patterns/dates/</a><p>- Research: <a href="https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/" rel="nofollow">https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...</a>
Just never use date pickers for birthday but for short term date picking like scheduling an appointment.<p>Date input can be DD, month in textform drop-down, YYYY and you won't have any problems anymore.<p>I don't understand why it is so hard for devs, PO,... to understand this :)
Solution: add a transparent native date picker transparently fitted to a drop-down/calendar icon on the right of the inputs. Requires JavaScript to sync value between native date picker and the xx/xx/xxxx inputs, and it requires some CSS to make the picker “invisible”, and tabIndex to -1. This gives users access to their localised date picker (which can be really important), and may or may not help accessibility. Not DRY, but it solves a bunch of different problems on different browsers (e.g. you can’t tell if a browser has a broken date picker).<p>This technique also fixes the issue where a Safari Mobile date picker defaults to todays date, for example when using > to move through existing dates that are empty (clicking Done unobviously picks today - often not what you want). Terrible UI for fields like birth date or employment end date. Although depends a bit on whether a blank date makes sense.<p>Oh, and be <i>really</i> careful of type=number on Safari - it silently fails. inputmode=xxx can help, but it has weird differences between devices last time I looked (versions, Android, iPad etcetera). My mum repeatedly failed to enter a dollar value into a type=number, because she was entering a thousand’s comma (the UI showed $ and , everywhere for numbers so it is a sensible mistake to make; although Safari will display the entered number in the input field the .value==0 —— arrrgh silent failures are hideous).<p>I hate Mobile Safari - buggy, impossible to get bugs fixed, relatively poor standards support e.g. still need -webkit- prefix for some standardised CSS from a decade ago. Oh, and you end up with people using obsolete phones stuck on old Mobile Safari versions. Android updates Chrome even if it doesn’t update the OS (although Android also has the problem, it is less of a problem).
I absolutely cannot stand those scrolling selectors. They're a UX nightmare in every possible way - literally every one of them would be better replaced by either a normal list, or (when they're numbers) a number input field.
While I don't claim that Org mode's `org-read-date` is ideal, I have yet to see a better date input UI.<p>Also, ISO-8601 not being universally adopted is a shame.
If anybody else is now thinking about alternative possible designs and wants to explore the way different design systems do it:<p><a href="https://component.gallery/components/datepicker/" rel="nofollow">https://component.gallery/components/datepicker/</a>
Hell, I’m half as old as those customers and the date-picker is still annoying AF for birthdays or really anything that’s not this month. It’s just a shit design, likely created by some PM who couldn’t think beyond their weekly work meetings.
One interesting alternative (that I can’t remember actually encountering, but just occurred to me when reading this) would be to have an Age numeric field before the calendar, entry in which would jump the calendar to the corresponding birth year.
I built an example that uses separate select tags for year, month, day, and time.<p>The benefits of doing this are:<p>- Standard elements that work everywhere<p>- Easy to refresh the available options after a date change<p>- Mimics the "rolodex" behaviour to quickly find any date/time<p>The libs I used are arbitrary, won't be hard to rewrite using only built-in Javascript, or any library / framework<p><a href="https://www.mozey.co/demo/ts/examples/datepicker/" rel="nofollow">https://www.mozey.co/demo/ts/examples/datepicker/</a>
It's not just the date picker in Safari. iOS in general... I don't get it why I need to uninstall and reinstall an app from the app store when I want to clean the app's data like I can easily do on Android. Why is there no way to clean caches? Instead a big chunck of the storage is filled with "other system files". And the keyboard is so error prone as well, I always do spelling mistakes or need hours to type short texts. At least it's just my work phone...
The solution works until you expand beyond the US to people with sane date and unit convention :P<p>DD/MM/YYYY is the way<p>purely safari's fault, makes sense otherwise to have this on the browser side.<p>Next challenge: A sensible input for a date range with optional time of day. Have not seen a good one yet I think, especially when you try to correct your made input.
A different pet peeve of mine on iOS is the USSD menu which is center-aligned, and i find that very ugly. Maybe the usage of this menu isn't universal but for someone from a developing country, we use that like a million times a day. Mostly we are choosing a menu item to continue with a dialogue and the numbers are not aligned.
Every year I get progressively angrier as I have to scroll through a GODDAMN SPINBOX on my phone to select my birth year.<p>Spinbox is great if you need to increment like 5 items up or down. Not 30+ and CERTAINLY not starting at goddamn 1900 and making me scroll down nearly 100 entries.<p>People who do this need to go to jail. Forever.
Anybody going to address the elephant in the room that this startup is probably fraudulent and peddling pseudo science?<p><a href="https://geneticure.com/" rel="nofollow">https://geneticure.com/</a><p>Does anything they say read like it’s been backed up by peer review studies?
I’m shocked that there’s such a myopic view of “date” as a type in design that we don’t really see concepts such as “expected date range.” Am I expecting an input that’s years ago? Recent? The future? These would all be very different widgets if designed well.
As a long time Apple user, the solution advertised in this is actively worse. Typing in a date manually is absolutely slower than quickly flicking to the year and the month and then touching the date.<p>Please don't force users of mobile devices to type in a date.
I use a very simple drop down prefixed with ISO week numbers here:<p><a href="https://stay100.app" rel="nofollow">https://stay100.app</a><p>It looks simple and basic, but <select> works very well on all devices.
Color picker also. The crayon box is crap.<p>Honestly, this aspect of Safari's UI (the default form input widgets for complex values) is severely under-worked and in desperate need of an overhaul.
Android date time picker is also fancy but icky imho. I don't know how it performs though<p>Honestly , 3 select boxes are so easy to understand even if they are somewhat clutter
If I remember correctly WebKit replaced the 3-wheel date picker with this recently because people thought that was too skeuomorphic. Guess they can’t win?
It would be nice if Apple had like a DateKit or something that standardized and nudged developers to integrate natural language date entry across the OS.<p>It needs to stop being a blockbuster feature that lets companies/products like Fantastical that bait and switched their paid users limit their competition. If Apple can spend the amount of time on things like LiveText and their creepy NeuralHash program, they can take 5 seconds to implement easy date entry.
> I chalked up the "New IE" stuff to annoying little CSS issues<p>Here, too, Safari is the cause of 2/3rds of the lines of exceptional UI code now that Edge switched to a compatible render engine. Or blocks features altogether. All major browsers settled on doing things a certain way and then you remember that you always need to check Safari and of course they want it another way, so you get to re-do the work and duplicate your code with a comment "//because safari wants x to be done this way". I had less trouble with MSIE6 back in the day, though I can't rule out that I did less fancy things back then.<p>These things are not like "oops we render it differently by chance", it's conscious choices like not supporting SVG or being able to read file names in JavaScript (can't have javascript-based upload progress bars or local file encryption if you want to keep the filename; need to encrypt on the server and have the server report progress back via another channel).
The pick date widget is (at least for me) a solved problem: Use the jquery ui datepicker.<p>The fact that a lot of people prefer to avoid using jquery (for no particualr reason) and all its widgets and instead try to re-invent the wheel (in a much inferior way) blows my mind.
You can't really blame Safari for the fact you shipped a site that requires users to tap a button hundreds of times.<p>That tells me you didn't once use your site the way many of your users do. That's completely on you.
Talking about dates and Safari, be aware of this in JavaScript.<p>new Date('12-27-2022'); works in Chrome but returns an invalid date in Safari & FireFox.<p>new Date('12/27/2022'); works for all browsers.
I like this as an alternative<p><a href="https://github.com/mikepage/headlessui-datepicker">https://github.com/mikepage/headlessui-datepicker</a>
tl;dr elderly can’t find the year picker in the <i>iOS</i> version of the date picker pop-up.<p>I feel like the data is flawed. This is (supposedly) 1/3 of tech <i>issues</i> raised by customer support — how many of which are total?
Edit: I have removed this comment due to post-specific moderation downweighing.<p>Further reading<p>[1]: <a href="https://github.com/minimaxir/hacker-news-undocumented/issues/64">https://github.com/minimaxir/hacker-news-undocumented/issues...</a>
Some commenters seem to forget what the MSIE monopoly was all about. About not keeping up with emerging web standards? That's a misconception. That was a result of Firefox interrupting the market.<p>MS deliberately added non-standard crap to get everyone off the rails when not using IE. That's why websites often showed "Best viewed in 1024x768 and 16M colors using Internet Explorer".<p>And that is a remark I see more often every day. And it's Chrome being recommended.<p>Remember why MS switched from EdgeHTML to Blink? Because Google would hamstring EdgeHTML at every corner on their services. Not completely break it, but make Gmail or Youtube a tad slower than in Chrome.<p>"Don't be evil" my ass.
At this point, I am convinced, all datetime inputs should be done with just text input. The moment I figured out I can click the text to enter numbers manually on my phone's timer, I never tried to scroll the stupid rolling thing to get to the correct time.
I feel like this is such a silly post.<p>Using the date input field should always adhere to the UX of the browser OS.<p>If I'm on Android and I spend my whole life learning the UX of Android's date picker, wouldn't you want the web's date picker to follow the same UX?<p>This is less a problem the website should solve and more of a problem that end-users need to learn.<p>If my grandma doesn't know how to use a feature on her phone you bet she is contacting a family member first. Maybe we should encourage our family to use tools that they are proficient in...<p>I'm an iOS user majority of the time and it is very intuitive to tap the text with the > symbol. Like others state, Android's UX can be just as confusing.<p>I'd say you're following UX best practices and are supporting the native accessibility features of the phone so :shrug:... close and move on