Incremental Layout post factum

The way the Incremental Layout works right now is that you can switch it on prior to an edge/entity addition (a process that normally would create a dramatic flip). If you switch it on, prior to the edge/entity addition, the “flip” is less dramatic. You also can switch it back off and the dramatic flip is back. Unfortunately, if you switch it back on again, it will not bring you back to the less dramatic “flip” situation. This is how the application works right now. Basically, the Incremental Layout cannot work post factum. It only creates a condition for the diagram, in which an edge/entity addition behaves less dramatically. But it will not change something that you already created.
I assume this is due to a certain sequence of events in the programming and I don’t know if it is possible, but it would be great if the Incremental Layout switch would be able to apply the setting post factum, without being necessary to undo the edge/entity addition prior to applying the switch. I’m talking about the ability to apply the switch immediately after an edge/entity was created (and not only prior). Again, I don’t know if it’s possible but I think it would be useful and appreciated given that it can save steps in the process, and make it easier to compare the two layout variants.

Thank you for your ideas. Right now incremental layout has particular use-cases, but you’re right that those cases are limited. Turning it on basically tells Flying Logic to suspend a number of rules for how it normally lays things out, in favor or keeping things as stable as possible from change to change. You could leave incremental layout on all the time but you’d find that that “rule breaking” would eventually make your diagram a rather tangled mess, which is why turning it off from time to time and letting Flying Logic “restore order” is also a good thing.

I have plans that a future version of Flying Logic will basically be “all incremental, all the time,” and this should satisfy many more use-cases. But there will always be tension between how you would lay things out yourself if you did it by hand, and how Flying Logic lays things out, because that’s Flying Logic’s job, while your job is creating the actual meaning of your document.

In my complicated diagrams, I typically either use group hoisting or incremental layout while doing a lot of moving things around, then “clean up” the diagram to help me check for completeness by switching incremental layout off then on again. It’s tremendously helpful when sharing screen and diagramming in a workshop because people can get lost quickly when they can’t scroll around quickly to see what just happened.
I’d recommend for this use case the following modes:

  1. Incremental layout mode, then reveals a button to clean up the diagram that you manually invoke when ready for flips.
  2. Regular mode, applying the layout rules constantly, as it is by default today.

It may also be interesting to explore changing the default, regular mode to calculate first when changes would be drastic and postponing the layouts until the next change. I find that when making changes to complicated diagrams, often the entire diagram flips and then flips back with the next change. Postponing even by one change could make the flipping less jarring.

. . . or maybe applying the layout rules every time to all but the “furthest” entities, which become those pivot points making the diagram flip around? And then waiting a few changes before re-laying out the furthest entities?

Thanks for your ideas. I have some pretty radical ideas about incremental layout I’m working on for a future version of Flying Logic!

1 Like