Skip to content

Commit d3e9fe1

Browse files
Updated readme file
1 parent 4390eb5 commit d3e9fe1

File tree

2 files changed

+10
-0
lines changed

2 files changed

+10
-0
lines changed

min/readme.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,11 @@ When using a graphics editor to manually draw your diagrams, it is common place
5050
* Diagram autolayout consistency. Our auto layout provides visual consistency across all diagramming documents. The user can customize the visual appearance for any diagrams that they wish manually. All users have various skills and preferences, so auto layout provides consistent default diagram viewing throughout the organization.
5151
* Always up to date. Your application's diagrams will not be effected by changes in the component's layout algorithms and application data. Your visualizations will always be up to date and in sync with your data.
5252

53+
#### Stable rules based auto layout of multi parent hierarchies
54+
The core problem of dependency diagrams layout is the endless number of permutations. As a result every time we make any changes to the diagram's relations, we get a new "optimal" layout. However that "optimal" layout can be so different from the previous "optimal" layout that the end user needs to relearn the diagram again and again. This becomes worse the more nodes you have. Analysis takes so much time, that it makes the automatic diagram layout useless. So it is very important that diagram does not change much between user edits.
55+
So in order to overcome that problem we added support of user rules that the auto layout algorithm follows. The problem is that "hard" rules are equivalent to manual layout if we start to define the placement of every node manually. Which destroys the whole point of even having auto layout for the nodes. So we introduced "soft" rules, which our control follows as long as they don't contradict to the purpose. Our control does ignore them when they are not applicable.
56+
* Moderate layout changes between edits. Multi parent hierarchy diagram does not change much when we add or remove nodes. Developer is encouraged to add order of nodes relative to each other, but that order does not enforce layout, control still has flexibility to choose optimal layout itself.
57+
5358
#### Auto sorting the diagram nodes into levels
5459
It is not obvious, but by default we distribute all nodes in the diagram into distinct levels. This gives the end user a clear indication about a node's relations. For any given node, all nodes that are below it in the diagram, are either it's dependents or minors. On the contrary any nodes found above the node are either its parents or superiors. This is a simple and straightforward visual sorting method that helps when analyzing and viewing large diagrams.
5560

readme.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,11 @@ When using a graphics editor to manually draw your diagrams, it is common place
5050
* Diagram autolayout consistency. Our auto layout provides visual consistency across all diagramming documents. The user can customize the visual appearance for any diagrams that they wish manually. All users have various skills and preferences, so auto layout provides consistent default diagram viewing throughout the organization.
5151
* Always up to date. Your application's diagrams will not be effected by changes in the component's layout algorithms and application data. Your visualizations will always be up to date and in sync with your data.
5252

53+
#### Stable rules based auto layout of multi parent hierarchies
54+
The core problem of dependency diagrams layout is the endless number of permutations. As a result every time we make any changes to the diagram's relations, we get a new "optimal" layout. However that "optimal" layout can be so different from the previous "optimal" layout that the end user needs to relearn the diagram again and again. This becomes worse the more nodes you have. Analysis takes so much time, that it makes the automatic diagram layout useless. So it is very important that diagram does not change much between user edits.
55+
So in order to overcome that problem we added support of user rules that the auto layout algorithm follows. The problem is that "hard" rules are equivalent to manual layout if we start to define the placement of every node manually. Which destroys the whole point of even having auto layout for the nodes. So we introduced "soft" rules, which our control follows as long as they don't contradict to the purpose. Our control does ignore them when they are not applicable.
56+
* Moderate layout changes between edits. Multi parent hierarchy diagram does not change much when we add or remove nodes. Developer is encouraged to add order of nodes relative to each other, but that order does not enforce layout, control still has flexibility to choose optimal layout itself.
57+
5358
#### Auto sorting the diagram nodes into levels
5459
It is not obvious, but by default we distribute all nodes in the diagram into distinct levels. This gives the end user a clear indication about a node's relations. For any given node, all nodes that are below it in the diagram, are either it's dependents or minors. On the contrary any nodes found above the node are either its parents or superiors. This is a simple and straightforward visual sorting method that helps when analyzing and viewing large diagrams.
5560

0 commit comments

Comments
 (0)