Re: List/tree widgets and keyboard navigation

[Calum Benson <calum benson sun com>]

Owen Taylor wrote:

> I think everybody would agree that its a nice feature for applications
> to have. The observations I would make would be:
> 
>  - It can't be handled automatically by the GTK+ widgets, since:
>  - It only makes sense for sorted lists.

>From the user's point of view, I'd say it's at least as useful on
*unsorted* lists, if not more so-- it's a lot more difficult to find an
object whose name you know amongst a collection of randomly-sorted
objects.  (MS Windows, or at least some Windows apps, don't make the
sorted/unsorted distinction; you can type whether the list is sorted or
not).

>     - A list may have 0 text columns or multiple text columns,
>       and for multiple text columns, the first column is not
>       always the correct column.

True, that is a problem with the Windows implementation too, although
MFC's multi-column lists are a bit of a usability disaster all round,
really!

One solution might be to use the column by which the list is currently
sorted as the one that is used for searching; or if the user hasn't
specified a column to be sorted, use the first column by default.  (An
up or down arrow marker on the currently-sorted column would be useful
feedback here too, but I don't think GTK does this just now either, does
it...?)

>  - This does not internationalize well.

Good point-- I honestly don't know if international versions of Windows,
for example, permit this functionality or not, or provide an
equivalent.  (If anybody is running such a version and can let us know,
it would be nice to find out.)

On the other hand, you could argue that just because a useful feature
can't be made available to one set of users doesn't *necessarily* mean
it should be unavailable to all... but that's probably a whole different
discussion in itself.

>    Any application with seriously large lists should provide
>    a search dialog so that the user can enter the search
>    string in an entry with all the editing facilities
>    of the entryt.

Indeed it should.  (Not that applications should employ "seriously large
lists" of anything anyway, if it can be avoided... especially as GTK has
a finite limit on the number of things that can be displayed in a list
anyway, as we've just read in another thread!)

>  - what is the correct behavior for a tree? My guess would
>    be that it should consider only the nodes of the tree
>    at the current nesting level

Good question... although my first guess would be "any nodes that are
currently visible".  That's off the top of my head, but I think I'd be
extremely annoyed if, having typed the first couple of letters, the tree
had scrolled to the first match and I could now see the object I wanted
to select a bit further down the tree... but when I typed its next
letter it remained unselected, because it happened to live at a
different tree level.

That sort of level of detail would be definite candidates for
prototyping and usability testing, though.

>  - If you are handling "the first few letters", when do you
>    decide to reset and start over?

Good question again! Windows just uses a preset delay, which often
catches people out-- well, me at least...

There's no way of changing the delay as far as I know, and no visual or
audible feedback from the control to say "your search has timed out--
next time you press a key, you'll be starting over again".  That's a
definite disadvantage of this method.

>My personal feeling is that it should reset at:
>- focus in and focus out
>- any keypress other than an alphabetic key

Perhaps even just having a single "abort search and restart" key would
do the job here?  E.g. pressing Esc, or something else that isn't bound
to another action while a list/tree item has focus.  Although the
question would then be, how would a user find out about that key? (A
message in the app's status bar, if it had one, when you started
typing?) 

Windows' preset delay does have the advantage that you can "abort" one
search and start another just by waiting for a second or two and
starting to type again-- which is sort of transparent in many cases,
with no extra documentation or knowledge required, but can easily catch
you out if you want to do multiple searches in quick succession.

>    Note that the Windows tree widgets handle only the first
>    letter, and a string like 'bbb' gives you the third
>    entry starting with 'b'.

True, the MFC control does only handle the first letter, but there are
other third-party controls (e.g. in RogueWave's Stingray libraries) that
give you the same keyboard functionality in a tree as in a list
control.  Unfortunately I don't recall off-hand how they address some of
the issues you brought up here, though... something else to investigate
at some point, perhaps.

Cheeri,
Calum.

-- 
CALUM BENSON, User Interface Designer  Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Enginering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems