Re: [Usability] Re: RFP: File chooser user interface

[Benjamin Kahn <xkahn ximian com>]

On Mon, 2003-09-15 at 12:05, Calum Benson wrote:
> On Mon, 2003-09-15 at 17:20, Magnus Bergman wrote:
> > It has come to my knowledge that there is a minority of users who make
> > heavy use of the auto completion feature. So I've been that convinced
> > that it must stay. But I'd like it to be disabled by default (so the tab
> > key works as expected).
> 
> Agree the Tab key ought to work for navigation by default, but there are
> ways to do auto-completion without without using the Tab key, e.g. like
> it's done in most browsers' address bars these days.  Not suggesting
> that's necessarily the way to go, but having hidden/advanced features in
> something that should be as simple as a file dialog sounds a bit scary
> to me :)

	I can think of three different completion methods being used by
different applications.

	1. Event completion.  When the user triggers the completion system
either by pressing some key or a button, the interface changes to
reflect either the filter, or to fill in more file information.  (The
current file dialog uses the tab key to handle both filtering and
completion.  Another example would be the Motif file dialog which used
an explicit filter button, but did not seem to have completion.  Windows
uses this a little with a drop down filter list.)

	2. Auto-fill completion.  While the user is typing, the application
fills in a file name in advance.  If the user ignores the filled in
values, they are replaced by the user data.  One key allows the user to
accept the input, another allows the user to reject the suggestion. 
Note that the filled in information may not be unique.  (StarOffice uses
this method in it's file dialogs.)

	3. Drop-down completion.  While the user is typing, the application
provides multiple possible completions in a drop down box under the
entry box.  (MSIE and Firebird and Evolution all use this method of
completion.)

	Note that since file objects might be remote and over slow (or
unavailable) links, performing the completion might be very expensive. 
Method (1) allows the user to request the lookup when they believe it's
okay, while methods (2) and (3) perform the lookup frequently.  

	I find version (2) to be quite difficult to use.  I never remember
which keys cancel the completion, for example.  Version (1), of course,
is a hidden feature which will only be discovered by accident (TAB
usually skips to the next widget) which might be unwelcome, or only used
by advanced or power users.

	So, I imagine a user test is needed to decide if beginner users are
helped by completion.  If so, (3) may be the best.  If not, (1) could be
the best case.

-- 
Benjamin Kahn <xkahn ximian com>