Automatic layout works poorly with orthogonal connectors
 

The default geometry of Automatic layout is probably good enough for hierarchies with straight-line connectors, but the results which it produces with orthogonal connectors are oddly distracting – making parent-child relationships less clear, direct, and symmetrical than they should be by default.
It's not even clear that it makes more efficient use of space. It sometimes even seems to waste a little space.

Consider, for example:
[IMG]http://farm7.static.flickr.com/6048/6284673098_709e75856b_o.png[/IMG]
Problems:[LIST=1][*]Parents are not properly centred over their child ranges,[*]single children are often linked to their parents by jagged three-stage lines with redundant corners, rather than by simple straight lines,[*]and finally, the layout sometimes (depending on the tree) uses slightly more horizontal space than the simple centred layout below (which is generated by [URL="http://forums.omnigroup.com/showthread.php?t=22521"]an Applescript[/URL]).[/LIST][IMG]http://farm7.static.flickr.com/6044/6284091003_e50a1c2cbd_o.png[/IMG]

I wonder if this could be corrected in future builds/versions ?

[COLOR="White"]--[/COLOR]

The weakness of the default Automatic Layout for orthogonal connectors, seems, on inspection, to consist in an artificial gravitational compression of sibling ranges, which skews parents towards each other, and away from the centre of their respective child ranges.

