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

[Kalle Vahlman <kalle vahlman gmail com>]

On Mon, 13 Dec 2004 07:07:50 -0500, Carl Worth <cworth redhat com> wrote:
> 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

I would hesitate to call this a typical or desired way to share files.
If you wish, you can share stuff through /usr/bin too, but I suppose
you'd have little or no help from GNOME to do it...
 
> 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.

But most are?

> 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.

You mean "traditional unix SYSTEM entries". Anything outside /home is
to my knowing not intended for users. Or why use /home at all if this
is not the case?
 
> 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.

I think this is something that has been discussed before, and some
good options came up. And there's always the bottom-left corner of the
window (perhaps there's a good reason to show the object name
(duplicate, btw) there instead of showing the parent?)
 
> 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".

Funny, I'd say this was a great feature! :)

>    [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".]

...and should be in GNOME, too.
 
> 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.]

This is issue 3.
 
> 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.

It's bad desing to hide things not meant for users to manipulate? No,
I don't think so.
 
> >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.

Or a Champion of Usability, depends on what angle you look at it.
 
> 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

It is, in the bottom-left corner demanding only one click. If the
previously discussed emblem stuff would magically be implemented, it
could be obvious from the looks of the window.

-- 
Kalle Vahlman, zuh iki fi