Re: The Future of Nautilus: Tree Sidebar and Split View

[Allan Day <allanpday gmail com>]

Next up: tree sidebar and split view.

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

Some criticisms have been levelled at split pane in the past. I don't
really want to revisit those now. I think there are probably better ways
to integrate this feature into the UI though - Garrett's got some good
ideas there.

It is worth making a general point about complexity, however. Nautilus
has six kinds of sidebar, tabs *and* panes, as well as spatial/browser
mode. Windows Explorer and Finder have a single sidebar, no tabs and no
panes, and there are good reasons why they don't.

The basic aim of the future nautilus proposal is simplification.
Simplicity is a virtue in all kinds of ways. Paring down the UI is good
for users (since it gives them less to process), it also opens up design
possibilities in terms of creating a focused, integrated interface.

A pared-down UI is also good from a development point of view, since it
means that there's less to maintain and we can concentrate on ensuring
that the UI that we do have is high quality.

So, tree sidebar! Me, Hylke and Garrett are keen to see this removed,
but we also want to get some feedback and to discuss this further. I'll
outline the arguments and the way this would play out with the current
design proposal.

The first reason for wanting to remove the tree sidebar is the general
streamlining effort itself: we need to reduce the amount of UI in
Nautilus. We're specifically targeting the tree view because it is less
essential than the places sidebar, and because it overlaps with existing
functionality. The path bar already allows some navigation of the tree,
and we've proposed some enhancements (see the 'side-step' menu concept)
to that which will make that much more powerful. The tree view also
overlaps with the list view and with split pane for certain kinds of
operations.

Another reason for removing the tree view is our current design
proposals around places. We'd really like places to be both a sidebar
and a menu. This would be a really nice feature, since it would allow
users to maximize the amount of screen space devoted to displaying
content while still allowing easy access to places functionality (it's
rather similar to spatial mode, actually), but this feature does mean
that the current method of switching the mode of the sidebar would have
to go.

There are a couple of questions that need answering, then. First: can we
enhance other parts of the UI so that they are able to replace
(partially, if not fully) the tree view? Possibilities include:

 * Improve the path bar so that it can be used to both navigate trees
and for advanced drag and drop operations. Our current proposals [1]
contain a number of possibilities here.
 * Reduce the amount of noise in the list view: we can rationalise date
formats [2], and we can hide the type column (sorting by type could be
done  an arrange menu item in the actions toolbar).
 * Enhance the functioning of the list view to allow effective
navigation of directory trees: remember folder expansions [3],
autoscroll on folder expansion [4], use the path bar to do quick
scrolling between expanded folders [5].
 * Better integrate split pane into the UI.

Second question: keeping in mind our answers to the first question, is
tree view absolutely necessary? Can users find ways to work without it?
Viewed impartially and objectively, do they absolutely need it?

Allan

[1] http://live.gnome.org/Design/Breadcrumb/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=346337
[3] https://bugzilla.gnome.org/show_bug.cgi?id=309800
[4] https://bugzilla.gnome.org/show_bug.cgi?id=488802
[5] https://bugzilla.gnome.org/show_bug.cgi?id=622985

-- 
Jabber: allanpday AT gmail.com
IRC: aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/