[Usability] My second file chooser proposal
- From: Magnus Bergman <magnus bergman observer net>
- To: GTK+ devel <gtk-devel-list gnome org>
- Cc: Usability List <usability gnome org>
- Subject: [Usability] My second file chooser proposal
- Date: Mon, 15 Sep 2003 21:15:18 +0200
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
madness!
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
completion.
(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
one.
(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
directory.
If a tree is used:
+ It will be easy to overview the whole tree.
+ Possible to distinguish between several similar directory
structures.
+ 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
application.
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
editing.
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
differences.
+--- 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
reasons:
* 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]