Hacker News new | ask | show | jobs
by RoddaWallPro 948 days ago
"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.
3 comments

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

Checkboxes are a good choice for a small number of options: https://m3.material.io/components/chips/overview . I'd say past a dozen options though this starts to become unwieldy.

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

Two column designs ( https://crlcu.github.io/multiselect/examples/search.html ) have mostly fallen out of favor, though I feel they still have their uses for larger lists with large numbers of selected values.

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

My boomer parents do. Most users I've seen in the wild do.

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”
Present a form with a 25 item native multiselect to 10 of your non-prgrammer family members. Ask them to perform two tasks:

- Select 5 non-adjacent items

- Select 5 adjacent items.

Report back with success rates.

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.

That two-window approach was particular useful where you needed to be able to rearrange the order of the items.

Now we tend to have a part of the record appearing to have texture (stripes or bumps) as a clue that grabbing it will afford pushing it up or down.

There’s many little common standards like that which have never appeared in “out of the box” controls provided by the platforms.

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. :)
Drag and drop? At least that’s only using a pointer device without modifier key…