7 ms·

Date widgets are almost universally bad. Most I encounter are unintuitive or outright buggy. However, OP complaining about usability and the providing three t

Date widgets are almost universally bad. Most I encounter are unintuitive or outright buggy. 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. And do they swap these placeholders and entered values if you change the country from US to an EU country? 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...

culi 4y ago
Actually the Firefox and Chrome date pickers look... exactly the same I don't think this is so much a problem of UI not being consistent as us just not providing resources to help elderly navigate the web better. Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache <input type="date" value="1960-01-01" /> Edit: ok, not "exactly" the same but functionally very similar. Or at least they'd have the exact problems pointed out in the post. See for yourself: FF: https://blog.nightly.mozilla.org/files/2017/06/input_date_calendar_1.png https://blog.nightly.mozilla.org/files/2017/06/input_date_ca... comparison: https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U2YQnUMato21MzzbR.png?auto=format&w=1600 https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
- RussianCow 4y ago
  > Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.
  - culi 4y ago
    Right then other things they could do: - provide some helpful text explaining to users how to switch between years - use an external library with a custom date picker The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is - what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics
    - seb1204 4y ago
      Such text will likely not be read by many. I think I will read it as I am generally a reader of how-to or help files to get a better idea of features. However the rest of my family you would need to point out the explanation text and likely also 'force' them to read it. They much rather tap around in the hope for the desired outcome.
- Someone1234 4y ago
  > Actually the Firefox and Chrome date pickers look... exactly the same They look nothing alike though. Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
  - culi 4y ago
    Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that? Would you mind providing a screenshot of how it looks on a different OS? Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
    - deleted 4y ago
      [deleted]
    - Semaphor 4y ago
      Windows: Firefox https://i.imgur.com/j8djrhN.png https://i.imgur.com/j8djrhN.png Chrome https://i.imgur.com/mmBInsQ.png https://i.imgur.com/mmBInsQ.png Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
      - kalleboo 4y ago
        The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png https://i.imgur.com/4w8IvO8.png Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png https://i.imgur.com/NSRvPcm.png
        culi 4y ago
- michaelteter 4y ago
  > Actually the Firefox and Chrome date pickers look... exactly the same It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem. At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).
- ls15 4y ago
  Or 1959-12-31, so nobody has to guess if it is yyyy-MM-dd or yyyy-dd-MM
ksec 4y ago
>And do they swap these placeholders and entered values if you change the country from US to an EU country? The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03. And always show 4 digit for years as YYYY.
- askmike 4y ago
  > I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Except for the vast majority of the world that doesn't use the English language.
  - deleted 4y ago
    [deleted]
  - kstenerud 4y ago
    Except that i18n is a thing in this modern world of whiz-bang UI toolkits.
    - emn13 4y ago
      Note that it i18n isn't implemented correctly by any of the browser date pickers. Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. So for anybody wanting to interact with both US sites and local sites (presumably quite a few people on the planet), they'll never be able to have appropriate browser date controls - either they get to have US controls on local sites, or local controls on US sites - and both are quite confusing, especially before you open the date control. Unopened date controls just show the client-culture-localized date, so if that doesn't match the site culture... it's going to be a mess.
      - nemetroid 4y ago
        Surely date widgets that behave subtly different depending on what website you’re currently visiting would be more confusing. > Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. For what it’s worth, whenever I have to write a date on an American-authored form, I use YYYY-MM-DD, as do all my colleagues.
Andrew_nenakhov 4y ago
> The moment you've got [1] [4] [1980], you no longer know which is month and which is day. The one true date format is YYYY-MM-DD
emn13 4y ago
I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. It's normal therefore to see dates in a format that's appropriate in context - a us news article might use a US format; others will use a different format that makes sense in context. Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.
- bmitc 4y ago
  > Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. What is odd about it other than being different and not being immediately lexically sortable in file names? Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,
  - nemetroid 4y ago
    The middle-endianness.
    - bmitc 4y ago
      That describes it, but what is odd? What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.
