While working on the 51 Line Charts for my Opioid Crisis data visualization, I ran into an issue with generating all 51 charts at the same time: The data was either in 51 rows stacked and I couldn’t access the dates effectively, or 306 rows unstacked and I had 6x as many objects as I needed when I did a join.
The solution was to use D3.nest. Nesting allows elements in an array to be grouped into a hierarchical tree structure; think of it like the GROUP BY operator in SQL, except you can have multiple levels of grouping, and the resulting output is a tree rather than a flat table. The levels in the tree are specified by key functions.
When I used the state as a key, it grouped each state’s data together in a tree.
Input:
D3 code:
Output:
A few useful tools and resources for understanding d3.nest:
Aren’t familiar with Sol LeWitt or his art? Read this.
I had an insight while going through the D3.js documentation to find a solution to another piece: d3.area() with a highly curved fit line isn’t that different from wall drawings 852 and 853! By the way, 852 and 853 are actually distinct pieces, though they are often grouped together into one display like the one at MASSMoCA. I worked on the solution to 852 first, then modified it to make 853:
Wall Drawing 852: A wall divided from the upper left to the lower right by a curvy line; left: glossy yellow; right: glossy purple.
Wall Drawing 853: A wall bordered and divided vertically into two parts by a flat black band. Left part: a square is divided vertically by a curvy line. Left: glossy red; right: glossy green; Right part: a square is divided horizontally by a curvy line. Top: glossy blue; bottom: glossy orange.
So much of implementing these drawings with D3.js rely on making a solid, usable data set to join elements with. (After all, D3 stands for data-driven-documents.) Creating these data sets is where I spend most of my time. Once I’ve created them, everything else follows pretty quickly.
Since d3.area() makes an area graph with given points, I had to create a data set of points. I wanted the start and end points to be defined with random (but constrained) points in the middle. Here is what I came up with for 852:
For 853, things were a little trickier since the left is oriented vertically:
d3.area()
One of the most important things to note about d3.area() is that you must sort your data sets (by x if the chart is horizonal, y if vertical) before passing them to the function. Otherwise you end up with something like this because the values are out of order:
D3 has selection.sort() built in, but you also need to pass a function telling it how to sort:
Most area charts tend to be horizontal, and nearly all examples you can find are structured in this way. You need to pass .x, .y0, and .y1:
If you are switching to a vertical orientation, you instead need to pass .y, .x0, and .x1:
Curves and Points
I played with a number of curve functions and a number of points to see how they compared to traditional interpretations of Sol LeWitt’s pieces:
curveCatmullRom
curveCardinal
curveBasis
curveNatural
curveLinear
I eventually settled on curveBasis for both pieces. It creates the smoothest curving line with the given random points, which produces results similar to the curved lines in Sol’s earlier work. curveCatmullRom was my second choice, but occasionally produced harsh concave regions.
For the larger standalone piece (852) I used 7 total points, including the end points. For 853, which consists of two different curves, I used 5 points each since the widths were smaller.
Rebuilding on screen resize
When you resize the screen, the divs gets destroyed and then rebuilt based on the new screen size. Here is the function I use to handle that. It is the same thing I used on 86 and on my Jekyll posts heatmap calendar. I wrapped the D3 instructions in its own function, called that function on first load, then wrote a function to destroy the node divs when the screen is resized and reexecute the D3 instructions after the screen resize ends. I’m sure it can be done with regular javascript, but jQuery makes this kind of thing fast and easy:
Tools Used
D3.js – The D3.js library is well-suited to Sol LeWitt’s works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s drawings.
jQuery – I’m using jQuery to detect changes in the window size and trigger removing & rebuilding the visualization.
Sol LeWitt is a conceptual artist who typically produced directions for producing a piece of art. Those ideas are the art itself. Learn more about Sol LeWitt here.
I made a standalone version with 40 rectangles and 15px wide bands. I thought it would be a fun learning experience to make it customizable with user inputs, so I made it possible for users to change the number of rectangles and the width of the bands and see the differences in real-time.
Similar to rebuilding on screen resize in the original version, I detect when there is a change in one of the inputs and then call a function to remove the divs and rebuild the treemap based on the inputs. jQuery makes this kind of thing fast and easy:
D3.js – The D3.js library is well-suited to Sol LeWitt’s works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s drawings.
jQuery – I’m using jQuery to detect changes in the window size and trigger removing & rebuilding the visualization.
LeWitt’s instructions are pretty open. The drafter can choose the number of rectangles. I chose 40.
Since screens work in pixels instead of inches, I chose to make the bands 15px wide. I tried various configurations and I think 15px
I chose to conform this to the size of the viewer’s window and have each display randomly generated, so each viewer will have a unique experience.
Just as the size of the wall this piece was implemented on determined the density of the lines, the size of the window will determine the density. You can try out different densities by resizing the screen. The illustration will rebuild after you resize the window.
The placement and size of the rectangles are handled by d3.treemap().
I tried a few different tiling methods and decided to use d3.treemapBinary. I liked the look of it the best.
Each viewer gets a unique experience because the size of each rectangle is set at random on each page load.
The underlying data set
So much of implementing these drawings with D3.js rely on making a solid, usable data set to join elements with. (After all, D3 stands for data-driven-documents.) Creating these data sets is where I spend most of my time. Once I’ve created them, everything else follows pretty quickly. Here is the function that creates the underlying data set on this piece. I owe major props to Eric Davis on helping me figure this out. I was getting close, but nothing I made was accepted by treemap(). He helped me identify my issues, which included making this data set and then passing it to d3.hierarchy before passing it to treemap.
Working with treemap
One of the difficulties of D3.js transitioning from v3 to v4 recently is that most of the tutorials you can find on the web no longer work. Thankfully Mike Bostock created a great example of a treemap with v4 that I referenced quite a bit.
After a few passes through the documentation and a call on my friend Eric Davis, we figured out how to pass data to d3.treemap():
Create a data set that has a clear parent-child structure with unique parents
Pass this to d3.hierarchy
Call .sum() on d3.hierarchy and sum the values before passing it to treemap
Pass it to treemap
See below:
Rebuilding on screen resize
When you resize the screen, the divs gets destroyed and then rebuilt based on the new screen size. Here is the function I use to handle that. It is the same thing I used on 86 and on my Jekyll posts heatmap calendar. I wrapped the D3 instructions in its own function, called that function on first load, then wrote a function to destroy the node divs when the screen is resized and reexecute the D3 instructions after the screen resize ends. I’m sure it can be done with regular javascript, but jQuery makes this kind of thing fast and easy:
D3.js – The D3.js library is well-suited to Sol LeWitt’s works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s drawings.
jQuery – I’m using jQuery to detect changes in the window size and trigger removing & rebuilding the visualization.
Aren’t familiar with Sol LeWitt or his art? Read this.
Wall Drawing 289: A 6-inch (15 cm) grid covering each of the four black walls. White lines to points on the grids. Fourth wall: twenty-four lines from the center, twelve lines from the midpoint of each of the sides, twelve lines from each corner. (The length of the lines and their placement are determined by the drafter.)
LeWitt’s instructions dictate that the lines are to go to a point on a 6-inch grid. I didn’t lay out a grid first, but I did round the random line ending points to they land on whole numbers.
I chose to conform this to the size of the viewer’s window and have each display randomly generated, so each viewer will have a unique experience.
Just as the size of the wall this piece was implemented on determined the density of the lines, the size of the window will determine the density. You can try out different densities by resizing the screen. The illustration will rebuild after you resize the window.
I tried drawing each line individually in time like I did with number 86, but it looked so much cooler with all lines coming in at one from their starting points. The viewer gets the understanding of where each line starts and the randomly-generated end points fulfill the requirement of the length and location of the lines being determined by the drafter.
Technical Details
The midpoints are determined by the size of the window.
Each viewer gets a unique experience because the length of the lines is set at random on each page load.
The underlying data set
So much of implementing these drawings with D3.js rely on making a solid, usable data set to join elements with. (After all, D3 stands for data-driven-documents.) Creating these data sets is where I spend most of my time. Once I’ve created them, everything else follows pretty quickly. Here is the function I wrote to create the underlying data set on this piece:
Transition
I handled the transition by first defining the lines as starting and ending at the same set of coordinates, then doing a delayed transition to their real end points:
Rebuilding on screen resize
When you resize the screen, the svg gets destroyed and then rebuilt based on the new screen size. New midpoints are calculated and new ending points for each other lines are calculated. Here is the function I use to handle that. It is the same thing I used on 86 and on my Jekyll posts heatmap calendar. I wrapped the D3 instructions in its own function, called that function on first load, then wrote a function to destroy the svg when the screen is resized and reexecute the D3 instructions after the screen resize ends. I’m sure it can be done with regular javascript, but jQuery makes this kind of thing fast and easy:
D3.js – The D3.js library is well-suited to Sol LeWitt’s early works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s symmetrical objects.
jQuery – I’m using jQuery to detect changes in the window size and trigger removing & rebuilding the visualization.
LeWittâs instructions dictate 10,000 10-inch lines on a wall. Since computer screens are much smaller, I chose 1,000 lines that are roughly 141 pixels long (100*sqrt(2)).
I chose to conform this to the size of the viewerâs window and have each display randomly generated, so each viewer will have a unique experience.
Just as the size of the wall this piece was implemented on determined the density of the lines, the size of the window will determine the density. You can try out different densities by resizing the screen. The illustration will rebuild after you resize the window.
LeWittâs instructions indicate that the wall should be evenly covered. Due to randomly generating the starting and ending values of the points, I couldnât figure out a way to have even distribution without having some lines go outside of the edges of the window. If I kept every point inside the window, a space around the edges emerges where the lines are not as evenly distributed. I decided it was better to have lines going over the edge than an uneven distribution.
Technical Details
Making equal length line segments
Making equal length line segments turned out to be a little more difficult than I anticipated. Lines are drawn by picking two sets of (x,y) coordinates and connecting them. If you leave this 100% random, youâll get lines of all different lengths and slopes. If you want lines of equal lengths and different slopes, however, you need to be a little more crafty.
I came up with two ways of doing it: 1) Pick a random slope and fixed length, then solve a series of rearranged quadratic equations derived from the point-slope form of a line and the distance formulaArchived Link. 2) Derive the second set of coordinates based off of a fixed formula with the first coordinates. This will result in lines having all the same slope initially. Then apply a transform to rotate the lines about their midpoints by a random angle.
Number two was faster and simpler for me to implement, so I went that route.
The underlying data set
So much of implementing these drawings with D3.js rely on making a solid, usable data set to join elements with. (After all, D3 stands for data-driven-documents.) Creating these data sets is where I spend most of my time. Once Iâve created them, everything else follows pretty quickly. Here is the function I wrote to create the underlying data set on this piece:
Rotation
To make the rotation work without affecting the even distribution of the lines, I needed to rotate them around their midpoints. Otherwise theyâd be rotated around (0,0), which puts lines out of the viewing area at large angles. I essentially used the midpoint formula to calculate the midpoints. I simplified since I know the length of each line. Here is the tranform attribute I applied:
Transition
I handled the transition by first defining the lines as starting and ending at the same set of coordinates, then doing a delayed transition to their real end points. I applied the rotation before the transition so that the lines would appear to grow, but not rotate. To create the effect of the lines being drawn one by one in real-time, I added a delay function with an index. With a 20 millisecond delay and 1000 lines, it takes about 20 seconds to complete:
D3.js – The D3.js library is well-suited to Sol LeWittâs early works. D3âs foundational principle of joining data to elements is easy to apply to LeWittâs symmetrical objects.
jQuery – Iâm using jQuery to detect changes in the window size and trigger removing & rebuilding the visualization.
Aren’t familiar with Sol LeWitt or his art? Read this.
Wall Drawing 87: A square divided horizontally and vertically into four equal parts, each with lines and colors in four directions superimposed progressively.
Since this is so close to 56 (which I’ve already done), I wanted to add an additional element to challenge myself and learn something: Transitions. The difference between the two is the separate color for each line direction, which ended up lending itself to transitions nicely.
Adding the color and transitions into this one made me change my mental model for how I’m building these implementations. I was able to complete the first three I picked (56, 11, and 391) with only four elements inside the SVG: One for each quadrant. This is because I was able to make a single pattern for each quadrant (even though it appears that there are four sets lines are going in different directions) and have the patterns match up with the other quadrants. Textures.js doesn’t support making line-based patterns with more than one line color, so I needed to find a different approach.
The solution turned out to solve my mental block for both the colors and the transitions. I started to doodle this drawing in a journal and realized that I did each line direction one whole layer at a time, layering each one on top of the others. Yet, I had been trying to cram all four directions into a single layer here on the web. So, I modified my D3 code to join more elements with different classes to the same underlying grid array to simulate the effect of layering the different colors.
Then, I added a transition() and a delay() to each “layer” so that the viewer can also experience and take notice of the intentional layering of this piece.
There is definitely more I can do with transitions. This is just the beginning for me. I achieved what I wanted with this piece, so I’m going to move on to others and continue exploring and learning how to implement transitions.
Here is an image preview. Click on it to see the D3.js version:
While any interpretation of Sol LeWitt’s instructions is technically valid as long as each statement is accounted for, I feel a responsibility to make my implementation beautiful, clean, and symmetrical.
When he says “four directions”, the common interpretation is 0 degrees, 90 degrees, 45 degrees, and 135 degrees.
On a wall, the dimensions are dictated by the physical size of the wall itself. On the web, since windows change size so easily and the proportions of the art are constant, I chose to define a fixed size for this piece.
Color Palette
Unlike the earlier colored versions that used grey, yellow, red, and blue, this uses Sol Lewitt’s second color palette of choice: grey, yellow, tan, and reddish-brown.
D3.js – The D3.js library is well-suited to Sol LeWitt’s early works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s symmetrical objects.
Textures.js – I’m using this library to quickly create the background patterns. It plays very well with D3.js, which is why I chose it. It is a great little library that is very easy to use. It has some limitations around the edges, but the alternative is writing my own SVG paths for the patterns, which I didn’t want to do at this time.
Aren’t familiar with Sol LeWitt or his art? Read this.
Wall Drawing 391: Two-part drawing. The two walls are each divided horizontally and vertically into four equal parts. First wall: 12-inch (30 cm) bands of lines in four directions, one direction in each part, drawn in black India ink. Second wall: Same, but with four colors drawn in India ink and color ink washes.
391 is one of the iconic images that people instantly recognize as a Sol LeWitt. After making the simple line drawings, I wanted to try something more comfortable and a little more complex. Now that I’ve created this, I could translate it into #419. Perhaps I will do this in the future.
Here is an image preview. Click on it to see the D3.js version:
While any interpretation of Sol LeWitt’s instructions is technically valid as long as each statement is accounted for, I feel a responsibility to make my implementation beautiful, clean, and symmetrical.
Besides for this being a commonly recognized piece where it would be noticeable that I deviated from the norm, when I made this I was still unsure of myself. I wanted to see if I could translate what I saw in person to D3.js as closely as possible. I think it turned out pretty well.
When Sol LeWitt says “four colors”, the regular interpretation is black/dark gray, yellow, red, orange. When he says “four directions”, the common interpretation is 0 degrees, 90 degrees, 45 degrees, and 135 degrees.
Sol LeWitt dictated a 12-inch bands. Since inches are fuzzy on the web and regular screens aren’t as wide as walls, I scaled things down and translated it into pixels. I kept with the spirit and chose a multiple of 12: 36 pixel bands.
On a wall, the dimensions are dictated by the physical size of the wall itself. On the web, since windows change size so easily and the proportions of the art are constant, I chose to define a fixed size for this piece.
D3.js – The D3.js library is well-suited to Sol LeWitt’s early works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s symmetrical objects.
Textures.js – I’m using this library to quickly create the background patterns. It plays very well with D3.js, which is why I chose it. It is a great little library that is very easy to use. It has some limitations around the edges, but the alternative is writing my own SVG paths for the patterns, which I didn’t want to do at this time.
This is two SVGs with two groups each (one for each row) and two rect elements in each group (one for each quadrant). The only difference between the left and right SVG squares is the color.
The stripes are singular path fills in each square. There is only one pattern per quadrant here because this piece has simple, non-overlapping colors.
Want to dig in a little further? Check out my implementation and view source. All of the D3 specs are there.
What I learned
There are tradeoffs to using libraries to generate patters for you. At the width of the squares I’ve specified here, the size of the pattern should be sqrt(2) times the size of the vertical one. When I run those calculations and set the diagonal patterns as such, the right one lines up but the left one is shifted too far up. I ended up finding a middle ground, but the stroke size of the bottom ones aren’t exactly 36 pixels wide. They are 37 pixels wide. That is the price I pay for using a library. I’ll learn to write my own SVG patterns in the future.
Many interpretations of Sol LeWitt’s directions (including ones he oversaw the installation of) are very geometric and symmetrical.
Aren’t familiar with Sol LeWitt or his art? Read this.
Wall Drawing 11: A wall divided horizontally and vertically into four equal parts. Within each part, three of the four kinds of lines are superimposed.
Wall Drawing 11 is remarkably close to Wall Drawing 56, which is the first one I implemented. I discovered that with only a few changes (width, height, and pattern direction) I could turn my code for 56 into 11.
While any interpretation of Sol LeWitt’s instructions is technically valid as long as each statement is accounted for, I feel a responsibility to make my implementation beautiful, clean, and symmetrical.
There are other valid layouts of this piece (the patterns could be in different directions as long as you use three), but I decided to implement the popularly known configuration currently on display at MASSMoCA. I will stray from this path later on in the project.
I reused most of the foundation I laid with Wall Drawing 56. I chose to change the dimensions to a rectangle to better fill the page and to differentiate it. A rectangle also stays closer to the version of 11 at MASSMoCA than a square.
Tools Used
D3.js – The D3.js library is well-suited to Sol LeWitt’s early works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s symmetrical objects.
Textures.js – I’m using this library to quickly create the background patterns. It plays very well with D3.js, which is why I chose it. It is a great little library that is very easy to use. It has some limitations around the edges, but the alternative is writing my own SVG paths for the patterns, which I didn’t want to do at this time.
Technical Details
I reused most of the foundation I laid with Wall Drawing 56.
I changed the width, height, and starting point of each quadrant to make a rectangle instead of a square.
Want to dig in a little further? Check out my implementation and view source. All of the D3 specs are there.
What I learned
I really got the hang of setting up patterns in multiple directions here and configuring them such that they line up to create a design where the edges meet.
Dimensions matter. I started out with this as a square, but I think it fits normal browser windows much better as a rectangle.
Aren’t familiar with Sol LeWitt or his art? Read this.
Wall Drawing 56: A square is divided horizontally and vertically into four equal parts, each with lines in four directions superimposed progressively.
Wall Drawing 56 was the first of Sol LeWitt’s wall drawings I tried to implement here on the web. I picked it for its simplicity: A square with four sets of patterns and two colors. I wasn’t sure exactly what interpreting and implementing these would entail, so I wanted something simple and recognizable at first.
While any interpretation of Sol LeWitt’s instructions is technically valid as long as each statement is accounted for, I feel a responsibility to make my implementation beautiful, clean, and symmetrical.
There are other valid layouts of this piece (the patterns could be in a different order depending on where you chose to start), but I decided to implement the popularly known configuration currently on display at MASSMoCA. I will stray from this path later on in the project.
On a wall, the dimensions are dictated by the physical size of the wall itself. On the web, since windows change size so easily and the proportions of the art are constant, I chose to define a fixed size for this piece.
Tools Used
D3.js – The D3.js library is well-suited to Sol LeWitt’s early works. D3’s foundational principle of joining data to elements is easy to apply to LeWitt’s symmetrical objects.
Textures.js – I’m using this library to quickly create the background patterns. It plays very well with D3.js, which is why I chose it. It is a great little library that is very easy to use. It has some limitations around the edges, but the alternative is writing my own SVG paths for the patterns, which I didn’t want to do at this time.
I had to do a lot of trial-and-error on the width, height, starting points for each quadrant, and pattern size to make sure the patterns turned out clean and symmetrical. If you dig into the javscript, you’ll see odd variable definitions.
This is one SVG with two groups (one for each row) and two rect elements in each group (one for each quadrant).
The lines/patterns are singular path fills in each square. There is only one pattern per quadrant here because this piece is in black and white.
Want to dig in a little further? Check out my implementation and view source. All of the D3 specs are there.
What I learned
In this first implementation I was getting my feet wet with Textures.js. I got a solid understanding of how to define and create patterns with it.
When my first cut was pretty rough around the edges (literally, because the patterns had odd spacing), I noticed how precise and clean the other versions I’ve seen are. I now pay special attention to the fine details when evaluating these pieces.
I’ll admit, unlike the other tutorials where I was able to figure out most of this on my own, I had to mine other examples to figure this out. I primarily followed Mike Bostock’s Pie Chart Update, II, but his commented Arc Tween example was extremely helpful in understanding what d3.interpolate is doing.
First we need to store the beginning angle for each arc. You’ll recall that I’m using two separate arcs, one for the main chart and one for the labels. For about 10 minutes I was trying to figure out why the first update was jumpy but all subsequent ones were smooth. It turns out that we need to store the initial angles for each set of arcs:
Next we need to write two arcTween functions to transition between the two. I followed Mike Bostock’s example for the first one, then adapted it to the label arc, too:
Last we need to include these arcTween() functions into the change() function we wrote before. I commented out the previous updates so you can compare them. The duration is 1/2 a second:
Here is is in action. As always, you can view source to see the fully integrated example:
Last week we made a pie chart with D3.js. Today we are going to update it in realtime when buttons are clicked.
Here is the basic pie chart again, slightly modified from the original (I only changed the letters):
The key to making this work is D3’s object constancy. We already baked that into the original design by specifying a key function for the underlying presses count data.
Setting Up
First, we need to copy the pie chart we made last week. Make a few updates: change all the presses in data to 1 and change the letters to A, B, and C.
Next, we need something to click so we can increment the count and update the chart. Three buttons will do nicely:
Recomputing the angles
We ultimately want to call a specific update function when we click each button, so let’s write one. We need to consider what the most critical parts of making the original pie chart were so that we can recreate only the necessary steps:
Defining the value function for d3.pie
Computing the angles based on that data
Putting that information in a path so it can be displayed
Remember that we have two arcs: The main pie and the one holding the labels. We need to update both!
Updating the data and chart on click
Now we need to update the underlying data and the whole chart on click:
Here is the result. Click the buttons and watch the chart change!
This is part of my ongoing effort to relearn D3.js. This short tutorial applies what I’ve learned about data joins, arcs, and labels. It varies slightly from other examples like Mike Bostock’s Pie Chart block because I’m using D3.js version 4 and the API for arcs and pies is different from version 3, which most tutorials are based on. I figured this out through some trial and error. Always read the documentation!
I’m eventually going to use this pie chart as a base to learn how to update charts in real time based on interactions like button pushes or clicks.
Getting Started
Always include the library:
Make a div to hold the chart:
D3 stands for Data-Driven Documents. So what do we always start with when creating something with D3? Data!
Since I’m eventually going to figure out how to update this chart in real time based on button presses, I’m going to start with some dummy data for three easy-to-press buttons: q, w, and e. As always, I log it to the console for quick debugging:
We’ll also need some basics like width, height, and radius since we are dealing with a circle here. Make them variables so your code is reusable later:
Next we need a color scheme. Be referring to the API, we learn that we should use .scaleOrdinal() for this:
Setting up the pie and arcs
We need to set up the pie based on our data. According to the documentation, d3.pie() computes the necessary angles based on data to generate a pie or doughnut chart, but does not make shapes directly. We need to use an arc generator for that.
Before we create the SVG and join data with shapes, let’s define some arguments for the two arcs we want: The main arc (for the chart) and the arc to hold the labels. We need an inner and outer radius for each. If you change the inner radius to any number greater than 0 on the main arc you’ll get a doughnut.
Making the shapes
We always start with an SVG. Select the div we created to hold the chart, append an SVG, give the SVG the attributes defined above, and create a group to hold the arcs. Don’t forget to move the center points, or else the chart will be centered in the upper right corner:
Now let’s join the data generated by .pie() with the arcs to generate the necessary groups to hold the upcoming paths. Give them the class “arc”.
Now we can append the paths created by the .arc() functions with the variables we defined above. We’re using the color variable we defined above to get the colors we want for the various arcs:
Once you save, you should see a chart. Now we’re cooking with data!
Labels
Let’s put some labels on it now. We’ll need to append some text tags in each arc, set the position with a transform defined by the labelArc variable we defined earlier, then access the correct letter to add to the label. Then we’ll make it white so it shows up a little better:
There you have it! A basic pie chart. Play around with the variables so you understand better what is going on.
I’ve been on a mission to relearn the fundamentals of D3.js from the ground up. This tutorial is a way to apply what I learned about data joins, click events, and selections. Along the way I learned about building arrays.
I also wrote this up as a block for those interested.
Basics
We want to make a 10×10 grid using D3.js. D3’s strength is transforming DOM elements using data. This means we’ll need some data and we’ll want to use SVG and rect elements.
Data
We could write an array of data for the grid by hand, but we wouldn’t learn anything then, would we? Let’s generate one with Javascript.
Picture a grid in your head. It is made up of rows and columns of squares. Since this is ultimately going to be represented by an SVG, let’s think about how an SVG is structured:
What you see here is a basic structure of rows and columns. That means that when we make our data array, we want to make a nested array of rows and cells/columns inside those rows. We’ll need to use iteration to do this. Easy-peasy.
The other question we’ll have when making these arrays is, “What attributes will this grid need?”. Think about how you’d draw a grid: You start in the upper right corner of a piece of paper, draw a 1×1 square, move over the width of 1 square and draw another, and repeat until you get to the end of the row. Then you’d go back to the first square, draw one underneath it, and repeat the process. Here we’ve described positions, widths, and heights. In SVG world these are x, y, width, and height.
Here is the function I’m using to create the underlying data for the upcoming grid. It makes an array that holds 10 other arrays, which each hold 10 values:
Making a Grid with D3 Data Joins
We made a cool array above and now we’ll make the data correspond to svg:rect objects to make our grid. First we’ll need to make a div to append everything to (and, of course, don’t forget to include the latest version of D3 in your header):
Now we need to assign our data to a variable so we can access it:
Next, let’s append an SVG to the div we made and set its width and height attributes:
Next, we can apply what we learned in Mike Bostock’s Thinking With Joins to make our rows:
And finally we make the individual cells/columns. Translating the data is a bit trickier, but the key is understanding that we are doing a selectAll on the rows, which means that any reference to data is to the contents of the single array that is bound to that row. We’ll then use a key function to access the attributes we defined (x, y, width, height):
You’ll note that I added style fill and stroke attributes to make the grid visible.
When we put it all together, here is what we get:
Note: If you are viewing this on your phone, you might want to switch over to a tablet or desktop. I haven’t optimized this example for mobile because that will needlessly complicate it.
Cool, huh? Go ahead and inspect the element and marvel at your find handiwork. Then change the fill, stroke, width, and height attributes and see how it changes.
Adding Click Functions
Let’s have some fun and add click events to the individual cells. I want to have cells turn blue on the first click, orange on the second, grey on the third, and white again on the fourth. Since D3 is data-driven, we’ll need to add some click data to the arrays and then add functions to change it and set colors based on the number of clicks.
Let’s break down that on('click') function:
When you click on a cell, it increases the click variable (originally set at 0) by 1.
The if statements set the color based on how many times it has been clicked mod 4. This satisfies the UI of only having four states: white, blue, orange, and grey. If you go to your console and call up the data for a certain cell, you’ll see that the full number of clicks is available.
Here it is. Click away!
Randomized click counts
What happens when we randomize click counts when we create the data array?
Note that Math.random() returns a number between 0 and 1, inclusive. Multiple that by 100 if you want a number between 1 and 100.
It changes when you refresh!
Mouseovers: Even more fun with a bigger grid
What happens when we change the click event to a mouseover event and make a bigger grid? It becomes a lot more fun. I’ll leave the implementation as an exercise to the reader. If you’ve been following along and writing this yourself instead of copying and pasting, you probably already know which variables and events to change:
These are my outputs from Mike Bostock’s Three Little Circles Tutorial, slightly modified so I could understand how each of these items work. This is a tutorial about selections and basic data joins.
We start with three basic SVG circles:
Now let’s select them and make them a little bigger and orange!
Now how about making them light blue and having a randomly-generated height that resets every second?
That’s cool!
Now let’s do some data joins. How about making the radius of the circle a function of a data set?
Looks like the radius is a square of the data. Go ahead and inspect the element to confirm!
You’ll notice that the function uses the name d to refer to bound data.
Let’t make these purple for variety and write a linear function to space them out horizontally.
This uses a new function: The index of the element within its selection. The index is often useful for positioning elements sequentially. We call it i by convention.
D3.js is a javascript library for manipulating documents based on data. It uses HTML, SVG, and CSS to do so. It emphasizes web standards so that you can use modern browsers without proprietary frameworks.
You can bind data to a DOM (Document Object Model) and apply data-driven transformations to the document.
Example: Generate an HTML table from an array of numbers, then use the same data to make an SVG bar chart.
Selections
D3 makes it a lot easier to modify documents than the W3C DOM API. The W3C method relies on verbose names and manual iteration. D3 employs a declarative approach that operates on arbitrary nodes called selections.
Here is Mike Bostock’s examples for how to change the text color of paragraph elements with the W3C method vs D3 method:
W3C:
D3:
Elements may be selected using a variety of predicates, including containment, attribute values, class and ID.
D3 provides multiple ways to change nodes: Setting attributes and styles, registering event listeners, adding/removing/sorting nodes, and changing HTML or text content.
Direct access to the DOM is possible because each D3 selection is a simple array of nodes.
Dynamic Properties
D3 has similar syntax to jQuery, but styles, attributes, and other properties can be specified as functions of data in D3, not just constants.
To alternate shades of gray for even and odd nodes:
Computed properties often refer to bound data. Data is specified as an array of values, and each value is passed as the first argument (d) to selection functions. With the default join-by-index, the first element in the data array is passed to the first node in the selection, the second element to the second node, and so on. For example, if you bind an array of numbers to paragraph elements, you can use these numbers to compute dynamic font sizes:
Once the data has been bound to the document, you can omit the data operator. D3 will retrieve the previously-bound data. This allows you to recompute properties without rebinding.
Enter and Exit
With D3’s enter and exit selections you can create new nodes for incoming data and remove outgoing nodes that are no longer needed.
When data is bound to a selection, each element in the data array is paired with the corresponding node in the selection. If there are fewer nodes than data, the extra data elements form the enter selection, which you can bring to life by using the .enter() selection. Example:
Updating nodes are the result of the data operator. If you forget the enter and exit selections, you will automatically select only the elements for which there exists corresponding data.
A common pattern is to break the initial selection into three parts: Updating nodes to modify, entering the nodes to add, and exiting the nodes to remove. Example:
By handling the three cases (update, enter, exit) separately, you control precisely which operations run on which nodes.
D3 allows you to transform documents based on data. This includes creating and destroying elements.
D3 allows you to change an existing document in response to user interaction, animation over time, or even asynchronous inputs from a third-party. A hybrid approach is also possible, where the document is initially rendered on the server and updated on the client via D3.
Transformation, not Representation
D3 does not introduce a new visual representation. Instead, its graphical marks come from web standards: HTML, SVG, and CSS. If browsers introduce new features tomorrow, you can use them immediately with D3, no update required.
D3 is easy to debug with the browser’s built-in element inspector. The nodes D2 manipulates are the same ones the browser uses natively.
Transitions
D3’s transformation focus extends to animated transitions, too. Transitions interpolate styles and attributes over time. The time between can be controlled with easing functions.
D3’s interpolators support primitives (numbers and numbers within strings like font size, etc) and compound values. They are also extendable.
Examples:
To fade the background of the page to black:
Or, to resize circles in a symbol map with a staggered delay:
D3 allows you to modify only the elements that change, which reduces overhead and allows more complexity at high frame rates.
D3 allows sequencing of complex transitions via events
D3 does not replace the browser’s toolbox, but instead exposes it and makes it easier to use. You can still use CSS transitions.
D3 has no primitive for creating multiple DOM elements. The .append() method can create single elements, but if you want multiple, you need to think in a different way.
Instead of telling D3 how to do something, tell D3 what you want. For example, on the Thinking with Joins page, Mike uses this snippet to tell D3 that the selection “circle” should correspond to data points. This concept is called a data join:
Data points joined to the existing elements produce the update (inner) selection. Leftover unbound data produce the enter (left) selection, which represents missing elements. Any remaining unbound elements produce the exit (right) selection, which represents elements to be removed.
Now let’s explain the svg.selectAll("circle"):
First it returns an empty selection since the SVG container was empty. The parent node of the selection was the SVG container.
The selection is joined to a data array, resulting in three new selections that represent three possible states: enter, update, or exit. Since the selection was empty, the update and exit selections are empty and the enter selection contains a placeholder for each new data point.
The update selection is returned by selection.data and the enter and exit selections hang off the update selection. selection.enter returns the enter selection.
The missing elements are added to the SVG container by calling selection.append on the enter selection. This appends a new circle for each data point in the SVG container.
Thinking with joins means declaring a relationship between a selection (such as a “circle”) and data, then implementing this relationship through the three enter, update, and exit states.
For static visualizations, the enter selection is sufficient. But you can support dynamic visualizations with minor modifications to update and exit.
If a given enter, update, or exit selection happens to be empty, the corresponding code does not operate.
Joins let you target operations to specific states. For example, you can set constant attributes (such as the circle’s radius, defined by the “r” attribute) on enter rather than update. By reselecting elements and minimizing DOM changes, you vastly improve rendering performance!
Similarly, it allows you to target animations to specific states like expanding circles as the come in and contract circles as they go out.
Here is a list of resources I plan to go through. I should be able to relearn the basics fairly quickly so that I can spend time making charts of my own. I’ll update completed items with check marks as I go through them.
Here is a minimalist responsive bar chart with quantity labels at the top of each bar and text wrapping of the food labels. It is actually responsive, it doesn’t merely scale the SVG proportionally, it keeps a fixed height and dynamically changes the width.
For simplicity I took the left scale off. All bars are proportional and are labeled anyway.
Go ahead and resize your window! This has a minimum width of about 530px because of the text labels. Any smaller than that and they are very difficult to read.
The basic HTML
The Styles
You’ll see that the axis is actually there but it is white. I found it useful to learn to draw it, but I didn’t want it so I am keeping it hidden.
The Data
The Javascript Heavy Lifting
This is where D3 really comes in.
Setting the margins, sizes, and figuring out the basic scale.
Setting the axes
Drawing the basic SVG container with the proper size and margins
Scaling the axes
Drawing the bars themselves
Adding the quantity labels to the top of each bar
This took me a while to figure out because I was originally appending to the rect element. According to the SVG specs this is illegal, so I moved on to appending them after everything else to they’d show on top. The positioning is tricky, too. I eventually found the correct variables to position it close to center. Then text-anchor: middle; sealed the deal.
Responsiveness
The general method for making D3 charts responsive is to scale the SVG down proportionally as the window gets smaller by manipulating the viewBox and preserveAspectRatio attributes. But after digging around on Github for a while, I found a fancier solution that preserves the height and redraws the SVG as the width shrinks.
Wrapping text labels
Wrapping text labels is tricky. The best solution I found is the one Mike Bostock (D3’s creator) describes. I modified it slightly to work with my chart, but the overall solution is the same.