( Rather like a dysfunctional family in which siblings never quite grow up, and, for lack of centred parental attention, continue to cling to each other, never becoming fully centered on their own children :-(

The result is this:
[IMG]http://farm7.static.flickr.com/6107/6289697545_7cfab8851b_o.jpg[/IMG]

A more natural (and much more clear and legible) default would simply be:

[IMG]http://farm7.static.flickr.com/6041/6290216124_e29ac51ae3_o.jpg[/IMG]

Is this beyond the capacity of the underlying Graphviz engine ?

Could the strange and dysfunctional mutual attraction of siblings not be switched off, or at least made optional for orthogonally connected trees ?

(In the Automatic Layout version, it is not even clear whose children are whose ...)

Perhaps this is the clearest illustration of buggy or dysfunctional output from automatic layout that I have seen.

Here is a simple and symmetrical outline structure – easily grasped at a glance:

[IMG]http://farm7.static.flickr.com/6215/6318208006_37a4a42561_o.png[/IMG]

What does [I]automatic layout[/I] do with it ?

[IMG]http://farm7.static.flickr.com/6220/6317688449_1d76bbdf8c_o.png[/IMG]
[LIST=1][*]The symmetry of our data is concealed. Automatic layout misrepresents it as asymmetrical.[*]Our clear and simple data becomes ambiguous. In fact, frankly unintelligible. Whose children are whose ?[*]Unnecessary cognitive noise is introduced. Where we should have simple straight lines, to the left and right, we have distracting dog-legs, with two redundant corners each.[/LIST]
(For any philologists out there, this is known, in Oxford English, as a 'dog's breakfast').

Not sure if this is a bug report:[INDENT][B]"Automatic layout introduces spurious asymmetries, ambiguities and distractions." [/B][/INDENT]or a feature request:[INDENT][B]"Plain vanilla orthogonal layouts (parents centered over child ranges) for nested structures, please."[/B][/INDENT]
Perhaps both ?

[COLOR="White"]--[/COLOR]

Wondering if this asymmetric and unreadable result of automatic layout was a quirk of a particular template, size or object spacing, I went to Omni's own gallery.

The foregrounded example, in position of honour at number one in the [URL="http://www.omnigroup.com/products/omnigraffle/"]marketing material[/URL] (available in the [URL="http://www.omnigroup.com/products/omnigraffle/extras/"]sample documents[/URL] package) does show an awareness that users will need and expect a simple orthogonal layout of their outlines. And the example shown seems to promise reassuring symmetry and simplicity and readability. Just the kind of thing you would expect from an Automatic Layout function.

Foobar Inc are at first well-satisfied with their choice of OmniGraffle for their [URL="http://www.omnigroup.com/images/product_images/OmniGraffle-Gallery-1_2.png"]organisation chart[/URL].

Soon, however, the company reorganises a little. They go for a slightly flatter organisational structure, they promote one colleague, but also prune the payroll a little – not entirely unheard of ...

They return to OmniGraffle 5, update their outline, and click [B]Automatic Layout[/B]. They are expecting this:
[IMG]http://farm7.static.flickr.com/6119/6319261304_2c32ccb231_o.png[/IMG]

In fact, they get something asymmetrical and misleading, or at best, uninterpretable. Who reports to who at bottom left ?
[IMG]http://farm7.static.flickr.com/6117/6319261486_9cbda4ffdb_o.png[/IMG]

Perhaps they have run into a one-off glitch ... The diagram is a bit wide anyway. Let's choose a left-to-right direction. Now what they are expecting is this:
[IMG]http://farm7.static.flickr.com/6114/6318750901_47fdb14a08_o.png[/IMG]

What [B]Automatic Layout[/B] actually produces is this:
[IMG]http://farm7.static.flickr.com/6234/6319261912_f9afcc9ea9_o.png[/IMG]

[B]Still[/B] oddly asymmetrical and messed up at the bottom ...

Omni's foregrounded gallery example gives the impression of offering clear, simple and symmetrical tree orthogonal layouts with parents centered over children. Clearly Omni knows that this is what people need and expect. Is this, in fact, what was intended by design ?

If so, there seems to be a structural clash between the design specifications and the actual capacities of the trumpeted 'underlying engine'.

If not, is there not a risk that the symmetry and clarity of the example given pride of place in the gallery might be a bit misleading ?

[COLOR="White"]--[/COLOR]

Or for a simpler experiment with [I]orgchart.graffle[/I] in the [URL="http://www.omnigroup.com/ftp/pub/software/MacOSX/Extras/OmniGraffle/OGSamples.dmg"]sample documents[/URL], look at the center of the lower edge, where Mark Yu has only one person reporting to him.
[LIST=1][*]Open the outline sidebar, and use it to expand Mark Yu's team by one, so that two people now report to him, and apply Automatic Layout. The data is still symmetrical, but the diagram immediately becomes asymmetrical, and the jagged dog-leg links appear to left and right.[*]Give Mark Yu a third team member, and apply Automatic Layout again, and the asymmetry becomes even more pronounced and strange. [*]If his team grows to have [B]five[/B] people reporting to him, Automatic Layout will again mess up the lower left corner of the diagram, and it will become unclear whether people are reporting to Mark Yu or to Jeff Monrow, the Office Manager ...[/LIST]

The [URL="http://www.omnigroup.com/products/omnigraffle/"]gallery example[/URL] of automatic layout:
[URL="http://www.omnigroup.com/images/product_images/OmniGraffle-Gallery-1_2.png"][IMG]http://farm7.static.flickr.com/6060/6320710581_47e681f5d0_o.png[/IMG][/URL]
might, I think, lead one to expect it to handle new hires with similar symmetry and clarity:
[IMG]http://farm7.static.flickr.com/6037/6321222482_0be98807c8_o.png[/IMG]
What [B]Automatic Layout[/B] actually produces is rather less symmetrical, and a lot more unclear, unexpected and distracting:
[IMG]http://farm7.static.flickr.com/6098/6320700405_853f178007_o.png[/IMG]
Who reports to who ?
Why the dog's-leg lines in place of straight and simple verticals ?
Why is a symmetric outline represented with an asymmetric diagram ?

[COLOR="White"]--[/COLOR]

What is going wrong in Automatic Layout ?
[LIST=1][*]The key problem is that Graphviz parents are agoraphobically skewed towards each other, in a way that is visually unexpected, and a source of further problems down-stream.
[IMG]http://farm7.static.flickr.com/6031/6322649030_d11f8ab572_o.png[/IMG][*]The forcing together of parents places pressure, in turn, on enclosed ranges of children, squeezed by cousins on either side.[*]In the clash between huddling parents, and enclosed children struggling claustrophobically for space between their cousins, [B]even-numbered[/B] ranges of squeezed children introduce spurious [B]asymmetry[/B], while [B]odd-numbered[/B] ranges of squeezed children seem to leave symmetry undistorted..
[IMG]http://farm7.static.flickr.com/6226/6322648928_c49dc022d6_o.png[/IMG][*]but even when the diagram is not artificially asymmetric, the squeezing of children between cousins still leaves some (or even all !!) parent-child relationships completely indecipherable.
[IMG]http://farm7.static.flickr.com/6091/6322648816_a324b54c8f_o.png[/IMG] [/LIST]
Solution ? Plain vanilla orthogonal trees, with parents centered over children. Even if this means politely setting Graphviz aside for tree diagrams (with orthogonal connectors), or adding a post-processor to clean up after it.

The complete unintelligibility of a range of five enclosed peers and their two cousins (above right) might seem to be as bad as it can get.
But wait, it doesn't yet conceal the symmetry of the underlying data ...
Theory would predict that if FooBar Inc adds just one more hire, and has an [B]even[/B] number of hires (six) enclosed on either side, Automatic Layout should offer not just complete unintelligibility of who is reporting to who, but, as a bonus, spurious asymmetry too:
[IMG]http://farm7.static.flickr.com/6055/6322858442_f646af0e05_o.png[/IMG]

There we have it – the three blue parents are now asymmetrically placed, and no one knows who reports to who. This is probably the full dog's breakfast, and it is all rooted in failing to center parents over their children, in the way that users would normally expect.

The diagram that FooBar Inc expected was:
[IMG]http://farm7.static.flickr.com/6091/6322855736_6517b0e80e_o.png[/IMG]

Which is much more readable – a much better ratio of signal to noise ...

A pity that the interactive Diagram Layout doesn't let us edit outlines while letting something like this evolve – an aid to clarity and better use of working memory.

As it is, the best we can do is run [URL="http://forums.omnigroup.com/showthread.php?t=22521"]an applescript[/URL] to clean it all up at the end ...

[COLOR="White"]--[/COLOR]

These are not the only outline patterns that are rendered unintelligible by Automatic Layout.

Here is another nested outline which is perfectly intelligible as long as we keep to the simple and obvious pattern of centering parents over their child ranges:
[IMG]http://farm7.static.flickr.com/6111/6323135419_3e5dfe6b51_o.png[/IMG]

Applying OG's Automatic Layout will, however, not only introduce redundant and distracting asymmetries, it will also make two parts of the outline quite impossible to interpret. One of them is a pattern that we haven't really seen before:
[IMG]http://farm7.static.flickr.com/6101/6323662616_a1538b8c4f_o.png[/IMG]

In fact, Automatic Layout's current outline-layout algorithm is not incapable of generating genuinely eye-watering levels of unintelligibility.

This example does at least look as [I]symmetrical[/I] as the Automatic Layout sample in the gallery on the OmniGraffle product page, but how many [B]un[/B]ambiguous lines can you find below the three blue parent nodes at the top ?

[IMG]http://farm7.static.flickr.com/6115/6325863493_a684398cc6_o.png[/IMG]

Possibly not many ...


That geometry is pretty good for straight connectors:

[IMG]http://farm7.static.flickr.com/6057/6326213699_7682527ff1_o.png[/IMG]
but it really doesn't work for orthogonal links.

The value of orthogonal links is that they reveal the connection between the horizontal and the vertical – they make the sibling structure and the parental structure equally visible – and they let the eye immediately see the balanced connection between the two.

To do that, however, orthogonal links really do depend on orthogonal layouts – hiding non-orthogonal layouts behind orthogonal connectors is just asking for ambiguity and dysfunction – and if Graphviz struggles to provide simple child-centred layouts, then perhaps it really isn't the right tool.

[COLOR="White"]--[/COLOR]

You nailed it
 

Rob,

You have nailed the issues that have bothered me with auto-layout and orthogonal lines... for years.

Update after update, and the issues still persists. In recent months, I've actually had to start moving things around manually or use other software.

No reply from OminiGraffle regarding this?

If you haven't yet, do flag this up with the Ninjas through Help > Send Feedback. (This is really the only way to help help it bubble up through the layers of priority in their database of issues to address).

I think, however, that they are unlikely to fix this family of bugs (unintelligible connector overlaps, spurious asymmetries etc) until version 6. It's rooted in the choice of Graphviz (which can't currently compute orthogonal allocations of space) as a layout engine. A solution would require extending Graphviz, adding a post-processor, or going for a different layout engine. (The last one seems unlikely).

It looks very much like a fudged compromise between those two perennial components of software engineering and perhaps human life in general – autonomous play and curiosity on the one hand (source of most creativity), and exchange of goods and services in a market on the other (source of most sustainability).

Graphviz has almost irresistible geek-cool, and plenty of scope for play and experimentation (I would have been tempted to choose it myself), but the market needed orthogonal trees, which Graphviz can't do. They clearly knew that orthogonal trees were important to customers – a noticeable proportion of the templates are for 'orgcharts', and until recently orgcharts were strongly foregrounded in the marketing. The compromise was to dress up non-orthogonal layouts in orthogonal connectors ...

(Probably looked OK in a few early test cases, but once you start to work with it, it's hard not to notice that you're looking at diagrams in drag – quite apart from the straightforward bugs ... )

Rob,

I'll echo what jessem said above. This bug has been driving me nuts for a couple of years, and all along I thought there was some obscure feature I just hadn't found yet. I finally decided to get to the bottom of the issue today after much cursing and anguish, and eventually found your post. You've perfectly nailed the problem here, and it's actually quite discouraging to learn that it's unlikely to be fixed any time soon. I use OG exclusively for creating orthogonal diagrams with automatic layout, and this bug represents a colossal time suck for me since I have to make so many manual fixes.

The TreeTool script (available elsewhere in the forum) is moderately helpful, but it's hardly a fix.

Omni team: Realistically, when is this likely to be addressed?

[QUOTE=JeffB;123443]Omni team: Realistically, when is this likely to be addressed?[/QUOTE]

Well, they did de-emphasize in their marketing the (formerly rather focal and foregrounded) impression that OG could (like many packages, including MS Office) automatically generate standard orthogonal trees, with parent nodes centred over their child-ranges.

Beyond that, the only response more eloquent than the silence on this forum has been the standard email formula that "we have filed this somewhere and it may receive attention if it is ever foregrounded by due democratic process … etc etc".

In short, I would really not be all that surprised to see this family of bugs (undecipherable overlapping links etc etc) reproduced in OG6.