On 06/28/2010 04:37 PM, Allan Day wrote:
> 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.

[...]

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

[...]

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

A little late to this part of the thread, but wanted to weigh in because
I think of myself as atypical (at least from what comments I've seen
over the years on this list).

I've been using GNOME since 2002 and as my exclusive principle desktop
since at least early 2007 (memory is fuzzy). I've regularly used Windows
since 2.x and Mac since System 6, in varying intensities. During the
System 7/8/9 years, I was a very heavy Mac user at work and Windows at home.

I grew to love the Mac's expanding folders in list views, something that
never has been available in Windows. I think a lot of people coming from
Windows use a mental model around the Explorer tree view. But I've
always thought it was powerful and simple to be able to navigate to a
folder in a spatial view (System 7/8/9) or browser view (in OS X), then
dive down farther - within the same window.

Since Windows 98, when I had a very slow computer and looked for ways to
cut down resource use, I came to prefer the browser view in Explorer.
Oddly, I prefer to use Explorer without the sidebar, whereas I prefer
the sidebar always visible in Nautilus (similarly, in OS X).

In any version of Windows, I've come to rely on the "keyboardability" of
the interface. It's so nice to be able to navigate rapidly and
consistently (i.e. when I go back in my history in browser view, the
previously selected item in that view is still selected). OS X has made
some strides, but still doesn't match Windows for that.

Bringing that all together...

I really like the way Nautilus's places sidebar gives rapid access to
starting points and/or drop targets, which can be at many different
levels in my hierarchy and even across different filesystems (or networks).

I no longer use the tree view, much preferring to use details view by
default and expanding folders in-situ. But I still think that it's
half-implemented after all these years: There's no persistence to
(un)folding (navigate away and return, and the previously expanded
folders are collapsed); there are several odd behaviors when creating
new items when folders are expanded; and keyboarding within it (with or
without expanded folders) isn't entirely predictable.

I've mentioned these points in previous emails, and I see from the
roadmap that some are at least being considered (hopefully, their status
gets bumped up), so I won't rehash them here. But I would like to say
that if all of the bugs or missing polish to the details view were
implemented, I'm confident that more people would find it possible to
replace the tree view for the use cases I've seen mentioned in this
thread (navigate to a point and drill down). I recognize that it does
have the disadvantage of mixing files and folders in the same view, so
I'm not pushing to remove the tree view. But I, for one, wouldn't miss
the tree view if it disappeared.

I should mention that I consider myself a combination power user,
programmer, and sysadmin: For different reasons and different parts of
my job, I have to work with a large number of "normal" documents (e.g.
Word, Excel, images, etc. - the organization of which might be addressed
by a flat tag-and-search system); deep hierarchical structures (I
develop Web sites and have many concurrent projects); and shell access
which can't easily be replaced by Nautilus (e.g. some rapid keystrokes
will allow me to edit disparate conf files as root without drilling down
or keeping a big list of bookmarks).

I also heavily use Windows XP within a VM on my machine (I program in
Flash), so I definitely appreciate (with and without a sarcastic
overtone of that word) the strengths of both platforms' shells on a
regular basis. And I admin an office of all-Mac users (save myself) who
store files on a Linux server, so I've still kept a finger on the pulse
of Mac OS X's evolution and have appreciated Finder's refinements over time.

Those last two paragraphs won't help you directly, but I hope they put
some perspective on my comments. I really do feel that Nautilus could
benefit from a tight(er) focus on what it does and how it works, as well
as from further refinement to its existing elements which are kept (list
view and keyboardability - hint, hint ;-) ).

I'm excited that there is a concerted effort to refine Nautilus, to
refocus it, and I'm looking forward to seeing the results. At the same
time, I'm afraid that we'll once again have a case where new elements
are implemented such that they work "well enough" and so never live up
to the full extent of their promise. Similarly, I worry that focusing on
new interface elements will obscure or distract from the remaining
issues from the previous iterations of interface additions and
re-imaginings for yet another development cycle (or more).

Cautiously positive,

- John
-- 
nautilus-list mailing list
nautilus-list@gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list

Reply via email to