[instaviz-users] Order-preserving trees, and several wish-list items

[Glen Low]

Peter, All

On 16/04/2009, at 2:41 PM, Paul Weiss wrote:

> What I'm (so far unsuccessfully) seeking is the ability to have  
> trees which preserve the order of their children. For example, I'd  
> like to preserve the semantic difference between (A (B C)) and (A (C  
> B)), regardless of the creation order of the nodes, and to be able  
> to change from one arrangement to the other.

It looks you want to be able to change the "document order" of the  
nodes. I'll have to check if the underlying Graphviz object model  
supports changing the order of the nodes. It would be similar to a  
"move to back" or "move to front" command that appears in many  
illustration programs.

> I'd also like to add a very strong vote for maintaining an undo  
> queue as basic functionality which should (IMHO) precede a lot of  
> fancier stuff. In my early explorations of the program, I've already  
> fat-fingered my way into several errors, including deleting one of  
> my more complicated exploratory graphs, the name of which was too  
> similar to another which I wanted to trash.

That would be good. I'd like to sit down with some of the Graphviz  
principals and also Ryan at some stage (since he's the author of  
CanViz) and thrash out a suitable graph-delta binary format. This way  
I can not only store a proper undo queue, but it will also work for  
various live sync'ing, interactive uses for Instaviz in the future.

> There was also a discussion on this list of preferences and program  
> modes. I think that it's a good idea to support several models of  
> work by means of preferences. (The old Smalltalk-er's design  
> desideratum of "low threshold, high ceiling" comes to mind.) For  
> example, I would almost always want the deletion of the root of a  
> subtree to delete the subtree, although someone else might find that  
> confusing. (I can also imagine graphs for which I would want the  
> removal of a subtree's root to create a forest, so it needs to be a  
> per-graph preference, in this case.)

The main issue with these kinds of changes is the lack of screen real  
estate and user attention to a mobile device. Without a suitable  
visible toggle etc. it becomes very easy for a user to inadvertently  
activate an unintended action.

But certainly we want to make common actions easy, e.g. I'd like to be  
able to delete a chunk of the graph rather than just one node, edge or  
everything... design-wise, this ties in well with the idea of multiple  
selection. If we can nail multiple selection in an easy and familiar  
way, we can do multiple deletes much easier.
>
> I do think, however, that there's a pretty clear cognitive  
> difference between browsing an object and editing it, even if the  
> two operations follow each other quickly in short chunks. A  
> difference in the semantics of gestures will be preserved by the  
> difference in the intent of the activity at a given moment. My  
> problem with (for instance) the strategy of the two-fingered drag  
> which has been adopted is that if contact has only been made with  
> one finger, an arc may be created between two random nodes. If the  
> graph is complex, and its topology is not already internalized, it  
> may be impossible to figure out just what one might have connected  
> up once the layout has been redone. In contrast, if my objective is  
> to move the graph, not to draw an arc, I'd be perfectly happy to  
> indicate to the program that I'm in "browse mode," not "edit mode,"  
> as long as that's cheap to do, in terms of cognitive load. I don't  
> want to ever accidentally edit something when my intent is to browse  
> it.

I'm still in two minds about this one. Using two fingers to scroll was  
a compromise, and with any compromise it achieved certain goals at the  
expense of others. Currently, the action that should be easy,  
browsing, is in fact a little harder than editing -- but the converse,  
having two fingers to edit, would make editing nigh impossible. What I  
hope will resolve the tension in my own mind is how to handle things  
like multiple selection, inline text entry and hyperlinking/pop-up  
balloon descriptions. If all of these can be achieved in a single  
mode, all the better. If the tension of all these functions within the  
multi-touch interface is too much, I may have to yield to some kind of  
multiple mode interface e.g. a browse mode for scrolling, zooming,  
hyperlinking and popup balloons only; an edit mode for select,  
multiple select, inline text entry, creating nodes/edges and  
autoscrolling when drawing. Hence the prominent blank space in the  
graph title bar on the right, it may sport an edit button in the  
future. We'll see in the 2.0 timeframe.

> Another previous discussion proposed a palette, or user-created  
> library of node types, with canned combinations of useful  
> attributes. I'd love to see that generalized to arc palettes as  
> well, so that I could have a source of prelabeled arcs which I think  
> of as relations, such as "IS-A," "COMPOSED-OF," "EATS,"  
> "COMMUNICATES-WITH," and so on, the labels being predefined  
> attributes along with the visual attributes of line style,  
> thickness, end decorations, and so on.

Either a palette or some way of copying and pasting styles would be  
good. Palettes will have to be set up and occupy a distinct "other  
space" from the actual graph, e.g. how to delete a palette entry or  
duplicate a palette entry, how to edit an entry, how to apply an entry  
to a node/edge. Copy and paste are nice in that the existing nodes and  
edges are WYSIWYG already, there is no "other space" for the user to  
interact with.




Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen
twitter: pixelglow

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman-mail5.webfaction.com/pipermail/instaviz-users/attachments/20090417/e7e43a8f/attachment.html