New layout proposal - single compact group

[nikola-velinov]

Hello David,

all the best in the new year 2024!

We are currently evaluating whether your brilliant library can be used for our purposes. We have large structures, but they are relatively flat - with few levels.

The problem is: Even with the compact layout, the chart becomes very, very wide.

We saw the idea for a new layout: https://github.com/bumbeishvili/org-chart/issues/236 It's a nice but very complex idea. On the one hand, it is complex to implement, and on the other hand, this structure could overwhelm some users.

Something much much simpler would make us happy, hence the following suggestion:

New layout proposal - single compact group

Instead of being divided into two groups, child-nodes are bundled in a single group. The goal is to save as much width as possible. Since one of two compact groups is eliminated, parent-nodes can be positioned closer together.

New parameters (just as an example, can be named and organized completely differently):

• compactGroupsCount with value range 1 or 2, default value is 2; relevant only if parameter compact == true (compact mode)
• compactGroupsLayout with value range "top_right" or "bottom_left", relevant only if parameter compactGroupsCount == 1; states whether the one single compact group is on the left/right side, in the "top" or "bottom" layout, or top/bottom in the "left" or "right" layout

Of course we could try to implement this new layout on our own.. This would be very time-consuming for us (lack of know-how). On the other hand, if you could offer this then probably many people around the world would benefit, not only we as in the case if we enhance at our site.

Please consider whether you would implement such a layout and what time frame would be conceivable for the implementation.

Thank you in advance! Nikola

Some Screenshots

1. Original - "top" layout, compact mode:

2. Transition to the new single group mode - "top" layout, compact mode, imaginary parameter compactGroupsCount set to 1, compactGroupsLayout == "top_right":

3. Final result - "top" layout, compact mode, compactGroupsCount == 1, compactGroupsLayout == "top_right":

(EDIT Jan 4: Order of nodes corrected)

[bumbeishvili]

Hi Nikola, I understand what you mean.

Unfortunately, I won't be able to build a layout similar to yours, since currently I don't have much time for it.

Although your suggestion still would be useful, since it gave me an idea to make it possible to override & add new custom layouts easily.

What I'd suggest for your case it to manipulate the data in a way, so that at the last level you have a single node, which will have additional information attached, then you can set different heights for this last level and have a custom HTML so that you simulate single column layout

https://stackblitz.com/edit/js-pf6ouo?file=index.html

[nikola-velinov]

Thank you for the prompt response!

We have also thought about something similar, but did not pursue it further, as several disadvantages would arise:

• The block of leaf elements is not collapsible.
• The number of child elements in the expand button of the parent element is misleading.
• There is no connection line comming from the parent for the individual child elements in the block, only one line for the entire block, which leads to a difference in the design of the connections of the leaf nodes, which ist not intuitively explainable to users (user asking: why is that?).
• A fourth disadvantage, which is not as obvious as the first three: The vertical line in the block of child elements is an HTML line, whereas the other connection lines are SVG lines. This would lead to different rendering of the lines (in different browsers on different platforms), especially if we generate a PNG image or if we generate a PDF file and print it from the PDF file. Basically there are two types of lines (HTML and SVG) and three types of representations - the first on the screen in the browser, the second on the screen in a PDF reader, and the third - on paper after printing. It will be cumbersome or even impossible to keep the appearance of the two types of lines consistent in all three types of representations (at different scale factors and different browser and PDF engines).

Each user of your library must decide in her individual case whether she wants to use this solution with its disadvantages in a productive application.

We fully understand that you don’t have time at the moment. Nevertheless, would it be theoretically conceivable for you to provide this feature? Not now, but at a later point in time - sometime in the future?

[bumbeishvili]

Some disadvantages can be addressed

The block of leaf elements is not collapsible.

Leaf nodes aren't collapsible in the normal tree too

The number of child elements in the expand button of the parent element is misleading.

You have the possibility to display whatever you want in the expand button, similar to node

There is no connection line comming from the parent for the individual child elements in the block, only one line for the entire block, which leads to a difference in the design of the connections of the leaf nodes, which ist not intuitively explainable to users (user asking: why is that?).

you don't need a multiple line, what you need is to connect line coming from a parent to the last node (again, configurable) and then having a single line from each custom node to the left which will have similar styling. But unfortunatelly, animation won't work well here

A fourth disadvantage, which is not as obvious as the first three: The vertical line in the block of child elements is an HTML line, whereas the other connection lines are SVG lines. This would lead to different rendering of the lines (in different browsers on different platforms), especially if we generate a PNG image or if we generate a PDF file and print it from the PDF file. Basically there are two types of lines (HTML and SVG) and three types of representations - the first on the screen in the browser, the second on the screen in a PDF reader, and the third - on paper after printing. It will be cumbersome or even impossible to keep the appearance of the two types of lines consistent in all three types of representations (at different scale factors and different browser and PDF engines).

