Re: Simplified Nautilus (with less chrome)

[Alexander Larsson <alexl redhat com>]

On Wed, 2010-01-20 at 13:30 -0600, David Siegel wrote:

> I question the trade-off that was made here: adding complexity to the
> toolbar to accommodate an advanced use case. All Nautilus users who
> use browser mode are affected by the increased complexity of the
> toolbar, while relatively few users are benefited by the addition of
> split view mode.
>
> I think the fundamental question Nautilus as a project needs to answer
> is whether this kind of trade-off (increased pain for inexperienced
> users vs. increased benefit for the usually smaller population of
> advanced users) is compatible with the needs of Nautilus' audience. To
> answer this, we would need to explicitly define what Nautilus is and
> who Nautilus is for. Is Nautilus for your average user who's not very
> organized, with little understanding of where files are? Or is
> Nautilus for more sophisticated users who need to perform complex
> organization of their files? Realistically, Nautilus is for a mix of
> both, but what is the priority? Should Nautilus provide advanced
> functionality as long as the default configuration is kept simple?
> This seems like a very good principle for software in general, and
> Alex suggests that Nautilus will embrace this principle once the
> toolbar editor is available. If that is the case, I urge you not to
> increase complexity in the toolbar until the toolbar editor changes
> land and the default configuration can be kept simple. I just don't
> think the benefit of split pane view is worth the cost of adding
> complexity to an already complex toolbar.

I agree with you in general, nautilus is something every user has to use
so we should strive to minimize its complexity. This is part of the
reason why for instance we've historically defaulted to spatial mode
(although ubuntu changes this default), as it is imho easier for the
common usecase of just using the file manager as a way to e.g. launch
your files (as opposed to doing file "management"). Basically, nautilus
is the shell users use to access files. However, with gnome-shell this
starts to change, and the exact uses of nautilus change a bit with that,
moving to something that is used less often and with a bit more focus on
the "management" part. See this discussion:

http://mail.gnome.org/archives/nautilus-list/2009-December/msg00001.html

Clearly split view is a feature for the slightly more advanced users,
and as such introducing it is a risk for confusion. This was clearly
brought up by me in the initial discussions wrt merging the split view
work:

http://mail.gnome.org/archives/nautilus-list/2009-February/msg00052.html

Like in the thread above, I still think that the split view feature is
not inherently problematic. In the default UI its only really visible as
one menu entry, so its unlikely to disturb inexperienced people much
when compared to the advantage it gives more advanced users.

However, as i mention in the thread, the risk is that the split view
mode gains "too much" features and turns the whole application into a
norton commander style dual pane file manager. We need to fight such
requests and try to keep the feature as lightweight as possible by
default. I do think we've done OK with this though, so far.

Now, to get back to your mail. You're talking about the toolbar and the
"increased complexity" in it. I don't really think there is a lot of
increased complexity in it. Here are two screenshots:

Before:
http://www.gnome.org/~alexl/nautilus-2-28.png

Now:
http://www.gnome.org/~alexl/nautilus-2-29-1-2.png

Wrt the toolbar, all we've done is move two widgets (view selector and
zoom). Additionally the "extra" toolbar has now been removed and the
location/pathbar has been made more of a "normal" non-toolbar item.

Where do you see the increase in complexity? Obviously there is a bit
less white space now, as the main toolbar has more stuff, but at the
same time this has lead to more space for the file view. Also, the
toolbar is longer now, but this is not a problem if the window is wide.
For a less wide window this means the zoom and view selector are hidden
(since they have less priority), but these are not that commonly used
widgets and loosing them in favour of more important widgetry when space
is tight seems like the right approach.

Of course, this doesn't mean I think this is the ideal layout of the
toolbar (witness the simplification efforts for instance, and the wish
for a toolbar editor, clearly there are at least some good ideas out
there). However, I contend that it is somehow much more complex than the
previous default. We could start discussing a better layout at any time,
but codewise it would be best to finish the toolbar editor work first
before implementing a change of default.