Our hope with Observable is that reactive notebooks, as a form of literate programming designed for tinkering, make code easier to understand and reuse. Sharing code is already popular today, obviously, but we think helping people better understand that code will foster creativity and innovation.
As is, I wouldn't fork something I can't use legally as it would be a dead-end. I can't find the word "license" on any of the bar chart pages, so I imagine it defaults to whoever wrote it owning the rights and anyone using it for anything is in legal jeopardy.
Where do you get ideas for your novel visualizations? Is there academic literature on the psychology of presenting data like this, or are you just dreaming up new things and adding features to D3 so you can do it? How do you recommend making the jump from forking and adapting others' visualizations to writing entirely new things from scratch?
I'm currently using Observable/d3 to develop/test a time based graph of multiple analog channels being read in real-time from an IoT device (i.e. Arduino Mega).
A bar chart race is in many ways “worse” than a static chart. The bar chart race forces you to wait for the animation to finish, whereas a static chart shows you everything simultaneously, and lets you look forward or backward in time by just moving your eyes. This can be generalized to say that a well-designed static chart is often better than an interactive or animated chart, since in the static chart, everything is visible up-front.
But in the same way that a good visual hierarchy directs the reader’s attention and simplifies a complex interface, bar chart races (and animations more generally) are effective at getting the viewer to watch the race as it originally played out, from start to finish. Time in the data is represented as real time, so you’re only able to see a single moment in time.
So bar chart races are probably worse for most perceptual tasks, but as a storytelling device, they are (seemingly) quite effective.
IMO bar charts are better at showing relative sizes of scalar numbers as opposed to 2d shapes. A circle with twice as much area as another just doesn’t look 2x as big to me.
Try adding your own scrubber using:
or any of the other offerings:
x.domain([0, d3.max(keyframes, ([, data]) => d3.max(data, d => d.value))])
Every time I see the "ka-chunk" as yearly data is iterated through in lockstep fashion, especially on a certain corner of the internet where "data is (or should be) beautiful", I cringe.
Data Is Beautiful, one of my favorite short clip youtube channels does this for all of their content: