Beeswarm comparison

This block 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:

• D3.js (v4)
• blockbuilder.org