Since you control the HTML , you can add an SVG line too, but yeah, it becomes more and more cumbersome

We fully understand that you don’t have time at the moment. Nevertheless, would it be theoretically conceivable for you to provide this feature? Not now, but at a later point in time - sometime in the future?

Maybe part of the the #236, but not as a separate feature

[nikola-velinov]

Thanks David! We are grateful for any kind of help! I'll try a few things out over the course of this week and post the results here at the end.

[nikola-velinov]

Hello David, I apologize for writing so late.. It wasn't so bad that a long time passed because it gave me a lot of time to think and I realized that there are several types of compactness. That's why I suggest another, third parameter that determines the type of compactness, I'll call it "compactDensityLeaves".

compactDensityLeaves == "low": Leaf nodes are only grouped if they have no siblings that themselves have child nodes. The grouping occurs multiple times. The sequential arrangement is maintained naturally. See screenshot "Compact 1 group density LOW".

compactDensityLeaves == "medium": Leaf nodes are always grouped, with multiple groupings occurring under the same parent node if there are other non-leaf nodes (that have child nodes) between the leaf nodes. This explicitly preserves the sequential order. See screenshot "Compact 1 group density MEDIUM".

compactDensityLeaves == "high": Leaf nodes are always grouped, in a single group per parent node. Essentially this is the "density" of the current compact mode of the OrgChart library. I noticed that the current compact mode of the OrgChart library sometimes groups "at the front" and sometimes "at the end". In my experiment, the leaf nodes are always grouped at the front. See screenshot "Compact 1 group density HIGH"

It is conceivable to have another parameter for controlling the compactness of parent nodes, as in #236 - for example called "compactDensityParents"..

The playground: https://stackblitz.com/edit/js-5mpjgf?file=index.html

Thanks for your tips! They are incorporated, also the number of child nodes in the expand/collapse buttons now takes into account the number of children under the artificial nodes. It is clearly visible that grouping in a single group can reduce the overall width compared to two groups, see screenshots "Comparison".

Summary New parameters (just as an example, can be named and organized completely differently):

• new parameter compactGroupsCount with value range 1 or 2, default value is 2; relevant only if parameter compact == true (compact mode)

• new parameter compactGroupsLayout with value range "top_right" or "bottom_left", relevant only if parameter compactGroupsCount == 1; states whether the one single compact group is on the left/right side, in the "top" or "bottom" layout, or top/bottom in the "left" or "right" layout; Relevant if you or a contributor manages to draw the svg lines like in the screenshot "Final result".

• new parameter compactDensityLeaves with value range "low", "medium" and "high"

This would be a non-breaking enhancement, since

• if compact == false then the normal classic view is displayed
• if compact == true, compactGroupsCount == 2 and compactDensityLeaves == "high", then this would be the current compact mode
  
  

Screenshots

Compact 1 group density LOW

Compact 1 group density MEDIUM

Compact 1 group density HIGH

Comparison Compact 2 Groups

Comparison Compact 1 Group (same scale)

Final result (if someone manages to draw the svg lines)

[nikola-velinov]

If you - the READER - are also interested in this stuff, then please leave a short comment "I'm interested too" so that we know that I'm not the only one on the planet who wants more layouts.

If you - the reader - have further ideas, please write about them here.

If anyone is an expert in svg and would like to contribute, please feel free to fork https://stackblitz.com/edit/js-5mpjgf?file=index.html and try to draw the svg lines as shown in the screenshot "Final result" above.

[milhlhat]

If you - the READER - are also interested in this stuff, then please leave a short comment "I'm interested too" so that we know that I'm not the only one on the planet who wants more layouts.

If you - the reader - have further ideas, please write about them here.

If anyone is an expert in svg and would like to contribute, please feel free to fork https://stackblitz.com/edit/js-5mpjgf?file=index.html and try to draw the svg lines as shown in the screenshot "Final result" above.

I'm interested too

[nikola-velinov]

Thank you milhlhat for your comment!

Do you have any ideas for improvement or further suggestions?

The ultimate goal here would be to be "data driven", such as the "hybrid" and "compact" data properties in the dabeng-OrgChart: https://github.com/dabeng/OrgChart

However, this would be too much at once. A first step would be a global change of the layout through something like the parameters suggested by me. And if in the distant future one were to also add "data driven" parameters, this would be a "non-breaking enhancement," as the global parameters would act as defaults, and if other parameters for specific nodes were provided through the data, the data parameters would override the global ones for the specific nodes (specific overrides general).