The user inteface for this is determined by the browser and the windowing system. It's nothing to do with your CGI program.

Ctrl-click is a common way of making non-contiguous selections. That may work for your users.

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Like davorg said, UI behaviour is up to the browser. For this reason, I don't like to trust browsers to do what I tell them. For instance, I never make javascript support a requirement for site usability, because some browsers won't support it and there are a few different JS implementations.

Along the same lines, I don't like to use multiple-select form elements. Different browser implementations may screw around with the way the multiple-select gets rendered and behaves, and I also don't like having to include a line like "control-click (or command-click, for Mac) in the list to select multiple options" so people know it's a multiple-select... I find it a headache, sometimes.

So instead I prefer to use checkboxes. The check box has standard behaviour, everyone knows how to use it, and so on. Also, the user doesn't have to scroll through a list to make sure he's selected every necessary option. Of course, when the list of options is too large you pretty much have to use multiple-selects (try cramming 100 checkboxes onto a page and see how your layout looks).

Of course, when the list of options is too large you pretty much have to use multiple-selects (try cramming 100 checkboxes onto a page and see how your layout looks).

Ah, this is where some people may be nabbed. The second you think you need to supply 100 options to a user, all of which are optional, there is something wrong with your user interface. For starters, I can't imagine a situation where you would even need to present a user with such a list. And even if you do find a reasonable use for such an idea, you shouldn't be cramming them all on one page. Make your user interface friendlier by splitting the gigantic form into multiple successive pages.

If you find a reason to supply 100+ options to a user about one thing, you could always group them as well. Make the first page of the application a page where they select the main groups they want to select options from, and the successive pages can deal with each group of options seperately, allowing the user to select sub-options of the groups they originally selected.

Remember: the simpler the interface, and the better setup it is, the happier your users will be :)

---

"User error. Replace user and press any key to continue."

I agree that it is rare that so many options all at once would be necessary, but one example comes to mind. On some job-seeking sites they ask something like "what regions would you like to work in". Then there is a multi-select box with entries like

Canada, any
Canada, Maritimes, any
Canada, Maritimes, Newfoundland
Canada, Maritimes, Newfoundland, St. John's region
...
[download]

and so on. I remember it being well-ordered enough that it wasn't difficult to find any particular region, but there were far too many options to make into checkboxes. The fact that any number of regions could be selected, as well as the fact that there were a couple of levels of precision, meant that it would be difficult to redo it (by grouping) in two pages. It probably would have taken three, and that's more than any single question should take. There was a similar situation for the 'what fields of work to search' question, and if there are too many questions on a form that take two or more pages to complete... well, that's no good.

In a situation like that I feel that multi-select lists are justified. I do agree, however, that such cases are rare, and for the vast majority of forms checkboxes are just fine.


LAI
:eof