3 ms·

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) A

by c-fe 3y ago

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1 website on all browsers. (Its of course a different story if you need custom functionality.)

zeroCalories 3y ago
The optimal date picker depends heavily on the platform too. Don't want your crusty custom date picker over my platform specific date picker that I know well.
mmcnl 3y ago
The default date picker is laughable. For example there is no way to control the format in which the date is displayed.
- ckolkey 3y ago
  Unless I'm mistaken, it's shown in a format localised to the user, so... i'd much rather you keep your hands off that, and I'll enjoy my DD.MM.YYYY
  - arcanemachiner 3y ago
    ISO-style timestamps are the only only one that makes any sense. YYYY-MM-DD or GTFO.
    - hoosieree 3y ago
      no need to fight over it, compromise is both elegant and simple: YMYY-YD-DM
      - Izkata 3y ago
        Non-jokingly, Kazakhstan has YYYY-DD-MM https://en.wikipedia.org/wiki/Date_format_by_country https://en.wikipedia.org/wiki/Date_format_by_country
      - arcanemachiner 3y ago
        A UTC-style compromise if ever there was one.
  - mmcnl 3y ago
    That would be easy, but if you have an app with localization then it's not useful. And also it's impossible to make the formatting consistent with other formatting in your app.
ssss11 3y ago
Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.
- _a_a_a_ 3y ago
  Well fuck them.
  - guhcampos 3y ago
    Thanks.
- 3c6bYDXLMj 3y ago
  [dead]
- xigoi 3y ago
  And that's precisely the problem.
- deleted 3y ago
  [deleted]
divbzero 3y ago
This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.
- xg15 3y ago
  Usability depends on the knowledge of your users how to correctly use the widget though - and that knowledge is greatly helped by consistency.
- Izkata 3y ago
  > etc. Screen readers and voice input: https://a11ysupport.io/tech/html/input(type-date)_element https://a11ysupport.io/tech/html/input(type-date)_element
MrJohz 3y ago
I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to select a range of dates, and even that's often different to the one I want to use to select the two dates of a return journey. Of the classic form controls, choosing a date is probably the one that has the most application-specific needs, and therefore the one that I would most expect to vary between applications.
- xg15 3y ago
  What would be the specific difference between all of those? For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page. But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.
  - docmars 3y ago
    At that point, you're creating and writing a different flavor of date picker -- and in static HTML land, there is no clean way to update page content dynamically based on user input, without some kind of JavaScript library interacting with those elements (talking to the UI) and coordinating input data, displaying new derived data/info based on those selections with snappy, accurate feedback. There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?
  - MrJohz 3y ago
    * For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling. * For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date. * If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals. * If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months. * This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant. These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.
sensanaty 3y ago
The default datepickers in browsers are not feature-rich at all though. They're fine for extremely basic "pick a date" type of usecases, but as soon as you want to do anything slightly complex like picking a range, a date & specific time in one or having it be interactive in some other way like Google Flights showing you a range of prices alongside the date etc., you have to create your own datepicker component (or use an already built one).

by c-fe 3y ago

zeroCalories 3y ago

The optimal date picker depends heavily on the platform too. Don't want your crusty custom date picker over my platform specific date picker that I know well.

mmcnl 3y ago

The default date picker is laughable. For example there is no way to control the format in which the date is displayed.

ckolkey 3y ago
Unless I'm mistaken, it's shown in a format localised to the user, so... i'd much rather you keep your hands off that, and I'll enjoy my DD.MM.YYYY
- arcanemachiner 3y ago
  ISO-style timestamps are the only only one that makes any sense. YYYY-MM-DD or GTFO.
  - hoosieree 3y ago
    no need to fight over it, compromise is both elegant and simple: YMYY-YD-DM
    - Izkata 3y ago
      Non-jokingly, Kazakhstan has YYYY-DD-MM https://en.wikipedia.org/wiki/Date_format_by_country https://en.wikipedia.org/wiki/Date_format_by_country
    - arcanemachiner 3y ago
      A UTC-style compromise if ever there was one.
- mmcnl 3y ago
  That would be easy, but if you have an app with localization then it's not useful. And also it's impossible to make the formatting consistent with other formatting in your app.

ssss11 3y ago

Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.

_a_a_a_ 3y ago
Well fuck them.
- guhcampos 3y ago
  Thanks.
3c6bYDXLMj 3y ago
[dead]
xigoi 3y ago
And that's precisely the problem.
deleted 3y ago
[deleted]

divbzero 3y ago

This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.

xg15 3y ago
Usability depends on the knowledge of your users how to correctly use the widget though - and that knowledge is greatly helped by consistency.
Izkata 3y ago
> etc. Screen readers and voice input: https://a11ysupport.io/tech/html/input(type-date)_element https://a11ysupport.io/tech/html/input(type-date)_element

MrJohz 3y ago

I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to select a range of dates, and even that's often different to the one I want to use to select the two dates of a return journey. Of the classic form controls, choosing a date is probably the one that has the most application-specific needs, and therefore the one that I would most expect to vary between applications.

xg15 3y ago
What would be the specific difference between all of those? For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page. But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.
- docmars 3y ago
  At that point, you're creating and writing a different flavor of date picker -- and in static HTML land, there is no clean way to update page content dynamically based on user input, without some kind of JavaScript library interacting with those elements (talking to the UI) and coordinating input data, displaying new derived data/info based on those selections with snappy, accurate feedback. There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?
- MrJohz 3y ago
  * For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling. * For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date. * If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals. * If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months. * This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant. These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.

sensanaty 3y ago

The default datepickers in browsers are not feature-rich at all though. They're fine for extremely basic "pick a date" type of usecases, but as soon as you want to do anything slightly complex like picking a range, a date & specific time in one or having it be interactive in some other way like Google Flights showing you a range of prices alongside the date etc., you have to create your own datepicker component (or use an already built one).