Topic on Talk:Style guide/Forms

I do not totally agree with your analysis here. To be fair, I'm a guy who doesn't like user interfaces and would generally prefer to have everything just be text-based... but still:

I think that multi-selects are actually valuable and I prefer using them (as a user) over groupings of checkboxes - particularly a long list of checkboxes. They have two key features that checkbox groupings don't:

1. You can rapidly select and deselect options because you can shift+click/command+click to select a long row of options.
2. They require less precision when clicking (drinking and clicking becomes a lot easier).

It's easy to prevent against a scrolling multi-select. And while I concede that a multi-select is likely less intuitive... my grandmother knows how to use one (this is saying a lot). Now, what would be cool is a multi-select coded to look like a checkbox grouping so we get the best of the functionality AND usability.

Hrm. Such a thing should be possible, actually.

One of the secondary bits for this is to actually define interface components based on function rather than form. So, for example, a "radio button" is the same as a "select pull down" in function: choose one item out of a set of discrete elements. This is the same functionality as a volume knob, or even a slider.

Ideally, you could just say "This is a time selection control" and the underlying system would know to generate a time selection slider.

As far as your point about multi-select, I'll grant that there are uses for them but in general people choose them when they aren't necessary (e.g., five options or some such). Further, I'd posit that if you are dealing with an interface that has hundreds of options in the set, the interface probably requires a different approach entirely.

This is awesome!!!!! I would be very interested to find out about suitable UI-options for a longer list of multi-select items? Unfortunately, we won't be able to get around this. I have seen category tree entry, but don't find that very appealing. Any other options?

I just found this interesting site about this problem: http://www.ryancramer.com/journal/entries/select_multiple/

It would be awesome, if we would have asmSelect or "Two select multiples" forms for Mediawiki.

In my opinion asmSelect is great. But you can't select many options at ones. On the other hand its gives you an overview which options are selected.

That article listed disadvantages of asmSelect as well. Requiring js, and usability disadvantages where after selecting one item, you have to go back to the select and start all over trying to find out where you were in the list.

IMHO, if we have a form in MediaWiki where we have enough check boxes that you would suggest using asmSelect as a fix for it, then what we really need to do is completely re-think the form. Not add some half-usable band-aid on top of it.

I'm quite a fan of the Chosen jQuery plugin (http://harvesthq.github.com/chosen/) for multi-selects. It also handles the related problem of single selects where there are an enormous number of options to scroll through, by adding a textbox for a filter search.

While we can certainly review some core forms for having "too many" multi-select options, it's not sensible to assert that a multi-select with 'many' options must, by definition, be badly designed. In many cases the number of options that will appear in the final form is entirely down to the user or the wiki administrator. So we might want to review the watchlist-edit form because users commonly have 'many' pages there. But there is no reason why a wiki might not be perfectly legitimately configured with hundreds of namespaces, and suddenly all sorts of filter selections have "many" options.