Save As mockup (Was RFP: File chooser user interface)

[Dave Malcolm <david davemalcolm demon co uk>]

On Mon, 2003-09-08 at 14:27, Owen Taylor wrote:
> GtkFileChooser is the next generation file selection widget for GTK+
> that will appear in GTK+-2.4. Quite a bit of work has been done on the
> application programming interfaces and on the internal implementation,
> but there is, as yet, no firm design for how the file selector should
> look and work.
> 
> This is a request for proposals for how the file selection user
> interface; what we are hoping to do is to get a number of user
> interface proposals, pick one or combine elements from multiple
> proposals, implement a first draft, and then refine from there.
> 

I've created some mockups of a "Save As..." dialog.

Users of Mac OS X (and, potentially, lawyers at Apple) may notice a
strong similarity between the proposal and the standard Aqua dialog.

You can see the basic form of my "Save As..." dialog proposal here:
http://www.davemalcolm.demon.co.uk/mockups/screenshot-save-as-basic.png

It's aiming to be as simple as possible for the user, although there's
quite a bit going on "under the hood".

Next to the "Where" label is an option menu.  This contains standard
locations to save to, bookmarks/favourites, and recent items, with
insensitive labels separating these categories.  Hence you can quickly
navigate to the various interesting places.  The working version of this
would have directory icons prefixing the places to give you extra visual
cues.

Clicking on "More Detail" yields an expanded version of the dialog which
you can see here:
http://www.davemalcolm.demon.co.uk/mockups/screenshot-save-as-expanded.png

The rather messy thing is a Next-ish/Midnight Commander style
horizontally scrollable path from the root(s) to the currently selected
directory.

The lists show all files and folders in a particular directory, but
filenames not matching the MIME type are insensitive.  Hence you can use
them for navigation purposes (for distinguishing all those different
directories) but can't overwrite e.g. "foo.jpeg" with a text file.

There are buttons to add new folders (useful to power users fairly
often, but not useful to novices), and to add the currently selected
path to the favourites (it should then appear in the option menu).

The filename extension is hidden by default; this can be adjusted using
the checkbox in the advanced version of the dialog.

Additional widgets, if needed, can be added at the bottom of the
expanded part of the dialog, hidden in the basic view.

If there is more than one filter, they are shown in this area with an
option menu to choose between them.  Otherwise the filter is not shown,
but is implicit (due to the way filename extensions are automatically
hidden).

Finally, power users can use the text entry field at the top of the
dialog to enter paths directly, with completion.


I've commented on some of the requirements below:

> 
> How the programming interface works
> ===================================
> The basic scheme is that the application creates a GtkFileChooser
> dialog with a number of buttons that it specifies; this buttons will
> be displayed along the bottom in the fashion of a standard dialog.
> 
> At any point, the application can query the selected file or files,
> and get notification when the selected files changes.
> 
> There are various configurable parameters:
> 
>  - The action of the file chooser: open mode or save mode.
Open mode and Save mode are too different from each other to cover with
a single design.  This proposal merely addresses Save mode.  I'm working
on a separate (though similar) proposal for open mode, which will be
optimised for a different set of tasks.

> 
>  - Whether the user can select multiple files at once

Not supported for the "save" operation.

> 
>  - Whether the user is selecting files or folders.

Trivially supported - just another mime type.

> 
> There are also several ways that the application can customize
> the user interface:
> 
>  - The application can provide a set of filters for the user to choose 
>    between. (JPEG files, etc)
See notes above.

> 
>  - The application can provide a widget that previews the currently
>    select file.
Appears at the far right-hand side of the horizontally-scrolling
browser.

> 
>  - The application can provide an arbitrary extra widget to packed
>    into the GtkFileChooser interface. (for example, a "open read-only 
>    checkbox" to the interface.)

As specified above.

> 
>  
> General considerations
> ======================
> 
>  - The design should strike a balance between ease of learning
>    and ease of use. It should be approachable for new users,
>    but also efficient for experienced users.

Basic design is very simple (yet easy to get at all "interesting"
directories); disclosure is used to present the relevant power user
features.

>    
>  - The design should take into account the fact that users 
>    will typically be familiar with and even switching between
>    this and the file selectors in other toolkits and operating
>    systems. A radically different user interface approach may
>    in fact be correct, but the tradeoffs of such should be
>    justified.
> 
Extremely similar to Mac OS X.

>  - The design should be accessible. As examples: all operations 
>    should be accessible through the keyboard. The design should
>    not use color as the exclusive way of indicating information.

I don't see any problems with this.

> 
>  - The design should allow selecting arbitrary files within
>    a heirarchical set of folders. The folder heirarcharchy
>    will generally depend on the environment, and may not match the
>    underlying filesystem. When run within GNOME, it will match 
>    that of Nautilus, when run within Windows, it will match
>    that of Windows Explorer.
> 
>    (The particular heirarchy should thus generally not be part
>    of the proposal.)

The root(s) of the hierarchy appear in the far-left of the horizontally
scrolling view

> 
> 
> Limitations of what is implementable
> ====================================
> 
>  - For GTK+-2.4, we'll need to stick to linear lists of
>    files, rather than grids of icons. Later revision of
>    the user interface to use a gridded display is possible,
>    so a design that woudl ideally use a grid, but can
>    initially use a list is a possibility.
>  - Designs should generally use standard GTK+ controls; while
>    writing simple new controls may be possible, it's going
>    to make the implementation tricker

I believe everything is done with standard controls.  Mockup was built
in Glade-2, with the exception of populating list controls and the
option menu.

> 
> 
> What to include in the proposal
> ===============================
> 
>  - What elements should be present and how they should interact

Detailed above.

> 
>  - Some rational for the above (how will people be using the file
>    selector, what are the important tasks that should be easy to do,
>    what is the relationship to file selectors that people are already
>    familiar with, if any.)

Specified above.

> 
>  - Composed mockups or screenshots done with Glade are not necessary
>    but may help to elucidate a proposal.

See above.

> 
>  - If you have, or can find, someone with the right skills, it
>    wouldn't hurt to have a working or partially working implementation
>    based on the code in the gtkfilechooser/ module in GNOME CVS,
>    but this is far from necessary.

I can code this if people want the idea taken further.

Thoughts?

Dave Malcolm