Locating Zines: 5CollDH Fellowship Wrap-Up Post

I’ve posted over the last few months describing different facets of my project, Locating Zines. I’m hoping that this post gives a broader overview of my project. If you saw the 5CollDH symposium in April, or have seen the video of the talk I gave there, parts of this post will seem familiar!

My project, Locating Zines, seeks to digitally explore networks of zines. Zines are small, self-produced booklets or mini magazines. Zine-making can be traced back to 1930s, when it became popular among science fiction writers. Later on, zines emerged in punk movements of the 70’s. In the 1990s, zines became an important part of riot grrrl culture. Originating in Olympia, Washington in the early 1990s, riot grrrl was a musical and social movement rooted in third wave feminism that centralized girls in music and subculture scenes. Because they were cheap to create and produce, zines were accessible to a wide range of people.

Riot grrrl helped to define zines as a space for teenage girls to speak to each other and to the public about the things that they faced. Girls writing about their experiences of sexism, rape, racism, heteronormativity, and mental illness, just to name a few, gained access to communities of other zinesters experiencing similar things. It is important to note that although zine culture of the 90’s is often associated with riot grrrl, the two were not intrinsically linked. Riot grrrl as a subculture was predominantly composed of white, middle or upper middle class women. Historiography often places riot grrrl as central to girl zines of the 90’s. This erases the histories of women of color and queer people who were making zines at the same time. In my project, I look at the myriad of zine networks of the 90’s that existed within and outside of riot grrrl.

Locating Zines began last summer, when I worked as a cataloger for a Five College Digital Humanities project called Zine Scenes, a collaboration between five college faculty and librarians Alana Kumbier, Michele Hardesty, and Leslie Fields, among others. My work involved gathering metadata, which in this case means data describing the physical zines I was looking at–I recorded things like places of publication, and whether a zine was printed black and white or in color. The database was intended as a research tool, an advanced finding aid for students interacting with archival zine collections. As I looked at my spreadsheet, however, I began to ask myself what this metadata on its own could tell me.

I started off making geographic maps. Zine exchanges in the 90’s were sometimes direct physical trades, but more often, zines were sent through the mail, either between zine writers pen pals, or larger zine distributors. Because of this, a large percentage of the zines I looked at listed the writer’s address. Many zines were actually designed to become envelopes when taped shut, and had a space for a recipient’s address to be written on the back. I worked with CartoDB, a web-based cartographic mapping program to map where zines were being produced, wondering if I could find trends that would tell me something. This is a time-based map tracing zines by the locations and dates that they were published:

I soon realized, though, that I was working with zine collections donated by individuals, which meant that they were likely to follow the geographies of those individuals. For example Tinúviel, the founder of the music label Kill Rock Stars, whose zines collection comprises a large part of the Girl Zines Collection at Smith, has a lot of zines from New York and Olympia, Washington, where she had record labels. This would skew the map data more towards those areas. Basically, my sample size was too small. To do any sort of conclusive analysis on where zines in general were being produced, I’d need to look at thousands of zines.

Early on in my metadata collecting, I noticed that many zines I was looking at reviewed other zines. I started keeping track of this information, curious about what it could reveal about networks. I decided to use Twine, a text-based game-building platform, to start to chart out connections between zines. Twine is similar to a choose your own adventure novel, where each passage links to a variety of different passages depending on which answers the user chooses. I used Twine as a way to visualize zine networks. The video below shows the network map I created.

Twine is definitely not designed to map networks. My map was actually created using the back-end of Twine, the part that’s not supposed to be the final product. Essentially, according to Twine this whole map is an extensive storyboard. On this map, each square represents a different zine. This map shows 1,017 zines. For the zines I have information about, when you click on a passage you can find metadata in it. I have information about around 150 of the zines in this map. The rest are only titles–zines that other zines reviewed, that I haven’t yet found in archives.

