Skip to content

Conversation

@wwqrd
Copy link
Contributor

@wwqrd wwqrd commented Oct 14, 2021

Second iteration on force directed layout (#1151).

The aim of the feature is to have a toggle which when activated would enable a ‘spring embedder’ physics based layout of the nodes on the sociogram.

This implementation uses this engine: https://github.com/d3/d3-force. It is primarily intended for d3, but is written in such a way that it can be used without it. cola.js was also considered but the documentation wasn't up to scratch.

Implementation

  • Layout engine runs using a web worker. Simulation state is calculated as fast as possible and stored in a ref object, meaning that the updates don't trigger re-rendering.
  • Consumers can read values as needed on requestAnimationFrame, to update the documents
  • A new set of components have been created in src/components/RealtimeCanvas/ for use with this feature. Original Canvas components have been left intact for use on the Narrative Interface.

Additonal notes

  • Breaks away from using react to update the dom, the NodeLayout component acts as a black box which manages it's own rendering, this allows it to run in a much more performant way.
  • Breaks away from the existing drag and drop implementation (although borrows very heavily from the implementation details), this was neccessary to extract the functionality from relying on React/redux
  • Will require similar updates to edge layout and potentially narrative group rendering. This may result in a peformance increase. A newly created RealtimeCanvas/EdgeLayout component has been created, which is compatible with the new simulation feature. Narrative interface uses the old Canvas/ components.
  • Zoom controls actually affect the mapping of the simulation values to the interview values. E.g. zooming effectively moves nodes. This ensures that what you see on the screen is what is saved.

Improvements

  • When zooming a simulated network, position values are clamped in range 0.0-1.0, effectively appearing "squished" around the edge. This was to ensure exported protocols did not contain invalid data.
    • We could hide these nodes during render so that they don't look squished (but still maintain clamped value in the data if exported at this zoom)
    • We could also ensure the network cannot be zoomed to a point that would cause this effect (complication with doing this is that the simulation may push nodes outside of this range still, but then the network could automatically zoom out).
  • Non simulated network could be updated to work in a similar way using a ref object and only updating network on drop - this would really improve the fluidity of the interface. Similar changes could be made to the Narrative interface.
  • Simulation options are not parameterized yet, but could be made part of the initialize function for the worker.

Testing
To test you will need an updated version of the development protocol, available here: complexdatacollective/development-protocol#18

@wwqrd
Copy link
Contributor Author

wwqrd commented Dec 13, 2021

  • I don’t think the parameterisation should be user facing. The range of usable values isn’t wide, and from my testing it seems like appropriate values within that range are specific to the graph itself. So, I think the UI element of this should just be something like a play/pause button with the label “Automatic positioning”. The simulation should always be running, unless the user hits the pause button.
  • The zoom level should be set automatically, and shouldn’t have a user facing UI. The logic for this should be: increase the zoom level until either (1) the max zoom level is reached*, or (2) a node reaches the edge of the screen in any direction

* We will set this constant based on testing with small numbers of nodes. Basically, we don’t want a 5 node graph to be flung to the outer edges of the screen

@rebeccamadsen
Copy link
Contributor

I'm just now seeing this, but initial tests from my perspective look fantastic. Will update after testing more.

@rebeccamadsen
Copy link
Contributor

I noticed a regression today. It seems like with the latest I cannot place nodes from the node bucket on a Sociogram with regular layout (not auto). If they already have a layout position, the nodes can be moved, but if they are in the node bucket, I cannot place them.

@rebeccamadsen
Copy link
Contributor

Is the "pause" meant to be a temporary thing? If a user "pauses", but leave the stage and comes back, auto layout kicks in immediately again. Intentional?

@jthrilly
Copy link
Member

Is the "pause" meant to be a temporary thing? If a user "pauses", but leave the stage and comes back, auto layout kicks in immediately again. Intentional?

Yep this is intentional.

I noticed a regression today. It seems like with the latest I cannot place nodes from the node bucket on a Sociogram with regular layout (not auto). If they already have a layout position, the nodes can be moved, but if they are in the node bucket, I cannot place them.

Oh dear. I must have broken this. I'll look at it again. Thanks!

@jthrilly jthrilly merged commit 1f0aaa6 into master Jan 5, 2022
@jthrilly jthrilly deleted the feature/layout-nodes branch September 4, 2023 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants