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

Fri Apr 17 02:31:02 CDT 2009

Could it be possible to reserve some margin area around the canvas so
that if drag or tab starts there it would pan the view?

-Pete

2009/4/17 Glen Low <glen.low at pixelglow.com>:
> 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
>
> _______________________________________________
> instaviz-users mailing list
> instaviz-users at pixelglow.com
> http://lists.pixelglow.com/listinfo/instaviz-users
>
>

-- 
Petri Sirkkala, sirpete(ät)iki.fi, Skype: sirpete
+358 400 98 2998 // ...likes Gmail... //