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

[Magnus Bergman <magnus bergman observer net>]

On Mon, 15 Sep 2003 13:25:36 -0400
Benjamin Kahn <xkahn ximian com> wrote:

> 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.

I see this as two different problems. Applying a filter is one and
performing completion is the other.

For the first one (applying a filter) I suggested the use of a combo box
where the user could either choose a filter (supplied by the
application) which I think should apply immediately, or the user could
enter her own filter. I think most users feel it's natural to press
enter to apply the custom filter, and to deal with that I think (1) is
the best solution. That is, making a filter button the default one then
the filter combo box is active. Or perhaps leaving the filter combo box
should apply the filer and the enter button will do just that, leave the
combo box (and maybe make the file selection list active).

For the second one (performing completion) I think it should only exist
for those people who are very used to tab completion. For the others I
don't even think it should be possible to type in the path by hand. If
should be i think typeahead searching in the directory/file lists will
be much more useful (and in that case it should be implemented in the
list/tree widget, not in the FOSD).