leea@ssc-vax.UUCP (Lee Carver) (10/13/89)
Any body care to offer suggestion on the following user interface
issue?
We have a situation where users will choose a few items from a very
large list. Typically, only one; occaisonally five or ten from a
list a several hundred candidates.
This isn't our application, but consider parts ordering. A store
has several hundred items listed in a on-line database; each
customer order is a few items from the master list. (Our
application is requirements allocation: Each piece of software
satisfies a small number of the 1000's of requirements).
This is to be done with X-toolkit style graphics, so windows, menus,
toggle boxes and all the other elements of a graphical user
interface are available.
The best presentation we have found uses multiple windows: one window
with the current set of selections, and one window with a menu of
all possible selections. A user is able to see the items already
selected, and can "easily" find new entries. Selected items in the
set of current choice allows them to be deleted, selecting items
from the menu of choices adds them to the current set.
By comparsion, when a single item is chosen from a large list, you
can have a scrolling menu with the selected item high-lighted. Or,
with multiple selections from a small list, you can have a fix menu
with high-lights or check-boxes.
There seem to be two problems that arise 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.
One question is whether both windows up at the same time is
reasonable. That consumes a lot of real-estate, even on a 19"
workstation screen. But if they are not both visible, what is the
"optimal" way to notify the user that more choices are possible?
Maybe its just a hard problem.
The other ("obvious" :-) question is: "Are there other, or proven,
presentation styles for this problem?" Surely other people have
addressed this issue, even if none of our style guides give much
guidance (Apple, Microsoft, DECwindows, SPC, Motif).
TIA. I'll collect mail responses for mass-publication.kent@sunfs3.camex.uucp (Kent Borg) (10/17/89)
leea@ssc-vax.UUCP (Lee Carver) writes: >We have a situation where users will choose a few items from a very >large list. Typically, only one; occaisonally five or ten from a list >a several hundred candidates. 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. Other features of the window are the same as the Macintosh's Standard Get File dialog. The top list is a view of the hierarchical file system, there are standard ways of navigating through it. There are keyboard equivilents for nearly everything the user can do. 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. The behavior of the Standard Get File is full of subtile complexity, but it is actually quite easy to use and is well known (virtually every Macintosh program uses it to ask the user to specify files). This elaboration upon it is something that a user can easily play with and figure out. In Macintosh terms, this is not a good solution, but it is about the best currently available. The biggest problem when this is used to specify files is that it is drastically different from the way the Finder presents files to the user. This is a problem with the current Macintosh user interface design. (At some point it is likely that the Standard Get File will become a service offered by the Finder and two techniques will converge.) 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. (I realize that many of the details of what I am talking about here are very Macintosh-specific, but the concerns which drive them will still apply.) 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. Can you tell us more about what the candidates items are? -- Kent Borg "Then again I could be foolish kent@lloyd.uucp not to quit while I'm ahead..." or -from Evita (sung by Juan Peron) ...!husc6!lloyd!kent