Re: FileChooser's path bar and re-rooting

[Seth Nickell <snickell redhat com>]

Rerooting *is* a violation of the conceptual purity of the path bar. Why
do it then? 

In interface design the first goal is to deal with the most common use
case well, then branch out to handle the other cases with as little
impact on the common case as possible (this differs substantially from
code design / architecture where "edge cases" often become central to
the design).

Here are two broad use categories guiding the design of the file
chooser:

1) Corporate desktop users working with documents
2) Traditional *nix developers

(1) is the primary use case. It involves relatively shallow use of
heirarchy, almost always constrained to the home directory.

(2) is the secondary use case. It involves deep *nix heirarchies, and
will often leave the home directory.

In some sense, the path bar's existence is primarily for (2). But while
we want to accomodate (2), we need to make sure it doesn't substantially
impact (1). Rerooting [home] allows a pathbar to exist without pushing
noisy (and often technobabble) text into the interface for (1).

I have a more "elegant" long term direction for the design that also
addresses some other downsides to the existing design. Currently the
flow of control between the list on the left hand ("shortcut" list), the
path  bar, and the file list is not very clean. The shortcut list
contains commands rather than encapsulating state. Further, we have a
one-off exception for rerooting the home dir... but from a user's
perspective going to one of the mounted devices (if using the GnomeVFS
flavour) also reroots the path bar. So some things reroot and some
things don't.

Instead of treating the list on the left as shortcut commands, we
explicitly define it as not controlling the file list, but as tied to
the state of the path bar's root.  One item in the list is always
selected, and controls the root of the pathbar. The pathbar's toggled
state, in turn, controls the current folder displayed by the file list.

For Category (1) users:
  - Items in the list on the left represent folders of particular
interest: current projects, a shared workgroup folder, etc. When they
want to use this folder, they want the "Henderson Project" folder, not
"/home/jferguson/Desktop/Documents/Henderson Project". That is, by
virtue of being a named object of primary interest, its place in the
heirarchy is not a relevant cognitive factor in referencing the object.
The object is effectively promoted to define its own context (and
becomes the context of any files and folders it contains: "the tax
spreadsheet in the henderson project folder").
  - All items in the list on the left behave the same, and interact
consistently with the path bar, so a useful mental model is more likely
to develop

For Category (2) users:
  - You switch to the Filesystem state and get full file paths. The
dialogue remembers this state in the same way that it remembers what the
last folder you were in was
  - We have a control (the path bar) that aids in the annoying task of
navigating deep heirarchies from a graphical interface

-- 
seth nickell :: interaction designer :: red hat