When we zoom in on the map, zine titles are visible as well. There are also arrows between the zines, which indicate who was mentioning who. This has been helpful as a research tool in determining different types of zine networking.

Arrows on Twine help to determine how two zines are connected.
Arrows on Twine help to determine how two zines are connected.

I managed to wrangle Twine into working for me, but it wasn’t easy. Twine wasn’t designed to handle this much data, nor to produce storyboards at the size I did.Currently the application takes ten minutes to open on my computer due to the sheer size of the game file. In addition, I can’t view the entire thing at once–the application won’t zoom out far enough. In order to pan around the way I did in the video, I had to set my screen to a really high aspect ration. It’s interesting to note that zines resisted being mapped and Twine resisted doing the mapping, and yet Twine became the most effective technology I used, and the only one that functioned as both a visual aid and a research tool simultaneously.

If you want to read more about the details of what Twine is and how I worked with it,check out my blog post about it.

I also explored other, cleaner ways of mapping zines. I worked with D3.js, a javascript library of creative data visualizations, to create what’s called a force directed map. I’ll be honest, I did not start out on this fellowship as a person who was comfortable with code, and learning to work with JavaScript was terrifying. In addition, my dataset was difficult to format–I had to spend a lot of time hand-entering data. Here’s a video of the finished force map (I’m having a lot of trouble embedding it in WordPress for some reason).

For this software, it makes more sense to only map zines that are connected to two or more other zines. This means that I only charted around 160 zines. Force maps are modeled after charged subatomic particle interactions. Dragging the map around creates interesting effects. Depending on which zine you drag it by, and how connected that zine is, the map will either move a lot, or a little. One problem with this type of map is that it doesn’t distinguish the connectedness of a zine based on whether that zine mentioned a lot of other zines, or was mentioned by a lot of other zines–a really big difference. For example, from this map, it looks like the zine Caught in Flux, a music zine, was incredibly popular. In fact, hardly anyone mentioned Caught in Flux–it just reviewed a lot of other zines. On a software like Twine, directionality of a connection is a lot easier to display, because Twine is story-based in structure.

In some ways, though, D3 does help me to visualize things that Twine can’t. In D3, for example, I’m able to try to begin to chart out subsections of zine communities by using color to highlight certain titles.

In the example above, I was curious about zines that I know were written by people of color, and the ways in which they existed within networks. What I discovered is that many of the zines written by people of color that I looked at mentioned each other’s zines directly, and there were few degrees of separation between them. These zines, though often historiographically invisible, were also very connected to other zine networks of the time–zines like Bamboo Girl and You Might As Well Live were heavily influential, and served as hubs to both other zines by women of color and to the network at large.

If you want more information about how I used force maps and D3, check out my blog post about it.

I thought that D3 would help me to detangle the dataset that had become so complicated in Twine. But try as I may, D3 was no more organized, and in fact it told me less. The more I tried to force zine data into neat visualizations, the more the zines themselves pushed back against them. When trying to map by genre, I had to contend with the fact that many zines refused to be categorized. I had to make choices–is this zine more of a personal zine, or a music zine? Where does the intent of the zine writer end, and my intent begin?

And here’s the thing: in 1993, if you were actually immersed in the zine cultures I have been studying, you wouldn’t have seen any of this. With thousands of zines available to me in archives and a whole slew of digital tools available to me, I can visualize what, at the time that these zines were produced, was completely invisible. The final form of my project is the other side of the Twine map–it’s actually a game.

You start out in the “zine library”–basically, the idea is that it’s sometime in the 90’s, and you’re in a bookstore or an info shop or something, and you find a stack of zines. You’ve never had access to a zine before, but you’re enthralled, and you want to read more of them. By clicking a link, you “pick a zine up”.

