Multiple SELECT alternatives

huge list but don't want it to take up lots of real estate

[ergophobe]

I'm trying to figure out a usability puzzle of sorts.

Here's the situation in brief.
- SELECT drop down lets user pick text that will be inserted at the cursor in the TEXTAREA associated with the SELECT
- Users should be able to select multiple options (i.e. multiple="multiple")
- The option list is huge - about 100 items in 5-7 option groups
- Most of the time, this is not used when editing in the textarea, so I don't want it to take up lots of space
- When it is used, I want many options to show. This is not an alphabetical list or anything like that.

Basically, this is a set of options that will be used over and over and over by a small number of users who will likely have them pretty much memorized, but it's a big list and I want it as easy as possible for them.

This is an extranet database and I can control which browsers people use (currently allowing and building for IE5+ and FF1+).

Currently I'm doing it with a JS/DOM solution: some simple scripting where it's just a regular select and then, on receiving the focus, gets the size and multiple attributes set so that the user can see 15 lines. Upon hitting a button, it inserts the text at the cursor and reduces back to a normal dropdown. This is okay, but not great.

Other solutions I've considered

1. A JS/CSS solution: An "insert tags" link that, on click, changes the link to display:none and changes a large multiple select to display:block. Upon clicking the insert button, it reverses this. That is sort of a pain though, as it is an extra step all the time ("click, select, click" instead of "select, click").

2. A popup that basically does what my current version does. Since this is a small number of authenticated users who are being paid to do this, they can reasonably be expected to allow popups and tolerate them if they improve usability. I'm currently thinking this is the best solution.

Anyway, I'm just curious to hear if anyone has some brilliant ideas on making this as easy to use as possible.

[tedster]

How about using a show/hide div setup -- with a big form table inside the div holding checkboxes.

[ergophobe]

Have you used anything similar?

What you propose is similar to my option #1 (which uses multi select rather than checkboxes). Like the solution I have now (JS/DOM solution) it makes things a bit jumpy. When the "display" property is switched on and off, a big list like that pushes the text entry area pretty much off the screen. Maybe that's just the best way.

I may just mock up all the options (JS/DOM, CSS, and JS/DOM with popup, all of which with the select/checkbox option) and let users pick a "skin". They already have a panel for setting preferences for the size of various data entry pages, what their login start page is, some default layouts for various monitor resolutions and a few things like that.

For now I'm just trying to figure out whether there's some obvious great way to do it that I haven't thought of yet.

If the list were either short or logically alphabetical, like a list of countries, states, colors, or whatever, it would be simple, but as it is it's just awfully cumbersome. I asked if there was any way to get it down to 40-50 choices and we all agreed that there isn't.

[tedster]

a big list like that pushes the text entry area pretty much off the screen.

Alternately, could you position the div on a high z-index and overlay the current screen content instead of displacing it? Or display it off to one side?

No, I haven't done anything exactly like this -- but in general I think checkboxes are more user-friendly than dropdown boxes and multi selects.

[ergophobe]

That's true. I've done that before where you change items in and out by changing to display:none, but never with items that occupy quite so much of the screen and are so differently sized.

I'll try that too as another option (it's a simple page overall, so spinning out various options is easy, it's coming up with one I really like that's harder).

Thanks

[Lobo]

You have to catagorise your choises? apart from anything else users do not like long lists .. it's a bit of a turn off, in my experience people don't like them ..

It depends on what your are linking to? EG products or information?

It may not be so helpful, but rather than trying to work out a coded work around .. rethink the structure and the UI

[tedster]

used over and over and over by a small number of users who will likely have them pretty much memorized

Will you have a chance to do a test with the users? In similar situations, I found that the users themselves often gave the best input on interface tweaks.

[ergophobe]

It will definitely get tweaked over time and they will definitely give feedback for tweaks (this is part of my main work and I expect to be working with the same folks for several more years - the three oldest among us have been collaborating since the late 1980s). What will be harder to get from them are ideas for entirely different approaches that go beyond tweaks, which is why I wanted to throw it out here first.

You have to catagorise your choises?

Not necessarily, but there is no organizing principle otherwise that makes them findable. Without categories it would be a nightmare. Think of the list of WebmasterWorld forums and you have a rough idea (is the Adsense forum under G or A?). The best way to think of this list is as a list of infractions and penalties such as

- public drunkeness
- theft
- bigamy
- gambling
- batterie
- assault
- prison
- banishment
- fine
- appealed

etc. If not categorized, it's just a huge long list that is that much harder to use.

apart from anything else users do not like long lists

The list of items and the categories they belong to is the result of input from three of the top scholars in the world on the subject and draws on the published work of several others. It has been pared as much as people are willing without losing the precision we want.

It depends on what your are linking to?

This is not navigational. This is a list of terms that get inserted in a textarea. Basically, there are large blocks of information about individuals divided into pieces depending on the source of information. We want each piece to get a set of brief descriptive tag that will use uniform terminology.