Feature: Display multiple subgraph

[alrapal]

Description

The system should be able to display multiple subgraphs

Possible challenges

• How do we select nodes that will become roots
• How does it fit with the current filtering system
• Is there a limitation of number of graphs?

I sent an Email to Axis to ask some concrete use case but did not receive an answer yet

[RuthgerD]

So I have looked at the code and in my infinite wisdom we actually already support multiple roots, you can test this by requiring 2 node IDs and then use the AsRoots collection method.

However this will return a combined graph with those roots, its not separate at all.
I really think the frontend should just open multiple queries for this if you want independent graphs, the overhead of pushing multiple graphs through a single pipe is not worth it.

[RuthgerD]

With combined graph I mean, if the two roots intersect it will be send like that, if you request a root from a week ago and a root of today they will have seperate graphs as they are not related.

Its just that its send as if its a single graph.

[ChrisAxt]

So I have looked at the code and in my infinite wisdom we actually already support multiple roots, you can test this by requiring 2 node IDs and then use the AsRoots collection method.

However this will return a combined graph with those roots, its not separate at all. I really think the frontend should just open multiple queries for this if you want independent graphs, the overhead of pushing multiple graphs through a single pipe is not worth it.

That's very convenient!

I had the same thought regarding multiple queries, I think that will be the simplest way to achieve this.

In terms of display:
I have been playing around with a split screen view for displaying the subgraphs, seems like it might be the way to go.

Something like this:

[RuthgerD]

Yes split view would be cool, it would require rethinking the gui a bit though, since you may want a different query for each pane

[ChrisAxt]

Yeah I was thinking about a "switch view" option which would have the split view and some way for us to send a query for each.

[RuthgerD]

We do have to be mindful of performance, currently there is a caching mechanism in place that is quite effective for switching queries over a single connection (ever noticed how the undo button is near instant?) ;
we should make that cache globally available if there will be multiple connections, but not needed for a proof of concept.

[ChrisAxt]

Yes! Of course we want the performance to be as good as it currently is. I will try come up with a solid idea of of the feature (visually) and we can take it from there?

[RuthgerD]

Yes visuals are most important here, i think there are no blockers otherwise.

[ChrisAxt]

I've come up with a very simple prototype for this feature.

The idea would be that you "activate" the split view mode (by clicking the button) then you would be able to select a pane and apply a filter or select a root node for that pane.

multi-subgraph prototype.pdf

Let me know what you think.

[RuthgerD]

Would this design be limited to 2 panes? it would be interesting to support infinite panes (so to speak) but the concept of pane focus is good, so when you focus a pane the current query for it will show right (in the filter panel)?

[ChrisAxt]

Currently it would be limited to 2, the reason being is that I thought more than that would be a bit much (in terms of business on the screen)

We could have the filter panel displayed on the pane currently in focus or have it where is currently is and include a label on the filter panel indicting which pane the filter is going to be applied to ("Selected pane: Top"), Keeping in mind that the filter panel will be able to be minimized by clicking on the hourglass icon.

[RuthgerD]

I could imagine them putting the website on a large display or something, it would fit the graphs just fine :) but maybe thats just me. But if you think for it in code, it will be good to generalize and support many graphs, then you can get it for free.

I would say keep the filter panel in the same place, and simply update the query based on which panel is focused.

[ChrisAxt]

Yea sure! Seems like a good use case! We will look into that.
Would you have an option to add more subgraphs? (Maybe the default could be 2 and the user could add more as they need?)

I agree!

[RuthgerD]

It really depends on how you split the view, you can make a recursive layout that allow you to split horizontally and vertically.
e.g.

[alrapal]

We are going to discuss today a bit more about this with Axis. We will get more details and will see what would fulfil the requirements. Keep you posted

[RuthgerD]

How did that go?

[alrapal]

So, based on the feedback, the pane view changed scope:
They would like to have it when the non interactive mode is on
They would like to have the possibility to choose how many views
They also said that depending on the time and the efforts they could be flexible

We need to think about a solution for:

• Querying the backend real time for multiple graphs
• Interaction with the other features (navigation, fitlering, shortcuts, etc -> onSelect state?)
• Display: which libraries using panes for instance
• How do we select nodes that will be root of subgraphs
• How do we define how many panes we want

Some ideas that were mentioned during planing for selecting node are:
-> Ideas: 2 modes, focus mode on 1 graph and split view with default number of 3 views
-> Possibility to select multiple node and make them root (creates the adequate number of views) (would be the neatest I think)
-> Select number of panes, creates X versions of the main graph that can be queried

[RuthgerD]

Querying the backend real time for multiple graphs

Use multiple connections, should be quite robust, based on focus the query pane can reflect the current query.

Interaction with the other features (navigation, fitlering, shortcuts, etc -> onSelect state?)

Listen to the "focused" pane for events, non interactive mode should be independent for each pane and shortcuts also just for the "focused" pane.

Display: which libraries using panes for instance

Please try a simplest solution before reaching to a library, css has excellent support for dividing html containers in any way you can imagine. The only thing that you need to think about is focus management.

How do we select nodes that will be root of subgraphs

Currently when you click on a node, you have an option to make that the graph root yes? lets add a second button that will open a new pane instead with that query. The only hard part (with the recursive layout) is to select from which panel you want to split off; but nothing unsolvable.

How do we define how many panes we want

I vote for the recursive layout I suggested, users can create new panels at their convenience without typing any numbers.

[alrapal]

So after a bit of research and brainstorming, here are some ideas.
One graph would be displayed by default.

When selecting a node, we could tick a checkbox next to where we select it as root to make it root in a new pane.

The current pane(s) size would be adjusted to fit equally and could be afterwards adjusted in size manually (this does not have to be, in which case we can just go for CSS instead of the library. We could also start with CSS and implement size handling later on to avoid dependency).

Panes could be selected and the selected pane would be the one interacting with the filtering panel. This implies that filtering should be stored in the front-end separately and repopulate the filter panel on selected pane change with corresponding data.

Non-interactive-mode would have to be reactivated via the button or shortcut and would be activated for selected pane.

This would theoretically allow to continue sending the queries to the backend.

We thought about limiting the number of panes based on screen size, since the idea is that is should be readable without interaction.

The main question now would be how to handle the different queries in the backend. We fear that having only one query stream and queuing the request might create some slow downs, especially if we do not limit the number of panes.

The panes library is the one @gusaxtcha found here

[RuthgerD]

Overall seems like a sane plan, I think each pane needs to be assigned their own stream as the API was designed around one stream per graph.

One thing that might be cool is being able to assign the same stream to 2 panes, but if you design the code right you should get that for free.

For the pane library, I'm not opposed to it if that simplifies things for you; I just always have bad experiences with trying to integrate external things, maybe this library is actually nice; who knows.