Re: RFP: File chooser user interface

[Thomas Leonard <tal00r ecs soton ac uk>]

On Mon, Sep 08, 2003 at 10:27:48AM -0400, Owen Taylor wrote:

> 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 think this scheme has already been dismissed, but I'll present it anyway
for completeness.

I won't talk about Open dialogs. I guess most people open files from their
filemanager, drag-and-drop to the application, or use cut-and-paste.
Having a separate dialog for this seems unnecessary, but could be useful
in emergencies as an expert feature, I suppose.

As others have suggested, please ensure that the saving and loading APIs
are separate, so that the dialogs can be presented differently.

The save box looks like this:

  +------------------+
  |                  |
  |     +------+     |
  |     |      |     |
  |     | Icon |     |
  |     |      |     |
  |     +------+     |
  |                  |
  | [Filename______] |
  |                  |
  |  [Cancel] [Save] |
  +------------------+

Users enter a name for the file, and then drag the icon to their
filemanager or a desktop icon, etc.

If the file has been saved before, 'Filename' is the complete path, with
the leafname selected by default. This allows easy resaving to the same
directory (Draft1, Draft2, etc) without extra dragging (the user saves by
pressing Return or clicking Save in this case).

Advantages:

- Very small, simple dialog.

- After saving, the file manager window is open, showing the saved file.
  This is exactly the view the user will see when opening the file later,
  avoiding the problem others mentioned that the user may not recognise
  their saved file.

- Can (possibly) save to other applications, eg by dragging an image from
  Gimp's savebox into a KWord frame.

- Since the user's filemanager is involved, all normal functions
  (searching, bookmarks, recently visited directories, rename, etc) are
  available, with a familiar interface.

- No problems about which 'default' directory to use. If the user wants to
  use a directory again, they keep the filer window open. Also, this
  allows automatic sharing between applications (I can save from Gimp, and
  then drag the newly saved file from that directory into KWord, etc).
  Any number of directory windows can be kept open (or minimised, etc).

- Desktop icons and panels can be used automatically.

- No need for thumbnailing, filters, properties, etc. The file manager
  provides all that.

Power users can enter a filename with tab completion (or whatever other
completion system we use). If a path component doesn't exist when the user
clicks Save, they are asked whether they want to create it as a directory.

The system is already implemented. Screenshots:

http://rox.sourceforge.net/phpwiki/index.php/HintsAndTips
http://rox.sourceforge.net/archive.html


Of course, people may not want this as the default (compatability with
Windows is important to many people here). Some useful things to have,
though:

- Separate save and open APIs.

- Save API:
  - Application provides MIME type and default name.
  - Save box provides application with a pathname to save to.
  - Application indicates when save is finished.
  - Save API tells application the new name (URI).
  
  This allows us to implement drag-and-drop and saving to remote machines,
  etc, by asking the application to save to a temporary file and then
  sending that (this is why the new name may not match the path the app
  saved to).

- Please, replace all Rename, Delete, New directory, etc buttons with
  'Open directory in filemanager' button. This is pointless duplication,
  whatever filemanager the user prefers.

Hope that's of some interest...


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1