Weekly update – 6 December 2024

[ryan]

This week I got wrapped up in unexpected client work, but it did lead to development of a new Inputfield module, which I think I’ll be using a lot, and hoping some others might find it useful too. 

It’s called Small Select Multiple, and the purpose of it is to provide a multi-selection input that is as simple as a single-selection input, and that didn't introduce new UI elements, sticking just to native browser controls. 

It came about because a client has a large front-end form that has a lot of multi-selection inputs, which we handled with checkboxes. It started to become too much for users, so we tried changing to AsmSelect. That helped a lot, but it still became overwhelming once a lot of options were selected. We needed something that looked simple from the start, and stayed simple even after a lot of selections had been made. The Small Select Multiple input seems to do the trick.

You can use this input type with Options fields or Page fields, or anywhere else you might us ProcessWire’s SelectMultiple, Checkboxes, or AsmSelect input types. Like the other Inputfield types, it’s not always going to be the right fit, and has it’s own unique set of benefits and drawbacks, but for the times where it suits the need, I hope you find it useful. 

Rather than writing more about it, I’ll link you to the module page for it. There’s more details and screenshots there. While you are in the modules directory, see the 3 other new modules posted this week too, they look great. Core updates coming next week. Thanks for reading and have a great weekend.

[adrian]

Hey @ryan - sounds like a potentially useful input for certain needs. I am wondering what you think about the option of the closed label being something like "3 of 50" or "3/50" because I think in some cases it's important to know if all are selected vs a limited selection.

[ryan]

@adrian Good idea, I will add that option. 

[artfulrobot]

This looks really useful, by the way!

Accessibility: I was going to submit this as an issue but perhaps you'd prefer discussion here as a precursor?

Browser-native selects have a cool feature: you can type the label to find an item. If you're able to use a mouse like I am then this is just an efficiency, but if you can only use keyboard navigation then this is really very valuable to usability (on a long list) and to efficiency (on a short list).

e.g. consider a list of countries. ("Where have you been on holiday?"). having to scroll and click is going to be awkward and slow; being able to type Uni and jump to United Arab Emirates (and below it United Kingdom) makes it a breeze.

This important accessibility function gets broken by the way the icons representing selected/not are inserted as text before the labels.

Sadly, CSS cannot rescue this - if CSS were supported better for <selects> then we could do various things to improve UX for visual users without it being at the expense of less able users.

What about instead of using visual characters for selected/not, using  <optgroup label="Selected"> and <optgroup label="Unselected">  and grouping the selected items first?

[adrian]

@artfulrobot @ryan - I wonder if some of the new techniques described here would help?

 

 

[artfulrobot]

Wow, well that's a Christmas present! So glad this is coming (slowly), Thanks forfor sharing it!