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

[Ryan Schmidt]

On Apr 17, 2009, at 02:16, Glen Low wrote:

> 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.

Graphviz syntax provides "ordering=out" but this never quite worked  
right for me. In my graphs when I wanted to preserve node order, I  
inserted invisible edges between them. This seemed to work more often.


>> 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.

I agree with Paul, and think an Edit button is the way to go. It  
certainly has great precedent among the existing Apple iPhone apps.