Link to force directed beeswarms

[curran]

Closes #194 by linking into the original bl.ocks.org version of beeswarm, which does use a force layout.

[Fil]

@HarryStevens has made https://observablehq.com/@harrystevens/force-directed-beeswarm which we could use (maybe copying it to the d3 collection?)

[curran]

Nice! Updated the link.

[mbostock]

In my view there is little reason to use a force-directed layout to produce beeswarm.

A force-directed layout will not result in an accurate positional encoding because the repelling forces (charge or collide) will push dots away from their intended position. This distortion is typically not evident to the author of the visualization, who may not even be aware of the problem. (D3 is too low-level to show the problem automatically, and none of the old d3-force examples demonstrated or mentioned the issue.) Also, force-directed layouts can be slow since they require many iterations.

I recommend using the dodge algorithm to produce a beeswarm because it ensures an accurate positional encoding. I also expect the dodge algorithm will be faster for most datasets (and if we wanted, we could invest some effort to make it much faster, which we can’t do with the more general force-directed layout algorithm). The d3-beeswarm implementation also deserves mention.

We could certainly do a better job of calling this gotcha out in the README and be explicit about telling people not to use d3-force for beeswarms in favor of the dodge algorithm. But I’ll still want to link them to the newer beeswarm examples. I also strongly prefer to link to examples that we (the D3 team) actively maintain so that they are likely to remain up-to-date and functioning.

[Fil]

My 2 cts opinion: I don't think the dodge chart is a direct replacement for the force-directed beeswarm. By contrast to the force-directed version, the dodge-beeswarm ​is not as compact; it doesn't have an "organic" shape when x is quantized (it becomes a stacked unit chart); it shows a meaningless "wind direction"; it's not symmetric around the axis.

Any of these characteristics might or might not be desirable, and it would imho be better to show the full extent of possibilities rather than declare a winner.

Variants and links:

• symmetric dodge
• pachinko
• unsorted dodge (to avoid the "wind direction") TBD
• jtrim-ons/accurate-beeswarm-plot - notebooks
• Kcnarf/d3-beeswarm - options block
• gorgeous old-style beeswarm
• @yurivish’s https://observablehq.com/@yurivish/building-a-better-beeswarm

This obviously doesn't need to be crammed into the README, but a blog post could be helpful to show all the goods!

For this issue I think we could:

1. transfer Harry's notebook to the @d3 team, and add considerations at the top
2. add considerations in README.md

Considerations would be something like:

You can use d3-force to create a beeswarm plot. Note that, while its compact aesthetic is appealing, this chart does not accurately encode the value on the main axis. Consider the dodge algorithm instead.

[HarryStevens]

For what it's worth, here is a comparison of methods: https://observablehq.com/d/64001745ea835efe.

[curran]

it would imho be better to show the full extent of possibilities rather than declare a winner

Strong agree.

It might be neat to include in the example lines that go from the exact position to the actual position, to visually show the inaccuracy. Similar to this example https://observablehq.com/@codingwithfire/cmu-covidcast-api-bubbles-interactive-timelapse/2

[mbostock]

The comparison of methods isn’t fair if it doesn’t show the error. (It is shown in Curran’s link but not Harry’s.) Without showing the error it is purely an aesthetic evaluation; the force-directed beeswarm may be “prettier” but it is less accurate.

[HarryStevens]

I updated the comparison notebook to show the mean and median horizontal shift of the circles.

https://observablehq.com/@harrystevens/beeswarm-methods-compared

[mbostock]

I sent you a suggestion to show the error. (It is zero for the dodge plots by design.)

It’s also interesting to only show the error:

[HarryStevens]

There it is.

For what it's worth, I'm agnostic about how the beeswarm example in the README is updated. If you would prefer to not endorse using d3-force to make beeswarms, it would be better to remove references to beeswarms in the README, rather than link to an example that does not use d3-force, as is currently the case.

[curran]

Tweaking the strength of X and Y can bring the error down.

From here you could use exact X and it would probably not lead to any occlusion. This does not have the same visual artifacts as dodge, but also does not have the aesthetic of the original force layout.

https://observablehq.com/@curran/beeswarm-methods-compared

[curran]

Also it should be possible to craft a "force" that just positions the X to be exact, and use only a Y force. Has anyone tried that?

[curran]

I have to say this is a really neat thread! Excellent exploration of the design space and tradeoffs.

[Fil]

added @yurivish’s https://observablehq.com/@yurivish/building-a-better-beeswarm to my list; (in our test example ordering by size would be a random shuffle)

[jtrim-ons]

Just to add a few details about another alternative to "dodge" that @Fil already kindly mentioned: I've been working recently on a "compact beeswarm plot" algorithm that is similar to the dodge function but avoids the "wind-blown" look and often takes up less vertical space. https://observablehq.com/@jtrim-ons/compact-beeswarm-plot explains the algorithm and has a simple implementation.

https://observablehq.com/@jtrim-ons/beeswarm-methods-compared is a fork of @HarryStevens' notebook with a compact beeswarm added for comparison (screenshot below).