Re: GtkComboBox design issues



Thus spake Calum Benson:
> James Henstridge wrote:
> 
> > If you decide on the form of completion found in most web browsers these
> > days, please do it similarly to mozilla, and put in a delay before
> > performing the completion.  It is really annoying to type in the exact
> > string you want and press enter, only to find that the program has
> > appended something extra onto the end.
> 
> Scott Berkun (former UI designer on IE4/5) posted a mail about
> autocompletion on the ACM CHI-WEB list the other day, explaining how and
> why they changed the history list behaviour between IE4 and IE5... I
> know that's a rather specialised case of a combo box, but you might find
> it interesting anyway:
> 
> http://www.acm.org/archives/wa.cgi?A2=ind0011b&L=chi-web&F=&S=&P=16970

Thanks!
Scott nicely describes two problems with the Netscape-style
autocompletion (and it seems I basically suggested IE-style completion ;-)
Also, IE suggests a way of conserving the Tab key:
make Tab go into the drop-down menu.

I have mixed feelings about this:
* It's good in that it allows one to use Tab, as shell-users are used
  to, and it behaves in a reasonable manner (Tab goes to the next
  widget (kinda -- see below), in this case the dropdown menu).
* It's bad in that the dropdown menu isn't -really- a different
  widget. Example:
  You're editing a field, and hit tab, expecting to get to the next
  field/widget, but instead end up in the drop-down menu, completing
  the field that you just thought you left.
  That is, tab-goes-to-dropdown makes navigation depend on whether
  there are any tab completions, which is bad -- you shouldn't
  overload behaviour.
* Also it's bad b/c if you then want to scroll through the
  completions, you're going to have to hit up/down -anyways-, so
  instead of moving your hand to the arrows right away, you hit Tab
  (at one end of the keyboard) and then the arrows at the other end.

My suggestion:
make `Tab-goes-to-dropdown' an option, but turned OFF by default
(let it be turned on for hard-core IE/shell users).
Instead, when the user is filling a form field,
drop down a menu possible completions (sorted alphabetically, say?).
If the user pushes down/up, the first/last entry in the menu is
highlighted and the completion appears in the form box, but
highlighted so they can kill it.
If they push up/down, their selection changes, as does the completion
(still highlighted); if they hit left/right, the completion gets
chosen and the end part stops being selected (i.e., you can edit this
completion); if they type anything, the completion gets killed and we
compute possible selections again.

That's kinda unclear; let me explain:

User types: ze

Which yields:

ze|
---------
zebra
zen
zero

(where | is cursor position

If the user keeps typing or does anything but hit up/down, we get

zea|
---------
<blank/no completion menu?>

If the user hits down, we get:

ze|`bra'
---------
zebra <--
zebras
zen
zero

where <-- indicates that zebra is highlighted, and `bra' is selected
text (i.e., typing kills it).

If the user hits up, we get

ze|`ro'
---------
zebra
zebras
zen
zero  <--

now from here, if the user hits up/down again, we just scroll through
the dropdown menu; (if they scroll off the edge of the menu, say the
hit down then up, we don't select any completion);
if the user keeps typing, we forget they ever hit
up/down, and if the user hits left/right (say, right), we get:

zeb|ra
---------
zebras

that is, the completion becomes the new value of the form field, and
we only look at its completions now.

This leaves one question: what happens to the cursor if the user goes
into the drop-down menu when they're not at the end of the string?
I'm tempted to say ``Move it to the end of the string (right before
the selection)'', though this may have problems -- thoughts?

(that is, the above would become, if the user hit down:
zebra|`s'
---------
zebras <--
)

*groan*
I see why editable drop-down menus are so complicated:
they're basically a `prompt' component, with the history and
completion features -- maybe we should support emacs/vi keys?
(just kidding -- actually, is the form box in a drop-down the same
text widget that Havoc's been hacking on?)

-- 
  -nils
Public key: http://www.nbarth.net/~nbarth/pub-key.txt

Attachment: pgpNDcYPIAXRu.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]