The making of circular treemap in Glamorous Toolkit
By: Tudor Girba
Tags: Moldable Development, Gtoolkit, Data Visualization

Taking a step back, there are a couple of things to notice. The algorithm has multiple layers of abstraction: At first, we have the recursive definition of the treemap. Then is the circle packing layout which, in its turn, is based on computing the enclosure of given circles, on identifying where to add a new circle, and on actually computing the location of the new circle. All these are separate pieces that can be used independently.

Having a multi-layered algorithm is not unusual. What is less usual is that all layers are exemplified and are inspectable through custom views. When following moldable development, these custom views are natural byproducts.

The first rule of thumb is that if we need to look at the raw view of an object type more than three times, we are likely missing a custom view. So, we build one. The second rule of thumb is that before solving a problem, we first depict it in a way that makes the solution evident.

This process is orthogonal to the typical test or example-driven development. For example, the circles enclosure is mainly a collection of circles. Yet, because we wanted to have a specific view, we ended up promoting it to a first class entity even though from a functional perspective, everything remained the same.

Thinking of custom views exercises the design in a way that testing does not. While writing tests during development builds testability into the system, guiding the design through custom views builds explainability into the system.

For example, while working on the algorithm, we had to deal with a bug when computing the enclosure of specific nodes. We noticed the issue in a larger treemap, and narrowed it down to a smaller case involving three nodes. The view below shows that the blue enclosure circle on the right is not the minimal circle we can draw.

The dedicated view reveals a bug: the enclosure (in blue) is not minimal.

The screenshot documented the bug report. Having the view around helped us locate the problem quickly and write a failing example for it. The solution came soon afterwards.

It is hard to convey the impact on the development experience of these custom views. It’s not unlike the testing: you have to practice it to fully appreciate it; and the more you practice it, the more pleasant the experience becomes. Like with testing, it’s counter-intuitive: building a view is a meta step that apparently distracts from the direct task at hand. Yet, building that view helps us make explicit what is important to explain and this leads to better design.

Custom views also help us tell others what is important. There is great power in being able to convey a problem about a detail deep inside a system through a single picture that requires little explanation. The pictures from the paper were deemed meaningful for communication purposes. Like the drawings on the whiteboard these picture are important in that they capture an intent. Yet, these pictures should only be drawn manually when the system does not exist. When the system does exist, the picture should never be drawn by hand. The system should draw it for us.