Re: [Usability] combo box guidelines?

[Matthew Paul Thomas <mpt myrealbox com>]

There's an unfortunate terminology confusion here. GTK calls the 
control we're discussing a "GtkComboBox", but it is not a combo box. A 
combo box is a combination of a text field and a menu, but the control 
in the "Connect to Server" dialog is just a menu.

The Gnome HIG calls the control a "drop-down list", but this is also 
misleading, since it often opens partly upwards. The Apple HIGs call it 
a "pop-up menu", but this is ambiguous, since that term can equally 
apply to shortcut/context menus.

I use the term "option menu", which is what the control was previously 
called in GTK.

On Sep 24, 2007, at 5:29 AM, Kevin Carlson wrote:
> ...
> On 9/23/07, Jacob Beauregard <jake13jake comcast net> wrote:
> > ...
> > Caleb Marcus wrote:
> > ...
> > > I disagree, I think that if the options can't fit on the screen,
> > > moving it down to display the maximum number of options is more
> > > important than preserving the current position of the combo box.

Opening all option menus the same way is more important than you might 
expect, because it is something that's not visible until you click the 
control. Without any visual hint about how it will behave, you need to 
be able to trust that any option menu will open in the same way -- 
otherwise you will be slower when using *every* option menu, regardless 
of what program it's in.

With the current behavior in GTK and in the Mac OS toolkit, you can be 
sure that an option menu will open in the same way every time. (KDE and 
Windows don't have option menus, they have drop-down listboxes instead, 
which are usually much slower to use.)

This sort of thing comes part-way between "invisible structures" and 
"small visible structures" in Bruce Tognazzini's prioritization of 
interface consistency.
<http://www.asktog.com/basics/firstPrinciples.html#consistency>

> > ...
> > A. Change the option
> > B. Look at other options
> > C. Nothing
> >
> > What would be the odds of each of these uses, and what would be the 
> > cost to each of them? Does maintaining the currently-selected option 
> > in different circumstances make it better or worse for the user? Are
> > different kinds of users going to have higher or lower costs with this
> > effect.

There are some cases where you're likely to want to choose one of the 
items *adjacent* to the current one. For example, a font menu where 
you're trying out each of the available typefaces in succession. Or a 
zoom level menu where you're finding a zoom level suitable for reading. 
In these cases, having the selected item appear exactly over the menu 
control is useful, because you can always drag up a few pixels to 
choose the previous item, or drag down a few pixels to choose the next 
item. After doing this a few times in succession, you can do this 
without even looking at the menu.

(The same should be true for shortcut menus, but unfortunately it 
isn't. When I right-click on the desktop and drag down a smidgen, I 
should always get the same item, i.e. "Create Folder". Currently I get 
either "Create Folder" or "Change Desktop Background", depending on 
where the cursor was when I started. That's bad.)

There are other cases where you're pretty much equally likely to want 
to choose any of the items in the menu. In these cases there would a 
small benefit from showing more items to begin with, but I don't think 
that's worth breaking the consistency of behavior.

> ...
> Maybe we should offer a way to do both and leave it up to the 
> individual applications, so when GIMP fills the space you can complain 
> about not preserving the position to the GIMP developers, or whatever.
> ...

As above, it's important that people be able to rely on every option 
menu behaving the same way. I think making it easily customizable by 
individual applications would be nearly as bad as not having it as a 
standard control at all.

Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/