FelipeDefensor
commented
1 month ago Thank you very much for the detailed analysis, Johannes.
It is true that TiLiA was designed with the bottom-up approach in mind. Given the current UI, building up from a contiguous level by splitting and grouping is indeed the more intuitive way to populate a hierarchy timeline.
However, there is already a create child functionality and it may be used to populate the timeline in a way that I believe is farily similar to what you described. It amounts to "increasing" the level of the starting leaf, creating a child bwlow it, splitting it, and repeating that recursively, as per the video.
https://github.com/user-attachments/assets/896b09a7-4a01-4488-9061-7d21a6ee6aef
The issue is, creating a child does not create a new, lowest level for it if the current node is already at the lowest level. You are required either to know the number of levels in advance and set the starting top level accordingly, or to change the levels of the parent units on demand, which leads us to the next point.
selecting all parents and clicking on "Increase level" (example screenshot below) starts iterating through the nodes at the bottom which leads to exactly one Change level failed: would overlap with parent error per node, except for the parent whose level is increased;
This is a regression that I'm surprised slipped through the tests again. Will fix it ASAP, and it should be just a matter of iterating through the nodes in reverse order.
here seems to be no easy way to select all nodes (e.g. using Ctrl+A) or all nodes of the same level (e.g. by Shift+Click) at once.
The easy way should be: zoom out far enough so you can box-select everything. However, the horrid performance of zooming when AudioWave timelines are involved made that impossible in your case. Fortunately, the performance has been brought to acceptable levels (zooming taking around 0.05 secods) in a soon-to-be-pushed commit. I will say more about that when answering #200 .
In any case, hanving something like Ctrl+A would be great, although I think that should be reserved to selecting all components in all timelines. What seems ideal to me is having a "Select same" context menu that could be used for selecting not only all the nodes in a level but also, for instance, all nodes that share a label.
In all cases where one did not keep one root node spanning the entire piece at the top, one may easily invalidate the entire tree by increasing or decreasing the level of only some, but not all, of the top nodes. For instance, if we were to increase only the Exp! node in the example below, the label would be ripped out of the context of its neighbours and would solitarily stand on level 1.
I may be missing the point here, by I feel that a lot of the more casual users will not want the constraints of a valid tree to be enforced. Hierachy timelines were not designed to be a strict representation of tree structures, in great part because of that, but also because they can do double-duty as, for instance, representations of single-level structures with no overlaps. For those reasons, I think it is best to enable the creation on invalid trees, while also, of course, making it simple to also create valid ones.
Terminologically, "Increase level" seems an unfortunate choice because the level number actually decreases when a node moves up. "Move up one level" would be unambiguous.
Not sure I understood this. The root of the tree is usually level one, right? (actual question from someone who did not take those data strucutures classes :D). So the operation that is currently called "Increasing level" actually moves the node down a level, correct?
If that's the case, I believe there is a mismatch in the intuition the user that has a background in maths or computer science and the one that has not. I may be wrong, but in the latter case I imagine it is much more intuitive to imagine level one as being the leaf level, given the way the nodes are laid out on the interface, so "moving up" means going up in the vertical (spatial) direction. I have tended to go with the more "user-friendly" naming in cases like this, as I do intend TiLiA to be used by a wider audience.
Scenario
Creating a hierarchy in top-down manner. A new hierarchy starts with level 1 and is built up by recursively splitting levels and adding children to the segments. The nature of this top-down procedure is to add more and more lower levels (level 2, 3...).
Desired behaviour
One selects a leaf node and clicks on "Create child". A new level is introduced underneath.
Current behaviour
One selects a leaf node and clicks on "Create child". The error
Create child failed: Hierarchy is at lowest level.Discussion
As things stand, before adding a child to a leaf node, one needs to increase its level. If the node is a child itself, this raises the warning
Change level failed: would overlap with parent. By extension, one needs to first increase the level of all parents in order to add a child. In my view, this is problematic for three reasons:Ctrl+A) or all nodes of the same level (e.g. byShift+Click) at once.Change level failed: would overlap with parenterror per node, except for the parent whose level is increased;Exp!node in the example below, the label would be ripped out of the context of its neighbours and would solitarily stand on level 1.It seems to me that TiLiA has been designed with the bottom-up procedure in mind, assuming that the user would first create a contiguous leaf level (without gaps) which always remains the lowest level, no matter how many levels are added above by merging nodes. The above-mentioned limitations prohibit building hierarchies in top-down manner. Allowing one to automatically add a new level below by clicking "Create child" will solve that problem and therefore considerably increase its scope of use cases. In addition, it will allow for a straight-forward creation of trees whose main branches have different numbers of levels (e.g., a middle section with fewer hierarchical levels, whose leaf nodes are not reaching down to the lowest level).
Terminologically, "Increase level" seems an unfortunate choice because the level number actually decreases when a node moves up. "Move up one level" would be unambiguous.