Post

🧵Okay let's do some BTS for Axios' elections #dataviz. 1/5: We used <canvas> for our big maps, which means we had to do some tricks with color hashes to get interactivity. What the reader sees vs. what the computer sees. Details on how it works: observablehq.com/@camargo/can...

Jacque Schrag@jacqueschrag.com

With so much election #dataviz to choose from, pretty pleased to have the map I worked on for Axios included. Thinking about sharing some behind-the-scenes look at what we did, so stay tuned for that.

11 reposts51 likes

Good question! Mainly performance reasons. The frequency that these maps are updating with new data + the amount of DOM elements being created (depending on the map) made canvas a better option for us. With multiple maps, SVGs started to get noticeably sluggish.

2/🧵 #a11y with #dataviz is hard, and I won't claim that we got it 100% right. But I do think we made good choices: - Used aria or sr-only text for describing the graphics - All information available in accessible tables, with skip links to them - For bigger tables, we included a search option

3/🧵 Last year I built a component library in #svelte for Axios' visuals because nobody likes building the same things over and over again. We expanded it to include election #dataviz & it made it so much easier to have consistency across multiple codebases and implementations of these graphics.

If at any point you all open-source this Storybook, it would be awesome! Super curious to see how these components are made reusable. I've always found it a challenge to make viz components the right mix of extendable while keeping things easy for simpler use.

4/🧵 We use @svelte.dev for bespoke graphics at Axios and the election #dataviz was no exception. Our graphics have to live in a lot of places, and Sveltekit + our component library made it straight forward to build once and share everywhere.

Fin/🧵 I am so proud of the work my team did this year. We only had 2 people working on elections graphics/backend rig the majority of the time, and we had to cover A LOT of ground to make it happen. I learned so much & look forward to applying to future projects - after a very well deserved break.

Hi! Yes, we use Sveltekit + Storybook (which just shipped support for #svelte 5 yesterday). We build components in SK & use the package feature to build. Storybook for documentation. It gets published to a private NPM package we have included in our other Svelte templates.

Very cool! Yeah it’s not really a “new” technique but I wanted to share bc most people don’t know until they start working on it. I also ran into some issues with edges or borders, so there’s definitely some extra logic in ours to only show when there’s actual data.

I also considered using a r-tree/flatbrush technique, but ultimately the API for the HitCanavs was simpler (and doesn't require an external dependency / r-tree implementation). I plan to re-investigate this technique in the future. github.com/techniq/laye...

github.comCanvas events for path shapes · Issue #153 · techniq/layerchartWhile a voronoi or quadtree can be used as a technique for single point events (i.e. tooltips), hit detection for paths/rects/etc (ex. GeoPath or Pie arcs) are more challenging. Using the r-tree al...