Re: The Future of Nautilus

[Alexander Larsson <alexl redhat com>]

On Wed, 2010-06-23 at 13:04 +0100, Allan Day wrote:
> Hi all,
> 
> Garrett recently blogged about reworking parts of Nautilus's interface
> [1]. These proposals are the result of a lot of work that him, Hylke, me
> and others have been doing recently.

Unfortunately this is an epically bad time for me wrt nautilus work. I'm
gonna be very busy with my work in spice over the summer, and then I go
on parental leave from middle of september until about february. I won't
have any significant time for nautilus until then. In fact, I hardly
have time for even reading Garretts blog, much less thinking deeply
about it. :/

In general I don't mind a simplification like this. For instance, i know
we have a bunch of users for things like notes, backgrounds, custom
icons/emblems, etc. But even so these are not core parts of file
management, so I wouldn't really mind losing them if the benefits are
good. And a drastically simplified UI *does* look good to me.

However, there are a few things that I actually think are important to
the core file management that are lost in your version:

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

* Tree sidebar

While I think the places sidebar is a better default for most people I
still see a great many people using the tree sidebar. If you know your
way about a filesystem and need to manage large hierarchies with many
files this is a very good way to get an overview of things and navigate
efficiently.

Having this availabile is just a drop down menu on the sidebar title, so
its very low profile for people not using it. I can't see it being a
significant confusion creater, it doesn't use more UI space (it shares
space with the places sidebar) and its very powerful for the people that
want to use it.

* Split view

I know you designers claim this is useless and make pointless jokes
about "extra pain", but there is a reason why dual pane file managers
has been around forever and why many people like them. And its not the
same as placing two windows next to each other, so a better WM is not
the solution here. Having two windows next to each other duplicates all
the window chrome, which is kinda painful, but it also loses the main
advantage of split views, which is that the file manager knows about the
connection between the two views, so that you can very efficiently do
options like "copy to other location", or have tools like
compare-two-directories. And keyboard navigation is *much* better inside
a window than with two windows.

Of course, split view is not something everyone will use, and even the
people who use it won't use it all the time. So, it has to be made as
"small" as possible in the UI when its not active. But I think we've
done a pretty good job at that. Its basically just a single menu item.

* Select view type

I don't see how you switch between e.g. list view and icon view in your
UI.




I'm not sure I like the new context menu replacement. The way its shown
horizontally means that there is very little space for items, if you
don't want to require a large window size. Basically it means that you
have to hand-design the context menu such that the longest translated
strings in any language fits in some smallest window width we decide
on. 

But that is not how context menu items work. They vary greatly with
different types of files (this is the context sensitive part) and they
are extended by things like plugins and script to make them even longer.
This extensibility would essentially be impossible with a limited screen
space for the context menu like in the proposal, removing the
possibility to extend nautilus for user specific things like version
control handling, custom scripts etc.


One thing I've long had on my todo list for nautilus but so far have not
had time to implement is a preview pane. This wold be something you can
enable and would show a larger preview of the current file, including
metadata for it and a button to e.g. play a movie or a music file
inline. Somewhat like this:
http://njpatel.blogspot.com/2007/02/nautilus-metadata-love-at-first-sight.html

It would be nice if the new design had a place for something like this.
(This would also replace the hover-over play of mp3 files which can be
something of a pain if you accidentally trigger).


Oh, and a last note, nautilus *does* have saved searches (i saw on irc
that you didn't know this). Just do a search and then "File -> Save
search As...". Its not super visible because its kinda useless without a
working indexer setup and there has long been performance issues etc
with tracker and beagle such that most people don't have it enabled.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an obese sweet-toothed romance novelist trapped in a world he never made. 
She's a manipulative streetsmart vampire from out of town. They fight crime!