We have several applications where we need to let the user select multiple items. HTML has pretty much always offered multi-select through it's forms in a fairly simple manner, complete with how it will be rendered on screen:
It's a simple bit of UI, but the fact is, most users have no idea how to use it. We have a multi-select box that is populated with rows that the user would generally have need to access. For most users, there are a half-dozen or so of these rows. Other users, can receive an authorization that provides them dramatically more rows. When we first launched this UI, which was a change from the old system of select boxes that did not make it clear what data the user was limited to under the stricter interpretation of the law that we were using.
The change, however, made selecting multiple records seem harder to our users. They simply didn't know that SHIFT+Click to select ranges or CTRL+Click (Command+Click for you Mac users) to select discrete items. Now, some sites will drop in instructions to help users figure out how to multiselect, but as our user base was relatively small (particularly who demanded multi-select) we proceeded without it.
However, I have recently re-launched Washington State University's Schedules of Classes site, and in re-doing the search form, I felt I needed a better way, particularly since one of the select boxes has ~150 items. To deal with that, I utilized a pair of select boxes and server-side sessions to allow the user to select one (or many) items from the 'source' list on the left to the destination list on the right.
This works okay, and I still use it for progressive enhancement. It should eliminate the problem of users not knowing how to select many options, though that remains to be seen, and I have seen it elsewhere. I think this makes a reasonable amount of sense in situations like this, where the number of elements that will be expected in the right column will be fairly small.
For a more involved solution, I opted to investigate re-inventing multi-select boxes, by looking at how they are done in Mobile. On Android, a mutli-select box causes a modal dialog to appear, where the select items are represented by checkboxes (it uses radio buttons for single-select). Now, a modal dialog is wholly unnecessary on the desktop, but the checkbox option makes a lot of sense.
To support this, I wrote a YUI module (which I'm investigating releasing through the Gallery, there are copyright issues with my employer, though), which is in use on that page. It is a widget, which is attached to an element containing a label, and an input[type=select] element (at least one, it will ignore any more that it sees).
The markup generated looks like this:
Select a fruit
- Apple
- Apricots
- Banana
- Cherries
- Durian
- Grapes
- Kiwi
- Kumquat
- Mango
- Strawberry
.yui3-form-checkboxlist > ul
{
overflow: hidden;
list-style-type: none;
}
It's more verbose, but in a progressive enhancement situation that isn't necessarily a problem, but more importantly, the form output that comes out of this when POSTing matches what comes out of the original implementation, so whatever you use to get the selected items on the server for a mutli-select should work here as well. I am not sure I have exceptional accessibility on this widget yet, but it should be possible to do fairly easily.
The more I look at this, the more I kind of question if I shouldn't have just served up the checkbox list from the server. I suppose it's a question for me of accessibility, particularly without JavaScript enabled, but I suppose the implementation I am enhancing may not be as accessible as it could be, even with title's set to describe what the buttons do. Still, the concept of replacing multi-select boxes with lists of checkboxes makes a lot of sense to me, though it's not as semantic for those browsers that already render in this fashion.