Web Form Woe

June 2, 2006 7:54 AM

Elegant design of ~500 multiple select elements in HTML? Am new to this whole presentation thing...

I am creating a web form in which users must be able to make N-selections between 500-600 elements. In most cases N <= 10. I have them stuffed into a bunch of select-multiple boxes, atm. Does anyone have suggestions for better layout?

posted by bastionofsanity to computers & internet (10 comments total)

Eee gods. That's almost going to be a nightmare anyway you do it. With that many I'd use checkboxes instead of multi-selects though because I'd be afraid of people missing a click and losing the choices they've made

Is there not a way to limit some of the choices (or page them) using some categorization? Can you do something like a Javascript that rewrites the choices based on earlier choices?
posted by bitdamaged at 8:02 AM on June 2, 2006

That's a tall order.

1. Is there any hierarchy to these 500 options? Any way to select one general category and select specific options from there?

2. Are these thematically grouped/groupable, so that most users would only need to look at one multiple-select box?

If (for example) this were a list of cities, I can imagine something like the OS X Finder's column browser, so that in column 1 you have continents, column 2 is countries, and column 2 is cities. But if people were likely to pick cities from more than one country, you'd need multiple rounds of winnow/select/submit.

What is the actual subject matter? That could help guide how you present the options. Do you have anything mocked up?
posted by adamrice at 8:09 AM on June 2, 2006

I'm not sure how to do it in HTML, but a system where you have two boxes, and a button to transfer the elements from the box on the left to the box on the right is always an elegant solution. The contents of the box on the right is the list of selected elements in the end. Another button can deselect the element by moving it back to the left side.

Make sure you alphabetize them.
posted by jon_kill at 8:10 AM on June 2, 2006

Um, don't do this.

Why on god's green earth are there more possible choices than the number of countries in the world?!?! If you have a huge set of objects like this, find some way to reduce it, or at least filter it. This sounds to me like there is some list of every single product in the whole system, and the developer just wants to spit out the entire list into a selectbox. Don't do it! Some ideas:

1. At some earlier point in the form/web-app/thingy, have the user make some selections that drive the possible number of selections down toward 100-200.

2. At the page in question, provide facility for filtering the list. Perhaps use a tab metaphor so that the user is only presented with a single 100-200 list at a time. He or she then can page through the smaller lists, making selections as she goes (those should be visibly added to a "cart" or "selection." If you hide the selection boxes, there's no way to see what's already picked.

3. Use some Ajax-y goodness and let users use the keyboard to do "typed completions." This only helps if the task is not a browse task, but is a known-item search. If I know I need a "ProForm 550 Rev. B" then I could type in that, and the selectbox would jump to the "P"s, then the "ProForm"s, etc. as I type. If the user really needs to browse, then you need a *good* browsing interface. And a select box isn't it.

4. Let people save their selections (if at all applicable). Sure, the user might need to be miserable once as she selects the printer cartriges for every printer in her office. But next time, please remember the user's default order!
posted by zpousman at 8:12 AM on June 2, 2006

500 items is a lot to wade through in one list, but you could avoid the accidental-clear problem by using checkboxes in a list.
posted by Armitage Shanks at 8:24 AM on June 2, 2006

I am currently polling the select boxes after every change to make an update to a div tag listing all currently selected choices. These choices are links that allow the user to deselect their choice, as well.
There is a semantic order to the choices. Each selection is a six character code. Eventually the human-readable equivalent for each code will need to replace the code in the select-thing object.
The current select-multiple page breaks the 731(last count) elements into select-multiple(s) of 20 displaying 5 at a time, ignoring any semantic grouping and just letting natural order (they are alphabetized) decide into which box they go.
posted by bastionofsanity at 8:32 AM on June 2, 2006

zpousman:
Your 3rd point interests me. It is something I considered, but ran into distribution issue. The codes are clumped in certain respects. e.g. abcXXX occurs 350 times in the list, abeXXX occurs 4 times, etc. And the XXX part can significantly change the meaning of a code.
posted by bastionofsanity at 8:46 AM on June 2, 2006

How about a page with two main elements: The list of currently selected items, and a form at the bottom of the list to add a new item. (If users also need to "unselect" items, then add a "remove" button next to each item in the list.)

The "add an item" form could just have single-select control with a list of all the items, or (probably better) it could also include a search box to filter the items. An auto-completing textbox like the one used on Google Suggest could combine these two functions into one control.
posted by mbrubeck at 10:36 AM on June 2, 2006

I am leading towards zpousman's answer. Dropdowns to create a filter that returns a collection of dropdowns with final selection in them. Just not sure how I want to structure it. One giant list of 204 items is not acceptable to users. There are sub-categories within that 204, but that would require another filter.
posted by bastionofsanity at 12:58 PM on June 2, 2006

Don't know if you're still checking this thread, but think about it like this (and use this explanation to argue for it to other folks on the team): If your solution takes 4 pages to build the final set of selection(s), and each page takes 10 seconds to load and only 5 seconds to make a seleciton, that's 1 minute. Compare this to loading a single page (10 seconds), but the user spending 3 or 4 *minutes* getting more and more frustrated all the while making the same selections from a much less optimal set of widgets. It's a no brainer for me: it'd be great if there were a way to do this on a single page, but there's not.

That's not to say that you can't make it *look* like a single page, using iFrames, Ajax, etc. etc. Then it's the best of both worlds -- it helps users filter down the list(s), but also appears to be a single page.
posted by zpousman at 5:06 AM on June 5, 2006