Zine Mapping in D3.js


Where games, archives, and zines meet, you’ll find 5CollDH Undergraduate Fellow and Hampshire College student Nora Miller hard at work. Miller’s project uses digital cartographic and network mapping tools to critically explore the physical and cultural travel of zines in the 1990s. This is Nora’s second post of three; you can click through to read the first and third installments, or read an interview with Nora by Jeffrey Moro. We also encourage you to check out their blog, locatingzines.5colldh.org!


When I began thinking about mapping the networks of zine communities, I investigated several tools alongside Twine, my favorite mapping software. The first tool I looked at, working with Michele Hardesty of Zine Scenes, was Gephi. At the time, we were completely perplexed by the software, which asked us to upload files containing our “edges” and “nodes”. Even after we figured out what those terms meant–an edge is a line connecting two nodes, or data points, in a network map–we had no idea how to produce visuals that made any sense, and eventually decided that the technology was too complicated.

this looks cool, but what does it mean???
this looks cool, but what does it mean???

The next method I investigated proved to be more fruitful, though I didn’t think so at first. I looked at a JavaScript library (basically a library of pre-written JavaScript that can be modified and customized by a user) of creative web-based data visualizations called D3. D3 features tons of different ways to visualize your data, including some seriously weird and cool ones.

Bubble My Page, for example, allows you to visualize the content of web pages in a bubble chart of word frequency. For example, here’s the google search page for cats:


This is a word frequency chart for the google search page for "cats".
This is a word frequency chart for the google search page for “cats”.

D3 has tons of visualizations like this one (and many more functional ones, too).

For my purposes, I wanted to use a force directed map. Force directed maps show connections between nodes of data using lines. The chart uses laws of electrical repulsion to create the most simplified possible network map, in which each data point, or node, is linked to those it is connected to using edges, or lines. When dragged around, the chart will reconfigure using laws of physics. I don’t quite understand how the science of it works, but it’s a useful type of visualization, and very pleasing to watch happen. To try one out yourself, check out Mike Bostock’s chart of character co-occurance in Les Misérables .

In order to create one of these maps myself, however, I needed to learn some basic things about JavaScript and HTML. I turned to Scott Murray’s book, Interactive Data Visualization For The Web. I highly recommend this book, as it made this whole process a lot less scary. Jeffrey Moro, one of the two awesome 5CollDH Post-Bacc fellows, also helped me out quite a bit with this.

Murray’s book provided me with a basic framework for creating a force map. It looked something like this:
Screen Shot 2016-05-23 at 4.22.20 PM

I’m about to explain what I did with the code, and if you actually know what you are talking about please forgive me for all of the mistakes I’m about to make, but here goes. Basically, at the top, the code calls up the script from D3 to run a force directed layout. That just means that everything else that we’re going to do is going to be working with pre-existing code that someone else wrote and put in the D3 library. Next, the code establishes some new information to send to the existing force layout. First, it asks you to set the width and height that the visualization will be on the webpage where it’s viewed–this took me some trial and error to adjust.

Then, (and here’s the exciting part!) it asks for nodes and edges. Here’s where things get really fun: Basically, the list of nodes lists every single item of data you want to have in your map. That list is automatically numbered (for some reason it starts at 0). In this section, you can also add a “group” for the node if you want, which allows you to change the color of nodes of a certain group. Next, you list the edges. Each edge has a source and a target–the node that the line originates from, and the node that it lands on. Instead of calling the sources and targets by name, they’re called by the number they’ve been assigned. So in the example above, when the edge “source: 0, target: 1” is called, it really means that Adam is connected to Bob. You can connect the same source to multiple targets.

So my first step was to take all of my data about zines and to organize it into spreadsheets that would be translatable into this format. I actually used Twine as a tool for doing this (see my past posts on Twine). I basically made a copy of the giant Twine map I had made of all of the zines I’ve looked at for this project, and got rid of all of the zines that were only mentioned by one zine. I did this mostly to spare myself the headache of transcribing over 1,000 data points, and 1,209 links into the edges and nodes format. So the only zines left on this new map were zines I had primary data on (around 100 or so, I think) and zines that had been mentioned by two or more other zines. I used find and replace on a word document to find all of the zine titles I had, numbered them starting with zero in a spreadsheet, and then exported the text to a new plain text document, where I then used an amazing tool called Text Mechanic to help me format in various brackets and whatnot. With that, I had my nodes file. Then, I went back to my original zine data spreadsheets, where I had originally charted zine mentions, cross referenced it with my new and improved Twine map, because many zines that were mentioned in the spreadsheet hadn’t made the “mentioned by two or more other zines” list, and one by one hand-entered source and target data into a spreadsheet.
It looked something like this:
Screen Shot 2016-05-23 at 4.40.55 PM


