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

Hi there,

Let me give you my point of view, as a user of Nuatilus:

Le 28/06/2010 16:37, Allan Day a écrit :
> 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.
I totally agree with Alexander here.

> […]
> 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.
Please explain why then :)
I'm not an heavy user of many sidebars nor tabs or split view, but I
find many of them actually helpful sometime.
This said, I wouldn't mind much if say, tabs, split view, places,
information, history, notes and emblems goes away: I don't really use
them, and I don't see practical reasons to do so.
But besides my rare usage of them, I already found tabs, split view and
history quite helpful (even though history is almost a duplicate of
other parts of the UI).

> 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.
As somebody already noted, there's no need to reduce the amount of UI,
it's only supposed to be a step towards "better usability". If it is,
I'm with you, but removing only to cleanup the UI is a bad way to think IMO.

> 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.
I always use only the tree view sidebar -- and there is a good reason
for this, to take your words. The pathbar isn't enough IMO, and even
with you proposal it still misses one of its advantages: fast and
accurate overview. And this overview helps a lot navigating in large
directory trees, what I do often.

> The tree view also
> overlaps with the list view and with split pane for certain kinds of
> operations.
Yeah, but the list view contains all the files, which again is against
the overview and fast navigation usage. I mean that the thing is here,
but not in a practical way -- I generally don't use this, even if I'm
sometimes happy it exists.

> 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.
I personally never found how using Places would help me navigating my
filesystem or simply managing my files. It provides quick access to a
few locations, but you got screwed soon: you either add lots of
bookmarks, and you then get flooded by them, or you don't add them and
you need to go folders by folders to the location you want, which takes
lot of time and lacks a simple overview of where you're going and from
where you come.
Ah, and I really dislike spatial mode for quite the same reason, then
don't expect me to second anything that goes this way :)

This said, I don't see why this is a reason to remove tree sidebar. It
only disallow the current way its is proposed to the user, but I'm
pretty sure a great solution to this problem can be found to still allow
both Places and Tree to live together.

> 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:
I will not respond "no" to the question because it would be pessimistic,
but still. And please, don't target anything that would be a "partial"
replacement of anything. Just get rid of it or keep it functional. I
mean, don't keep a reduced version around just to be able to say "it is
there". You probably didn't wanted to do such a thing, but I understood
you sentence this way…

>  * 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.
That's a quite nice idea IMO, but I don't think it can replace the tree:
how would you DnD to a completely different location, say, another drive
or network?
And even if you make this possible, I don't think that the user would be
happy if she needs to hover a collapsed element to make it appear, for
the siblings menu to popup, start going down the siblings menu hierarchy
to finally find the drop location. Seems overcomplicated to me :)

One key of the tree view is that several trees can be opened at once, I
think. The famous overview, global view or whatever.

>  * 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).
I don't think it is these columns that makes using the list view as a
tree a pain. It is (for me) the fact that you get all the files of all
the opened folders, which destroy its use as an "overview" and "quick

>  * 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].
Again, even if I think it can be pretty cool features, it won't replace
the tree view completely (see above, again).

>  * Better integrate split pane into the UI.
Haven't I heard you'd like to remove it? But again, I don't see how it
would completely replace the tree view, it only makes DnD ot other paste
methods easier.

> 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?
I don't know about an impartial view of the situation (I'm probably
partial, as we all are more or less), but I would be *really* annoyed if
the tree view goes away.
Of course perhaps I don't think about what could ba a worthy
replacement, but with the current proposals, I think I'd probably simply
use another file manager then.


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