3 ms·

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

by 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.
  - darkerside 3y ago
    Thank you for this perspective. I despise when a website makes me pick by birthday in a typical date picker. Maybe we are lacking vocabulary for these different types of date widgets. I've never heard anyone take about an historical date picker as a separate concept.

by MrJohz 3y ago

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.
- darkerside 3y ago
  Thank you for this perspective. I despise when a website makes me pick by birthday in a typical date picker. Maybe we are lacking vocabulary for these different types of date widgets. I've never heard anyone take about an historical date picker as a separate concept.