Explanations
This rendered come from the idea of forcing to structure a document such as a Curriculum Vitae, and be able to get different view of it.
I somehow started with the Voronoi view, and so choose p5.js as the starting API, knowing Processing and its graphics and mathematics capabalities, and a powerful Voronoi API, which would need much more work for several obvious (how to use the partitioning in a clear way) and less obvious reasons (distributing the elements from a document on a plan can only be perfect for an even number of nodes...).
The next objective was the filtered view.
I did a quick version of the rendered view, as it is the simplest to get fully working, but also the less useful for this program: the filtered view must be properly structured to work, and as such can be easily reused for a better version of the rendered view. But getting a quick working rendered view was useful as a point of reference.
The filtered view is currently using tabs for the filtering. In the future I might add a text-based filtering, but that will probably be aimed at longer document than a Curriculum Vitae. Note that the current program relies heavily on recursion and will not be adapted for a long document.
How does it works?
- It starts by creating an intermediate Tree view of the JSon content with only one kind of element, keeping the children (values in a non-final key-value tuple) and the elements (values in an array) separated. The type is also kept (root, child, element, leaf) for easier treatment
- Then the different rendered are called:
- The filtered renderer creates the buttons in a div block, and the content (including sub-buttons) in another div block. The Javascript calls are using prefix to know which elements to click, hide or show, and a default click is also done on the first menu item. The same creation is done recursively in the div content: a new div for the buttons, a new div for the content, new javascript calls with the new prefix, a new default click...
- The simple renderer uses exactly the same logic of the filtered one, but with div instead of button, without grouping the buttons and with the div class using the depth (instead of unique IDs used for the filtering logic) so a default style can be defined in the CSS file.
- The graphical display try to distribute the elements based on their hierarchy on the defined area: the centres of distribution are currentlythe sites for the Voronoi graph. It would be more correct to have sites only for the leafs but to color the partitions following the hierarchy. That will be the object of another update.
The distribution is also used to display the rectangles of partitions and to color them using the hierarchy: the parent defines the color, the children lighten it.
Current bugs and limits
- The Voronoi graph is still fragile: it is enough to have the wrong canvas size to break it. It is due to the distribution that might push 2 sites in the wrong places (related to this GitHub issue?). I applied and adapted the suggested change from the ticket, and it is quite robust now, but from the discussion could break still.
- I haven't adapted the voronoi creation to use the hierarchic colors like in the treemap. I will eventually add that.
- The filtered view creates unique ids and classes for the JS tab code to work (adapted from the tab tutorial of W3C). As such, it is not possible to predefine CSS styles.
- As the keys of the JSON file are used to define IDs and classes in the filtered view, some allowed characters in JSON keys are not allowed in the HTML. Spaces are currently replaced, as initial numbers (replaced by their name, so 3 becomes "three" for instance), but some are missing, like ":" and "(" ")".
- And as the CSS styles are currently manually generated, there is a limit to the depth where they apply, currently 6. It could stupidly be generated in a big css static file with many levels, but the best would be to do it using the script. A refactoring is probably needed first.
- p5.js helps with the manipulation of the DOM, but sometimes it makes things more confusing, as it might seems that you can write sequencially in a DIV, but you will actually not. So applying the \ before writing the content and the \ after will not work. The block will be empty and closed before the content. It seems that it is always needed to select the created element to write in it as children (as it would be with pure JS). As p5.js is not targeted to HTML manipulation, it is not the most documented aspect.
Thus it is possible that the hierarchy inside the generated DOM is still not correct.
Original Json