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.
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/
It went like this. Imagine you have a system written in Python and you want to split it for various reasons.
You'd first look for components that already exist. In this case, the system already seems to have top components available (as documented by top folders).
Personal computing was conceived to be personal. Personal, as in experiencing computation the way it fits you. Your context should come first and dictate what is interesting. The experience should follow.
1/
For example, consider where you are reading this tweet. Or where you are writing a reply to it. It's not unlikely that you are doing it exactly in the same way many other millions of people are doing it: using the generic interface that Twitter offers.
2/
Of course, this is convenient. At the same time, it might not match your actual needs. For example, say you like writing longer threads. Longer threads imply more consideration and possibly longer time to write. And, you may want to handle multiple drafts in parallel.
3/