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



On Mon, 2010-06-28 at 17:35 +0200, Holger Berndt wrote:
> On Mon, 28 Jun 2010 15:37:29 +0100 Allan Day wrote:
> 
> > Next up: tree sidebar and split view.
> 
> [...]
> 
> > Some criticisms have been levelled at split pane in the past. I don't
> > really want to revisit those now.
> 
> I have read statements about split pane in the past that can hardly be
> called "criticism" in any constructive or reasonable way. I haven't
> read much real criticism yet. In fact, I didn't see any negative
> comments from outside of your group at all, yet.
> 
> On the other hand, I got quite some positive feedback from users; and
> the press coverage that I've seen after 2.30 was also very positive.
> 
> > I think there are probably better
> > ways to integrate this feature into the UI though - Garrett's got
> > some good ideas there.
> 
> I'm curious to see those. Even more since Garrett didn't seem to
> understand what split pane is all about in the first place.

If you want to discuss the particulars of our proposals, please do so.
Let's not make this personal.

> > Windows Explorer and Finder have a single sidebar, no tabs and
> > no panes, and there are good reasons why they don't.
> 
> Many other default file managers for many years don't have anything
> closely remote to GIO/GVFS either. There are good reasons why they
> don't. Virtual filesystems for remote places are a pretty obvious
> complication for the mental model - but they're also incredibly useful.
> I can only guess why I haven't heard much about removing GVFS for
> simplicity reasons: Because in contrast to split pane, by
> coincidence, you guys use GVFS yourselves.
> 
> That's the danger when having a small group of 2, 3 or 4 individuals
> sitting together and thinking about what all the rest of the world
> needs, or worse, what it doesn't need:

There's a word for that: design.

A range of design and usability specialists have been involved in this
process, which we are now opening up for discussion.

> The view is inherently skewed.

I can assure you that the people involved do not have a insular view of
users' needs. Quite the opposite, in fact.

> But, as you're starting the comparison with MS or Apple products:
> Windows and Mac don't have many things that GNOME has. That powers a
> huge software industry.
> 
> When you're done with Nautilus, are you going to simplify GEdit down
> to what Windows' notepad.exe can do, next?

You're misrepresenting what I wrote. I was making a general observation
in the context of Nautilus. I didn't suggest that we emulate Windows or
OS X in every respect, nor would I.

> > The basic aim of the future nautilus proposal is simplification.
> 
> I thought the fundamental design goal was to enable to user to do their
> file management tasks easily and efficiently, and simplification was
> hoped to be a tool to reach that goal.

It is.

> I would definitively have agreed
> to that, up to a certain extent. But ...
> 
> > Simplicity is a virtue in all kinds of ways. 
> 
> ... obviously I was wrong, and simplicity is the goal in its own right.

Not true. I described a number of positive consequences of simplicity.

> And to that, I do not agree.
> 
> > Paring down the UI is good for users (since it gives them less to
> > process), 
> 
> No. I can tell you what's good for users:
> If the application helps them
> to get their work done. They don't open Nautilus to enjoy its look.
> Nautilus is a file manager, and people open it when they want to manage
> their files.

You seem to be suggesting that the design proposal prioritises
aesthetics over practicality. That isn't true.

> And anyways: Split pane has very, very little impact on the default UI.
> It's a single, tiny menu item. 

I wasn't talking about split pane.

This is supposed to be about developing a positive vision for the
future. Can we stick to that?

Allan
-- 
Jabber: allanpday AT gmail.com
IRC: aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/



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