My second file chooser proposal

This is my second proposal for a FOSA dialog. The basic philosophy is
the same as in my first one, but a few new things has been taken into
consideration. Mainly as a result of discussions a have had with
several different people. I will first list three points (which
really apply to any dialog), and then discuss the three variations
of the dialog (which I believe is required).

1 A dialog is not an application.

  Or, more specifically in this case, a FOSA dialog is not a file
  manager. I think it's a bad idea to make it resemble any file
  manager. Any user should be able to clearly distinguish the
  differences between an application window and dialog. (This was not
  a problem until the world got invaded by windows inspired
  strangeness.) I've seen users who fire up the word processor,
  creates a new document and selects "save as", just to find their
  files. They must see their desktop as a jungle with a few known
  safe location from which they know what to expect. Stop the

2 All features should be clearly visible.

  I think that dialogs should be designed a way which makes context
  menus and eventual hidden features unneeded. Ideally, tool tips
  shouldn't be needed either. (This applies to dialogs, not
  application windows.)
3 Works from top to bottom and from left to right.

  A human scans through information in this order, therefore the
  widgets should be placed in this order. (See my previous mail for
  more details.)

Directory Selection Dialog

There should be a separate dialog for directory selection. It is not
a variant of the open dialog, nor the save as dialog. I don't think
it is necessary to distinguish between "open directory" and "save
directory", just "choose directory" will do. Sure the different uses
of it will be more open oriented (like "Add a directory to share") or
more save oriented (like "Move file...").

+--- Select Directory -------------------+
|                                        |
|  command-line-like navigation          | (1)
|                                        |
|  [ Create Directory ]                  | (2)
|                                        |
|  +- Root -+- Directory -+- Preview -+  | (3)(4)(5)
|  | Home   |             |           |  |
|  | A:     |             |           |  |
|  | C:     |             |           |  |
|  |        |             |           |  |
|  +--------+-------------+-----------+  |
|                                        |
|  + - - - - - - - - - - - - - - - - -+  |
|  |                                  |  | (6)
|  +- - - - - - - - - - - - - - - - - +  |
|                                        |
|                     [ Cancel ] [ OK ]  |

(1) command-line-like navigation

  This widget is hidden by default and must be explicitly enabled in
  gtkrc. I allows to user to type in the directory with auto
(2) Create Directory

  A button to create a new directory inside the selected one. It pops
  up an input box and makes the newly created directory the selected

(3) Root list

  I'm not involved in the discussion about what should go into this
  list, and I have no real opinion about it. But this is where I
  think it should be placed. Alternatively it can be merged with the
  directory list (so the "roots" show up in every directory).

(4) Directory selection list

  I'm not sure if this should be a plain list or a tree. I will try to
  sum up the advantages and disadvantages with each.
  If a plain list is used:
  + It will be easy to overview and not too much information.
  + Single click navigation (like in GQView) could be used.
  - Multiple directories can only be selected if they are in the same
  If a tree is used:
  + It will be easy to overview the whole tree.
  + Possible to distinguish between several similar directory
  + Multiple directories can be selected anywhere (if the have the
    same root that is).
  - A potential scroll-nightmare.

(5) Directory preview

  What I call a preview here is (most probable) a list of files inside
  the selected directory. It could also tell the number of files and
  the size of all files together. I think this should be considered a
  preview and it should be hidden if a preview is not requested (by
  the application).

(6) Optional widgets supplied by the application.

  Some options about how to treat the selected directory. I guess this
  will frequently be "include sub directories" and "follow symlinks",
  but of course also things that only makes sense to a single

