leea@ssc-vax.UUCP (Lee Carver) (10/26/89)
Back on 12-Oct I sent out a question on how to chose a few items from a large list. I gathered 7 responses; thanks to everyone. I tried to summarize responses, so some were dropped here. I'm still hoping for a truly novel solution, so some comments on the problem and the offered solutions. To recap, there seem to be two problems in the "few-of-many" selection problem. First, a user can forget what has been selected. In very large menus, no selected item may be visible on the screen. Second, a user should be able to quickly access all possible choices. Scrolling menus seem an adequate solution here, but fail on the "forget" problem. The original proposal was to have two scrolling menus. The first menu shows the items a user has chosen. Items in the chosen menu can be selected and deleted. The second menu show the candidate items a user may select from. Items in the candidates menu can be selected and added to the chosen menu. The major problem with this approach is substantial screen real-estate. Several people pointed out that large lists can often be handled as a hierarchy. This minimizes the number of choices that a user needs to view. I guess you still need to show the selected items separately. Unfortunately, in this case there is no "natural" hierarchy. I fear the parts ordering example I offered was poor. A better example would be "choose from checks written the last year". The check number is clearly the critical identifier, but just try to come up with a useful hierarchy. One fruitful addition from several soruces was a filtering mechanism. This would allow the user to focus on a limited set of candidates. As long as you have to use a lot of real-estate for the two menus, you might as well add a filter. This follows with a summary of responses to induce additional cogitation. Please understand that I have abstracted the responses; complain to me if you don't agree (or I have mis-represented you). Most resposes agree, "few-of-many" is a hard problem. From: Craig Hubley <uw-beaver!rutgers!gpu.utcs.utoronto.ca!craig> > I don't think commonly supported approaches serve you very well. > Of course, if you can break that big list down hierarchically, > preferably in several different alternative ways, then you might > find a more manageable task for your user. > If this is impossible, then perhaps 'carrying' the selected items > around with you on a cursor (that is, the list of items *is* your > cursor, with arrow attached to the top-left corner would seem to > solve a couple of your problems. The fact that this would obscure > some menu items would be offset by the fact that you could move the > thing out of the way quickly to see what's behind - this is time- > multiplexing making up for lack of space multiplexing. Now that is really an interesting idea: a big cursor, with the selected items. I suspect X would gag if I changed the cursor often, or to large sizes, but??? Hard to do under character addressable (curses) screens too. But what a concept! From: kent@sunfs3.camex.uucp (Kent Borg) > On the Macintosh there is a `conventional' solution to this problem (To > see my example, find a Macintosh programmer and ask to see: "The > Commando interface for specifying files for an MPW link.".) > > It is a single window with two different scrolling lists and a few other > controls. Basically you click on an item in the top list to select it, > then you press the "Add" button, and it appears in the bottom list. You > can change your mind by selecting an item in the bottom list, then > clicking on the "Remove" button. Sounds like a emerging presentation standard for the two-menu approach. Glad to see some prior experience in this problem. > If the user starts typing characters, they are treated as an incremental > search on the current folder (directory), the first file which matches > is scrolled into position and highlighted, if there is "too long" a pause > in the typing, further typing will start a new incremental search. > The "Enter" key is the same as pressing the "Add" button. Neat implementation of a filter. > In Macintosh terms, this is not a good solution, but it is about the > best currently available. Uh-huh. It seems to be a hard problem. > The reason that this `bad' solution is among the best, is that it > draws upon established conventions. Many alternative solutions suffer > from either being too unfamiliar or being familiar but misleading: a > solution which involved dragging icons around would be bad because the > Finder already has the user doing that; other applications should not > do that until it becomes a means for interapplication communication > and is integrated with the Finder's icon dragging. Another problem: > if this solution were on the Macintosh and were used to specify items > which are *not* files, then it should not look like a standard *file* > dialog. It may function the same way, but if you don't want users to > get confused about what is being selected, make it look distinct. > You said "a very large list...several hundred candidates". If there > is no prospect of the list ever being any larger than a couple hundred > alphabetized items, then fast incremental searching, a scroll bar, > up/down arrows to move the current selection by one, etc., might do. > If the candidate list is any bigger or more complicated, you will need > some kind of querying system. A very few check boxes (toggled, two > state controls), or radio buttons (a 1-of-N-choice control set) might > be used specify properties of items to show up in the list. If there > is some structure to the items selected (always an entree, maybe an > appetizer, maybe dessert), you might present the candidates in a way > which indicates that structure. You might `parse' the choices on the > fly to modify what remaining candidates are presented. From: few@quad1.quad.com (Frank Whaley) > In our environment (primarily 24x80 CRTs), there isn't enough real > estate to viusally present all of the data. Therefore, we have to cut > corners. We guarantee the existence of a SEARCH key, and have developed > a standard of bracketing ([ ___ ]) text input fields which will pop-up a > menu of possible selections if the SEARCH key is pressed. Using our > metaphors, we would present a box of "searchable" input fields with an > indicator that the contents of the box will scroll vertically. We also > have indicators for horizontal scrolling... > > +-A long list of goodies-+ > ^ [ apples ] | > | [ oranges ] | > | [<orizontally scroll>] | > | [ __________________ ] | > v [ __________________ ] | > +-Press EXEC to continue-+ > > Pressing SEARCH would present a display like this: > > +-A long list of goodies-+ > ^ [ apples ] | > | [ oranges ] | > | [<orizontally scroll>] | > | [ __________________ ] | > v [ +------------+____ ] | > +-Pr|[a list ]|ntinue-+ > | of many | > | more | > v choices | > +------------+ We considered having the candidates "pop-up" in a menu to conserve real- estate, but were unable to come up visually satisfying presentation. How do users know that more choices exist? For Mr. Whaley's application, the application forces you to make some hard choices. Does anyone have a "standardized" presentation to indicate pop-up choices? > > I've seen a lot of style-guide shortcomings over the last few years. > My standard approach is to abstract the problem and take it to an > Administrative Assistant to see how they'd do it without a computer. Any ideas on how to run this experiment? I think you come up with the "two-menu" answer (a book of candidates and a page of choices). Two sources that explicitly drive home the point of user filtering of the candidates: From: Hilarie Nickerson <uw-beaver!ames!zodiac!hil> > Have you considered adding some database query facility with which > a user could narrow the search? You could do this via form-filling > since the choices will have similar properties. From: uw-beaver!rutgers!pdn.paradyne.com!reggie (George Leach) > Anytime I hear of scrollable lists or menus, > I immediately think that we have a search problem, not a selection problem. > ... > Can items be categorized in any way to help reduce the searching time? > [Use a] ... hierarchy of menus and only display mutliple selections within > a certain submenu? The notion of a "search problem" is a good point, and an excellent heuristic. Unfortunately, I don't think the classic "search" answer of heirarchical menus applies here. In particular the "few" in "few-of-many" means that more the one choice is made. How do you remember the complete set of choices? But the notion of "a search problem" suggests that the user would like some kind a filtering over the complete set of candidates