[seek-dev] Re: new screenshot

[Shawn Bowers]

> The question of whether to use a) one tree with instances in the tree, 
> or b) two panels where the first tree filters individuals in the lower 
> list, is the hard one.  In (a) we can't really combine categories 
> easily, so you are stuck with looking at the actors in a single 
> category, which can be limiting and means you might have to expand lots 
> of folders to find what you are looking for.  But the UI is very 
> understandable. In (b), you have a tree used as a control in a way that 
> is not typically done, so we need to be sure the increased query 
> functionality (e.g., abillity to select multiple properties at once) 
> justifies the hit on intuitiveness.  Also, (b) will likely suffer from 
> screen real-estate problems.  The single panel onthe left already seems 
> too small because we frequently want to see 15+ rows of actors or even 
> more for data.  Making 2 panels just makes it worse.

A good example of a similar interface with the two panels is the html 
produced by javadoc, e.g., (I am sure everyone is familiar with this, 
but just in case):

http://java.sun.com/j2se/1.3/docs/api/

If you click on this url, you see two frames on the left.  The upper one 
restricts what you see on the lower one. (Actually, the upper one is a 
tree that has been flattened ...) I think with good labels (e.g., "all 
classes" in the javadoc example), and the labels that result by clicking 
on a package in the top panel, it should be farily intuitive.  Also, 
once you click on a concept, you will immediately see a result in the 
bottom panel -- so it is interactive in such a way that most users 
wouldn't need to read a document to understand what is going on.

Actually, now that I think about this more, isn't this style of 
interaction integrated within windows? For example, it is exactly what 
you do in windows file explorer ... where the tree is on the left, and 
the right panel has the files and subdirs of the selection on the left. 
So I guess I am disagreeing with your comment that b wouldn't be 
intuitive and is unconventional.

I do agree, however, with your expert :-) that the existing workflow 
zoom-panel wastes real estate, and that it should float (with the option 
of making it go away and come back, like in powerpoint, etc.) Also, 
having it float would provide the needed real-estate, I would think.


shawn