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: