Re: FileChooser's path bar and re-rooting



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]