Low branch trees

Under this poetic name lies the idea of ​​a convenient representation of tree data structures and its practical implementation. Maybe something similar had already happened somewhere, but I have not met; and here my friend Edward Averyushkin suggested an interesting idea that I tried to develop.

The classic representation of the entity tree (for example, the menu of sections of the site, the main menu in the programs) is quite convenient and obvious in the case of a “high” tree with not too deep nesting of elements. Whether it is a drop-down menu (as the main string menu of programs) or a drop-down (as in the left panel of popular file managers), everything is quite convenient and intuitive. And what if the tree is low and spreading? Each parent has few children, but nesting reaches, say, 10. Or 50 ...

Then in the case of a drop-down menu, we get huge indents horizontally. In the case of a drop-down ... Paradise for a masochist.

Let's imagine this as a staircase in a rather narrow room. In the case of “tall trees,” we have very narrow, but high steps, and then everything is pretty good. In the case of "low trees", we simply abut the wall at a still high altitude.

So, the conclusion is obvious. Spiral implementation. But how to transfer it to the plane? Minus one dimension. Here we have to sacrifice the simultaneous opening of several branches. Maybe (and certainly), there is a better solution, but I’m not a mathematician, but what I’m writing about at least solves the problem — a tunnel.

Implementation example

I wanted to implement a more or less practical example. Take a certain database of restaurants with a certain common set of signs (tags) organized in a tree.

The tree for illustration of this article is not very good because of the small nesting of the elements, but for example it will come down; this is not significant, as will be seen later - you can make any desired depth without much damage to the convenience of navigating the tree.

Suppose we have a task to design a restaurant search system for this tags. For example, the average rich family of the village Podvukhukholyovka decided at the weekend to go to a restaurant, of which there are 351 in the village. The family is choosy, each member of her with character, but after long discussions with scandals, they decided that they wanted an expensive restaurant, with separate rooms for smokers and non-smokers, with loud live music and in full force - mother, father and five children from different marriages . Sorry. Suffered

So, the approximate scheme is as follows. Each village restaurant that wishes to participate in this system, after all sorts of negotiations, rollback of contracts, registrations in the system, etc., is entered into the database with all the necessary information about itself and is associated in the database with a set of tags to which it corresponds. Omit the interface implementation, it does not matter.

Tag Tree

Consider a little more detailed tags themselves. Everyone has (besides the obvious parents, brothers, children, etc. id) two important features:

1. virtual - means that this tag is only a container (folder) and is not involved in the search (can not be added to the filter);
2. replaces - a list of other tags that this tag replaces; for example, the tags "For smokers" and "It is possible with children" are somewhat incompatible; then when this tag is added to the filter, those “replaces” fall out of the filter.

<?xml version="1.0" ?> <tags> <tag id="1" name="" virtual="1"> <tag id="11" name="" replaces="12 13" /> <tag id="12" name="" replaces="11 13" /> <tag id="13" name="" replaces="11 12" /> </tag> <tag id="2" name="" virtual="1"> <tag id="21" name=" " replaces="221 222 23" /> <tag id="22" name="" virtual="1"> <tag id="221" name="  " replaces="21 23 222 4" /> <tag id="222" name=" " replaces="21 23 221" /> </tag> <tag id="23" name=" " replaces="21 221 222 4" /> </tag> <tag id="3" name="" virtual="1"> <tag id="31" name="" replaces="311 312"> <tag id="311" name=" " replaces="31" /> <tag id="312" name="  " replaces="31" /> </tag> <tag id="32" name="" /> <tag id="33" name="" /> </tag> <tag id="4" name="  " replaces="23 221" /> </tags> 

 <?xml version="1.0" ?> <items> <item id="1" name=" " tags="13 221 311 312 32 33 4" /> <item id="2" name=" " tags="11 23 32 33" /> <item id="3" name=" " tags="12 21 311 32 4" /> </items> 

Again, the implementation is a demo. You can JSON th, you can even voice recording with speech recognition system.

Client part - tunnel

Further, each resident of the village can go from his ipad (the whole Dodge is covered with a high-speed Wi-Fi network) to a special site where he will see something similar to this (by reference a living example; I apologize for some damp incarnation - this is a demo prototype which is still in development; SVG + JS + CSS):

Clickable, link to a live example.

• To add a tag to the search filter, drag it to the center.
• When dragging a “virtual” tag to the center, its children simply open up; non-virtual - and his children open (if any), and he himself is added to the filter.
• With a simple click (tapa) on the tag opens his children (if any).
• When dragging the tag "outside" close its children.
• Selected tags in the center can be removed from there by dragging them outside.

Now, in general, the essence of this tunnel. When children open, the circle of their parent and his brothers increases, and the circle of children appears in its place. That is, we are moving further inside the tunnel. When closing children (or choosing the brother of their parent), respectively, we go backwards along the tunnel. Just artificially moving around the tunnel without opening / disclosing children can be done with the mouse wheel (or footer).

Thus, the goal is achieved - with a tree in which there are few brothers of the same level (it does not fit a lot in a circle), we have almost unlimited possibilities for presenting a very spreading, deep tree without losing visibility.

I would be glad to comment, suggestions and criticism.