Skip to main content
100%

Beeswarm comparison

✓ Published0🌍 Public
KKcnarf
Last edited Apr 11, 2017
Created on Jul 20, 2016

This example compares two beeswarm techniques for plotting the flare.csv dataset, in which dots are offset vertically to avoid overlap without changing their x-position. A force-based arrangement uses d3.forceSimulation with x, y, and collision forces, while a second arrangement uses the d3-beeswarm plugin. Red coloring and connecting lines highlight deviations from the exact encoded x-value, showing that the force method shifts dots horizontally more than the beeswarm method. Both use SVG rendering and Voronoi cells for interaction.

AI-generated description

This <a href='http://bl.ocks.org/Kcnarf/5f9491610aa5a5c085d48d66164de36a'>block</a> compares 2 techniques that both produces a static beeswarm.

The top most beeswarm is the one from mbostock's beeswarm block. It is implemented using d3-force’s collision constraint. The bottom most beeswarm is produced with the d3-beeswarm plugin I made (see the Github project).

This block aims to understand the differences, advantages and drawbacks of the 2 techniques. I'm focusing this comparison on the capability of the beeswarm to exactly reflect the encoded data (ie. the x-coordinate should exactly reflects the encoded data): the more it's red, the less it represents the encoded data. That's the main reason why the d3.force technique doesn't suit my needs, and why I made the d3-beeswarm plugin.

Here are some thoughts:

  • exactly encoded data: this block allows to vizualize the main drawback of a force-based beeswarm, that allows to re-arrange horizontally each dot; note that this behaviour could be considered marginal and not so important, but this is a high-level constraint for my usecase ... One can notice that most of the deviations come when there is some accumulation (see around 600 or around 3200)
  • computation time: force-based beeswarm takes more time to be computed, as the d3.force is a generic algorithm that does a lot more than just producing a beeswarm arrangment
  • aesthetic: the 2 beeswarms look great; the second beeswarm is less compact because it exactly encodes data; note that the easthetic of the second beeswarm seems 'to go to the right' because data are sorted from max to min before computing the arrangement
  • live arrangement: one can decide to vizualize the live arrangement of the force-based beeswarm ... adding the waouhhh effect
  • rearrangement: (not experimented) I guess one can easily add/remove/drag a node on the force-based beeswarm, which will in response rearrange itself automatically ... adding the waouhhh effect once again

Acknowledgments to:

  • <a href='https://d3js.org/'>D3.js</a> (v4)
  • <a href='http://blockbuilder.org'>blockbuilder.org</a>
gpl-3.0 Licensed

Similar vizzes