I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react.
My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use <input type="date" /> do we get a datepicker across browsers? (Looks like yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)
Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed.
There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.
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.)
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.
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.
* 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.
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.
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?
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.
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).
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.
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.
"shift/control-clicking to get multiple things is a flat no-go from a UX perspective" - Do you mean that this is NOT how you should do multiselects? If that is what you mean, then how _do_ you do them? If I have a list of items and I want to select 10 or 15 of them in a row, I currently don't know of a better UI to do that with than shift+click.
Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.
HTML has had checkboxes since at least version 2 (1995), so just use those if you want to do multi-select using checkboxes. I don't think you can do shift-clicking to select ranges though (without resorting to js) but control-click is of course redundant as that is just the default behavior for a list of checkboxes.
This is pretty much correct, though I feel there's some finer points depending on the number of options (5? 10? 50?) and the expected number of values chosen (2? 4? 10?).
Tag-style multiselects are fairly common (see https://react-select.com/home for an example). These are good where the number of values a user is expected to have selected is small (less than five imo) but the number of options is large enough to make checkboxes impractical. If you're expecting a higher number of things to be selected, you could have the option list stay open after an option is clicked, so they user doesn't have to reopen it each time they want to add an option (and, in fact, the "Animation" example does precisely that).
Yeah, shift/control-click is a longstanding workflow for multiselect and macOS, Linux and windows all support it with various platform-specific subtleties. The worst part of the web is losing all these sorts of features because some web designer thinks they’re a “bad UX”
The nice thing about native behaviors is you only have to teach them once. Custom behaviors per application make it harder for people to develop a model of how their computer works because you have to learn a new interaction model per application. I’m pretty anti the notion that UX is intuitive in any sense: all human-computer interaction is learned at some point and we should focus more on educating people how to do tasks like this than pursuing some lowest-common denominator concept of “intuitiveness” or “discoverability”.
Anyways, my favorite multiselect paradigm is the old windows one with two list boxes side by side and buttons in between.
Django has a version of that widget in the admin panel and I really like it.
I actually like native web multi-select widget because I know how it works and it works well. But most people don't know how it works, no one is going to teach them, and they aren't going to look it up (they probably don't even know what to search for to learn!). So you need one that works just with clicks and no modifier keys or most people won't actually be able to use it. In other words, it's not accessible.
Why not do both? Gmail's a great example of this. Hold shift while clicking two checkboxes in a range of emails, and watch as the entire range is selected for you to manage. :)
> Is the look/feel/controls consistent across browsers? (No.)
And to think that having a native look-and-feel used to be considered a must for any desktop application!
I would be much happier if all websites's UI components (not the actual website design of course) had the look-and-feel native to my browser (and if browsers actually cared to make them look good, TBH) rather than inventing their own dumb styles for everything.
<Aside> from the rest of the discussion, `input` element is infamously shitty for having vastly different ways of interacting with it, whereas most other HTML elements have one signature.
My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use <input type="date" /> do we get a datepicker across browsers? (Looks like yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)
Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed.
There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.