Re: Split/dual pane view again (but this time with code)

[Holger Berndt <berndth gmx de>]

On Fri, 20 Feb 2009 12:16:33 +0000 Alexander Larsson wrote:

> If you
> even start Norton Commander chances are that you're gonna do some
> heavy file management, like restructuring a set of folders or
> something.

Well, I don't know if people really switch file browser applications
depending on what they are about to do.. Typically, you choose one
tool, and then stick to it, as you have your bookmarks there and know
your way through the interface.

I agree in so far as that default tool is likely to be Norton
Commander-like when heavy-duty filesystem work is a common task for
the user.

> As such, I think we need the main focus of the UI to be on this form
> of light use.

Agreed.

> Things like tabs and split view increase the total
> complexity of the mental model of the app (things like which
> pane/tab/whatever is affected by each
> option/operation/visual-feedback/, etc). 

Absolutely, yes.

> Split views are a further addition to the complexity of the app. I
> don't think the split view feature per-se is all that bad, it can be
> made a pretty small part of the user interface that doesn't need to
> affect non-users much.

In fact, this is the main motivation behind the UI-draft that I
screencasted -- be as un-intrusive as possible. Just stay out of the
way of non-users.

That, on the other hand, is hard to get into accordance with the HIG
considerations that you raised below.

> However, what I fear is that introduction of a
> split view will lead to more and more creaping of the application
> model towards the norton commander style of application.

That is true. As a matter of fact, there's at least one more feature
building on split-view that I'd personally like very much:
Meld-integration to diff the directories or selected files of the two
panes.

I don't think that's something to be afraid of, though, as this would
obviously be an external extension and not bother non-users at all.
Kind of like the terminal extension.

> We get things like keyboard shortcuts conflicts between expected NC
> operations and regular app behaviour (like for instance the use of
> "tab"), menus full of split-view specific operations, etc. 

I'd take the conservative approach here: Offer menu options, so that
interested users can assign their own keyboard shortcuts. I guess this
would work for everything except the "tab switches active panes"
mantra. But as this could be (and currently is) implemented by adjusting
the focus chain, this would again not affect non-users of split-view at
all.

> "View->Split View" is a kind of weird naming with view used twice. If
> you compare with the other things in that menu, like "side pane" its
> more of a toggle the visibility of that object. So, perhaps something
> like "View->Extra pane" or something would make more sense.

Agreed.

> Also, I don't like the "Side Pane" toplevel menu. Menu operations
> should be arranged by what they do, not what application feature
> enable them. So, file copy operations should be in edit just like
> other such operations
> 
> Generally we don't hide menu items that are not availible atm, we just
> make them insensitive

Now, this is indeed a dilemma. On the one hand I completely understand
your reasoning. On the other hand, all this "extra" functionality
should not bother the non-split-view user at all, and I don't think
insensitive split-view menu items sprinkled all over the place are
a good idea. As a non-user, I'd be annoyed.

Maybe it can be seen as a different "mode". We have spatial mode, we
have navigation mode, and this could be an "extended" navigation mode
that can be toggled on and off on the fly.

> as otherwise the menus change in weird ways
> depending on app state, which causes for instance other operations to
> move in the menus. See the Gnome HIG for details. 

Maybe I got this wrong, but this should not be a real problem when the
menus hook into proper UI-manager placeholders.

> Is there a possibility to do a sane limited split view
> addition in Nautilus, or should we recommend people who desire
> NC-style functionallity to just use a NC-style application?

That is a good question. Personally, I'd like to not have to choose
between simplicity and power. To continue doing 80% of my simple file
browsing tasks in Nautilus' clean interface, but have more power in the
backhand just a keypress away for the rest of the 20%. And even during
those tasks, taking e.g. Gnome Commander would be a significant step
back (completely new UI, desktop integration, bookmarks, GIO,
asynchronism ...).

Holger