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.
Thank you, so much for pointing this out so succinctly. I'm a 59 year old engineer (originally electrical, but got a bit into software engineering and have been doing enterprise network and security design deployments for the last 30 years). With very aged parents and a mother-in-law all over 85, I have more and more become aware of the absolutely horrible user interfaces that abound all over the place. Smart phone and web based offerings to do basic tasks of interacting with government, bank, shopping and similar services literally are unusable in many if not most cases for most over 70. ( My loved ones all have used PCs since the 1990s). Banners blot huge chunks of screen real estate, metaphors for selection and entry of data change within a services pages let alone between them, active screen objects may as well be hidden.
When I retire from full-time work, I almost feel like I should make it my mission to front up to these organisations and "pretend" I'm their typical user or customer that they are not serving very well at all, and put a rocket up them demanding why with all their technical and designer resources they should have at their disposal why they can't provide a useful and satisfying user experience.
> Smart phone and web based offerings to do basic tasks of interacting with government, bank, shopping and similar services literally are unusable in many if not most cases for most over 70.
been working on the web for ~20 years now. the amount of debugging, switching devices, just general hacks i need to do in order to interact with certain websites is a bit crazy:
- open my desktop browser
- open a specific browser
- disable all extensions
- open a new private tab
- inspect element with the dev tools
- js breakpoints and fixing minified js code on the fly
- removing or adding css
- allow location/camera/etc permissions
all so that i can press a button on a website :))
i’ve always worked in small teams. and we always tested on all the browsers, on all the devices. manually and automatically. and this is every time we deployed.
how some of these broken websites get to see the light of day is just unreal.
huge, big, small, all of them, startup, fortune 500, international bank, local government services. errors occur due to a huge number of reasons: ISPs, lack of testing, connection issues, outdated tech, cdns, certificates, javascript, js minifiers, assumptions made by devs/po’s. basically the web is so huge and complex that websites will fail in any random number of ways.
If you created a document of design guidelines that you could simply link in response to posts like this, it might actually go a long way. I would be glad to read about what you’ve learned about user interfaces and the considerations necessary to include the elderly with regards to accessibility, and would certainly bookmark it / utilize it / consider it when creating UI. I’d imagine others would also.
If anyone else has such a thing, I would encourage you to share.
The original Human Interface Guidelines from Apple were the golden example of good design. Research-based concrete rules for everything (including designing custom UI elements), resulting in a coherent and useable GUI UX.
What should really happen is putting these "designers" into the helpdesk seat. Or at the very least have them observe how people use their designs and they are not allowed to interfere. It will be a painful lesson for them. But as long as these things don't happen, we will be stuck with this major suckage that is modern UI.
I remember the time when we would pay for software and expected quality in return. Nowadays it's either free (sponsored by ads and or surveillance) or bundled with hardware to be abandoned when the manufacturer wants money again.
Gut reaction: Designers blaming a serious percentage of users are obviously working for a company with users who are a poor match for their skills. Management should "encourage" them to move on, to other companies, whose users would let them really shine.
> What should really happen is putting these "designers" into the helpdesk seat. Or at the very least have them observe how people use their designs and they are not allowed to interfere.
The fact that this isn't natural standard practice speaks volumes to the current state of """UI design""".
I wonder if you could actually rather quantify date related errors by analytics. I actually booked the wrong return flight once because the date picking logic was too intelligent for me. There should be many signals pointing to this.
Any user who designs something like this that doesn't realize the number of mouse clicks needed to navigate this interface doesn't need to be a designer. Helpdesk experience won't save them, they're either bottom of the barrel incompetent or outright malicious. I could understand if it were something more complicated, but there's no excuse for this stuff with date pickers.
At a certain point companies employ "experimentation" (mainly A/B tests) to do exactly this. They measure dropoff and other things, and have targets, e.g., "acceptable dropoff" or whatever they might term it internally. That small amount of user loss (fraction of a percent to a few percent depending on feature/daily usage/other metric) due to a design is considered acceptable: not that they don't care, it's just not considered impactful enough to the business to matter.
Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:
1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").
2. The textbox should be selected and ready to type into as soon as the datepicker is opened
3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession
4. There should be a typical month view with days of the week visible, in case I'm on mobile
5. The current date should be highlighted on the month view.
6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.
Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.
In my web apps, I make dates text boxes that can handle inputs like “next Thursday”, “Monday at 5p”, etc by running the inputs through https://github.com/mojombo/chronic
I like the idea of inputs being able to make sense of as wide of a variety or formats as possible.
For number inputs I’d like to build into Rails something that can handle basic math expressions. For example, a person can enter “120 / 2” in an input and get 60. This is useful for expense apps where you need to expense half of something.
If folks are interested, I can open source these bits. I’d like to expand them as much as possible to handle an even wider variety of inputs.
That's a cool library. I note that WolframAlpha handles this type of stuff readily. Does anyone ever bundle Wolfram products into theirs to handle natural language type things? I'm not immediately sure of the licensing framework, but it would seem nice to be able to do that.
Edit: It seems that WolframAlpha does have an HTTP API.
Embedding wolframalpha is probably overkill, when all you need is simply a small arithmetic expression parser and to understand expressions like "next month" or "2 days ago", which even tools like GNU date support.
I quite like the iOS time picker, but agree the analogue clock style that I think Android popularised is awful. The iOS one also gives a number keypad if you tap the wheels so you can enter that way if you prefer. It’s a shame they don’t do anything similar for dates.
I've never see the analog style clock one before, wow that is garbage. I'm not a fan of the iOS style time 'reels' either, but like you say, at least it opens a keypad if you click on them.
To break down why this picker is bad, here are several UX snags I immediately ran into.
1) It was not obvious how to set minutes, and I spent several seconds trying to get the hour hand to go in between hours.
2) When I let go and it snapped to minutes, it was not obvious to me how to go back and change the hour I had just input incorrectly. Then after I input minutes I expected it to jump back to hours but it didn’t. This is especially bad if your first interaction is a single touch rather than a press and hold, as it will jump with a wrong input and no obvious way to go back before you can even process how the interface works.
3) I have to look at different areas at the same time to select a time. My finger is trying to scroll a circle (where btw my finger covers the number), but I have to look above to see what the input is.
4) The above was even trickier in the minutes inputs, since there were not markings for sub-5 minutes.
5) It was not obvious that the top bar was clickable as an input area to select am/pm, especially since clicking the top bar would not otherwise allow you to input the time.
6) It’s not obvious with the switch to minutes / seconds that the units have switched. Need some representation of this on the clock face itself.
Some major ticks on all inputs and minor ticks that pop up on the minutes input would help a lot with 1, 4, and 6. Could be subtle markings, but would help quite a bit imo. But really this didn’t need to be anything other than a simple text input.
Those aren't so bad, they're reasonably intuitive to anyone who knows how to read an analog clock, and though they're easily fat fingered, you do one click for hour, one for minute and AM/PM in the non 24h versions. Imagine a scrolling time picker where you couldn't scroll the hours, only the minutes. That's what common date pickers are like.
I'm still perplexed that this isnt how every website works.
The absolute worst are date pickers that grey out unbookable dates to look like past dates and default to one week from now, leading me to believe, if I'm not careful, that Im booking a ticket for today.
Seemingly no website that lets you book things has sensible date UX.
Some of these are really great ideas! But I think they should be relegated to an external library or perhaps a web component. The issue here is this is the HTML datepicker. The picker itself isn't well-defined but things like being able to type in human-readable data/time and having it interpret that would likely conflict with the HTML standards already defined and be extremely difficult to define further. Not to mention you could only really do something like that on desktop and the issues pointed out in the post are dealing with mobile date pickers
Very nice site. I was clicking around trying to find a sample of your date-picker and noticed that the "Free Courses" link is not working properly. I believe it is treated as a relative link as it takes me to:
Programmers and UI designers should observe there two common use cases:
1: dates close to the current date, such as flight dates, meetings, delivery dates.
2: birth dates and similar (wedding date, start of employment), often a long time ago.
For “near future” dates, date pickers are somewhat handy because you can see the day of the week, and glance the number of days compared to other dates.
For date of birth, date pickers are useless. You don’t need to pick anything, you will just know it by heart in most cases and you can type it fast enough.
Programmers like date pickers, because you can’t choose nonexistent dates, you can’t confuse day/month number, and you can’t enter ambiguous 2 digit years. And they like consistency, so the same design is used for all use cases.
I think it's just Chrome and Safari's mobile versions that "don't allow" text input. And they actually do allow it. But most users don't have a keyboard hooked up to their phones
The issue is that with mobile something has to pop up. So browsers need to make the decision between an onscreen keyboard or the built in pickers (this holds for color pickers as well)
If web developers don't want any of this, they could always just use `type="text"` instead of `type="date"`, but this leads to other accessibility issues and means you have to write a ton more code for proper validation
Yeah, but from a user perspective text is superior to date. I don't even know a non technical person that doesn't curse under their breath when a date picker pops up.
A simple "date (DD/MM/YYYY)" or similar format above a text field is a blessing these days, but I'll take anything over a date picker. A good date picker would let the year drop down somewhere, show calendar view, and allow text input of the date. That's the minimum requirements, a month drop down would be nice too. Sometimes I run into date pickers that have some unintuitive way to page years, one click at a time of course, and while I dislike that, at least I can move back by a year, it doesnt ruin my day. Imagine someone deciding that to input the exact time of something you'd select a drop down containing Unix timestamps, one option for each second, that's probably the only thing I can think of that would be more frustrating and senseless than the current state of affairs, and even then perhaps not because at least it's a dropdown you can scroll on. Literally a scrolling dropdown of all dates back to 01/01/1900 would be a superior UX to the current common date picker design.
> I don't even know a non technical person that doesn't curse under their breath when a date picker pops up.
I used to designed software for factory automation and every time there’s dates involved the datepicker is always an explicit requirement. I tried to ignore that once (they were more annoying to implement back in the days) and the plain text field didn’t even get past the first meeting. I guess “non technical person” is not as coherent a group as you may imagine.
> Yeah, but from a user perspective text is superior to date
Hmm I'm not sure if that's always true for mobile users (the subject of this post). Given any default starting date, I can enter in my DOB in:
- 1 tap
- 2 swipes
- another tap
If I was instead presented a keyboard I'd have to make 8 taps. 9 if I count having to switch from abc to 123. And this is under the assumption that the text field has an input mask built-in so I don't manually have to type the separators. If I did have to type those this would be bumped up to 11 taps
I agree with you on desktop though. But the thing is, that already is the way it works on desktop. You can ignore the calendar picker and just type it in directly. It actually works that way on mobile too, but most people don't have a keyboard plugged into their phones
Lol the crux here is "swipe to your year". This could be 100 swipes or more. This should not be the standard way you select a number from a sequence of numbers, it is insanity. But even that is better than the common approach which only let's you swipe months.
I've seen it on desktop as well as mobile, I've seen it implemented in JS and not just an HTML5 problem, so there are no excuses, but on the topic of mobile, I have a keyboard that pops up just as quickly as a calendar view, even with the argument that most people prefer to use their phones graphically and spatially (which I don't entirely buy), there's no reason to prevent me from typing in a 4 to 8 digit number if I want to, none. UX design is not just an issue of number of taps, it's an issue of cognitive load required for interaction also, both considerations can introduce or reduce friction, and in the case of a commonly implemented date picker you have artificially introduced friction from both of those considerations, it's a devolution in design, plain and simple.
The issue is that with mobile something has to pop up. So browsers need to make the decision
Back in the day we had buttons in inputs, so a user could either click on white to enter the text or click on a button to see a picker/something. Same goes for type-or-choose comboboxes, search-or-choose object picker fields, type-or-calculate numeric fields and so on.
In addition to that, specifically for date fields in inhouse systems I’ve often added a popup button with most obvious starters. E.g. some reports assume days around today and some are mostly month-oriented, so a popup contains “today (<date>)”, “yesterday”, “start/end of week/month/quarter”, some combination of these. And also “+/- <unit>” buttons to quickly adjust a period in case they changed their mind. Users were happy. Good luck choosing a previous quarter and narrowing into it with these modern ui abominations.
It’s not a mobile issue, it’s an issue with stupid decisions around “stupid” users who still don’t get it, as all our occasional tests on eldery show. These ui patterns are designed for someone who never existed irl.
And what’s worse, these uis are not forced to use by those very designers. We could see a great improvement if they were forced to sensibly pick 50 random dates and other fields before collecting their paycheck.
In the 21st century, every date picker should be able to accept both mouse and keyboard input and be very permissive about what is allowed.
There should be a text box I can just type "January 1 2022" or "2022-1-1" or "4/20/69" into, and it just figures it out (with a disambiguation dialog and 'save as default' popped if I feed it something ambiguous).
But that’s exactly the problem. A good website employs an “international-first” approach. As such, having such lenient formatting can be a compounding problem pretty quickly as you’re trying to accommodate all types of formatting dates for all languages and regions.
Imo, the site to plainly and explicitly require an exact type of date formatting. It’s very easy to validate and they can even help with formatting.
The site shouldn't have to do any of that. Ideally, the client-side date picker should handle it (it has the context to know user preference on whether "4-1-69" means January 4 or April 1, and the context to know to ask for clarification if it doesn't know the user's preference yet).
The problem being, the date picker is already a (single) input field. Having multiple input fields for what is already an input field somewhat defeats the purpose.
This doesn't address the real problem, though, which is IMHO that a calendar-like presentation doesn't lend itself easily to numeric date input/selection, especially, if it's about a date outside the current month. (E.g., a 3-column list view, which could be operated both by mouse/touch and keyboard input, may serve the purpose a bit better. Safari mobile could even style them rolodex-like… Which is, BTW, how it used to work on Safari mobile, before they switched to the unified style.)
It's called false simplicity. It looks easy but is actually hard to use. It's like Microsoft's ribbon design change. It hides a bunch of elements but made it difficult to figure out and click through.
Literally yesterday I encountered the date picker that didn't allow to manually change the value and didn't display whole calendar properly, with days in 5 and 6 row either invisible or not reacting to selection. And when it is obligatory event date field in insurance claim system, it is hard to apply Hanlon's razor.
Another similar input problem: when you can't manually type the country code in the phone field and have to scroll through the a dropdown menu just to choose the right set of numbers. Even if you know it.
This is not the case, I have used date pickers on desktop that were equally atrocious. Granted they were implemented in JS, so not a problem with the browser rendering but still, if we are talking about design here, the designers of those interactive elements need a stern talking to as well.
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.