Re: FileChooser's path bar and re-rooting

[muppet <scott asofyet org>]

On Tuesday, March 16, 2004, at 12:00 AM, Ryan McDougall wrote:

> I think the point is that we should not necessarily halt our progress 
> wrt UI simply because it breaks some things that were done in the 
> past.  Rather we should ask ourselves whether the way that it was done 
> in the past is the right way to do it, or if we can do it better in 
> the future.

Nobody's asking for a halt to UI progress --- we're trying to keep from 
throwing out the baby with the bath water.


> If you forget a little Unix heritage for a second, and imagine a 
> possible Unix-based desktop of the near future, what _should_ that use 
> case you mention be like:
>
> Alice has a file Bob needs, and she wished to make it available to 
> him.  Alice says "the file is at location X", Bob "goes" to X 
> retrieves the document.  Why should X be a Unix path? Could it not be 
> a URI, or perhaps just a folder in "networks://Folder"? In those two 
> cases, there is no concept of $HOME.

Yes, if there is no unix path involved, it may make sense for there to 
be no "leading noise" in the path bar.

But in a user's home on a local filesystem, it *does* make sense to 
have the "leading noise" there, because that information is important.

Just because it's ugly and "archaic" doesn't mean we should hide it 
from people.  This isn't just about unix paths, the same goes for 
c:\Documents and Settings\ and \\fileserver\share\place and 
ftp://host/foo ---- we should make the full path to *whatever* *is* 
*the* *current* *root* available in the pathbar!

As both i and Joel pointed out, even just having the leading path 
information tucked away in the "<" button is sufficient.  This would 
give the simplicity to the "average user", and full power for the 
"advanced user".

Make it easy enough for inexperienced users to use, but do not hinder 
their ability to grow into advanced users!


compare
  http://asofyet.org/muppet/tmp/subdir-rerooted.png
    (the current implementation, with Home rerooted)
and
  http://asofyet.org/muppet/tmp/subdir-tucked.png
    (the full path available by clicking the "<" button, but tucked away
     by default; using the user's name instead of "Home".)

In the first, there is loss of information, but there's no doubting i'm 
in a folder under my home directory.

In the second, there is no loss of information, but there's also no 
confusing leading path, and since i know my username (i did type it to 
log in, after all), i can rather quickly guess that i'm in a folder 
under my homedir.

And, in fact, the home dir "shortcut" should be highlighted when it's 
active, like this:
  http://asofyet.org/muppet/tmp/home-highlighted.png


Notice that i'm not proposing sweeping changes to the UI, or removing 
the elegance and flexibility of seth's design --- i'm just saying, take 
out the confusing magic, don't pretend that a hierarchical file system 
is not a hierarchical file system, and don't treat users like they 
can't handle the information in front of them!


When is it okay to re-root?  When the root is *actually* different.  A 
vfs-backended file chooser may have a pathbar containing

  [ftp://gtk.org] [pub] [gtk]

A windows machine may have a list of drive letters in the "shortcuts" 
list on the left, and the pathbar could contain

  [c:] [Documents and Settings] [username] [Desktop] [pictures]
which may be shortened to
  [<] [Desktop] [pictures]

But note that the full context of this location, whatever that context 
may be, is always available.

--
How come hair colors for women take an hour, but "wash out the gray" 
stuff for men only five minutes?  This is so unfair!
    -- Elysse, complaining about commercials