kk@shasta.tivoli.com (Kerry Kimbrough) (05/11/91)
Here's a little question for all you OPEN LOOK style guide gurus. Also, for all you OPEN LOOK toolkit implementors. The UI problem involves selecting something from a large, indefinitely long list of choices. For this, the scrolling list is perhaps the best OL control. If you're not quite sure which item you want, the scrolling list lets you browse the possibilities and pick one. However, if you know exactly which item you want, then most people will prefer to just type in the name, rather than scroll through a long list. The question is this: according to OPEN LOOK style, what is the best way to present both access methods --- type-in and list selection --- so that users can use either one or both, as suits them? Toolkit implementors: the ideal would be a scrolling list that would scroll as you typed, much like Emacs incremental search: Hit 'F' and the first item beginning with 'F' is highlighted, etc.
ed@Canada.Sun.COM (Edward Lycklama - KL Group Inc.) (05/12/91)
Here's a little question for all you OPEN LOOK style guide gurus. Also, for all
you OPEN LOOK toolkit implementors.
The UI problem involves selecting something from a large, indefinitely long list
of choices. For this, the scrolling list is perhaps the best OL control. If
you're not quite sure which item you want, the scrolling list lets you browse
the possibilities and pick one. However, if you know exactly which item you
want, then most people will prefer to just type in the name, rather than scroll
through a long list.
The question is this: according to OPEN LOOK style, what is the best way to
present both access methods --- type-in and list selection --- so that users
can use either one or both, as suits them?
Toolkit implementors: the ideal would be a scrolling list that would scroll as
you typed, much like Emacs incremental search: Hit 'F' and the first item
beginning with 'F' is highlighted, etc.
Actually, the XView toolkit does allow this; the trick is to get the keyboard focus into
the scrolling list. Visually this happens when the list goes from protruding to indented; usually
you get this to happen by hitting the return key until the focus jumps into the list. Then you
just type the letter, and the first name beginning with that letter is selected.
Ed Lycklama
KL Group Inc. | Phone: (416) 594-1026
134 Adelaide St. E, Suite 204 | Fax: (416) 594-1919
Toronto, Ontario, M5C 1K9 | UUCP: ut{zoo|csri}!suncan!klg!ed
CANADAopenlook-request@openlook (05/15/91)
> The question is this: according to OPEN LOOK style, what is the best way to > present both access methods --- type-in and list selection --- so that users > can use either one or both, as suits them? [This seems too easy, Kerry, what am I missing?] I suggest implementing a scrolling list next to a text field. When a user selects an item from the scrolling list, display it in the text field; when the user enters a value into the text field, select it in the scrolling list (or, if not a valid item, complain). On occasion I find a more complex (for the implementor) u.i. more appropriate: For a selection u.i. that requires frequent interaction, give an abbreviated menu button with a short list of choices, plus an extra (oblong) button. The short list gives those choices most often picked by users, the extra button gives access to a popup window with the scrolling list of all choices. For those who like to type in a value, either put the text field next to the abbreviated menu button (when users often want to type in a value), or next to the popup's scrolling list (when users don't usually need to type in a value). An enhancement includes a way to let the user pick which items show up in the short menu. Note: If you use the more complex u.i., put the short list in an exclusive (or non-exclusive) choice control; and make the extra button a regular, oblong-shaped button. > Toolkit implementors: the ideal would be a scrolling list that would scroll as > you typed, much like Emacs incremental search: Hit 'F' and the first item > beginning with 'F' is highlighted, etc. Neat idea. We suggested this to Tony Hoeber, et al, when they were designing the scrolling list. I don't recall exactly why they chose the each-typed-character-matches-the-1st-letter u.i., instead of the incremental approach. I think it may have been that other GUIs used the single-letter match; this method is very similar to the mnemonics/accelerators used to operate other controls in most GUIs. Steve Humphrey UNIX System Laboratories
kk@shasta.tivoli.com (Kerry Kimbrough) (05/15/91)
> > The question is this: according to OPEN LOOK style, what is the best way to > > present both access methods --- type-in and list selection --- so that users > > can use either one or both, as suits them? > > I suggest implementing a scrolling list next to a text field. Agreed, this seems like the required combination of controls. My question then concerns the preferred style for presenting these controls. How is the text field positioned w.r.t. to the list? How is the text field aligned w.r.t the list? If the text field/list represent a single property value, then which control is aligned with the label --- text or list? The central style problem is how best to make clear that the two controls are bound together and represent a single thing, not two things. If there is a OL Style Guide ruling on this issue, then I haven't been able to find it. But perhaps someone can find what the best interpretation of the Style Guide would be in this case.
fgreco@govt.shearson.com (Frank Greco) (05/15/91)
> The central style problem is how best to make clear that the two controls are > bound together and represent a single thing, not two things. You might put the textitem and the list in *one* "panel" (aka "control") with the borders turned on or a separate color (or shade) to indicate visually that the two are connected. I have had good success with this regardless of whether the textitem is below the list or to its side. [side note: if OL allowed multiple colored or multiple fonted panel items within one panel, you wouldn't have to create a separate panel] Frank G.
** Sender Unknown ** (05/16/91)
> If the text field/list represent a single property value, then which > control is aligned with the label --- text or list? > > The central style problem is how best to make clear that the two controls are > bound together and represent a single thing, not two things. Here's how I *want* to do this: Label: [..] _________ The [..] is intended to be an abbreviated button (not abbreviated menu button) that, when pressed, pops up window containing the scrolling list. But we don't have this control in OLIT (oops), so what I do instead is Label: ________ (Choices...) The (Choices...) is an (oblong) button. If you want to put the scrolling list in the same window as the label and text field, then I suggest ----------- [=] Label: ________ | | | | | [^] | | [ ] | | [v] | | | ----------- [=] I think this (or something similar) is what you were looking for. While my crude drawing above suggests having a 5-line scrolling view, a shorter view (3 lines) would minimize the real estate lost and reduce the visual ``noise'' (too many text things yelling at the user--this is why I prefer putting the scrolling list in a popup window). For a pleasing visual, align the baselines of the label, textfield, and 1st item in the scrolling list. Good luck, as we haven't added a way of conveniently aligning baselines. (You pretty much have to use a BulletinBoard if you go this far). Finally, Frank Greco's suggestion of bounding the label, text field, and scrolling list with a chiseled line or differently colored background is OK. My preference is to not do that, as I think the close proximity of the three elements suggests they work together, and the many lines or ``patch-work quilt'' of colors can distract the user. If you have a control area that has many such sets of controls, then I guess the box or color is necessary, to help the user sort out the multiple controls; but, gosh--maybe the control area is simply too complicated and ought to be redesigned (probably into a multiple Categories window, like the OPEN LOOK workspace property sheet). [Note: This is my opinion. Moreover, I do not mean to denigrate Frank's suggestion.] > If there is a OL Style Guide ruling on this issue, then I haven't been able to > find it. Kerry, I don't think the Style Guide covers this particular case. My interpretations (interpolations?) are as above. Steve Humphrey UNIX System Laboratories
tom@elan.Elan.COM (Thomas Smith) (05/18/91)
Regarding possible designs for an enhanced scrolling list, that provided an alternate type-in interface to accelerate finding a list element... Earlier, kk@shasta.tivoli.com (Kerry Kimbrough) said: >>> The question is this: according to OPEN LOOK style, what is the best way to >>> present both access methods --- type-in and list selection --- so that users >>> can use either one or both, as suits them? >> >> I suggest implementing a scrolling list next to a text field. > Agreed, this seems like the required combination of controls. My question then > concerns the preferred style for presenting these controls. How is the text > field positioned w.r.t. to the list? How is the text field aligned w.r.t the > list? If the text field/list represent a single property value, then which > control is aligned with the label --- text or list? > The central style problem is how best to make clear that the two controls are > bound together and represent a single thing, not two things. Then fgreco@govt.shearson.com (Frank Greco) responds: > You might put the textitem and the list in *one* "panel" (aka "control") > with the borders turned on or a separate color (or shade) to indicate > visually that the two are connected. I have had good success with > this regardless of whether the textitem is below the list or to its > side. The problem with using color changes, font changes, or even "outlined" grouping in situations like this is that it calls undue attention to the control. The user will see your grouping as an exception - something different from the other controls - and give it more importance. For instance, suppose you had a dialog box to change fonts. You might use a scrolling list to select the typeface, a choice item (set of radio buttons) to choose the style, and another choice item to choose the size. By making the typeface control a different font or color from the rest of the controls, you are saying "this control is different from the rest," which is not really true. Open Look does in fact have a mechanism for associating parts of a single control: proximity. In a toggle item (non-exclusive choice), for instance, there is no question that all of the boxes are associated with each other and the label. A toggle item looks like this: --------- ---------- --------- Choose one: | First | | Second | | Third | --------- ---------- --------- The toggle boxes for "First", "Second", and "Third" are as close to each other as they are to the label (about 3 pixels). When controls are separate from each other, they are about 10 pixels apart. The point of all this? In order to associate your text item more closely with the scrolling list, it should be sufficient simply to put them closer together. ----------- Choose one: | First || | Second || | Third || ----------- ^---------- By the way, did you know that in XView, you can type a letter into the list (which has to be the "current" item), and it will scroll to the next entry that begins with that letter? I bet your users don't know it - an explicit entry is much better feedback. One of the early versions of XView (1.0.1?) had an option to put a type-in field just like the one you described onto the list, but that option disappeared. I wonder why? Hope I've answered more questions than I've raised. Thomas Smith Elan Computer Group, Inc. (415) 964-2200 tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom