Re: The Future of Nautilus: Show the filesystem

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.

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

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.

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 think this summary maps pretty well on to the list of use cases you've
provided above (correct me if I'm wrong here).

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


Jabber: allanpday AT
IRC: aday on

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