The questions I'll address are UI ones; you probably want to mail
Arlo Rose <arlo workthatmouse com>
(the UI lead for Eazel, was in charge of Mac OS 8 UI, etc.)
(cc'ing to the list), as he can probably help a lot with such things
(or even test some of them out -- they have a UI test lab there!).
I'll include my amateur opinions below.
Thus spake Kristian Rietveld:
> 2. Owen told about the issue of duplicates in his mail of Oct 26. I think
> this problem only applies to the GtkComboBoxText. Having the same
> GtkWidget on the grid of the GtkComboBoxGrid twice isn't possible. But the
> question is: Do we want duplicates or not? Do we want an option to switch
> the allowance of duplicates on/off?
Do we have a particular case where duplicates are useful?
I'd like to see a good reason to support them, esp. if they add
complexity to the API/codebase.
Otherwise I'm tempted by eXtreme Programming: do the simplest thing
that works.
OTOH Qt allows duplicates, right? So Troll Tech thinks someone has a
use for duplicates.
Basically from the perspective of pop-up menus, duplicates make no
sense, but from the perspective of a shell-type command-line history
they make sense; two different paradigms -- I don't know which is
closer to what a combobox is/should be.
> 3. Which kind of {tab,auto}completion do we want in the
> GtkComboBoxText? It now has tabcompletion when typing and it'll try to
> autocomplete if the user presses enter.
This is a difficult one, as we have 3 standards:
(1) Shell tab-completion/arrow to scroll command history
(2) Browser-style (IE/Moz) autocompletion
(3) Tab switches between widgets in dialogs
1 & 3 conflict in what the behaviour of tab is, and many people feel
strongly about both, so it probably should be configurable.
The default setting should be TAB switches widgets (not completion),
as that's what newbies are familiar with, and anyone who has TAB
completion hardwired into their brain can probably figure out gnomecc.
Which leaves two questions:
(a) how do you keyboard navigate widgets if TAB is bound to completion?
{ I have no idea, and neither would most users -- ideas? }
(b) if not TAB, then what key should be the completion character??
{ some people have suggested Space (problem if your string has spaces
in it), other options could be Right Arrow (at the end of your
input? might make editing input harder) or Esc (conflicts with Esc
= Cancel) }
Also, enter should not default to autocomplete if this is an `editable
combobox' (er, where the user input new strings), but could be if it
were a non-editable combobox (i.e., pop-up menu). However, if it were
autocomplete on one and not the other, this could be confusing.
So this is a thorny question.
My suggestion (off the top of my head):
Pop-up a list of possible completions in the menu/list below.
If the user likes a completion, they can hit DOWN to scroll through
the options. In particular if there is a unique completion, hitting
DOWN provide `tab'-completion.
This provides a tabcompletion that:
* Is visually obvious (you hit down to scroll down the list)
{ Yes, there is a problem if the combobox is near the bottom of the
screen, so the menu pops above the combobox; thus,
make DOWN go to the FIRST item on the completion list,
and UP go to the LAST item.
This results in: consistent keyboard
usage (so you don't need to look at the screen) and intuitive
behaviour both times.}, which makes it easy for new users to discover,
and means that the non-standard (not TAB) key isn't a problem.
* Doesn't interfere with TAB navigation.
* Leverages the advantages of a GUI to show an updating list of
possible completions, which can easily be scrolled through
(or selected by mouse, if that's your game) (this actually makes it
MORE useable than a commandline!)</buzzwords>
The only problem I see with this is that the tab-complete list might
flash when updating quickly (esp. for fast typists); solutions would
be:
(a) fix the size of the tab-complete list box/window so it doesn't
resize when its contents change
(prolly make it as big as possible, though preferably below the
input box -- none of this microsoft 3-4 line endless scroll-buffer;
the user should see as many completions as possible)
(b) queue box refreshes, so it changes maybe 1x/second at most?
(this needs testing prolly)
(c) and if the user hits DOWN, immediately refresh the list based on
the completions of the current textbuffer.
Re: autocompletion:
The ONLY time you should have autocompletion (IMHO) is if the user is
selecting from a FIXED list of options (i.e., a popup menu), and there
is only one possible completion, in which case it would be fine to
either (or both):
(a) complete the user's input (but highlighting it so it can be
killed)
(b) make Enter select the unique completion.
The reasons I think this should be the only time that happens is:
(1) If there is not a fixed list of options, than maybe the user wants
to enter a new input which we don't know about, so we shouldn't
second-guess the user (in some webbrowser I had an awful time
trying to get it to NOT autocomplete -- I got in the habit of
leaving a SPACE right in front of my cursor so it wouldn't try to
autocomplete. This contortion should be avoided)
(2) If there's more than one possible completion, there's no
obvious/natural/canonical way to choose one completion over the
others. Any attempt to do so confuses the user `Hey, I wanted the
other one!'.
I think this resolves all problems (intuitive, useable, doesn't get in
the way/conflict with other user expectations)...
> I hope somebody will respond, so I can get these issues right before I
> release the next snapshot (which I intend to do in about 2 weeks)...
Sorry about not commenting earlier -- I've been a bit busy; however,
I'll definitely take a look at your next snapshot, and maybe at the
latest one.
--
-nils
Public key: http://www.nbarth.net/~nbarth/pub-key.txt
Attachment:
pgpoH4QgY652g.pgp
Description: PGP signature