[UX] Remove multi-select list form elements from core by switching to Select2

[jenlampton]

Multiselect HTML select elements are hard for users. Selecting more than one requires Ctrl+clicking (or Cmd+clicking on Mac). Explaining this to users who sometimes have trouble even clicking the mouse is no one's idea of fun.

There are several modules for Drupal that replace all multi-select HTML elements with better alternatives:

• Better Select
  
• Chosen
  
• Select2
  
• Selectize
  
• Bootstrap Multiselect
  

There are also some great javascript libraries:

• Selectivity: https://arendjr.github.io/selectivity/
• SelectWoo: https://github.com/woocommerce/selectwoo

I would love to see the multi-select element removed from Backdrop's UI in favor of one of these better solutions.

(Looking for issues to mark as accessibility issues for an upcoming Sprint. Decided that this one does not qualify - @stpaultim 08/17/2021).

[klonos]

I'm pretty sure we already have an issue for this...

[jenlampton]

I thought so too but couldn't find it.

[klonos]

Selecting more than one requires Ctrl+clicking (or Cmd+clicking on Mac).

...and there's no way to use the multiselect on mobile where ctrl/cmd are not available.

I was thinking that it is kinda funny how the Better Select project usage stats show that there's only slightly over 600 sites still using it and in fact the number of installations is decreasing over time. Also, there is no port of it in D8 that I can find. So, people must be solving that issue in a different way somehow. So, a quick research brought into light the following:

https://api.jquerymobile.com/selectmenu and http://demos.jquerymobile.com/1.2.0/docs/forms/selects/

https://silviomoreto.github.io/bootstrap-select/examples/#multiple-select-boxes

Perhaps worth looking into as alternatives?

[jenlampton]

What you're seeing in the usage statistics is not "number of installations is decreasing over time" but the "number of sites reporting usage, decreasing over time". The majority of sites using this module are D6, and since there's no reason to have the update status module on for D6 sites anymore, people simply turn it off.

I think the easiest first step would be to remove the multi-select widget from core. After that we could look into adding fancy javascript based solutions. First things first?

[klonos]

The majority of sites using this module are D6, and since there's no reason to have the update status module on for D6 sites anymore, people simply turn it off.

Never thought of that. Your theory seems to be right because it is only the 6.x and the overall graphs that are declining - the 7.x graph seems to be relatively steady. Nevertheless, still weird that there's only so very few reported installations and that the highest it has ever gone to is a bit over the 1.000. I mean for such a useful module.

I think the easiest first step would be to remove the multi-select widget from core. After that we could look into adding fancy javascript based solutions.

Yep, with you on that 100%. Just thought that better_select is a JS solution too.

[jenlampton]

No PR here yet, so bumping to 1.7

[jenlampton]

As this issue has already missed a core release and still doesn't have a PR, I'm going to remove the milestone. That said, since it has [UX] in the title it is a priority issue for us, and can be rescheduled as soon as there's a PR for review.

[jenlampton]

I need this for a current project I'm working on, so assigning to myself.

[laryn]

@jenlampton, another option that fits this need and could be considered is Select2: https://www.drupal.org/project/select2

[jenlampton]

That's pretty slick @laryn, thanks! My concern with all of the possible approaches is the JavaScript library we'd need to incorporate. I'm not very good at judging whether something is a good candidate for core inclusion or not.

[jlfranklin]

As awful as multiple select elements are, they are at least standardized in the awfulness. Better Select is one of the first modules I install on Drupal sites for exactly that reason. That said, I'd rather let site developers choose which override is best for them, if any.

Porting Select 2 as a module is the way to go, in my opinion.

[jenlampton]

I also usually choose better select since it switches from a standard select (that's awful) to standard checkboxes (that are less awful) and there's no library needed.

I'd rather let site developers choose which override is best for them, if any.

That's how we handled these problems in Drupal. Just look how many drop-down menu solutions there were! However, here in Backdrop our philosophy is different, we're supposed to choose what we think is best for most people, and then if the want to change it they can - but at least that way most developers won't even need to think about it in the first place.

Porting Select 2 is the way to go, in my opinion.

I think I'm also leaning towards Select2 in terms of both features and aesthetic. As an added bonus, we could also use Select2 to replace our ancient autocomplete JS code. Here's an issue for Drupal about doing that very thing: https://www.drupal.org/node/2346973

That issue looks stalled due to front-end performance on the autocomplete, and accessibility. There appears to be some accessibility improvements in the SelectWoo fork.

I'm going to start on porting the Select2 module to Backdrop. Once we have a contrib version we can evaluate it's candidacy for core, and see if we can address the issues faced in the D8 queue if they also apply here.

[laryn]

@jenlampton Just curious if you ever started/made progress on Select2. I was searching to try to find this issue and stumbled on these (neither of which I've tested):

• from @quicksketch:
  https://github.com/quicksketch/backdrop-select2
• from @gifad; newer but looks abandoned and incomplete (partial README; no LICENSE, etc.):
  https://github.com/backdrop-contrib/select2

[jenlampton]

No, I didn't make much progress (unassigning from myself). I was daunted by the current state of Select2 and the amount of work involved in replacing our autocomplete (and my weakness w/ jQuery in general).

[jenlampton]

de-scoping this issue since we also have #459

[klonos]

I just came across https://github.com/davidstutz/bootstrap-multiselect and I have to say that I'm impressed by the functionality/features as outlined in the demos/examples here: https://davidstutz.github.io/bootstrap-multiselect ...checkboxes, search filter, support for select-all/reset, collapsible and optionally selectable optgroups, disabled/locked options, templates to allow styling almost every aspect, ...you name it. It's dual-licensed as Apache/BSD3.

I've added a screenshot to the issue summary.

[yorkshire-pudding]

Thanks @klonos - I think bootstrap multiselect looks really good for usability and also configurability.

[herbdool]

I'm surprised that Multiselect isn't on the list. It's not the fanciest but it's fairly easy to use, requires no complicated 3rd party libraries, and has simple JS. It can be enabled per field so it won't be forced on select fields that won't play nicely with it. And it's a separate widget so it doesn't hijack the existing select list. Could use a bit of a UI improvement but not much in my opinion.

Regarding Bootstrap Multiselect, it looks slick. But it requires Bootstrap so I don't think it's a candidate because of that.

[herbdool]

I also thought Better Select is pretty simple. I found it odd that the label and description were inside the scroll though (there's an old issue for that too https://www.drupal.org/project/betterselect/issues/2109405). The image at the top of this thread for it shows the label on the outside, so I'm confused. It probably could be fixed if the inner checkboxes could be wrapped in a div instead of relying on the outer div.

[klonos]

I'm surprised that Multiselect isn't on the list.

We can surely add it. I was never a fan of that module because it assumes that there's enough horizontal space to have 2 boxes side by side ...not sure if there's a mobile version of it where the boxes are stacked on top of each other and the add/remove arrows shift orientation too - that would be great (yet still a widget that takes too much screen real estate).