Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automatically switch to table on high node/connection count #1721

Closed
rade opened this issue Jul 26, 2016 · 3 comments
Closed

automatically switch to table on high node/connection count #1721

rade opened this issue Jul 26, 2016 · 3 comments
Assignees
Labels
component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer feature Indicates that issue is related to new end user functionality help-wanted An issue that would be good for non-maintainers to attempt
Milestone

Comments

@rade
Copy link
Member

rade commented Jul 26, 2016

Until we have a dedicated high-node-count mode (#1614), the table mode is a pretty good substitute...

scope with a thousand connected processes created with

nc -lk 1122 &
for i in $(seq 1 1000) ; do nc localhost 1122 & done

topology visualisation - this takes a while to render and is rather unusable:
screenshot_2016-07-26_08-20-25
topology table (from #1673) - this renders quite quickly and is perfectly usable:
screenshot_2016-07-26_08-21-04

I therefore propose that we automatically switch to the table for high node/connection count. As noted in #1614 (comment), this should be done on a hysteresis.

@rade rade added component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer feature Indicates that issue is related to new end user functionality labels Jul 26, 2016
@rade rade added this to the July2016 milestone Jul 26, 2016
@rade
Copy link
Member Author

rade commented Aug 2, 2016

So I think the behaviour we are looking for here is:

Whenever a UI action takes you to a visualisation that exceeds the complexity threshold, we switch to table mode instead. Except when that UI action was "switch to visualisation mode" - this is mainly because our heuristics for what is "too complex" aren't perfect; we don't want to prevent users from seeing the visualisation when it does in fact work.

I don't think we need to automatically switch from the visualisation mode to table mode when complexity increases due to extra nodes and edges being added. Hence we don't need a hysteresis either.

So the automatic switch to table mode is always triggered by a UI action. Such as selecting a different view or changing filters.

That leaves the question what the threshold should be. Something like node_count + 2*edge_count < 500? Or should there be some ^2 in there somewhere? We probably don't want to get too clever here, at least to begin with.

@rade rade modified the milestones: August2016, July2016 Aug 4, 2016
@rade rade modified the milestones: September2016, August2016 Aug 16, 2016
@davkal davkal added the help-wanted An issue that would be good for non-maintainers to attempt label Oct 14, 2016
@jpellizzari
Copy link
Contributor

@davkal and @rade, I would like to give this issue a try. The way I am understanding this, we would switch the to the table view if the graph view exceeds a complexity threshold when the user does an action.

My first inclination is to figure out which of the action-types would need this behavior, then apply the "threshold" logic to each (using some sort of white-list so its easy enable/disable this behavior for individual actions).

@davkal can you think of a more clever way of doing this than listing the individual actions manually? Should I look to do something further downstream in a component instead?

@jpellizzari jpellizzari self-assigned this Oct 31, 2016
@jpellizzari
Copy link
Contributor

@davkal talked about this issue and decided it would be good to implement this behavior on page load. That way, the user can still switch to graph mode if they want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer feature Indicates that issue is related to new end user functionality help-wanted An issue that would be good for non-maintainers to attempt
Projects
None yet
Development

No branches or pull requests

3 participants