Re: [WSG] making big selections

2008-05-02 Thread Andrew Maben


On May 2, 2008, at 1:04 AM, Andrew Harris wrote:


Been having problems with deciding on the best user interface for a
particular type of form input (for an intranet application).

When we have a list of values from which a user can select one or more
items, there are a couple of choices.
- we can use checkboxes, which is nice and easy for (lets say) up to
15 options, starts to get a bit clunky up to 25 and just gets ugly
from then on.
- we can use a multiple select list, which operates reasonably well up
to quite a large number of choices, but gets a bit of negative
feedback from users who don't find it intuitive. The whole modifier
key thing throws people and they can't tell what's been selected
without scrolling right through the list (what a nightmare that would
be on a screenreader!).

AFAIK, the multi-select is the *right* way to go, but when we're
talking about your larger lists (200+ items) I agree that it is next
to impossible to use - scrolling increments become tiny and you can't
tell what's been selected at a glance (as all selections may be
outside the viewport of the form control).


This is a thorny and much-discussed issue. The consensus seems to be  
that, as you note, the multiple select is not a viable option. And as  
you also point out, offering very long lists of check boxes is  
problematic for several reasons: it's hard for the user to keep  
track, wasteful of space, etc.


I'm happy that I've never had to deal with quite this problem, but in  
a variation I have had to deal with situations where subsequent  
options depend on initial choices, and I've found users to respond  
quite well to an interface where they are only offered the relevant  
subsequent option set after their initial choice. I use JS to open  
and close hidden sections of the form (you have to be careful to  
empty any completed fields if they go back and choose a different  
initial option, but while tedious this is fairly trivial).


I would suggest that any long list can be broken down into sub- 
sections. e.g. if you're listing towns in the US:

Time Zone - State - County

If the list is truly heterogeneous then the alphabet is a sure standby.

So, perhaps:  Choose your item from: category set(s) - item checkbox  
list


The category sets can be nested as necessary - if you have say 1000  
options to choose from, ten primary categories, each offering ten  
subcategories, each with a list of ten items. To allow the user to  
put away a list after making choices keep a display of chosen  
options conspicuously visible, you could even use JS to permit  
removal of items without having to return to the original checkbox.  
Hand-coding all this would certainly be a royal pain, but with server- 
side scripting it's easy using loops.


btw - the CHI-WEB list is also a great place for discussions of this  
type of issue.


Good luck!

Andrew







***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] making big selections

2008-05-01 Thread Andrew Harris
Been having problems with deciding on the best user interface for a
particular type of form input (for an intranet application).

When we have a list of values from which a user can select one or more
items, there are a couple of choices.
- we can use checkboxes, which is nice and easy for (lets say) up to
15 options, starts to get a bit clunky up to 25 and just gets ugly
from then on.
- we can use a multiple select list, which operates reasonably well up
to quite a large number of choices, but gets a bit of negative
feedback from users who don't find it intuitive. The whole modifier
key thing throws people and they can't tell what's been selected
without scrolling right through the list (what a nightmare that would
be on a screenreader!).

AFAIK, the multi-select is the *right* way to go, but when we're
talking about your larger lists (200+ items) I agree that it is next
to impossible to use - scrolling increments become tiny and you can't
tell what's been selected at a glance (as all selections may be
outside the viewport of the form control).

We recently trialled something like this
http://justinsomnia.org/2005/01/roll-your-own-multiple-select-listbox/
(an array of checkboxes styled to look like a big multi select), but
although I was pretty happy with the style and feel of it, the user
testing canned it... they'd rather sort through a huge array of
hundreds of checkboxes (!). At least they can see at a (sort of)
glance, what has been selected.

In the end, I had to admit a partial defeat. Standard HTML elements
are just not set up for this scale of information. Sticking to my
roots, however, I'm looking for some sort of 'progressive enhancement'
javascript that will allow me to use the multiple select as the basis
for a more user friendly representation.

So, any thoughts? either on the problem, or suggested solutions / UI
libraries / examples.

-- 
Andrew Harris
[EMAIL PROTECTED]
http://www.woowoowoo.com

~~~ * ~~~


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***