A while back we implemented the squarified treemap algorithm in #GToolkit.
The implementation is based on a paper written by Bruls, @mackees and van Wijk in 2000 that describes a heuristics-based algorithm.
1/
The paper describes the algorithm in detail, and most of the explanations are based on visual depictions.
Here is a visualization showing the core iterative steps taken by the algorithm.
2/
Of course, the main goal of implementing an algorithm like this is to produce the final picture. Here is how such a result looks like in #GToolkit.
3/
But our goal is not only to produce a functional system. We want an explainable system. The rule of thumb is that if a human deems a representation as meaningful, it should be the responsibility of the system to carry it forward.
4/
In our case, when we inspect the algorithm, we want to see the picture showing the steps as in the paper!
5/
Once the algorithm object knows how to present itself, we document the code through examples that give us interesting algorithm objects.
6/
And once we have examples, we can quickle write a narrative.
@swardley I find that the most exciting part, which might also be the most difficult to explain, is that conclusions seem to emerge before people agreeing with each other, or even before any of the participants having the conclusion formed a priori.
I think that's extraordinary.
2/
@swardley Perhaps an example might shed some light.
In one of the groups, we build 3 maps. Each of them started with a certain assumption, and in each case mapping further sentences eventually turned the assumption upside down. Literally. In all three cases. With the same people.
3/
It's written for a first time reader. It's not quite short, but it's not that long either (~4000 words). It has concrete examples, but also a little broader theory.
It starts from the reading problem: reading accounts for the single largest expense in software development today, but it's just a strategy to gather information from the system. We can automate much of it, but we should do it through custom tools.
2/
To give a hint as to why this is relevant, I describe of an experiment in which we gave student teams the same requirements and a constrained tech. They produced very different structures which suggests that a system's inside emerges over time and that we need to react to it.
A beautiful example of #MoldableDevelopment. The view itself is not the most interesting part. The fact that you can write it with a screen of code is. That code is the legend of the tool.
While the tool is generic, we can easily imagine customizing it for specific contexts. For example, highlight specific files that are important for a specific investigation, like those from a special folder. When every view is an extension, you enable a rich experience.
2/
In the not too distant future, we’ll look back to this age and find the present default tools rather quaint.
Lepiter is the latest significant step in our journey to making systems explainable. Here is a behind the scene peak of how we got here.
1/
Our guiding north star @feenkcom is making the inside of systems explainable. We spent a great deal of energy rethinking how we can figure systems out, and this led to #MoldableDevelopment and #GToolkit.
#GToolkit proposes a new development experience. We see the environment as a language made out of visual and interactive operators that can be combined in many ways while working with the environment.
3/