Re: The Future of Nautilus: Show the filesystem

[Alexander Larsson <alexl redhat com>]

On Thu, 2010-06-24 at 11:34 +0100, Allan Day wrote:
> Hi again,
> 
> OK, first issue! We might have to agree to disagree on this one, but
> let's run through the arguments and see where we end up.
> 
> For those that don't know, the proposal being discussed is to toggle the
> presence of the file system entry in the sidebar, and for the default to
> be that it is hidden.
> 
> <snip>
> > * Show the filesystem
> > 
> > While I agree that navigating the filesystem from the root is not an
> > extremely common operation, it *does* happen. So, while it should not
> > have a significant visibility in the UI it should be accessible without
> > using any hidden method or enabling any "uber-geek" mode (thats
> > generally not known about unless you google for it).
> > 
> > I know you think that "normal" people should not have to do this, but I
> > think your definition of "normal" is a bit to tight. Nautilus is the
> > main file manager of the desktop, and the desktop should let you do
> > everything you need without falling back to the terminal or other
> > "hidden" means, for *all* users. Let me list a few reasons to navigate
> > outside your homedir:
> > 
> > * You set up a shared directory outside your homedir for e.g. music
> > files or movies on a machine with multiple users
> > * At the office everyone has various nfs automounts that contain shared
> > project folders for all the projects the company has
> > * You want to get a file with another user that is in his homedir
> > * You're a system administrator (and you'd like to only read things with
> > raised permissions when its really really necessary, for security
> > reasons)
> > * You're a developer and use nautilus-svn or equivalent, and your source
> > trees are not in $home
> > * You need to find and attach some logfile to a bugreport
> > * You have a webserver serving from /srv/foobar, and you want to manage
> > files there
> > * You're a student on a course and are told that the files needed for
> > the assignment you're working on can be found in directory "foo"
> > somewhere.
> > * ... many other 
> > 
> > Now, some of these could be done in better ways, the file sharing for
> > instance, but sometimes file sharing is just not set up right and you
> > just need to do it this ways. Many others could be handled with
> > bookmarks, but that only works if bookmarks are already set up, and
> > initially they are not (and additionally there may be way to many
> > projects to have them all as bookmarks so you're more likely to only
> > bookmark the ones you're currently working on).
> > 
> > We should do our best to make all these cases have better ways to do
> > them, but at the end of the day there will be cases and setups we didn't
> > think of, and the file manager needs to be generic enough that it can
> > handle them anyway. And it needs to do this for everyone, not just "uber
> > geeks" that know how to enable some magic knob, because you can never
> > tell when any user suddenly needs to do something not supported by
> > another approach.
> </snip>
> 
> I think we agree on the vast majority of this. We should aim so that
> non-technical users don't have to delve into the bowels of the file
> system for common actions. One of the things that we've got in the
> design proposal is a facility for easy sharing of files and directories,
> which should minimize the need for this.
> 
> My personal view is that technical users will quickly discover how to
> permanently show the file system if they want it. There will also be
> plenty of ways to quickly access the lower levels of the file system:
> through the location bar, through Alt+Up, or by setting up a bookmark to
> the desired location.

I don't think people, even technical should have to modify the default
UI just to be able to do things they need doing. A setting like this is
clearly not a "preference", its not about if you prefer it or not. Its
something you need to use (or not), so hiding it as a preference is imho
a bad idea.

> But what about non-technical users? My sense is that they will not go
> into the file system unless directed to do so, since they ordinarily
> wouldn't know what to do when they got there. In these situations,
> should they occur, they will be following a walk-through, which could
> include a direction to 'Display file system' or however we want to
> express it. That doesn't seem like a particularly heavy additional
> burden in those situations.

I don't think normal people should need to be told to enable some
preference just to do something (and then they probably leave it
enabled).

But obviously we disagree on this. Lets not rehash it forever.

> You might ask if there is any real benefit to this change. The benefit,
> I think, is that it removes a technical-looking and - for most users (we
> could argue about this) - never used part of the UI. The result is an
> interface which is a tiny bit thinner, but more importantly, is
> friendlier and optimised for the vast majority of users. (It is worth
> pointing out that Finder doesn't have access to the File System or an
> equivalent.)

OSX finder does show the filesystem, but its not called that. Its called
"Macintosh HD", "<name of computer>" or similar things. However, by
default they do hide "unix stuff" (like /usr, /bin, etc) in the
filesystem by placing .hidden files in the root.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an otherworldly soccer-playing inventor in drag. She's a tortured 
paranoid mechanic living homeless in New York's sewers. They fight crime!