So let’s say you click on Bamboo Girl. You’ll see a picture of the zine, and some of the metadata I’ve collected about it (ideally, you will have read the whole zine, but for ethical reasons I’ve chosen not to digitize any zines, and try to get the concepts of them across through metadata instead.) Anyway, here you are “reading” Bamboo Girl. You’ll see that there’s a list of other zines that are mentioned in Bamboo Girl. Let’s say I pick Girlhero. I know, from my Twine map, that there are actually two zines that mention Girlhero, Bamboo Girl, which is where we came from, and Yawp!. But I haven’t looked at a copy of Girlhero, and don’t have any metadata for it, so neither does the 1996 edition of you–and you haven’t seen my map. Maybe, you wrote a letter to the writer of Girlhero, but they never wrote you back. Maybe you look for it in the zine library but, not finding it, you give up. The object of this game is to navigate through networks without hitting any dead ends. It is intentionally frustrating. As you play, you may begin to chart out connections in your head. If you play long enough, those connections might become more elaborate.

Now, two decades after the zines I’m studying were written, I can visit archives, use computers, and make maps. But when these networks were being built, people within them, zine writers and readers, couldn’t see the whole network at once. In working with two sides of Twine for this project, I sought to replicate two sides of the experience of tracing networks.

Next year, for my Division III (senior thesis) project at Hampshire College, I plan to use data I have collected and digital maps I have made to continue to critically explore zine networks of the ’90’s. I hope to use my maps in conjunction with excerpts from zines, scholarly literature exploring zines, and my own academic writing to write a multimedia digital essay.

Without the help of a bunch of amazing people, this project would not have been possible. I want to thank members of the Zine Scenes team: Alana Kumbier, Michele Hardesty, Leslie Fields and Julie Adamo for inspiring me to do all this in the first place, and providing incredible advising throughout the project. I’m also super grateful to the 5 College Post Baccalaureate fellows, Jeffrey Moro and Mariel Nyröp, for all of the support they gave me, including teaching me how to set up a WordPress site and some fundamentals of coding, and generally talking me through pretty much every crisis I had in my project during this fellowship. I also want to thank Marisa Parham, the director of 5CollDH, whose work enables all of this to happen. Thanks also to this year’s other student fellows, Eunice Esomonu, Ott Lindstrom, Tanvi Kapoor, and Isaiah Mann—your feedback was really helpful, and your projects inspired me!

Thanks to this fellowship, I was able to travel to visit two two zine archives. During my first trip, I visited the Sallie Bingham Center at Duke University, where Kelly Wooten, the research services and collection development librarian for the Bingham Center, helped me out a ton in my research. Later on in the year, I visited the Queer Zine Archive Project in Milwaukee. I’m immensely grateful to Milo Miller and Chris Wilde, the co-founders of the QZAP, for being amazing hosts and giving me a great introduction to their collection!

Thanks also to my friends and family, who put up with a lot of me being overtired and talking a lot about confusing computer problems.

If you’re interested in future updates on Locating Zines, follow my blog: locatingzines.5collDH.org
If you’d like to play my twine game, you can do that here:
http://www.philome.la/roryminelor/the-zine-library/play

Zine Mapping in D3.js

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.
http://www.locatingzines.5colldh.org/2016/05/
www.locatingzines.5colldh.org
crawl=CC-MAIN-2019-35
50077
application/http; msgtype=response
sha1:RSPPYHVGNF3LPK2KVLRCU7FFE4RHIULK
<urn:uuid:3449e6bc-4557-4b8a-a65a-3fe0005ad208>
2019-08-22T05:07:56Z
184.154.119.130
text/html
sha1:6N33ZNHFHOF64H5O6HJU5KRQXQWNLEE3
<urn:uuid:c517a158-5c30-4b7b-84fd-431545dad561>
http://www.locatingzines.5colldh.org/2016/05/
response
<urn:uuid:ddde81f2-d01d-49d3-8b3d-1489bc895755>
isPartOf: CC-MAIN-2019-35
publisher: Common Crawl
description: Wide crawl of the web for August 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-15.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/