How do you learn d3.js?
Practicing data visualization for fun and profit
I’ve been thinking quite a bit about how people learn d3.js, I don’t mean technical mastery of a useful library, I mean learning the craft enabled by a new tool. Creating data visualizations with d3.js puts the practitioner in the unique position of controlling the data, code and design all at once. With d3 in your tool belt you look at datasets in a different way, you know you can create custom tools for communication with interactive interfaces. You can bend time to your will. You can explain things that are really hard to explain with words.
So how does one acquire these powers? I asked some of the most skilled practitioners I know how they went about learning d3 and an interesting pattern emerged: start (small) projects with an idea and no idea how to implement it, and then try to implement it.
I’ll let them tell you in their own words:
Nadieh Bremer
I tried to sketch/create visualizations of datasets that interest me (such as exoplanets) without thinking of what was “easily” achieved by d3. And so when, while building, I came across something that wasn’t standard I would be on Stack Overflow a lot trying to find little pieces of the puzzle that I could then combine to make it into what I needed specifically. I wasn’t necessarily looking for things that would stretch me, but my designs would somehow always involve several aspects where I had no clue on how to do it, so I learned a lot while trying to figure it out
Shirley Wu
I always picked side projects that were kind of congruent to what I was working on at work, so there was synergy between what I was learning on the job and what I was learning on the side. But for side projects I had more freedom with, I’d come across a dataset or an idea I really wanted to visualize, and I’d try to sketch out/dream out what would be the best viz for that.
It’s been really interesting because there have been some things that when I dreamed it up, I wasn’t technically good enough to figure out how to implement (animating svg paths on scroll, for example, I dreamed that up a year before I actually was able to implement it). But as time went and i worked on other things for fun, I would eventually learn enough to be able to implement it.
Tony Chu
I started with a design vision, then worked backwards to figure out how to achieve it. I learned D3 for my thesis project at SVA, because the story I wanted to tell involved helping people understand campaign finance data.
Unlike Shirley who actually diligently read the documentation, however, I just copied code off D3’s gallery, and messed with it. (which was why I didn’t truly understand Enter Update Exit until AFTER I built Let’s Free Congress =P)
I certainly practiced, 2 prototypes a week for like, my first 7 weeks working on the thesis project. But it wasn’t deliberate practice, it was more like iterative prototyping.
Zan Armstrong
I was introduced to D3 by first drawing a smiley face with just SVG, then vanilla javascript to control the SVG, and then D3 to build the SVG. From then on, everything I was learning was driven by “I want to do X… now how do I do that?”
I mostly approached learning by either knowing there was something I wanted to learn and creating a project around it (my first website: newzealand.zanarmstrong.com) OR trying to do something that I believed was possible and figuring out what I needed to know to do it, often by creating something small to learn the key technique, and then incorporating it into the bigger project.
The emphasis on Zan’s last sentence is mine, and I’m not the only one who believes in the power of examples. But I digress, the true theme of this post is that of starting a project and letting the goal inform your technical needs. For a long time this was actually the opposite of my approach: I would learn a new technique and search for ideas to apply it to.
What originally woke me up to the idea of flipping my approach was a talk by Bill Atkinson at EYEO
At the 2:30 mark he says:
I have nothing against programming, I don’t like programming, I don’t like computers, I have a healthy disrespect for them, which has done me a good stead. Computers are bad for human’s self feelings, because they are always right and you are always wrong. I think a better way of looking at it is not in terms of “I want to learn this language”, instead its to get a project, what do you want to do? what do you want to make? and let that pull the tools, you’ll learn whatever you have to learn to do that project”
Hearing one of the pioneers of computing and user interfaces, and my intellectual grandfather, say my approach was completely backwards was a big shock. But it made me realize that I’ve had so many ideas that were sparked by a possibility only to get derailed by the slightest bump in the road. So many folders of code with a sweet technique that will never be seen or understood because I wasn’t motivated by a goal to finish them. Whereas people trying to realize a vision will plow through whatever gets in their way to make it real.
It’s been inspiring for me to hear my contemporaries echo the sentiments of a legend. I feel compelled to share this pattern, especially when so many people are trying to learn this new discipline of interactive data visualization. As it happens another pattern emerged from the four people I interviewed: they are all speakers at the 2016 OpenVisConf! You should probably go and learn even more from them :)
I’d like to thank Nadieh, Shirley, Tony and Zan for answering my questions in the first place. I’d like to especially thank Zan for providing a lot of valuable feedback on this post and pushing me to dig deeper into the theme.
I’d love to hear if this approach resonates with you, or if you had a different path on your journey into d3.js! Comment here or take the discussion to twitter.
