Kibana: [APM] Service map: layout improvements (timeboxed exploration)

[ogupte]

There are currently two separate issues with the layout:

1. The current layout is not as visually pleasing as we'd like
2. we have indications from customers that the layout is incorrect in certain scenarios

We will try to solve the first point by experimenting with different Cytoscape layouts and settings. Ideally, something in the style of a flow chart would more accurately represent relationships between service nodes.

We will try to solve the second point by inspecting the service map for different customers and create specific issues for the problems we find.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[nehaduggal]

Some feedback on when there are just 2 nodes on the map and looking at maps within a service.

• We should get rid of the turn, if there are only 2 components involved.
• The connector should be thinner.
• The map is too zoomed in for the nodes.

[cyrille-leclerc]

We have very interesting UX feedbacks initiated by @formgeist .

Can we leverage this feedback to improve the UI of service maps? This feedback included insights on:

• The style of connectors: rounded, square elbows, lines
• The positioning of services on the map
• Service maps with many services
• Service maps for async services

[smith]

Some possibilities:

• We started out with cytoscape-dagre. We might want to try it again, along with some of the more sophisticated methods of rendering the lines so they're pretty and curvy.
• The (appropriately named) cytoscape-elk implements the Eclipse Layout Kernel layout algorithms. It looks like it might be appropriate and flexible.

[ogupte]

Service maps layout recommendations

• Current layout:

• With existing service map examples in storybook, I tried a number of different layout and edge combinations. Here are a few that stood out to me:

dagre + unbundled-bezier edges

This combo seems the most natural to me:

• 
• The dagre layout positions the nodes in a similar Left -> Right pattern that we currently have. In contrast the to default, breadth-first layout, where nodes are aligned purely by rank (distance from starting services), dagre is much more organic, with highly connected services being located closer to each other.
• The edge type unbundled-bezier has the advantage of overcoming overlapping lines issue we have with taxi edges. Also the curved edges compliment the more organic arrangement of nodes. When you consider how edge metrics are displayed on the curved lines vs the taxi, there's much less confusion on which connection the metric applies.

cose + taxi edges

• 
• taxi edges convey a deliberate connection between nodes, like a schematic. The disadvantage of taxi edges is that they don't tolerate overlapping well. Without interaction and inspection, it can be difficult to discern which nodes a taxi edge is connecting.
• The cose layout overcomes the shortcomings of the taxi edges, by effectively minimizing the amount of edge overlap. It does this by running the graph through a physics engine, simulating attraction, repulsion, elasticity, etc. The result is a graph with very natural arrangement. The downside is that it can be difficult to influence the final positions of individual nodes when the graph is initialized. E.g. client nodes which connect to many service nodes tend to end up in the middle of the graph rather than the left side, since the center is the natural position to minimize overlaps.

breadth-first + segment edges

• 
• The existing breadth-first layout enjoys more control over which services appear in the beginning and end of the service map, however nodes in the middle are purely positioned by order of their rank in the connection hierarchy (distance from root nodes). This mean that if a service has many first-level connections, they will all be lined up in the same rank which can be an inefficient use of real estate. It also suffers from confusing cross connections between nodes of the same rank.
• segment edges help overcome the issue of overlapping lines of the taxi and straight edge styles while maintaining the clean, deliberate connection between nodes that we like in taxi. Metrics displayed on segment edges, also enjoy a strong visual association with their respective connecting lines.

breadth-first + unbundled-bezier edges

• 
• This has the advantage of being the least complex solution, since it's just a simple style change for the edges.

Try it out

Check out the examples by pulling my branch (https://github.com/ogupte/kibana/tree/apm-71770-service-maps-layout-spike) and running yarn storybook apm to view it locally. You can copy the hipster store response data and paste it into the JSON-based service map to recreate the screenshots above.

[smith]

Thanks for putting these together. We can probably do a lot more with unbundled bezier edges by tweaking the settings. cytoscape/cytoscape.js#2579 has a bunch of good examples we could draw from.

[sqren]

Awesome work with storybook @ogupte. Is the storybook with the different knobs merged in for anyone to play around with?

[cyrille-leclerc]

Exciting @ogupte ! I like as well "dagre + unbundled-bezier". ISs it possible to add more horizontal spacing? I have in mind that it could help prevent overlaps on vertical connectors and better position metrics on the map while leveraging the large width of modern screens.

[smith]

@cyrille-leclerc these are our available options when using cytoscape-dagre: https://github.com/cytoscape/cytoscape.js-dagre#api, so yes we can adjust every kind of spacing. We'll of course want to try any adjustments on many maps and screens, since an improvement in once situation may not be right in another.

[ogupte]

Awesome work with storybook @ogupte. Is the storybook with the different knobs merged in for anyone to play around with?

@sqren, It can be pulled from my branch (https://github.com/ogupte/kibana/tree/apm-71770-service-maps-layout-spike). I don't plan to merge this branch since it adds a bunch of code to import new layout extensions and expose various settings. Once the spike is complete, I'll create a new PR to merge the specific changes we want.

[formgeist]

@ogupte Thanks for providing these examples. I was wonder if it's not too many much work, would it be possible to add the health statuses to the nodes in the generated maps? I would love to be able to see how the indicators might factor into this as well. Thanks!