Categorical X: raincloud plots / categorical stats...?

[njvack]

if x is a categorical variable, it might be nice to show the categories as raincloud plots (half-distribution with individual points in a category as points -- either dodged a little bit, or drawn as horizontal "fringe" (I think I kind of like fringe in this case but I can be convinced elsewhise

then the stats panel would need to show something reasonable for this

oh god it's a matrix isn't it, that's not nice to put in that lil panel

maybe this is a bad idea?

this is also a totally different sort of plot than the bivariate scatter and maybe just doesn't make sense in this product

[njvack]

Some analysis notes on scope and fit (from a codebase review with Claude Code) — parking here for whenever this gets picked up. Not planning to build this right now.

Is it off-brand?

Less than it first appears. Scatterize's differentiators aren't scatter plots per se — they're visible raw points, click-to-censor, robust fits, and nuisance residualization. All of those transfer to group comparison, and censoring arguably matters more there ("is that group difference driven by one subject?"). Categorical X vs. numeric Y is the other most common bivariate question. The product identity survives; the codebase takes a beating.

Why it's big

The whole pipeline assumes continuous numeric X:

• Column selection (dashboard.js) only enables numeric columns for X/Y; categorical X changes selector logic, state serialization, and URL round-tripping.
• The plot (plot-model.js, scatterplot.js, WebGL renderer, axes, SVG export) builds a linear X scale, KDE over the X domain, CI bands from slope/intercept. Rainclouds need a band scale, per-group half-violins, jitter/dodge layout — effectively a second plot mode.
• The models all produce slope + intercept. With unordered categories: Spearman and Theil-Sen are meaningless, OLS becomes one-way ANOVA via dummy coding, and the robust analog needs rethinking (Kruskal-Wallis is the natural rank-model counterpart). The model selector's semantics fork by mode.
• Smoothers and custom X ticks need graceful disabling in the new mode.

Ballpark: 1,500–2,500 new/changed lines in a ~6,000-line codebase. A "version 4 flagship feature," not an issue-sized change.

The "oh god it's a matrix" problem is solvable

The existing panel grammar (model-level table + per-variable sections) maps cleanly onto ANOVA: an omnibus table (n, df, F, p, η²) plus one section per group (n, mean, SD, median). No matrix.

Pairwise post-hocs are the matrix, with two outs:

1. Don't ship them in v1 — omnibus + visible per-group distributions is already more honest than most bar-chart figures.
2. Make them hover-contextual: group-hover infrastructure already exists (legend hover → diagnostics highlighting), so hovering group A could surface "A vs. each other group" as a temporary panel section. A matrix is only a matrix if you show all of it at once.

Fringe vs. jittered points

Design pushback on the fringe idea: the Voronoi hit model, hover, and click-to-censor all need points with area. Fringe lines break the app's most distinctive interaction. Deterministic jitter/dodge (so URL-shared state reproduces exactly) keeps censoring natural; fringe could remain as a secondary density cue like the existing axis fringes.

Cheap on-ramp, if ever wanted

Optional jitter when X is low-cardinality numeric, plus per-group mean markers — no new stats mode. Roughly a tenth of the effort, serves a chunk of the use case, and would show whether people actually use the app this way before committing to the full mode. (The binary 0/1-X-as-t-test case already works today, and the axis KDE strip already helps with clumped X.)

---

Generated by Claude Code