rahimnathwani 4y ago
The month input could be a drop-down with a three-letter abbreviation for the month. That would eliminate the need for a label.

culi 4y ago

Actually the Firefox and Chrome date pickers look... exactly the same I don't think this is so much a problem of UI not being consistent as us just not providing resources to help elderly navigate the web better. Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache <input type="date" value="1960-01-01" /> Edit: ok, not "exactly" the same but functionally very similar. Or at least they'd have the exact problems pointed out in the post. See for yourself: FF: https://blog.nightly.mozilla.org/files/2017/06/input_date_calendar_1.png https://blog.nightly.mozilla.org/files/2017/06/input_date_ca... comparison: https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U2YQnUMato21MzzbR.png?auto=format&w=1600 https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...

RussianCow 4y ago
> Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.
- culi 4y ago
  Right then other things they could do: - provide some helpful text explaining to users how to switch between years - use an external library with a custom date picker The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is - what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics
  - seb1204 4y ago
    Such text will likely not be read by many. I think I will read it as I am generally a reader of how-to or help files to get a better idea of features. However the rest of my family you would need to point out the explanation text and likely also 'force' them to read it. They much rather tap around in the hope for the desired outcome.
Someone1234 4y ago
> Actually the Firefox and Chrome date pickers look... exactly the same They look nothing alike though. Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
- culi 4y ago
  Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that? Would you mind providing a screenshot of how it looks on a different OS? Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
  - deleted 4y ago
    [deleted]
  - Semaphor 4y ago
    Windows: Firefox https://i.imgur.com/j8djrhN.png https://i.imgur.com/j8djrhN.png Chrome https://i.imgur.com/mmBInsQ.png https://i.imgur.com/mmBInsQ.png Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
    - kalleboo 4y ago
      The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png https://i.imgur.com/4w8IvO8.png Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png https://i.imgur.com/NSRvPcm.png
      - culi 4y ago
michaelteter 4y ago
> Actually the Firefox and Chrome date pickers look... exactly the same It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem. At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).
ls15 4y ago
Or 1959-12-31, so nobody has to guess if it is yyyy-MM-dd or yyyy-dd-MM

ksec 4y ago

>And do they swap these placeholders and entered values if you change the country from US to an EU country? The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03. And always show 4 digit for years as YYYY.

askmike 4y ago
> I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Except for the vast majority of the world that doesn't use the English language.
- deleted 4y ago
  [deleted]
- kstenerud 4y ago
  Except that i18n is a thing in this modern world of whiz-bang UI toolkits.
  - emn13 4y ago
    Note that it i18n isn't implemented correctly by any of the browser date pickers. Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. So for anybody wanting to interact with both US sites and local sites (presumably quite a few people on the planet), they'll never be able to have appropriate browser date controls - either they get to have US controls on local sites, or local controls on US sites - and both are quite confusing, especially before you open the date control. Unopened date controls just show the client-culture-localized date, so if that doesn't match the site culture... it's going to be a mess.
    - nemetroid 4y ago
      Surely date widgets that behave subtly different depending on what website you’re currently visiting would be more confusing. > Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. For what it’s worth, whenever I have to write a date on an American-authored form, I use YYYY-MM-DD, as do all my colleagues.

Andrew_nenakhov 4y ago

> The moment you've got [1] [4] [1980], you no longer know which is month and which is day. The one true date format is YYYY-MM-DD

emn13 4y ago

I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. It's normal therefore to see dates in a format that's appropriate in context - a us news article might use a US format; others will use a different format that makes sense in context. Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.

bmitc 4y ago
> Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. What is odd about it other than being different and not being immediately lexically sortable in file names? Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,
- nemetroid 4y ago
  The middle-endianness.
  - bmitc 4y ago
    That describes it, but what is odd? What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.

rahimnathwani 4y ago

The month input could be a drop-down with a three-letter abbreviation for the month. That would eliminate the need for a label.