Starting guide for nice diagrams: quick hints for choosing a graph layout algorithm for the Diagram component
Comments (4) Visits (5225)
Now, we may wonder: with automatic arrangement of diagrams, humans (developers or end-users) have no role to play anymore? Well, don't worry, there is still place for humans taking decisions. These decisions concern basically two kind of choices that are in the hands of the developer (alternatively, if appropriate, the developer can offer these choices to the end-user thanks to configuration GUI):
The present post focuses on the first point: how to chose the graph layout algorithm that fits. In some cases, this choice is quite straight-forward, in other cases it is a bit trickier, and to guide your choice you can find below a short synthesis of information present at various places in the Elixir Enterprise documentation (Reference and User Manual), enriched with a few additional hints.
This algo organizes the nodes in horizontal or vertical levels, in such a way that the majority of the links flow uniformly in the same direction. A typical example:
This algo is the obvious choice for representing hierarchies, that is for hier
The obvious choice for representing trees (such as organization charts), where each node has one single ancestor. A typical example:
Can also be used if the graph is not a (pure) tree, however in this case the Tree layout only takes care of the shape of part of the links (those that contribute to the pure tree part of the graph, the so-called "spanning tree" of the graph).
Your graph does not represent a hierarchy, is not a tree and the orientation of links does not matter? Then Force-Directed layout is likely to fit. An example:
A remark, however. For large graphs (say, with thousands of nodes), this algorithm is much slower than Hierarchical or Tree layout. Therefore, for performance reasons, you may prefer using them for such graphs, even though the graph is not a Hierarchy nor a Tree.
Obvious choice in case your graph has no links at all, or you want nodes to be placed on a grid or matrix while ignoring the links. An example:
Short and Long link layout
Both are link layouts, that is they do not move the nodes, they only reshape the links in such a way that crossings and overlaps are reduced or avoided. But why two different algos, Short link layout and Long link layout? The answer is that they have different (mostly complementary) characteristics, and, depending on the case, one or the other provides results that fit better the aesthetic and performance requirements. How to chose one or the other? The dumb rule is to try any of them; if it does not fit, try the other one (and explore the multiple options of each).
That said, it is also useful to be aware of some characteristics of each, which help making the choice. In very brief, the names "Short Link layout" and "Long Link layout" refer to the fact that the first one fits better when most links are "short", that is they interconnect relatively close nodes, without too many other nodes placed as obstacles that would need to be avoided by the path of the link. It is the converse for "Long Link layout": it usually fits better when links connect distant nodes with many obstacles in-between.A more in-depth comparison follows:
Short Link layout
Long Link layout
The two screenshots above hold for the same graph. At a quick look, the results of the two link layouts are pretty much similar, but a closer look, many details are different in terms of link-link crossings, link-node overlaps, symmetry of connection points with respect to the node box, number of link bends (how many turns).