better visual cues / consistency to directionality in radial view

[rade]

The radial view one gets when selecting a node could do a better job of positioning the connected nodes such that the directionality follows the "inbound at top, outbound at bottom" approach we use to lay out the main graphs.

Follow-up to #875, which says

Concepts involving re-arranging the nodes were unsuccessful, as it lead to very unbalanced "sides" of the diagram which lead to difficult to read diagrams.

I suggest an approach where the list of connections is sorted to have inbound first, bidirectional second, and outbound last. We then place needs nodes on n_nodes equidistant positions on the radial circle by iterating through the list and placing the first node at the top, the 2nd node to its left, the third to its right, the fourth to the left of the 2nd node, the fifth to the right of the 3rd node, etc.

Add some special casing for small numbers of nodes, e.g. always create at least 4 positions - top, bottom, left, right - and place nodes in their "best free match" positions.

[bia]

@fbarl, @miklosp and I thought about this a bit. I propose a radial view with directionality grouping as follows :

I don't know how many rows should be the maximum, but this layout still creates problems when the spacing is too tight.

What do you think?

[rade]

Looks fine, and makes better use of the space than the existing view. BUT...

It looks like the circle has been divided into four quadrants - top for inbound, bottom for outbound and left/right for bidirectional. That reserves way too much space for bidirectional links, which are rare. I reckon the segment size needs to be somewhat dynamic, perhaps 0-180 degrees, proportional to the ratios of the number of nodes in each directionality bucket. So, for example, if there are no bidrectional connections, then inbound and outbound nodes could be places in the full 180 degree top and bottom arcs, respectively.

this layout still creates problems when the spacing is too tight.

every layout will have some upper bound on the number of nodes in can show.

[bia]

every layout will have some upper bound on the number of nodes in can show.

Perhaps there's an opportunity do design a more graceful way for nodes to overlap.
What if (in the case where there are 50+ connections) nodes could stack horizontally and show only one label (cycling through each node's name on hover).

or

[rade]

Dealing with lots of nodes is (or, rather, should be) a separate issue.

[fbarl]

What do you think?

I like the radial layout with directionality grouping as in the screenshot above, although I also agree with @rade that it should be split in 3 quadrants rather than 4.

One problem I see though is that such a layout does consume a bit more space, which we'd have to figure out how to deal with in the context of Weave Cloud (Workload Summary graph).

Perhaps there's an opportunity do design a more graceful way for nodes to overlap.

I just opened #3293 to discuss this separately, but I just wanted to point out that we already have a notion of stacked nodes, which we could potentially use here, although the problem is that some topologies already display all their nodes as stacked, so it would be mixing of use cases :/

[rade]

it should be split in 3 quadrants rather than 4.

Umm, you cannot divide a circle into 3 quadrants ;)

What I was suggesting is that the four segments are sized in proportion to the number of nodes they need to contain, with the additional constraint that no segment exceeds 180 degrees (or perhaps just shy of that, e.g. 135).

[bia]

tl;dr forget the multiple orbit thing.

you cannot divide a circle into 3 quadrants

:)

I think it is more clear when data senders are centred on 0°, receivers on 180° and bidirectionals on 90° (we can choose only one side right or left).
Here, the sender and receivers are skewed by -20° and limited to fan out by 90° and the bidirectionals are centred on 90°.

This whole valence thing looks much more complicated and takes too much space. Let's drop it, organise the single orbit with senders on top and receivers on bottom, and focus on improving the grouping of nodes to fix this problem.

[rade]

I think it is more clear when data senders are centred on 0°, receivers on 180° and bidirectionals on 90° (we can choose only one side right or left).

Agreed. I didn't mean to suggest otherwise. Though skewing looks weird and I'd rather have bidrectionals centered at 90° and 135°.

What I was proposing is that the segment size is variable, not the segment center position.

[rade]

If we want to keep things simple, I suggest we stick to the single orbit, with four segments located as follows:

• 300° - 60° inbound
• 60° - 120° bidirectional
• 120° - 240° outbound
• 240° - 300° bidirectional

This gives us 120° each for inbound, outbound, and bidirectional.

[bia]

Though skewing looks weird and I'd rather have bidrectionals centered at 90° and 135°.

135°? Do you mean 270°

This gives us 120° each for inbound, outbound, and bidirectional.

I got the impression that there are fewer bidirectionals. If so, we could allocated a smaller portion to bidirectionals?

[rade]

135°? Do you mean 270°

Oops. Yes.

I got the impression that there are fewer bidirectionals. If so, we could allocated a smaller portion to bidirectionals?

There typically are indeed fewer bidirectionals. But sometimes there aren't. For example, in the Nodes topology usually everything is bidirectional. Hence if we go with fixed segment sizes I would rather stick to 120° each. OTOH, if we go for variable segment sizes, we could adjust the size between 90% and 150%. But that is more work.

[ngehani]

The goal should be to show summary in the workload summary view. If it gets too crowded with lots of nodes, then you can have a hover to show how many nodes and then clicking it would bring up a modal (or something) to show the fuller picture before going to Explore which shows that in context with the rest of the cluster.

[rade]

The goal should be to show summary in the workload summary view

This is the scope oss repo. There is no 'workload summary' here.

If it gets too crowded with lots of nodes

Dealing with lots of nodes is covered in #3293.

[ngehani]

Oops - I didn't notice scope repo - lost track - never mind.

[bia]

Time passed, and I'm not a big fan of the radial view anymore. Instead, I propose 2 simple steps to resolve this issue for now :

1. We do what @rade originally said, though I don't think that always creating at least 4 positions is necessary - we could simply turn groups of 3 to the most appropriate angle.
   [i.e. the centerpoint of incoming nodes is also the vertical centerpoint]
   To summarise, while maintaining equal radial distribution of nodes (as we already have), group inbound connections towards the top, bidirectionals to the sides and outbound connections to the bottom. Here are some before/after examples :
   →

→

2. Make highlights more aggressive as in Better visualization of a large number of nodes in circular layout #3293

[rade]

Fine by me, on the grounds that it is definitely an improvement on the status quo.