8 ms·

So I'm not the only one. 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

So I'm not the only one. 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.

deleted 4y ago
[deleted]
culi 4y ago
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
- friend_and_foe 4y ago
  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.
  - culi 4y ago
    > 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
    - mgkimsal 4y ago
      > Given any default starting date, I can enter in my DOB in: - 1 tap - 2 swipes - another tap =================== How? Reading this, I can’t imagine any scenario where I could enter a specific date on mobile with 4 interactions.
      - culi 4y ago
        well I guess 5 1. Tap the year-month 2. Swipe to your year 3. Swipe to your year 4. Hit the checkmark 5. Tap the day of the month
        friend_and_foe 4y ago
        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.
- wruza 4y ago
  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.
tsergiu 4y ago
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.
- bradgessler 4y ago
  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 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.
  - mastersummoner 4y ago
    Chronic is an awesome date library, agreed.
  - bmitc 4y ago
    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. https://products.wolframalpha.com/api/documentation https://products.wolframalpha.com/api/documentation I'm curious if anyone has used it. It costs but it could save an immense amount of time.
masswerk 4y ago
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.)
RedShift1 4y ago
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.
- kalleboo 4y ago
  I miss the old days when Apple and Microsoft had teams of people user testing every new feature instead of just following the whims of their designers
  - speed_spread 4y ago
    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.
- riedel 4y ago
  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.
- andrepd 4y ago
  > 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""".
- mannykannot 4y ago
  My personal experience is that a significant number would simply blame the users.
  - 4y ago
rieTohgh6 4y ago
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.
causi 4y ago
Every non-typed input field should be able to be manually edited with a keyboard.
martyvis 4y ago
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.
- survirtual 4y ago
  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.
  - voakbasda 4y ago
    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.
    - phlummox 4y ago
      [dead]
marvel_boy 4y ago
Absolutely. I would suggest another kind of job for this kind of "designers".
superjan 4y ago
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. Please realize that consistency != usability.
pwinnski 4y ago
As one of the comments on that thread points out, every desktop browser seems to allow text input, and every mobile browser is obtuse like iOS Safari.
- friend_and_foe 4y ago
  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.
shadowgovt 4y ago
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).
- dclowd9901 4y ago
  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.
  - shadowgovt 4y ago
    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).
ymolodtsov 4y ago
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.
neycoda 4y ago
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.

deleted 4y ago

[deleted]

culi 4y ago

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

friend_and_foe 4y ago
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.
- culi 4y ago
  > 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
  - mgkimsal 4y ago
    > Given any default starting date, I can enter in my DOB in: - 1 tap - 2 swipes - another tap =================== How? Reading this, I can’t imagine any scenario where I could enter a specific date on mobile with 4 interactions.
    - culi 4y ago
      well I guess 5 1. Tap the year-month 2. Swipe to your year 3. Swipe to your year 4. Hit the checkmark 5. Tap the day of the month
      - friend_and_foe 4y ago
        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.
wruza 4y ago
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.

tsergiu 4y ago

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.

bradgessler 4y ago
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 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.
- mastersummoner 4y ago
  Chronic is an awesome date library, agreed.
- bmitc 4y ago
  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. https://products.wolframalpha.com/api/documentation https://products.wolframalpha.com/api/documentation I'm curious if anyone has used it. It costs but it could save an immense amount of time.

masswerk 4y ago

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

RedShift1 4y ago

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.

kalleboo 4y ago
I miss the old days when Apple and Microsoft had teams of people user testing every new feature instead of just following the whims of their designers
- speed_spread 4y ago
  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.
riedel 4y ago
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.
andrepd 4y ago
> 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""".
mannykannot 4y ago
My personal experience is that a significant number would simply blame the users.
- 4y ago

rieTohgh6 4y ago

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.

causi 4y ago

Every non-typed input field should be able to be manually edited with a keyboard.

martyvis 4y ago

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.

survirtual 4y ago
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.
- voakbasda 4y ago
  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.
  - phlummox 4y ago
    [dead]

marvel_boy 4y ago

Absolutely. I would suggest another kind of job for this kind of "designers".

superjan 4y ago

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. Please realize that consistency != usability.

pwinnski 4y ago

As one of the comments on that thread points out, every desktop browser seems to allow text input, and every mobile browser is obtuse like iOS Safari.

friend_and_foe 4y ago
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.

shadowgovt 4y ago

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

dclowd9901 4y ago
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.
- shadowgovt 4y ago
  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).

ymolodtsov 4y ago

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.

neycoda 4y ago

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.