d3/d3-force

Using force in business applications

plqplq opened this issue · 5 comments

plqplq commented

This is more a strategic question than a bug report.

So all these force examples are impressive as is the science behind them, but for business applications, I'm not getting very far with it

Fundamentally we want some kind of technology that stops labels and nodes overlapping, and to space them out in a logical and well presented way in our charts and diagrams.

We've needed it for donut charts, where the labels were colliding, but gave up with force and ended up using our own algorithm which finds cluster groups (pie slices which are too close and so text is overlapping), centers on the middle member of each group, and then spreads out the neighbouring nodes out from the center.

Now we are writing network diagrams, which can be radial or top down. Even the simplest of scenario where we want to stop data boxes (representing each endpoint) from overlapping, seems impossible.

As an end user I want to say

  • Nodes are this big
  • Nodes are to be spaced out along this axis/line/equation - or centered etc
  • Connecting lines to move with the nodes
  • Wrap this text if it fits vertically and is overlapped horizontally

We don't want it visually moving in front of the user. We want it to execute the simulation up front and then display. We've worked out how to do this based on using simulation,tick within a loop (and then called "ticked" at the end), but sometimes the loop takes too long and we don't know how many ticks to call before all the collisions are resolved. Ideally we'd like to call simulation.tick once and all overlaps will be resolved in one call - is that possible ?

So is the force system the wrong choice of technology for this ? and if so what should we use instead ?

If its the right technology, where can I look for examples or learning resources that will help us achieve these goals ?

thanks in advance

ZJONSSON commented

Here is another one: http://bl.ocks.org/zjonsson/1691430

  • 👍2
alexburner commented

Unrelated to labels but also worth noting: If you're using the force layout in a setting where all the ticks will be calculated up-front, and only the final result of the simulation is displayed, it can be useful to split the simulation out into a web worker thread. Then running the simulation doesn't block the browser's main thread for your page (and all other scripts / user interactions within).

plqplq commented

We decided in the end that force wasn't the right idea here. We think that if the layout is going to be fixed (i.e. predictable based on the data we have) then you should be able to calculate it without an unknown sequence of ticks and tests. This might not be true in modelling particles, but we think that for applications like network diagrams and location layouts, it is generally true, so we are pursuing new algorithms to calculate best fit without using simulations.

However I appreciate all the input and ideas above.

alexburner commented

@plqplq I'd be interested in hearing what layout algorithm you settle on. Our own use case is visualizing network diagrams, but their topologies were varied and complex enough that force-layout seemed to have the "best fit" for the largest number of cases. I'd be curious to hear about reasonable alternatives.