Dialog boxes from 10,000 feet

["Christopher D. Beland" <beland MIT EDU>]

First, I'd like to take a step back from the specific of buttons and
keybindings to talk about how the different pieces of the Gnome
dialog box system should fit together.

>From a user interface perspective, there are several related but
distinct tasks we've been talking about (feel free to add to these
lists):

 - Open single file (with current application)
 - Open multiple files (with current application)
 - Open file(s) in current application with preview
 - Open file(s) on remote filesystem
 - Save working document (in a particular format)
 - Save all files (in current application)
 - Chose a program (for a particular purpose - opening, adding to a list)
 - Chose MIME type for this file
 - Chose ____ from a list

And we've been flaming about what functionality and Look and Feel
these dialogs should have, like:

 - Layout
 - Scrolling style
 - Highlighting style
 - Auto-completion (both visual and command-line)
 - Keyboard accelerators/accessibility
 - Application-specific filtering
 - User-defined filtering
 - System-wide filtering
 - File/directory history

And been trying to include various file management tasks like:
 - Delete
 - Rename
 - Move (rearrange)
 - Find files


Here's some higher-level principles I propose that might help sort out
some of the problems we've been discussing:

 - Common dialog boxes should be constructed as components that all
   applications can call on the fly.  This provides the benefits of
   code reuse without the expense of firing up a monolithic
   application.
 - Not all dialog boxes should have the same functionality.  For
   example, if an application cannot accept saving or opening multiple
   files, the dialog box should not try to facilitate this.
 - The dialog boxes should have a consistent Look and Feel (layout of
   buttons and windowpanes, scrolling behavior, general way of
   interacting, keyboard accelerators). It's OK if everything doesn't
   work everywhere, but doing the same thing in different places
   should produce the same results.


How I Think Things Should Work...


Because there are a multitude of dialog boxes that the user might
encounter in any number of applications, there needs to be a global
preference dialog for dialog boxes (how meta...) which is accessible
both from Control Center and from the dialog boxes themselves.  From
here, the user should be able to turn auto-completion on/off, set
filters, rebind keys, and otherwise alter dialog box behavior.

It seems to me that it would be really useful if you could open or
save to any location you have permission to do so, whether that be on
local disk, or on an HTTP, FTP, SMB (et. al) file system somewhere
else.  Certainly if I'm opening or saving, I want to be able to just
type "/home/beland/paper.txt" hit Enter, and have the system DTRT
without any other input needed from me.  But I'd also like to be able
to type "http://beland.mit.edu/picture.gif" and have it open across
the network.  The Nautilus project seems to be hiding protocol support
for circumstances like this under the gnome-vfs abstraction layer; it
makes sense for other bits of Gnome to take advantage of this.  

It also seems likely that directory tree and file displays should be
components provided by the file manager, but maybe not.  It would be
nice if the components of Nautilus that the dialog system uses were
installable separately, so users of other GFMs wouldn't suffer.  But I
think it's probably even more critical to not load redundant code on
people who have a default installation.  But I don't know enough about
how the system works to make an informed opinion.

But anyway, in terms of user-visible pieces, there may need to be
something in the tree display (perhaps above the root level of the
local file system) that advertises to the mouse-only user that say,
http:// URLs are valid input.


Specifics...


Take "open single file with current application" as a starting point.
We can argue about what this dialog box should look like, and what
various keys, modifiers, and clicks should do.  (Due to the amount of
traffic and confusion of this with other dialog boxes, I'm not sure
what the current consensus favors here, and which questions are left
unsettled.  Could maybe someone who is actually thinking about doing
implementation perhaps post a summary at some point?)

