Re: Column View

[Jürg Billeter <j bitron ch>]

On Mon, 2003-12-01 at 18:45, Tristan O'Tierney wrote:
> --- Jrg Billeter <j bitron ch> wrote:
> > The problem (or one of the problems) I see is the
> > following: Look again
> > on your scroll3.png. Where can I see that the parent
> > of the active
> > folder "Conceptual" is located in
> > Documentation/Cocoa? I think that
> > something like that is essential in a navigational
> 
> look at the bottom of scroll3.png. you'll see a
> horizontal scroll bar. scrolling backwards shows you
> the entire file tree that you have traversed.. this is
> nice in mulitple ways: it acts like a  "History" of
> where i've been, since as i scroll back i go to where
> i was previous in the file system.  it also has a tree
Perhaps I have to clarify as this wouldn't fit my requirement of always
knowing where I am in the filesystem. Suppose you have multiple file
manager windows open, say we opened two folders a few minutes ago, did
some work in another application and then we need to switch back to one
of the file manager windows. If I have to scroll back in the window just
to see whether it's the one I'm looking for, it's much less efficient.
With a tree sidebar (BTW I'm always talking about a folder-only tree)
it's not always visible at first, too, but very often (depends on the
folder hierarchy and the window size, of course) you can see much more
(grand-)parents of a folder at the same time.

> metaphore, since it's esentially a branch structure. 
> the difference if you compare it to a tree is that
> only one node is visible at a time.  i.e. if i'm in
> /usr/local, i can't see files in /etc, whereas if i
> had a tree view with /etc and /usr/local open i could
> see both.  this may seem like a downside at first,
> because for example what if you wanted to drag a file
> from /etc/ to /usr/local? you could in the tree.  in a
> column view, to achieve such functionality you would
> drag a file, then go to the edge of the column view to
> scroll backwards in the history until you saw /, at
> which point you could drag the file over /usr and
> either wait 1-2 seconds, or press the space bar, at
> which point the folder would be selected. you could
> repeat this until you got into /usr/local. then
> letting off the mouse button would "drop" the file
> into that folder.  the mac calls this "spring loaded"
> folders: if you have a file dragging, and you press
> the space bar on top of a folder where the mouse
> pointer is it traverses into that folder.
Yes, I understand this, but IIRC spring loaded folders are patented by
Apple, so at least in the same way, it couldn't be implemented. But if
the patent even affects a somewhat different, similar way, the column
view would perhaps be less usable than it could be.

> > view - as you anyway
> > don't speak about the spatial architecture. You say
> > that the benefits of
> > the column view are high when you are in a deep
> > nested folder, but then
> > you don't know where the folder is located in the
> > system. This is for
> > example bad in a situation where you have two almost
> > identical folder
> > hierarchies (for example source directories of
> > different versions) and
> > you can only identify them by the name of the
> > highest folder in each
> > hierarchy.
> > 
> 
> the spacial view, if i remember correctly, is
> basically the windows 95 style file viewer where
> opening each folder generates a new window that
> overlaps the previous.. correct?   this is a very poor
I don't remember exactly how Win95' default explorer behaviour has been.
It has sure similarities but I suppose that there were some important
things missing.

> system of browsing files overall because opening each
> window subsequently hides the root folder behind it.
As Nautilus saves (or will save?) each folder's position and you
normally won't position the parent window behind the folder window, this
is not really an issue (but could well have been back in Win95).

> this makes it very difficult to drag files backwards
> in the file tree. if you follow my example with the
> column view, you'll see it's quite easy to go
> backwards in the file tree.  and if you read my post
> prior to that, you'll see the column view is also
> quicker to traverse than a tree view. in a tree view,
> you don't know where your parent folder is if the tree
> happens to be cut off due to scrolling down too far,
> so the downside is no worse.
In many (I even tend to say most) cases you will see the parent folder
in a folder-only tree view and beside that, if you just want to traverse
to the parent folder, use the up button. In the column view you have to
scroll much oftener as it always show files and folders because the
program can't know, what you're looking for. With a tree view sidebar
you won't see files which only disturb while traversing a file system.

> when i said that you see big benefits in the column
> view once you start traversing into deeply nested
> directories, i was pointing this out because this is
> the column view's "best case" senario.  if you compare
> access times of a tree view and a column view for the
> scroll1.png, you'd find faster access times on average
> STILL for the column view due to Fittz law. this would
> make the column view faster in tree like browsing, and
> faster in deep nested browsing.  every system has it's
Your "proof" that the column view is faster than the tree view is
essentially based on the fact that no or at least no common tree view
implementation highlights the parents of the currently selected node.
Beside that, you assumed that the eye just triggers on the small arrow,
I assume, that the indentation helps a lot, too. In general it also does
matter whether you use a folder-only tree view but in your example it
wouldn't make a big difference. Conclusion: I'm not sure whether -
according to Fittz law - column view browsing is really faster than tree
sidebar (with additional highlights) browsing is. Do you think, it's
really still faster?

> downsides though, and the column view's is drag&drop
> backwards in the file tree.  however it's benefits
> outweight it's downsides, because poeple more often
> access files than move them backwards in the file
> tree.
Just to access a file it probably doesn't matter what interface type one
uses.

> > Ehm, IIRC Apple has patents of some parts of MacOS
> > X' new user
> > interface, have you assured that the column view is
> > not affected?
> > 
> 
> originally, the file browser came from NeXT Step. 
> this was implemented in GNUStep (also known as
> windowmaker) quite some time ago. here is an example: 
> http://www.linuxfocus.org/common/images/article127/filev24.jpg
> 
> it's safe to say, considering that windowmaker's been
> out before mac os x, that it would be perfectly legal.
Ok, I just wanted to be sure.

> all in all, nautilus currently has a list and icon
> view. adding an additional column view wouldn't
> increase the complexity of the interface much, and for
> those like me who would greatly appreciate such an
> addition, we'll use that as our default view. for
> those who don't, they can always use the spacial
> (icon) or list view.  i understand people don't have
Sure, I don't really discuss whether it's going in Nautilus or not (I
won't decide anything anyway) but I'm really interested in different
user interfaces and what we can do to improve Nautilus' default user
interface therefore I try to combine the advantages of all interfaces.