Open file dialog

  This dialog contains an idea which will probably be considered mush
  too radical and different by most people (including myself actually).
  It can be ignored, so don't let it affect your opinion on my
  proposal in whole. The idea is that the user typically only selects a
  directory the first time she opens or saves a file. The preceding
  times the same directory is used. Therefore the directory navigation
  widgets are not needed in the dialog and can be replaced by a button
  for changing directory. (Again, just ignore this and read on if you
  don't like it.)

+--- Open (File) --------------+
|                              |
|  Directory [_____] [Browse]  | (1)
|                              |
|  Filter [_______________[V]  | (2)
|                              |
|  [ Select All files ]        | (3)
|                              |
|  +- File ---+- Preview ---+  | (4)(5)
|  |          |             |  |
|  |          |             |  |
|  +----------+-------------+  |
|                              |
|  + - - - - - - - - - - - -+  |
|  |                        |  | (6)
|  +- - - - - - - - - - - - +  |
|                              |
|           [ Cancel ] [ OK ]  |

(1) Current Directory (or location as some likes to call it)

  This widget only shows the current directory, it can not be edited
  by default. But if the auto completion feature is enabled (in gtkrc
  see above) the (power) user can type in the directory with auto
  completion. To change the directory you press the browse button which
  brings up a directory selection dialog (or alternatively inserts
  one into this dialog). (Again, just ignore this and read on if you
  don't like it.)

(2) Filter combo box

  This widget does two things. It lets the user select one of the
  predefined filters (supplied by the application). And it lets the
  user enter her own filter. (See my previous mail for more details).

(3) Select all files button

  This button will only show up if multiple selection is allowed.

(4) File selection list

  A plain list with only files (no directories). If multiple selection
  is allowed, clicking will toggle the selection of the file.

(5) Preview

  A preview of the file and/or perhaps some meta data, whatever
  appropriate. I guess this will usually be provided by the
  application. Some people has suggested that previews should be
  removed completely in favour of thumbnails. But I think that is a
  task for the gnome file chooser, not the default gtk one.

(6) Optional widgets provided by the application

  Widgets to select how the file should be opened. It has been
  suggested that only a limited set of options are needed (such as
  "open read only") and that there is no need for applications to add
  their own. I disagree. There might be need for things such as:
  * Load the whole file into memory or disable some advanced features.
  * Use the global setting from the file or convert it to the current
    global setting.
  * Import the file and loose some meta data or allow only limited
  These examples has no general use, out of context they mean nothing.
  But to some application they might be crucial. It has also been
  suggested that all the options can be replaced with an button for
  the options. But in that case I think it's still needed to present
  a summary of the current options (otherwise many users will feel
  uncertain and frequently click options button just to make sure).
  And I really think this is a problem for the applications to solve
  (in some cases a button may be better and in other cases not).

Save As dialog  

  This is much like the open dialog and I will only go into the

+--- Save As -----------------------+
|                                   |
|  Directory [__________] [Browse]  |
|                                   |
|  Filter [____________________[V]  | (1)
|                                   |
|  +- File ------+- Preview -----+  | (2)(3)
|  |             |               |  |
|  |             |               |  |
|  +-------------+---------------+  |
|                                   |
|  [ Delete File ] [ Rename File ]  | (4)
|                                   |
|  File Name [___________________]  | (5)
|                                   |
|  + - - - - - - - - - - - - - - +  |
|  |                             |  |
|  +- - - - - - - - - - - - - - -+  |
|                                   |
|                [ Cancel ] [ OK ]  |

(1) Filter combo box

  Apart from applying a filter on the file list it might also be used
  to add an adequate suffix to the filename.

(2) File list

  It has been discusses whatever or not it is necessary with a file
  list in the save as dialog. But I think it is for the following
  * One might want to check how the other files are named before
    deciding on the new filename. Either to be consistent with the
    other names. Or make sure it the name is unique enough.
  * One might want to use the name of an old file as a template for
    the new name.
  * One might want to select a certain file to overwrite.

(3) Preview

  This might be useful for finding the right file to overwrite. Or
  perhaps to find a similar file in order choose a similar name.

(4) Delete/Rename file buttons

  These are only here as a better alternative to a context menu. Maybe
  they should be hidden by default?

(5) File name entry

  This is the main difference between the open dialog and the save as
  dialog. It does nothing apart from letting the user enter the
  filename. (The optional auto completion stuff is in the filter
  combo.) The main thing is that I believe it should be placed here
  and not somewhere else in the dialog.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]