Hierarchy and Hierarchy Charts
UPDATE: Latest versions of hierarchy and hier_chart can be found here: http://support.nodebox.net/discussions/show-your-work/961-updated-h...
I have long enjoyed drawing hierarchies: org charts, family trees, outlines, treemaps, Sankey diagrams, sunbursts, icicle trees, sentence structures, cladograms, decision trees, taxonomies of every kind. I have made all of these using Nodebox, but each one was bespoke, sometimes hard to make, and hard to reuse.
My goal was to make a generic system for making hierarchies in Nodebox. In this note I introduce the hierarchy data structure and node. I the next note I will describe a node to draw standard org-chart hierarchies.
The first thing needed was a standard, flexible, generable purpose data structure (see table attached). I defined one using a Nodebox table. It has three columns:
- hierarchy ID. A string dot descriptor uniquely identifying every position in the hierarchy. IDs always start with an h to make sure Nodebox treats them as stings, not numbers. Each level is separated by a dot and siblings are numbered from 0. So h.1.0 is the first grandchild of the second child of root h.
- level. An integer representing the level of depth for each position. The root is always the sole node at level 0. Each subsequent generation occupies a level.
- hierarchy item. A string or number or path or data row associated with each position. I recommend having only one row in the hierarchy for each position, but by repeating IDs you could associate multiple rows with a single position.
These hierarchies are strict. There is only one root, you cannot skip levels, and each child can have only one parent.
I have attached a typical hierarchy table so you can see what they look like. This table is for the org chart hierarchy described in my next note.
My intention is to create a whole family of nodes that can accept these standard hierarchy tables as input. I will be sharing some of these in the days ahead.
CREATING HIERARCHIES
The next thing needed was an easy way of creating these hierarchies. After much experimentation, I settled on the hierarchy node, described here.
It turns out you can efficiently describe the exact structure of a hierarchy by simply making a depth-first traversal and recording the level of each position. This ordered list of levels uniquely determines the structure.
By "depth-first traversal" I mean start at the root (level 0) and then visit each child in turn. If that child is a parent, next visit its first child. When you get to the end of that chain, work your way back up until you find another sibling, then repeat the process until each child has been visited once.
For an example, see the attached screenshot with the numbered structure. The positions are numbered from 0 to 20. The list of levels needed to describe this structure always starts with 0 (the root), then 1 (the first child is always on level 1), and then the rest in depth-first order. In this case the first child has 3 children; the second of these has 4 children. So 01 is followed by 2, another 2, then four 3s, then back up to the final sibling at level 2. Then back up to level 1 (the second child has 2 children and 1 grandchild), and then back again for the final subtree. The final list of levels is 012233332122312332323.
With practice it becomes easy to quickly enter these level lists. For large hierarchies with hundreds of positions you may want to extract these levels directly from some data source. For example XML files (like NDBX files) use indentations to represent the level of each entry; these indentations can be directly converted to a level list.
The hierarchy node is very simple; it takes only two inputs:
- levels. A list of integers representing the levels of each position in depth-first order, starting with the root at level 0. You can use a make_strings node to quickly enter such a list.
- items. A list of items for each position. This list is optional; if no items are input, the node will create a standard index list (0, 1, 2, etc.). If the items are fewer than the number of positions, indices will be added to fill the remaining slots. If the items are more than the number n of positions, only the first n items will be used.
Given these inputs, the hierarchy node produces a standard hierarchy data table with the three columns described above. The IDs are computed and assigned automatically. Currently this node will build hierarchies of up to 12 (0 to 11) levels; if more levels are needed this capability would be easy to add.
The attached demo shows a simple hierarchy created from a level list. In this case, no items were provided, so the node used the numbers from 0 to 20 instead. You can see the actual data table by rendering the draw_table node. The actual drawing of the diagram is accomplished using my labelmaker and hier_chart node. The hier_chart node is described below in the next note.
It's been a long journey to create this system, with many false starts and much left on the cutting room floor. I think I finally have a system simple and powerful enough to open up a world of new possibilities.
In addition of org charts and outlines, I would also like to see this node used for purely artistic experiments. A Calder mobile is a hierarchy. You could define hierarchies of color and filter the table to apply colors to your designs in a systematic way. Purely visual hierarchies would be easy to define and position on a canvas.
Stand by for more fun with hierarchies!
-
hierarchy_data_structure.png
44.6 KB
-
hierarchy_node_screenshot.png
445 KB
- hierarchy_node.ndbx.zip 248 KB
hierarchy_data_structure.png
hierarchy_node_screenshot.png
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by john on 04 Jun, 2025 11:17 PM
PART 2: The hier_chart node.
Hierarchies are not much fun until you can see them. There are MANY ways of representing hierarchies. My intention is to provide a family of nodes to do this. The first of these is the hier_chart node.
Hier_chart draws a standard "org chart" style diagram. The diagrams can flow north, south, east or west, and can be connected by several different styles of connectors. Nodes at each position can be paths or labels (text paths inside containers created by my labelmaker node).
Hier_chart takes 7 parameters:
Hier_chart outputs a list of positioned groups: one group holding all the links followed by one group for each node. If originally supplied as paths, each node is automatically enclosed in an invisible, consistently-sized box big enough to hold the largest node. This system ensures clean placement across levels.
The attached demo shows two views of the same hierarchy. The hierarchy is a typical company org chart I found on the web (see previous note for the table structure). The output of the hierarchy node is fed into a null node which then feeds into the rest of the network.
The Nodebox nodes below and to the left of the null node create the standard chart at the bottom of the canvas. I created the rounded rects for each company division using my labelmaker node using a rect shape. You can see what the labels look like before being inserted into the chart using the stack2D node. You can also try using the two other supplied shapes and changing the other settings on labelmaker. For more about labelmaker, see http://support.nodebox.net/discussions/show-your-work/898-labelmaker
Before feeding these labels into the hier_chart node, I first color them independently for each subtree (region) using a "tree_colors" node and a palette produced from my color_brewer node. Tree_colors shows how to differentially color substructures within a hierarchy (if you so desire).
Hier_chart1 then produces the org chart directly. By adjusting the settings on both the labelmaker and hier_chart you can have fine control over the exact appearance of the chart. You can quickly step through different color palettes, container shapes, fonts, sizing, and spacing.
Hier_chart2 produces the alternative chart on top of the canvas. Instead of using labels it uses simple text paths (with strings extracted from the hierarchy), colored again by subtree using a slightly different set of colors. It uses curved links instead of angular, and flows to the east instead of the south.
Once you have your hierarchy defined you can experiment with many different ways of drawing it and can adjust the layout to fit any size constraints.
I am only just starting to play with these hierarchy and hier_chart nodes. I may post more of my experiments in this thread, and I encourage anyone out there to do the same!
Enjoy!
Support Staff 2 Posted by john on 05 Jun, 2025 09:32 PM
UPDATE
After trying hier_chart on larger and larger hierarchies, I found a bug which could cause an unnecessary gap to appear between an occasional pair of subtrees in certain rare situations.
I have fixed this bug.
Attached are version 2s of the two previous demos (for hierarchiy and hier_chart) each with an updated version of the hier_chart node. The bug made no difference to small charts like the ones in these demos, but could have affected large charts.
When you are ready to give hier_chart a try, use the node from either of the demos attached to THIS post, not the attachments in the first two posts above.
Sorry about that!
A personal note:
Was this bug hard to find? Yes it was. Was this bug hard to fix? Yes it was. Layout tasks like this one are hard for computers in general, and even harder for Nodebox because of its lack of recursion.
It's foolish to ever say this, but I hope that was the last bug!
Support Staff 3 Posted by john on 06 Jun, 2025 05:57 AM
And now... my first real hierarchy chart made with my new system.
This chart shows the structure of subnets inside a single one of my nodes - in this case, the very hier_chart node I used to make it!
I've wanted to make a chart like this for YEARS. The structure of subnets in a complex node like hier_chart, its main-level subnets, the sub-subnets inside each of those, the sub-sub-subnets inside those, and so on - up to ten levels deep in this case - form the skeleton on which all the other hundreds or thousands of nodes hang.
Many of the nodes I publish in my library have deep structures like this because I make them out of other Cartan Library nodes. And yet I've never seen a subnet diagram like this before. I've made a network to draw the network within any given subnetwork, and I can output them in a slide show, but I can't see the actual structure of how they all fit together - until now.
To construct this chart I first made a new Nodebox file containing ONLY my hier_chart node. I made one modification (discussed below). Then I just entered that file into the top node of my subnet chart network. It worked perfectly the first time.
The only real challenge was finding a way to draw it that wasn't too wide or to tall. I adjusted the labels to snugly enclose the subnetwork names, plotted the chart to the east to create a vertical chart, then rotated it to create a landscape oriented chart.
I also made a new subnetwork, hilite_subtree, that let me highlight a particular subtree within the chart. This subtree, level_bottom, is the inner core that does the layout. Because this kind of layout is deeply recursive - and Nodebox doesn't do recursion - I had to hardwire it by creating a string of 12 identical copies of level_bottom, enough to allow a maximum depth of 12 levels. Leaving in all 12 of these large subtrees would have made the overall chart absurdly wide, so the one modification I made was to remove all but one of these subtrees - and highlight the remaining one in red.
I have attached a zipped folder containing the subnet chart network and the file holding the single reduced hier_chart node that it reads. In addition to the screenshot I have also attached a low-res poster of the chart and one closeup.
I am very pleased with how smoothly this went. I hope it will be the first of many interesting hierarchy charts to come.
If anyone out there uses this technique to make subnet charts of their own projects, please share!
Support Staff 4 Posted by john on 07 Jun, 2025 05:32 AM
Here is more polished version of my subnets program.
It's now plug and play. Just launch it, click any node then click outside the node to see the two root-level parameters, enter a NDBX file, enter a subtree ID to highlight (if you want) and boom: instant subnet chart.
I also fixed the ordering so at each level the siblings are arranged from left to right in alphabetical order. And I made a few adjustments so the layout will work fairly well for a wide variety of trees. You can see the improved version of the hier_chart subnet diagram in the screenshot.
Of course you can fiddle endlessly to make a poster quality version. Change the canvas size, background color, fonts, spacing, sizing, highlighting, anything you want.
I spent the afternoon making 14 charts; it was quick and easy. I even made a cheerful little movie of all the different charts with an Apple soundtrack. All attached.
Enjoy!
5 Posted by lastvector on 07 Jun, 2025 06:49 AM
John
Thank you very much.
I've often been impressed by your skills with Nodebox, and
this is no exception. Very impressive.
gottfried
Support Staff 6 Posted by john on 07 Jun, 2025 08:25 AM
Thanks, Gottfried. I've had a lot of practice, but this one was harder than usual. Now that it's finally working, I'm having lots of fun with it.
Support Staff 7 Posted by john on 17 Jun, 2025 06:11 AM
UPDATE. New versions of hierarchy and hier_chart can be found here: http://support.nodebox.net/discussions/show-your-work/961-updated-h...