Description
The Fibery model allows creating relationships in the database table to the same table. For example, a feature can have a relationship to a collection of features. This allows creating recursive relationships that can even become cyclical. We already have problems both with explaining this powerful concept to users and visualizing such relationships.
Hierarchical views (lists, smart folders, and new tables) allow displaying such relationships recursively, but only at the first level of the hierarchy, and only provided that the relationship type is one-to-many.
For example:
The setup looks like this:
How we build a hierarchy with self-relations right now
The hierarchy is built in such a way: we get all the features, select those that do not have a parent feature, and assume that they are at the first level. Then we move down from them until we reach the features that have no child elements.
If there is a cycle in the hierarchy (F1 → F2 → F3 → F1), then we never reach the features from the cycle recursively (each of them has a parent), so at the second step, we exclude the found features from the general set of features, and draw the missing ones also at the first level.
Elements of the following levels (for example, bugs) are drawn each under their first-level element and no special problems arise.
Bottom level
Imagine a situation where we want to draw recursive relationships at a level other than the first. Let's first imagine such a setup:
View:
Product Area 1
Product Area 2
Then we make self-relation on:
❌ Option 1
and the view should turn into
Product Area 1
Product Area 2
Here we do recursive grouping only within the product area feature collection.
Will it be difficult to explain to the user why there is only Feature 1-1 under Feature 1, and there is no Feature 1-2? This is an open question.
If I drag Feature 1-2-1 into Feature 1, should I change both the feature to Feature 1, and the product area to Product Area 1? Apparently yes, otherwise the feature will remain in its place. Will this be clear?
❌ Option 2
The second option is to consider the root elements those that are directly related to the product area, and then go deeper using all features. Then we get such a tree.
Product Area 1
Product Area 2
Here it becomes unclear, Feature 1-2 belongs only to Product Area 1 or to both product areas at once.
It appears that this option is even worse than the first one.
✅ Option 3 (proposed by :michael: and selected for his responsibility)
Build the tree for the Features the same way as we do at the root level
Then attach root Features to its Product Areas. That is it.
The result will be:
Product Area 1
Product Area 2
Problems here: Feature 1-2 actually belongs to the Product Area 2, but it's not reflected here.
On the other hand, DND behavior appears to be logical, for instance, if we move Feature 1-1 to the Product Area 2, we will detach it from the Feature 1, and attach to Product Area 2.
The same algorithm theoretically can be applied at any level, not only the bottom one. But we will have to test this in practice.