Some thoughts on hiding the file system, (and an OS X anecdote)

[Carl Worth <cworth redhat com>]

On Sun, 12 Dec 2004 12:01:21 -0500, Havoc Pennington wrote:
> > The Unix file system isn't a design implementation that shouldn't be
> > exposed, its an inherent and deeply ingrained design choice that cannot
> > entirely be eliminated from the UI without a massive amount of pain.
> > Even MacOS exposes some of the nature of the file system. 
> 
> But OS X also does exactly what I am advocating ;-)

And I think the hiding in OS X already causes confusion, and as such is
not an ideal model for emulation.

Here's an actual experience that occurred last night. My wife
(non-"technical" user of OS X), was burning a CD of photos for my
sister. I had some of the photos she wanted on my (Linux) laptop so I
(being the nefarious shell-user of this thread) did the following:

	rsync -avz photos herlaptop:/tmp

And I said, you can find the photos in "slash T M P".

I wish I had an accurate recording of the confusion that ensued. The
final result was an exasperated, "I'm looking in T M P, and there are no
photos here", after which she gave up and handed me her laptop.

There were multiple causes of the confusion, but the common thread was
an attempt to hide the file system from the user interface. And not all
of these problems are unique to a "shell-user" being involved. Here's a
breakdown of what I learned after-the-fact, (along with commentary on
how things would happen in Gnome):

1) The "/" entry, is abstracted as "Macintosh HD". I didn't know the
   exact name for this, but it was well-positioned in the interface, so
   that my poor description, "the top-level computer icon or whatever",
   was sufficient for my wife to look there.

   [Gnome has "Computer" which is similarly easy to find.]

2) The abstraction of "/" hides most of the entries there. Only 13/32 on
   my wife's computer appear. I don't know what mechanism is used to
   determine which entries to display, but all of traditional unix
   entries, (bin, etc, tmp, usr, var) are hidden.

   [Gnome fortunately does not have any such mystic hiding.]

3) My wife also had a "tmp" directory in her home directory which she
   did find. The presence and name of this directory was almost
   certainly my doing. But the confusion came not from the name "tmp",
   but from two directories in the file system with a common name
   component.

4) There is a way to view "/tmp" in the file browser, but no
   direct-manipulation mechanism that I could find. I had to use the
   menu to select "Go->Go to Folder" and then use the file system name
   "/tmp".

   [Gnome does not have this problem due to the lack of hiding mentioned
   in 2. But nautilus does provide a similar filesystem-based interface
   through "File->Open Location".]

5) Finally, in the user interface, there is no way to distinguish a view
   of "/tmp" from "~/tmp" except by their contents, (ie. one had the
   photos of interest and one was empty). The titlebars of both folder
   views have a folder icon followed by the name "tmp".

   [Gnome behaves similarly in this regard.]

6) This ambiguous naming appears in other parts of the interface. The
   "Recent Folders" list now shows two indistinguishable names "tmp".

   [Gnome doesn't put viewed folders into "Recent Documents" but does
   have the same problem displaying "foo.txt" twice after opening
   /tmp/foo.txt and ~/tmp/foo.txt]

What lessons can be drawn here? The problem in [4] stems from actively
hiding aspects of the filesystem, (such as "/" for root and separator)
while at the same time providing no alternative mechanism for some
operations. That's clearly bad design.

>From the above, the only problem in Gnome is the ambiguous display in
[5] and [6]. I don't know if Gnome has an active goal to hide as much as
possible about the filesystem, (ie. "/ shall not appear in the
interface"). If so, I would contend it would be misguided.

I think it is appropriate to default to "trailing component only" when
displaying something like a folder view, but I think the full path
should be made available, (perhaps via something like View->Properties
which could display other attributes such as (recursive) size, and other
attributes such as whether the folder is currently shared).

As for the ambiguity in short lists like Recent Documents, I think that
there's good prior art in how emacs can be made to uniquify buffer
names[*]. With this tweak, buffer names are made unique by appending the
minimal unique trailing portion of the containing directory. For the
example of /tmp and ~/tmp, I get buffer names of:

	tmp
	tmp<cworth>

And also things like:

	Makefile<sound/drivers>
	Makefile<linux-2.6.9/drivers> 

I think something along those lines would be useful and easily
understood. I don't think it's helpful to try to prevent a user from
ever seeing a '/'.

-Carl

[*] By default, emacs appends consecutive integers to buffer names that
clash. This is a poor choice since the numbers have no intrinsic
semantic content, and worse, the numbers are not stable as buffers come
and go. Instead, with a minor tweak:

	(require 'uniquify)
	(setq uniquify-after-kill-buffer-p t)
	(setq uniquify-buffer-name-style 'post-forward-angle-brackets)

emacs can be made to use "minimal unique trailing portion of the
containing directory".