Re: RFP: File chooser user interface

[Magnus Bergman <magnus bergman observer net>]

This is my idea of how a file choser dialog should look like. First I
have listed the three main points I have taken into consideration.
Then there are "picures" of the three variations of the dialog (open
file, select directory, and save file as). And last there are some
comments and thoughts about the different parts of the dialogs.

1 Not a full fledged file manager.

  Personally I don't like the idea of file choser dialogs being able
  to do all sorts of different thing. (Like encrypting files and
  mailing them to your friend.) Object oriented design makes such
  things quite easy and tempting for programmers to add, but I do not
  find it usefull, just confusing.

  And if it is desired to have a full fledged filemanager in the
  dialog, it should be provided by a file manager. But GTK should not
  be depentant on any filemanager but provide it's own simple dialog
  (as fallback at least).

2 No context menus or hidden features.

  I appreciate that the current GTK file dialog has no context menus.
  I think it makes it fell robust and reliable, and of course easy to
  overview.

  The hidden feature (filtering and completion) in the current GTK
  file dialog is quite nifty, if you know about it. But the fact that
  it is hidden makes it useless to most people. I think the best
  would be to have a special widget for filtering. There the user can
  select a predefined filter or enter her own. Auto completion is not
  very useful in a file dialog anyway and can be removed without
  being missed too much I think. 

3 Works from top to bottom and from left to right.

  This is something I find extremely important in any user interface.
  Not the least in dialogs. Simply put, the first widget you need to
  pay attention to should be placed in the upper left corner and the
  last one (the OK button) in the lower right corner. To have things
  in this order feels natural and intuitive to us since it is the way
  we always scan things with our eyes (not only then we read). (I
  don't know about people using right to left locales, so I would
  be very interested in discussing this with someone who does.) My
  idea is that the user interacts with the widgets in a sertain
  order. And that should be the same order as she sees them when
  scanning the dialog. Then the user selects a file it typicly looks
  like this:

  1: That type of file to open (this affects which files are shown).

  2: Where is the file.

  3: Which file.

  4: How to open the file (in cases where is a choice).

  5: OK
  
  I bevieve this is the main thing to consider then designing the
  layout of the file choser dialog (or any other dialog for that
  matter).



