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



Hi Colomban,

Thanks for the useful feedback. There's just a couple of comments I'd
like to make.

> 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 :)

Sorry, I should have been clearer about that - it was the bit where I
talked about the benefits of simplification. Having a focused and
integrated UI is probably the most important reason, I think.

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

Maybe I didn't express this right the first time round, so let me make
it clear: the whole point of the future nautilus proposal is better
usability. We're not proposing that features be taken away just for the
sake of it, honest! :)

This debate around simplification has maybe clouded the issues a little.
Here are the pertinent factors with tree view as I see them:

The sidebar switcher: we want to replace this, so that it is possible to
have a places *menu*. The idea is that this menu would be the default -
so no sidebar by default - but that it could be converted to a sidebar
using a simple option somewhere. The places *menu* concept is great,
since it maximises the amount of screen space used for displaying
content but still enables quick navigation, but it does mean that we
need to rethink how we toggle the sidebar as well as how many kinds of
sidebar can be supported.

Bookmarks: these probably aren't that useful if you're using tree view
(correct me if I'm wrong here :) ), but would tree view users be happy
not to be able to access them at all? The bookmarks menu will disappear
in our proposal, making the places sidebar/menu the only place to access
them.

Path bar: is the path bar useful when the tree view is displayed? There
is definite overlap between these two aspects of the UI. So, assuming we
keep the tree view, do we hide the path bar when it is displayed?

Thoughts?

Allan



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