[Select] Allow range selection using shift key

[dvh91]

• I have followed (at least) the PR section of the contributing guide.

I've added a feature to the Select component (multiple-values variant) which allows the user to use the shift key in order to select multiple options.

[mui-pr-bot]

@material-ui/core: parsed: +0.14% , gzip: +0.18%

Details of bundle changes

Generated by 🚫 dangerJS against e5540dc

[eps1lon]

Thanks for working on this issue! We need some tests for this feature though. Like selecting (multiple) options, deselecting (multiple) options, shift-key for mousedown and keydown etc.

Could you explain why you went with Shift instead of Ctrl as the modifier key?

[dvh91]

@eps1lon Will work on adding tests.
As for the behavior- shift is the common key for selecting multiple items (as a range) while ctrl key used for multiple select but not as a range.
The ctrl behavior is not relevant for MuiSelect as the menu is not closed once one option selected. It would have been useful if the default behavior is closing the menu once one option selected but when using ctrl, it would skip the closing of the menu.

Found in the web something that might put my thoughts in better words:
http://www.mit.edu/~mbarker/formula1/f1help/03-fund3.htm#:~:text=To%20select%20a%20range%20of%20cells%2C%20use%20the%20SHIFT%20key,pressing%20the%20Right%20Arrow%20key.

[eps1lon]

As for the behavior- shift is the common key for selecting multiple items (as a range) while ctrl key used for multiple select but not as a range.

Thanks. It wasn't clear to me that you implemented range selection.

[dvh91]

@eps1lon Is that something you guys want to push or wait with it?

[eps1lon]

@eps1lon Is that something you guys want to push or wait with it?

GitHub notifications are quite noisy so the occasional requested review slips through.

Some missing tests/assertions:

• aria-selected state of each option after shift-select
• shift-click on non-multiple select i.e. <Select />

Keyboard support should go into the minimal implementation. Bolt-on a11y is usually harder than planning a feature with a11y in mind from the start.

[oliviertassinari]

Do we really need to implement the range feature, like the one we have with the tree view? It seems that such behavior will be frustrating considering how easily the popup can close. What about we aim for simplicity?

1. We change the Select multiple behavior to close when a value is selected (consistency with Autocomplete): [Select] Consistency with Autocomplete #18136.
2. We restore the current multiple "keep popup open when value selected" behavior when the ctrl or meta keys are pressed. Matches select2, requested in [Autocomplete] Don't close the popup when Ctrl/Shift clicks #19654.

[eps1lon]

Do we really need to implement the range feature, like the one we have with the tree view?

Native select has it built-in. The purpose of a custom Select is to have a customizable native select. I haven't seen a custom Select that's worth giving up native UX.

It seems that such behavior will be frustrating considering how easily the popup can close. What about we aim for simplicity?

Seems like we have an issue with the close trigger.

consistency with Autocomplete

What makes the Autocomplete the source of truth for perfect UI here? This argument is not constructive. Why not implement this behavior in Select and Autocomplete instead?

We restore the current multiple "keep popup open when value selected" behavior when the ctrl or meta keys are pressed.

This PR is about range-selection with SHIFT not arbitrary multi select with CTRL.

[oliviertassinari]

Native select has it built-in.

I was wondering about the requirement for it as, so far, the custom multi-selects or combo boxes I could benchmark don't have it. I don't know if it's because most people don't ask for it, or if it's because the UX isn't great or because it's too costly/hard to implement.

Do we have an opportunity to abstract the ctrl, meta multi-selection into a hook, and share it with the Autocomplete? It's the 4th time I encounter this potential need: 1st time at onepixel for an image gallery, 2nd for the tree view, 3rd time for the select, 4th time for the autocomplete.

[eps1lon]

if it's because the UX isn't great or because it's too costly/hard to implement.

Or because users can't rely on the same UX between pages because every component looks (basically) the same but works different. Falling back to multi-click select after shift click is most likely not measured because most devs are ignorant about the existence of shift-select in UIs.

the custom multi-selects or combo boxes I could benchmark don't have it.

Benchmarking is a misleading technique to collect requirements. This is one of the many reasons.

[oliviertassinari]

because users can't rely on the same UX between pages

Very possible, I find this argument convincing.

My assumption is that the request vs cost ratio is low, making this feature a high opportunity cost for the design system teams in the industry.

Benchmarking is a misleading technique to collect requirements

I was using the following reasoning: by the absurd. We are in a mature industry with a lot of legacies. Let's assume the range feature is something important, then we should see it implemented in at least a couple of popular web interfaces, users being used to it. If it's not the case, then it means that the UX/UI/developer teams out there have better problems to solve. Also, assuming our aim is to replace these teams, we should have priorities close to them. Hence, it's probably not a feature we should value a lot.

[oliviertassinari]

@dvh91 We appreciate the contribution, however, it has been stale for a while now. If you want to push forward with it, I would recommend moving the logic to the combo box (Autocomplete). The current UX of our Select component is not as great as it could be. The issues I can remember without looking at the issue history:

• Performance starts to suck after 100 items. We pay the cost of React's component, we have often 10 layers when having fewer would be faster to render. We need to at least stop the MenuItem > ListItem inheritance.
• Locking the scroll when the popup opens is a strong move. It works well on mobile but not that much on desktop.
• The UX on mobile could be improved by displaying a bottom sheet. It would make customizations a bit harder but probably work better
• The UX of multi-selection with sub-header is broken

[henrymorton]

Hi guys,

Hope I find you well!

Can I ask if this problem was ever solved or will be looked at again?

My original request was #5302.

I would have thought the shift/range select option would be useful - it would certainly reduce the risk of RSI that people like me are currently facing from constant mouse clicking to select things.

Many thanks!

Henry

[Emilname]

would the work on this feature ever finished? very important behavior. Or can you give me some tips on how can i customize autocomplete to implemet it myself?

[oliviertassinari]

@Emilname The feature is available on the Autocomplete. Could you confirm? Does it solve your issue?

[tihuan]

@oliviertassinari sorry for pinging! I just checked Autocomplete and tried shift + click (and cmd + shift + click) on the multiple value example and it didn't select the range.

Or by feature did you mean that now Autocomplete menu won't close when you do cmd + click or ctrl + click, and we still need to implement our own range click?

Thanks so much!

CC: @Emilname @henrymorton

[oliviertassinari]

@tihuan Right, there are two different dimensions here:

• Is there a key to keep the popup open after one option is selected?
  • The Autocomplete uses event.metaKey (⌘ on macOS and ⊞ on Windows) or event.ctrlKey (control on macOS and ctrl on Windows). This was implemented in [Autocomplete] Don't close popup when Ctrl/Meta is pressed #22696
  • The Select behave differently, it doesn't close the popup on multi-selection mode, this is likely a mistake. I have added item 5. in [Select] Consistency with Autocomplete #18136 (comment).
• Is there a key to select a range of options? This is won't fix.

[tihuan]

Got it! Really appreciate the clarification 😀 Have a wonderful day!

[kealjones-wk]

@oliviertassinari I see that you said

Is there a key to select a range of options? This is won't fix.

Does that mean that this kind of behavior will never be built in?
As it has been a few years is this still the current position Mui has?