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