For "open multiple files with current application" you could have a
button "Select multiple files" that toggled on and off.  When it's on,
single mouse clicks expand the current selection to include new files;
when it's off, single clicks just change the current selection.
Alternatively, the usual select-multiple-files convention (Ctrl-click)
could be used, and the text "Hold down Control to select multiple
files" added to the box.  "Select all" and "Deselect all" buttons
should also be present - maybe even an extra box (with pulldown)
labelled "Select all files that match..." so I could, say, select
files that are named "icon*.jpg" as I am often wont to do.
(Checkboxes are only a good idea if you are selecting multiple files
in multiple directories, methinks, and even then, I think there
*might* be better ways to do it.  Functionally, checkboxes are
actually no different than just highlighting the file name.)  Other
ways to select multiple files (Ctrl-Arrows, etc.) might be useful for
advanced users.

"Preview" functionality is really useful, especially for graphical
files.  I might also want my MP3s or Quicktime files to have their
titles extracted from inside the actual content.  Or have a window
listing the contents of a plaintext or HTML file, or the files
contained in an RPM archive or tarball.  Sometimes, you want the
preview to be used as the files' icons, and other times you want a
single pane for previewing files one at a time.  There are a couple of
ways to solve this problem:

 - Letting the application specify a component to display the preview
 - Have a central MIME types registry automatically determine the
   component to use
 - Both: Let the application override the default MIME listing

Or maybe previewing is too hairy, and you'd rather give this
functionality through a button labelled "Browse current directory in
[name of Graphical File Manager]..."

Punting to the file manager certainly makes sense for those occasions
when you realize that you've forgotten to do something, or you need to
open a file in a *different* application, or don't remember what
application opens it.  It makes less sense for operations that help
you decide (in a very immediate sense) which files you actually want
to open (which previewing does).  As such, I'm a little on the fence
about whether or not "Delete" "Rename" and "Create Directory" should
be in the Open dialog boxes.  These are often necessary for write
operations, but I think would be less needed for read operations
(especially on read-only filesystems, of course) and removing them
would reduce clutter.

Applications may also want to specify what kind of files they can
open, but it is dangerous to filter out files from the user by default
- especially if you are depending on file extension.  Though I do
agree that dotfiles should be hidden by default, but with a "Show
dotfiles" option included prominently.  (I have also been the victim
of many interfaces which force me to slog through a bjillion dotfiles
in my homedir.)


I don't know if anyone is actually arguing for a "save multiple files"
functionality in the dialog box system.  It does make sense for an
application to ask "Overwrite existing files? (All / None / Specify
files...)"  when you chose "Save all..." from an MDI.

"Save as..." would certainly need the application to specify which
formats it is capable of saving in if there is more than one.


Certainly, the default place to save/open files should be the user's
home directory (and *not* the directory where the calling program
happened to have been installed, or necessarily its current working
directory).  Certain applications may wish to override this (if they
are asking a user to chose, say, an icon from a known location) and
advanced users may reconfigure this.  Believe it or not, this is
actually an area of significant user confusion in many interfaces.
("Where did my file go?!?")

Speaking of choosing icons, this task is equivalent to choosing a file,
except with certain filters and preview functions enabled.  There's
not very much reason to have a separately designed and implemented way
to do this.  


Also sorely needed is a system-wide "program chooser."  There are any
number of places where I might need to chose a program off a list, say
to open a file with (e.g. GFM), add to a list (e.g. session
management), or add to a list in a complex way (e.g. gmenu, which
requires copying meta-data along with program path).

"Programs" are both distinct and not distinct from "files."

Distinct: I'm a novice mouse-only user.  "Programs" are things that
pop up from the Gnome footprint menus which I can run.  "Files" are
things I open and edit and save, and which I use the "file manager" to
move around, rename, delete, etc.

Not distinct: A program (say, a Perl script) can live in a user's
homedir along with other files.  Or it may live in /usr/local/bin
along with other files not menu-accessible. 

gmc actually has an "Open with..." dialog that gives you a big tree
that represents your existing menu tree, and below that, a line to
specify a command, and a "Browse..." button.  I don't have any
complaints, other than that other Gnome configuration tools and
applications should be able to use this functionality.


At this point, I'm not sure what things should be automatically
remembered system-wide vs. only for a particular application or
file type, since I'm not sure what features we've actually agreed on.


Usably yours,

Chris Beland
MIT Athena User Interface Project