I bet this is boring just to read–doing it was no picnic, either. I’m sure, in retrospect, that had I formatted my data better as I was collecting it, and had I not so stubbornly clung to Twine as my main mapping tool, I might not have had to hand-enter as much data, but I’m a poet, not a computer whiz, so this was how it went. Anyway, after I’d hand entered 311 connections between zines, I used a combination of Text Mechanic and find and replace again to get it into { source: , target: } format. Then I plopped it all into the framework Scott Murray’s book had given me, and boom! I had a force map.

Later on, I made a bunch of visual adjustments. I won’t get into how those adjustments worked, but I added tooltips, which basically gives a user information about a data point when they mouse over the node, and then fades out when they mouse out.

Here is a video of the force map I made (I’m having a bit of trouble embedding my code into WordPress at the moment).


As you can see, I also added color-coded genres to my map. I did this by adding them into the list of nodes, like so:
var dataset = {
nodes: [
{name: "Wrecking Ball", genre: "personal" },
{name: "Ablaze!", genre: "music" },
{name: "Alien", genre: "personal" },
{name: "Adventure Playground", genre: "music"}

I organized different genres by different colors:
Screen Shot 2016-05-23 at 5.20.55 PM

That’s one neat thing about force maps–you can directly visualize and single out different parts of a dataset. For example, I was curious about networks of zines written by people of color, and how those networks were structured. I highlighted zines who I knew were written by people of color.


Something I really like about the force layout is its interactivity. When you click on points on a force directed map, you can drag them around the screen. This dragging simulates more than just physical forces–it simulates the impact a zine has on the networks surrounding it. Some zines, when clicked on and dragged, don’t move the map very much. These zines are less connected to other zines in the map, and really only move the zines directly connected to them. Other zines are more central hubs, and they drag the body of the map further. Unfortunately, this dragging effect is seriously flawed, because it presumes a lot about directionalities of connections. Because force maps don’t, by default, differentiate between source and target–there’s a line drawn, not an arrow, so it’s impossible to tell if a zine mentioned another zine, or was mentioned by another zine. On the force map I made, the music zine Caught in Flux appears to be heavily popular and influential, when in fact most of the connections emanating from it are zines that Caught in Flux mentioned, not the other way around. Under my current methods of measuring connectivity, force maps don’t fully tell the story that my Twine map, which has arrows, does. In the following image from my Twine map, you can see that the zine Circumspect mentions several other zines, and that the zine Wrecking Ball is mentioned by two other zines. On a force map, this would not be apparent.
Screen Shot 2016-03-11 at 1.56.28 PM

At the end of the day, the process of using the force map felt, in a way, like wrestling a dataset that already resisted me on every level into a format designed to smooth that resistance out. And in some ways, that smoothing out worked. The maps I made are clean and neat and they make sense. But in many ways, the resistance of zines, the ways in which they renamed themselves, or wouldn’t adhere to a genre, the ways in which networks were much more complicated than who was mentioning who–you don’t see any of that when you look at a map like this. To create a map is to, in some ways, make an argument for a definitive truth of the thing that you are mapping. On a topographical map of a mountain range, say, the map should ideally provide precise data about the geographies of those mountains. The trouble is that zines resisted prescriptive rules of what published material should be on every level. To flatten their networks into definitive visualizations would lose not only the important resistances that shaped zines as entities, but also would be inaccurate. In some ways, I wanted my maps to help me envision the impossibility of doing this type of mapping. The force map looks complete. When I look at it, I think that it tells me something definitive. It doesn’t make me ask if that thing is true. In this way, this map will never be accurate or complete.



Nora Miller
Follow Nora Miller:

Nora is a Division II student at Hampshire College and a 2015-2016 Undergraduate Fellow with 5CollDH.

Nora Miller
Latest posts from