+--- Open (File) ----------------------------------+
|                                                  |
|  Filter [___________________________________[V]  | (1)
|                                                  |
|  +- Root -+- Directory -++- File -+- Preview -+  | (3)(4)(5)(6)
|  | A:     |             ||        |           |  |
|  | C:     |             ||        |           |  | (7)
|  |        |             ||        |           |  |
|  +--------+-------------++--------+-----------+  |
|                                                  |
|  Selected File [______________________________]  | (10)
|                                                  |
|  + - - - - - - - - - - - - - - - - - - - - - -+  |
|  |                                            |  | (11)
|  +- - - - - - - - - - - - - - - - - - - - - - +  |
|                                                  |
+--------------------------------------------------+
|  [ Help ]                     [ Cancel ] [ OK ]  |
+--------------------------------------------------+

+--- Select Directory -------------------+
|                                        |
|  +- Root -+- Directory -+- Preview -+  | (3)
|  | A:     |             |           |  |
|  | C:     |             |           |  |
|  |        |             |           |  |
|  +--------+-------------+-----------+  |
|                                        |
|  Selected Directory [_______________]  |
|                                        |
|  + - - - - - - - - - - - - - - - - -+  |
|  |                                  |  |
|  +- - - - - - - - - - - - - - - - - +  |
|                                        |
+----------------------------------------+
|  [ Help ]           [ Cancel ] [ OK ]  |
+----------------------------------------+

+--- Save As -------------------------+
|                                     |
|  Filter [______________________[V]  | (1)
|                                     |
|  [ Create Directory ]               | (2)
|                                     |
|  +- Root -+- Directory -+- File -+  | (3)(4)(5)
|  | A:     |             |        |  |
|  | C:     |             |        |  |
|  |        |             |        |  |
|  +--------+-------------+--------+  |
|                                     |
|  [ Delete File ] [ Rename File ]    | (8)(9)
|                                     |
|  Selected File (name) [__________]  | (10)
|                                     |
|  + - - - - - - - - - - - - - - - +  |
|  |                               |  | (11)
|  +- - - - - - - - - - - - - - - -+  |
|                                     |
+-------------------------------------+
|  [ Help ]        [ Cancel ] [ OK ]  |
+-------------------------------------+



(1) Filter

  This is a combobox that (kind of) does two things. It lets the user
  selected one of the filters supplied by the application. And it
  lets the (more experienced) user enter her own filter to show a
  cusom set of files. This is meant to replace the currently hidden
  feature. It could be used to show hidden files (be eftering ".*").
  Maybe the filter should affect the directories as well (so that
  hidden directories could be shown). I'm not sure how the user
  shuold tell the dialog that she is done typing and wants the files
  filtered. Most users would probably want to press enter, so maybe
  there should be a filter button which becomes default then the
  filter widget is active (like in motif)? Or should maybe the
  filtering should be done when the filter widget looses focus (so
  the user should press tab)?

(2) Create Directory

  This might be considered bloat, but I find it quite useful.
  Sometimes then you save a file you want to create a new directory
  to put it in. It might be a little controversial to suggest that
  it shouldn't be placed together with the other buttons. But I look
  at it like this: first you create the directory, then you select
  it. But I guess it could aswell seen as this: you create a
  directory and implicitly selected it instead of using the directoy
  selection widget(4). I find no reason to include this button in a
  open dialog.

(3) Root selection

  I don't really have any good idea what to call this, but the idea
  is to let the user choose between different directory trees. On DOS
  like systems it has an obvious use. (Actually I stole this idea
  from GEM which I use on my Atari ST). On plain UNIX like systems
  (without Gnome or such) this widget might be pointless, but it
  would be useful for the directory bookmark feature discussed
  earlier. Alternatively its content could always be either appended
  or prepended to the content in the directory selection widget(4).
  This is a popular design in many DOS programs.

(4) Directory selection

  A plain old directory list. On the top there is an up-directory
  item. I think this is better than having an up-directory button.
  It doesn't have to be called ".." but rather "[up]" or something
  that is easy to understand. It will be analogous to how browsers
  (at least the ones I use) represent FTP directories, and therefore
  familiar to many users.

(5) File selection

  A plain old file list with ONE column of files.

(6) Preview

  The preview is placed on the right side of the file selection
  widget(5) since it is closely related to which file that is
  selected. Not together with the custom widgets(11) which are more
  related to how the file is opened (and that is something the user
  deals with after she has selected the right file). In the case of
  directory selection the content of the directory can be considered
  a preview, but that hasn't much to do with the implementation, just
  with how you look at it.

(7) Directoy/file separator

  Both the root selection widget(3) and the preview widget(6) has
  fixed minimal sizes. The rest of the space is shared between the
  directory selection widget(4) and the file selection widget(5) and
  can be adjusted by the user. From what I have seen users tend to
  give longer names to files than to directories, maybe this should
  be considered by the default placement of the divider?

(8) Delete File

  I'm not sure this button is needed, it will possibly do more harm
  than good. A potential use could be to delete obsolete files then
  saving saving a new one. But I think make more sense to either
  overwrite an obsolete file (if it has the same name) or delete the
  files with a separate file management program.

(9) Rename File

  This I find useful and justified in the case one want to use a
  specific filename but also save an old file with that name. Maybe
  it would be better with a dialog that says "a file with that name
  already exists do you want rename or owerwrite the existing one?".
  But that is kind of a hidden feature, a new user would not assume
  that this would happen (and probably rename the file with another
  application first).

(10) Selected File (or Directory)

  Having this widget at all in an open dialog is not very useful. But
  I find myself using it to give temporary names to files without
  saving them, then either save them or just delete them at a later
  point (in the Turbo Pascal IDE for example). But I wouldn't cry if
  it was excluded from the open dialog.

(11) Some other optional widgets supplied by the application

  If the application wants to add extra widgets to the dialog they
  should be placed here. I can not think of any other use for this
  than to give the user some option related to how the file (or
  directory) should be opened or saved. If there exists sane cases
  there widgets with other uses are needed, maybe they should appear
  somewhere else?