Hi, I am using tinderbox often to analyze existing system landscapes in the starting phase of bigger IT projects. What I am looking for actually is an idea to represent the systems, applications running on these systems, changes on these systems and applications and their dependencies on a flat level like a mind map.
The collecting of information I will do in outline view because of the given hierarchy. But presenting the dependencies it would be easier to show all components on same level.
Only idea I have so far is to use agents to collect all notes and create a map view based on the agent.
So, my question is, if this would be the best approach or maybe someone here has a better idea or solved something similar before ?
Of course your own containers, and the agent, will be very sophisticated.
A map of an agent container (i.e., āMap Levelā in the example), by default rearranges itself when the agent refreshes. See Re-Arrangeable Agent Maps. To control that use the $CleanupAction attribute, whose value you set to none for the agent.
Itās also possible to invert the process ā have all the notes in a master container and use agents (each of which is mapped) to pick out sub-categories.
A hidden benefit of @PaulWaltersā solution is it also moves what may be a big map out of the root (highest (outline) level of the document). If not using an agent, Iād thus suggesting making big maps in a container and not just in the first (root) map as is presented when you start a new TBX.
If you want to see itrems linked in the map, donāt create links in the map but use the originals. The background rationale is getting into the weeds, but trust me, linking originals notes as opposed to aliases will make your mapās linking more persistentā .
ā . Iām not trying to hide anything, but just avoiding getting-started overload. more on linking and aliases can be read about here.
As a general matter ā I always create this structure in new Tinderbox documents:
Root-level containers for:
Notes
Agents [for documents that use them]
Prototypes
Templates
Code [for documents that have code notes]
Thereās nothing prescriptive about this ā other than the advice to segregate ātypesā of content into dedicated containers, and keep oneās working data (the ānotesā) out of the root.
Thanks @mwra, @PaulWalters for your insights. I will try it in next days following your suggestions, especially regarding cleanupaction attribute and linking of the originals !
One topic left is a way of kind of automatic layout generation using X,Y coordinates of the note dependent of the notes directly linked to. Any idea regarding this ? I expect I have to use X,Y attribute of the note and adding kind of fix distance to it?! Just want to avoid implementing a second layer of graph layout generationā¦
While auto layout sounds attractive ā and the math is certainly doable ā the problem is the math. Consider
$Xpos and $Ypos for a note and its alias in an agent container are not the same ā the maps can have different layouts. So the calculations would have to focus on the aliases {X,Y} in the example earlier in this post.
As @mwra suggested, itās best to consider links between original notes. Since there is no obviously discernible mapping between {X,Y} for originals and {X,Y} for aliases, whatever math takes into account links in the original would probably need some sort of intermediate numeric attributes to calculate the effect on map layout in the map made of aliases.
I believe (without proof ā just supposition) that auto-layout can be fragile because it has to take account of numerous exogenous factors: note dimensions, anchor points for links (not calculable), etc.
I donāt mean to scare you off from this ā it is a very interesting puzzle. But, auto-layout might be more time consuming than just manually setting up the map you want.**
** Consider that auto-layout based on figure metadata is not common feature of many graphical applications. OmniGraffle might be an exception ā and even there the effort to work out the math is not trivial.
Donāt overlook Tinderboxās force-directed layout method, aka ādanceā. See more here. It might fit your needs.
Before writing any code in this context, do ask yourself, is this a strict hierarchy? IOW, do all items have one, and only one parent. If not, Iād revisit the plan. Itās not impossible but a little harder than in the minds-eye, where everything looks cool and lays out perfectly.
If it is a strict hierarchy, why not view it in Outline or Chart views. Of not, and it all relationships (inlcuding parent/child outline nesting) are implemented with links, try Hyperbolic view.
Thanks Paul, these thoughts regarding complexity and effort were preventing me to start.
I will start with the manual approach and will proceed step by step. For me part of the Tinderbox approach and will try to use this as an possibility for more thinking about the dependencies.
In the end, I like Tinderbox because not everything is done automatically. This offers more freedom to me.
Unfortunately it is only in the āMaterialā world a fixed structure (System - applications - Feature). But business objects and business projects will not necessarily follow it.
Keep in mind Smart Adornments that can help with gathering notes, and other affordances of Map views that can help with understanding the map ā subtitles, captions, colors, textures, badges, etc.
If whatever you come up with is shareable in any way ā please post an image here so that others who are looking to do a similar task can see a concrete example.
@PaulWalters, @mwra Lot of time passed by because lot of other projects to do. I followed your advice to arrange map view manually. Based on this manual arrangement, I have started to begin with the map view and to generate an outline view by using a predefined link type with an OnAdd action to remember source and destination of the link for later. After finishing the map, I duplicated the whole container to a new one and applied a stamp for redefining the $Container attribute of all notes. Based on a former hint by Mark in another forum post.
Example Tinderbox file is enclosed: Many thanks for your support ! MapOutlineViews.tbx (85.2 KB)
This is an embarrassing question, but Iām dropping in here anyway.
What is this grouping function called that sticks two notes together in a box? And how do you turn it off or undo it? I have searched forum, help, etc, but canāt find it.
These are called composites. The article explains how to break apart a composite. To disable them completely, see the subarticle to the aforementioned, on āSuppressing formation of compositesā.
You are so generous Mark, thank you. One follow up. When I broke the composite the two notes still stuck together, not as composite but dragging one dragged the other. Was that because of a missing action I didnāt take?
Hard to say. It is confusing, IMO that the when Cmd+dragging a note out of a composite the compositeās border keeps expanding and so there is no visual evidence that you have dragged the note far enough away to exit the composite.
Another way to break the composite is to select it and use Edit menu ā Break Composite. Or set $NeverCompoite to true (ticked, in the UI listings).
Yes it does. I did use Break Composite from the menu, but maybe had to cmd-drag to actually take them out of composite space. There is no way to make $NevrerComposite universal to a document right? Assume would have to incorporate in prototype.