Re: notes on combo boxes

[Nils Barth <nils_barth post harvard edu>]

On Fri, Aug 04, 2000 at 10:43:54AM -0700, Guy Harris wrote:
> On Fri, Aug 04, 2000 at 10:10:23AM -0700, Guy Harris wrote:
> > On the other hand, I seem to remember reading *somewhere* a critique of
> > either combo boxes in general, or non-editable combo boxes; I forget
> > what it said, but I'll see if I can find it.
> 
> I couldn't find it in the places I thought it might be - Alan Cooper's
> *About Face* likes the combo box, and none of the Web sites I had
> bookmarked that seemed like candidates had a combo box critique in any
> obvious place.

You prolly remember this one:
http://www.mackido.com/Interface/ComboBox.html

MacKiDo has some interesting remarks on GUIs beyond the above,
and provides a different take on the Mac interface than Tog.

The basic objection is:
The combo box is a complex, complicated widget.
Its use and behaviour is not readily apparent, and can't be easily
explained.
There are alternative ways of doing things.

My take:
First, there are 3 widgets I'd like to distinguish:
1) pop-up menus: the Mac's way of doing selectable lists in one
   line. When clicked on, pops up to fill whole screen, with
   arrows on the end that if you mouse over, the menus scrolls.
   This scrolling happens at 2 speeds (faster if you go waaaay
   onto the arrow, slow if you just edge over).
   When you release the button, the item is picked.
This is basically an improved Motif menu, with scrolling
(though it came out before Motif).

2) drop-down menus: Microsoft's way of doing selectable lists
   in one line. When you click on the box, a small
   scrolled window drops down. Once you move the scrollbar to the
   selection and click on the item, it is selected.
   Scrolling happens a la scrollbox, since it is just a scroll
   box.
Some people have been calling these non-editable combo boxes
(non-combo combo boxes!), which illustrates the confusion with:

3) combo boxes: Microsoft's way of doing edittable selectable lists
   in one line (the description should convey the problem of
   complexity). Looks identical (I think) to a drop-down menu.
   Behaviour is...er, see MacKiDo.

For mouse navigation of menus up to about 100 items,
pop-up menus are very fast. Click, drag, release.
This is also the way that regular (File, Edit, etc.) menus are
handled (more or less -- the Mac has some subtle inconsistencies
as of System 8.5 between regualr menus and pop-up menus).

I haven't looked at the recent scrollable menu patch; if it
requires clicking to scroll, then it is broken -- this should
be a mouse-over, as in the mac (and recently windows, in some cases).

I think that if GTK pop-up menus allow jump scrolling by initial
letter, the main objection to their poor keyboard navigation is
answered.

Drop-down menus are rather slow, and not terribly more useable than
pop-up menus:
They require a minimum of two clicks (no draging, sorry), and
usually more.
They only display a small selection window, so much more scrolling
is necessary.
The drop down menu may actually drop up, if the widget is too low
on the screen. This makes it inconsistent and less usable.
It looks EXACTLY like a combo box. This is because they are used
for similar purposes, but the behaviour is different.

I think that drop-down menus are basically a poor idea/version
of the pop-up menu, with one notable exception:
they make it marginally easier to navigate very very long menus
That is, you can click on the sliver of an elevator to move directly
to the end/middle of a very very long menu.
However, if pop-up menus scroll at a reasonable speed, then they
are not so slow at navigating medium size menus.
I think the Mac scrolls about 20 items per second on the Fast
pop-up speed. Alternatively, we could dial up the speed for longer
menus if this is a problem. (10% a second?)
Alternatively, we could make the pop-up menu a bit more complex
 -- it's already been suggested to add a % indicator or such
 to the arrow region so people don't get so lost in LONG pop-ups.
We could make this clickable/editable/a spin-button
(just brain-storming).

Sorry to belabor this -- I feel that pop-up menus are really
superior to drop-downs, and wanted to should that they can be
superior in Every way.

------

We need some kind of combo box, if only for interface designers
who like it.
However, I would suggest:
We carefully consider the behaviour. I like the idea of an
edit box with a pop-up menu indicator right next to it.
This has basically the behaviour of a combo box while being
clearer (this is suggested on MacKiDo).

If we have a combo-box (or work-alike), and pop-up menus,
but no drop-down menus, then there is no drop-down menu/combo-box
confusion.

Re: drop-down menus with arbitrary widgets (or pixmaps and text,
or whatever) to select: how about pop-up menus with this?
In fact, this should prolly not be too complicated, and anything
that's too involved (many different widgets in a MENU!) should
pop up its own window.
However, for small selections of pixmaps etc., this should be
fine (again, as pop-up menus).

Some advantages of a pop-up menu over a drop-down menu:
faster
can use more of the screen, show more info
cleaner -- similar to regular menus
less cluttered

sorry for rambling.
Summery: combo boxes are a necessary evil, but not too bad if
the behaviour is thought out.
drop-down menus (in addition to combo boxes) are confusing and
 unnecessary -- pop up menus are better, and for long lists one
 should probably use a selection box.
pop-up menus in GTK need work, but the idea is basically sound
(see macs)

-- 
  -nils