So far, the discussion has been mostly around the characters of the Avengers, at a collective level. Lots of data is available about each individual character, as well – for example we can look at any Avenger and see every appearance they’ve made over the last 50 years. Here’s Captain America’s record number of appearances:

And Iron Man, who’s not too far behind:

An my personal favourite, Hawkeye:

In each of these graphics, I’ve marked the issues where the character has returned after a significant absence. We also, of course, see their first appearances (Hawkeye’s being in issue #16th, ‘The Old Order Changeth‘). You can see a pile of other Avengers’ ‘appearance maps’ in this Flickr Set – if there’s another character you’d like to see, let me know.

For the first time here we can see that we can gets some information about the individual issues past the issue number. We can look at the title, the characters who appeared in the issue, the geographic locations involved in the issue (from Alaska to the Kree homeworld), and more (the Comic Vine API offers the possibility of concepts to be linked with individual issues as well, but this information hasn’t been well-populated in the wiki).

One thing that you might have noticed from the graphics so far is that there are a lot of spikes – issues in which a lot of Avengers characters are present. The most spectacular example of these ‘party issues’ is Volume 3, #10, ‘Pomp & Pageantry”, in which a whopping 119 Avengers appeared! Here are all of these party issues since 1963:

We can see that these heaps-of-heroes issues are a pretty new phenomenon – and also that the current Avengers writer, Brian Michael Bendis, LOVES a party. He’s written lots of issues with more than 30 avengers, and even a couple with more than 50.

Which brings us nicely into a discussion about creators. So far we’ve been focused mainly on fictional characters – what about the real people that made these comic books? Like, for example, Sam Rosen, and Artie Simek:

Mr. Rosen and Mr. Simek hand-lettered all of the dialogue, and drew all of the word balloons for most of the first 50 issues of the Avengers, most often alternating back and forth, issue to issue. They’re part of a group of about 7 letterers who have been responsible for most of the Avengers typography:

Similarly, we can see that there are about 10 people who have been editors on the series for long stretches of time:

You don’t see nearly this kind of consistency with pencillers:

Or inkers:

I wondered after getting a look at how these creators were involved in the history of the series, if perhaps they (particularly the writers & editors) might be responsible for some of the content decisions that I examined in the last. For example, are there certain editors or writers who included more female characters in their books?

I overlaid a heat map onto the creator maps just saw above, with red stripes to indicate a high number of female characters and blue/green stripes to indicate the boys-club issues. Here are all of the editors again:

And all of the writers:

While it probably begs for some statistical analysis, it does seem that the gender balance gets a boost when Jim Shooter takes up the series in the early 70s. Indeed, he’s in charge during the high water mark of Avengers feminism in 1983-1984, a level which the series never gets back to.

We can see similar correlations for the numbers of gods/eternals per issue:

Or robots/synthezoids/androids per issue:

From these we can see that while Brian Michael Bendis DOES like to party, he DOESN’T particularly like robots, and definitely isn’t a big fan of the gods.

Besides that, what have we learned from this two-part data-exploration of the Avengers? You’ve probably learned that I have too much time on my hands. I’ve learned that I really need to get my old collection out of storage and revisit some of these excellent stories. I’ve also learned that, if there’s one form of punctuation that defined the silver age of comics… it’s the ellipsis. So, to finish us off, here’s a medley of the 53 ellipsified issues in the history of Earth’s Mightiest Heroes:

(You might see a blank box here, in which case you might want to try viewing the page in Chrome).

Last week, I was pointed by Santiago Ortiz to this excellent chart made by Theo Zaballos, in which he plots the relative interestingness in Avengers characters from the animated series, over time. It’s a fantastic example of the power of visualization to help us understand things – or, put another way, the power of building systems to think about systems. It’s also a reminder that visualization doesn’t always need to be pitted against huge, world-changing tasks – it can be useful in exploring small, fun, even seemingly frivolous things.

I started reading comics in 1985 (coincidentally, when I was 10). For years, I’d visit the comic shop every Wednesday, and pick up a stack of titles – and The Avengers was a real mainstay on my list. I was always more of a reader than a collector; my longboxes were full of dog-eared issues from incomplete series, which I revisited over and over again until the stories imprinted themselves in my brain.

There’s a huge storehouse of mythology, cultural touchstones, and real historical events contained in the pages of the 570 issues of the Avengers.

Inspired by Theo, and using comicvine.com’s API, I’ve put together a few datasets and some tools that I can use to visually explore some of this leotarded history.

The Avengers has been published pretty much continuously since 1963. Here are the covers of all 570 issues:

Now, you might be aware of a little, low budget art-house movie that’s being released tomorrow about this particular group of costumed heroes. That movie features 5 avengers – Captain America, Iron Man, Thor, Hawkeye, and Black Widow. But did you know there were 127 more Avengers? You may know that the Avengers were created by Stan Lee and Jack Kirby, but you might be surprised to hear that there were 184 other people who invented Avengers characters. In total, there have been 581 men and women who written, edited, pencilled, inked, colored, lettered, and otherwise created at least one issue of the Avengers.

Let’s start with a look at those characters. My first thought was to use images of the characters in my visualizations, but while the Comic Vine API provides images in all kinds of sizes, the styles of drawing are so varied that it ended up not holding together. Instead, then, I built a small tool that let me go through those characters and pick three colours that I thought represented them the best (everybody gets a shield!). Here are all of the Avengers in an overlapped plot that doesn’t really tell us much, but gives you an idea of what these icons look like:

These character icons can be drawn at any size, and give us a nice way to plot the characters that isn’t just dots or boxes. Here’s all of the Avengers again, this time plotted by their number of appearances:

Below Captain America is a cluster of the most consistent Avengers – Iron Man, Vision, Scarlet Witch, Thor, Hawkeye, Wasp, and Henry Pym (aka Ant Man). That blue and grey dot trailing just behind is Jarvis, the Avengers’ butler – who also happens to be an honorary member of the team.

Using those same shield icons, but sorting by issue so that characters in an issue together form a radial line, here is every appearance of ever Avengers character in every issue:

It’s not too helpful, but we can use this same system, and filter it by any number of criteria. For example, let’s look at just first appearances of Avengers:

You can see the same graphic in a timeline form here:

I built a little tool to let me assign three colours to each Avenger, so they’re all represented by small spheres (now would be a good time to look at the full resolution version of that image – a good strategy for everything I’m going to put in this post) We can see a big cluster of major Avengers appearing in the first few episodes, with some other big names coming in the next few years (Vision, the Avenger with the 3rd most appearances in issues, doesn’t come along until #57). While there are a couple of major additions along the way (She-Hulk & Photon in 1982), we can see that the cast of characters for the team is defined pretty early.

One of the first things that I was interested in was the gender balance in the Avengers over time. While there have been women on the team since the beginning (Janet Van Dyne, aka The Wasp, appears in issue #1), has this changed or increased over the 50 year span of the series?

Let’s have a look:

You’ll notice that the Wasp (in yellow), and the Scarlet Witch (in red), pretty much hold the fort for the female Avengers until the late 70s, at which time variety and frequency of female characters increases. There are some dips – 1990 to 1992, and 2005 to 2007, and overall the female ratio at the Avengers mansion peaks in the 1980s and never quite gets back up to that level again.

Of course, there are many other categorizations of comic characters that we can make aside from gender. I mentioned Vision before, who is a robot (OK, OK, he’s a synthezoid). How have superheroes of the electronic persuasion fared amongst Earth’s Mightiest Heroes?

I’m glad you asked:

Here we see some much more interesting patterns. Robots are big from the late 60s to the early 1990s, after which they disappear. There’s a robot renaissance of sorts from 1990 to 2005, but again they lose density (see what I did there, Avengers fans?).

We can do the same thing with Gods, and Eternals (if you don’t know the difference, ask your local comic shop clerk):

Again, there is some real patchiness here. Now, the clever ones among you might be wondering if these patterns are tied to historical periods, or if they are linked to the preferences of specific writers, editors, or artists. Is that crowded patch of Gods in 1985 due to a cultural fascination with myth? Or do Mark Gruenwald & Jim shooter just really, really like Thor? Great questions, and ones that I’ll take a look at Part 2 of this post.

This week-long dig through Avengers data has been fascinating. Even as an Avengers fan, it’s been surprising to see the depth and richness of content that finds its way into the pages of every issue and volume. As I’ve been working, I’ve also been reading a lot about the various people – inkers, letterers, writers, who have built the Avengers story over time. It has been a good reminder, particularly in the wake of a blockbuster film, that myths are rarely formed by individuals.

Finally, it should give anyone fearing a shortage of Avengers storylines and characters for possible sequels some reassurance – 5 down, 127 to go. (Mr. Whedon, if you’re looking for a researcher, you know where to find me.)

‘Nuff said. (For now.)

Most of us probably know that the loom played a part in the early days of computing – the Jacquard loom was the first machine to use punch cards, and its workings were very influential in the early design of programmable machines (In my 1980s basement this history was actually physically embodied; sitting about 10 feet away from my mother’s two floor looms, on an Ikea bookself, sat a box of IBM punch cards that we mostly used to make paper airplanes out of). But how many of us know how a loom actually works? Though I have watched my mother weave many times, it didn’t take long at the start of this project to realize that I had no real idea how the binary weaving patterns called ‘drawdowns‘ ended up making a pattern in a textile.

To teach myself how this process actually happened, I built a functional software loom, where I could see the pattern manifest itself in the warp and weft (if you have Chrome you can see it in action here – better documentation is coming soon). This gave me a kind of sandbox which let me see how typical weaving patterns were constructed, and what kind of problems I could expect when I started to write my own. And run into problems, I did. My first attempts at generating patterns were sloppy and boring (at best) and the generative methods I was applying weren’t very successful. Enter Ralph E. Griswold.

Ralph Griswold was a pioneering computer scientist, best known for developing the string programming language SNOBOL. He spent a decade at Bell Labs, studying non-numerical computation, and went on to become Regents’ Professor at the University of Arizona. After this illustrious career in computing, he shifted his attention to the mathematics of weaving. Mr. Griswold died in 2006, but he left behind a huge archive of resources for weavers and curious learners, including academic papers on pattern generation using cellular automata.

The first successful pattern possibilities for Infinite Weft came from applying and modifying the techniques in the paper. I built a simple interface in which I could advance the automata generation by generation, and switch between a set of very simple rules (courtesy of John von Neumann). Here’s what a sample pattern generated from these von Neumann automata looks like on the software loom:

And here’s a sample, woven on a table loom with black & white yarn to make the pattern clear:

While these techniques produce fairly satisfactory results, the automata themselves tended to repeat after not too many generations – while you can alternate between rules, and start with different ‘seed’ patterns, and adjust the threading of the loom to get a variety of finished patterns, the systems themselves would inevitably repeat. What about a truly infinite weft?

As it turns out, there are some cellular automata that are non-repeating. Given any generation N, the result of the next generation, N+1, can’t be predicted from the outcomes that have happened before. Could I apply such an automata to generate an infinite ‘pattern’? Well, I gave it a try, and the results look promising. Here is a look at a pattern generated using Wolfram’s Rule 30, a (quite possibly) universal cellular automaton:

And a similar pattern, hand-woven by my mother:

Now we get into some pretty interesting conceptual territory. In theory, a long enough stretch of this woven textile would be Turing-complete – a computable fabric. Embedded somewhere in the pattern would be instructions to solve any conceivable problem. Past the math, this system also lets us challenge what we think of as a pattern, in a fabric context (after all, this pattern has really no pattern at all).

This project is still very much a work in progress – this blog post is a peak into the process and chance to get some of my thoughts into writing. The next obvious step is to finalize work on the pattern generation, and get some large-scale textile woven from my mother’s ‘real loom’, which is a 16-harness floor loom (for this we’re going to need a computerized dobby head, which is a bit of an investment). I would also love to see other weavers outputting sections of this ‘infinite’ weft – please get in touch if you have a loom and would like to try weaving a section.

Source code for Infinite Weft is available in a public GitHub repository here.

And, as always, please don’t hesitate to leave a comment if you have any questions or suggestions.

Last year, I released a video visualization of the 1236 exoplanets identified by the NASA’s Kepler mission. Since then, there have been another 1091 candidates identified, and I thought it’d be a good time to update my visualization – and release the source code.

So, here it it: http://github.com/blprnt/Kepler-Visualization

I’ve tried to comment the code as well as possible – and the sketch overall is fairly simple. You will, of course, need Processing to get it running, as well as Karsten Schmidt’s esssential toxiclibs.

I won’t give the whole talk away, since you can watch it for yourself below. As always, I’d love to hear feedback/questions/ridicule – you can leave a comment below, or join in on this already feisty thread on Google+.

Oh, and Batman. And Wayne Gretzky.

You can watch the video below (it’s about 50 minutes). As always, questions, feedback and bizarre non-sequiturs are welcome.

These days my spare time is typically measured in seconds – so I took advantage of a rare free morning today to put together a very simple list of the some of the work that I have built since the beginning of 2009. You can find a link to this list at the top of the site – or you can just click here. As always, comments and suggestions are encouraged and appreciated.

Accessing information from the Twitter API with Processing is (reasonably) easy. A few people have sent me e-mails asking how it all works, so I thought I’d write a very quick tutorial to get everyone up on their feet.

We don’t need to know too much about how the Twitter API functions, because someone has put together a very useful Java library to do all of the dirty work for us. It’s called twitter4j, and you can download it here. We’ll be using this in the first step of the building section of this tutorial.

1. Authentication

Here’s the tricky part. In the olden days, Twitter used to be happy with us sending it a username and password pair for authentication. Now, all of the Twitter API functionality uses an oAuth system, which allows people to authenticate applications through a login at twitter.com (so that developers never see the user’s login information).

That’s pretty good from a security standpoint, but it makes our job a little bit harder. Now, instead of just needing a short username and password, we need FOUR things to authenticate our sketch: A consumer key & secret, and an access token & secret. You can get all 4 of these things from the twitter developer page.

1. Visit https://dev.twitter.com/ and login with your twitter username and password
2. Click on the ‘Create an app’ button at the bottom right
3. Fill out the form that follows – you can use temporary values (like “Jer’s awesome test application”) for the first three fields.
4. Once you’ve agreed to the developer terms, you’ll arrive at a page which shows the first two of the four things that we need: the Consumer key and the Consumer secret. Copy and paste these somewhere so you have them ready to access.

5. To get the other two values that we need, click on the button that says ‘Recreate my access token’. Copy and paste those two values (Access token and Access token secret) so that we have all four in the same place.

2. Building

1. Open up a new Processing sketch.
2. Import the twitter4j library. In your downloaded twitter4j files, you’ll find the core .jar in a directory called ‘lib’. You’re looking for a file called something like ‘twitter4j-core-2.2.5.jar’. We can add this to our sketch by simply dragging the twitter4j-core-2.2.5.jar file onto your sketch window. If you want to check, you should now see this file in your sketch folder, inside of a new ‘code’ directory.
3. The first thing we’ll do in our new file is to store the credentials that we gathered in the first part of this tutorial into a ConfigurationBuilder object (this is a built-in part of the twitter4j library):

** Don’t use the credentials below – these are fake ones that I made up – use the ones that you copy & pasted in steps 4 & 5 above

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setOAuthConsumerKey("lPFSpjBppo5u4KI5xEXaQ");
cb.setOAuthConsumerSecret("SYt3e4xxSHUL1gPfM9bxQIq6Jf34Hln9T1q9KGCPs");
cb.setOAuthAccessToken("17049577-Yyo3AEVsqZZopPTr055TFdySop228pKKAZGbJDtnV");
cb.setOAuthAccessTokenSecret("6ZjJBebElMBiOOeyVeh8GFLsROtXXtKktXALxAT0I");

4. Now we’ll make the main Twitter object that we can use to do pretty much anything you can do on the twitter website – get status updates, run search queries, find follower information, etc. This Twitter object gets built by something called the TwitterFactory, which needs our configuration information that we set above:

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setOAuthConsumerKey("lPFSpjBppo5u4KI5xEXaQ");
cb.setOAuthConsumerSecret("SYt3e4xxSHUL1gPfM9bxQIq6Jf34Hln9T1q9KGCPs");
cb.setOAuthAccessToken("17049577-Yyo3AEVsqZZopPTr055TFdySop228pKKAZGbJDtnV");
cb.setOAuthAccessTokenSecret("6ZjJBebElMBiOOeyVeh8GFLsROtXXtKktXALxAT0I");

Twitter twitter = new TwitterFactory(cb.build()).getInstance();

5. Now that we have a Twitter object, we want to build a query to search via the Twitter API for a specific term or phrase. This is code that will not always work – sometimes the Twitter API might be down, or our search might not return any results, or we might not be connected to the internet. The Twitter object in twitter4j handles those types of conditions by throwing back an exception to us; we need to have a try/catch structure ready to deal with that if it happens:

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setOAuthConsumerKey("lPFSpjBppo5u4KI5xEXaQ");
cb.setOAuthConsumerSecret("SYt3e4xxSHUL1gPfM9bxQIq6Jf34Hln9T1q9KGCPs");
cb.setOAuthAccessToken("17049577-Yyo3AEVsqZZopPTr055TFdySop228pKKAZGbJDtnV");
cb.setOAuthAccessTokenSecret("6ZjJBebElMBiOOeyVeh8GFLsROtXXtKktXALxAT0I");

Twitter twitter = new TwitterFactory(cb.build()).getInstance();
Query query = new Query("#OWS");

try {
  QueryResult result = twitter.search(query);
}
catch (TwitterException te) {
  println("Couldn't connect: " + te);
};

5. This code is working – but we haven’t done anything with the results. Here, we’ll set the results per page parameter for the query to 100 to get the last 100 results with the term ‘#OWS’ and spit those results into the output panel:

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setOAuthConsumerKey("lPFSpjBppo5u4KI5xEXaQ");
cb.setOAuthConsumerSecret("SYt3e4xxSHUL1gPfM9bxQIq6Jf34Hln9T1q9KGCPs");
cb.setOAuthAccessToken("17049577-Yyo3AEVsqZZopPTr055TFdySop228pKKAZGbJDtnV");
cb.setOAuthAccessTokenSecret("6ZjJBebElMBiOOeyVeh8GFLsROtXXtKktXALxAT0I");

Twitter twitter = new TwitterFactory(cb.build()).getInstance();
Query query = new Query("#OWS");
query.setRpp(100);

try {
  QueryResult result = twitter.search(query);
  ArrayList tweets = (ArrayList) result.getTweets();

  for (int i = 0; i < tweets.size(); i++) {
    Tweet t = (Tweet) tweets.get(i);
    String user = t.getFromUser();
    String msg = t.getText();
    Date d = t.getCreatedAt();
    println("Tweet by " + user + " at " + d + ": " + msg);
  };
}
catch (TwitterException te) {
  println("Couldn't connect: " + te);
};

It seems stupid to come all of this way without doing something visual, so let’s throw all of the words that we see in the tweets onto the screen, quick and dirty, at random positions. The following code takes our existing instructions and puts them into the standard Processing setup/draw enclosures so that we can do some animation over time:

//Build an ArrayList to hold all of the words that we get from the imported tweets
ArrayList<String> words = new ArrayList();

void setup() {
  //Set the size of the stage, and the background to black.
  size(550,550);
  background(0);
  smooth();

  //Credentials
  ConfigurationBuilder cb = new ConfigurationBuilder();
  cb.setOAuthConsumerKey("lPFSpjBppo5u4KI5xEXaQ");
  cb.setOAuthConsumerSecret("SYt3e4xxSHUL1gPfM9bxQIq6Jf34Hln9T1q9KGCPs");
  cb.setOAuthAccessToken("17049577-Yyo3AEVsqZZopPTr055TFdySop228pKKAZGbJDtnV");
  cb.setOAuthAccessTokenSecret("6ZjJBebElMBiOOeyVeh8GFLsROtXXtKktXALxAT0I");

  //Make the twitter object and prepare the query
  Twitter twitter = new TwitterFactory(cb.build()).getInstance();
  Query query = new Query("#OWS");
  query.setRpp(100);

  //Try making the query request.
  try {
    QueryResult result = twitter.search(query);
    ArrayList tweets = (ArrayList) result.getTweets();

    for (int i = 0; i < tweets.size(); i++) {
      Tweet t = (Tweet) tweets.get(i);
      String user = t.getFromUser();
      String msg = t.getText();
      Date d = t.getCreatedAt();
      println("Tweet by " + user + " at " + d + ": " + msg);

      //Break the tweet into words
      String[] input = msg.split(" ");
      for (int j = 0;  j < input.length; j++) {
       //Put each word into the words ArrayList
       words.add(input[j]);
      }
    };
  }
  catch (TwitterException te) {
    println("Couldn't connect: " + te);
  };
}

void draw() {
  //Draw a faint black rectangle over what is currently on the stage so it fades over time.
  fill(0,1);
  rect(0,0,width,height);

  //Draw a word from the list of words that we've built
  int i = (frameCount % words.size());
  String word = words.get(i);

  //Put it somewhere random on the stage, with a random size and colour
  fill(255,random(50,150));
  textSize(random(10,30));
  text(word, random(width), random(height));
}

** Extra-coolness: see this example working in the browser with Processing.js!!

That’s it! This example is very simple, but it’s the bare bones of what you need build a project which connects Twitter through Processing.

Shortly I’ll add another post which shows how to use Processing with the Twitter Streaming API, so that we can deal with large volumes of tweets over time.

Good luck!

Near the end of this summer, I was asked by the publishers of Popular Science magazine to produce a visualization piece that explored the archive of their publication. PopSci has a history that spans almost 140 years, so I knew there would be plenty of material to draw from. Working with Mark Hansen, I ended up making a graphic that showed how different technical and cultural terms have come in and out of use in the magazine since its inception.

The graphic is anchored by a kind of molecular chain – decade clusters in turn contain year clusters. Every atom in these year clusters is a single issue of the magazine, and is shaded with colours extracted from the issue covers via a colour clustering routine. The size of the issue-atoms is determined by the number of words in each issue.

Surrounding this chain are about 70 word frequency histograms showing the issue-by-issue usage of different terms (like ‘software’ or ‘bakelite’). I used a simple space-filling algorithm to place these neatly around the molecule chain, and to stack them so that one histogram begins shortly after another ends. This ended up resulting in some interesting word chains that show how technology has progressed – some that make sense (microcomputer to e-mail) and some what are more whimsical (supernatural to periscope to datsun to fax).

Picking out interesting words from all of the available choices (pretty much the entire dictionary) was a tricky part of the process. I built a custom tool in Processing that pre-visualized the frequency plots of each word so that I could go through many, many possibilities and identify the ones that would be interesting to include in the final graphic. This is a really common approach for me to take – building small tools during the process of a project that help me solve specific problems. For this visualization, I actually ended up writing 4 tools in Processing – only one of which contributed visually to the final result.

My working process is riddled with dead-ends, messy errors and bad decisions – the ‘final’ product usually sits on top of a mountain of iterations that rarely see the light of day. To give a bit of insight into the steps between concept and product, I’ve put together a Flickr set showing 134 process images that came out of the development of this visualization. Here are a few images from that set:

Rough beginning

Early molecular chain

Denser chain with test ‘word span’

A diversion

Near-final

Lost in the image records are the steps that involved the data – and there were a lot of them. The archive was text that came from an OCR (optical character recognition) process, and was incredibly messy. To make matters worse, the file names for each issue were machine-generated and didn’t tie to the actual date order of the documents. A great deal of our time was spent cleaning up this data, and compiling customized datasets (many of which never ended up getting used).

While the final graphic is pictured above, it looks much better in print – so make sure you get a copy! Better yet, you can order a poster-sized version of the graphic by clicking here.

[The above graphic is an interactive 3D bar graph. If you can't see it, it's probably because your browser sucks can't render WebGL content. Maybe try Chrome or Firefox?]

Ben Fry and Casey Reas, the initiators of the Processing project, announced at the Eyeo Festival that a new version of Processing, Processing 2.0, will be released in the fall (VIDEO). This 2.0 release brings a lot of really exciting changes, including vastly improved 3D performance, and a brand-new high-performance video library. Perhaps most interesting is the addition of publishing modes – Processing sketches can now be published to other formats other than the standard Java applet. The mode that is going to cause the most buzz around the interweb is Javascript mode: yes, Processing sketches can now be published, with one click, to render in pretty much any web browser. This is very exciting news for those of us who use Processing for data visualization – it means that our sketches can reach a much broader audience, and that the visual power of Processing can be combined with the interactive power of Javascript.

While preview releases of Processing 2.0 will be available for download very soon, you don’t have to wait to experiment with Processing and Javascript. The upcoming JS mode comes thanks to the team behind Processing.js, and we can use it to build sketches for the browser right now.

To get started, you can download this sample file. When you unzip the file, you’ll see a directory with three files – the index.html page, processing.js, and our sketch file, called tutorial.pde. If you open the sketch file in a text editor, you’ll see something like this:

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);
}

void draw() {
  //instructions in here happen over and over again
}

If you’re a Processing user, you’ll be familiar with the setup and draw enclosures. If you’re not, the notes inside of each one explain what’s going on: when we run the sketch, the size is set to 500px by 500px, and the background is set to black. Nothing is happening (yet) in the draw enclosure.

You can see this incredibly boring sketch run if you open the index.html file in your browser (this will work in Firefox and Safari, but not in Chrome due to security settings).

Processing.js is a fully-featured port of Processing – all of the things that you’d expect to be able to do in Processing without importing extra libraries can be done in Processing.js. Which, quite frankly, is amazing! This means that many of your existing sketches will run, with no changes, in the browser.

Since this is a data visualization tutorial, let’s look at a simple representation of numbers. To keep it simple, we’ll start with a set of numbers: 13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9 35.1, 34.3. (These numbers are obesity percentages in the U.S. population, between the 1960s and the present – but we’re really going to use them without context).

Typically, if we were to put these numbers into a Processing sketch, we’d construct an array of floating point numbers (numbers with a decimal place), which would look like this:

float[] myNumbers = {13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3};

However, we’re not in Java-land anymore, so we can make use of Javascript’s easier syntax (one of the truly awesome things about Processing.js is that we can include JS in our sketches, inline):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

Our .pde file, then, looks like this:

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);
}

void draw() {
  //instructions in here happen over and over again
}

Now that we have our helpful list of numbers (called, cleverly, ‘numbers’), we can access any of the numbers using its index. Indexes in Processing (and Javascript) are zero-based, so to get the first number out of the list, we’d use numbers[0]. To get the fourth one, we’d use numbers[3]. Let’s use those two numbers to start doing some very (very) simple visualization. Indeed, the first thing we’ll do is to draw a couple of lines:

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  //Draw two lines
  stroke(255);
  line(0, 50, numbers[0], 50);
  line(0, 100, numbers[4], 100);
}

void draw() {
  //instructions in here happen over and over again
}

OK. I’ll admit. That’s a pretty crappy sketch. But, we can build on it. Let’s start by making those lines into rectangles:

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  //Draw two lines
  stroke(255);
  rect(0, 50, numbers[0], 20);
  rect(0, 100, numbers[4], 20);
}

void draw() {
  //instructions in here happen over and over again
}

At this point, I’m going to introduce my very best Processing friend, the map() function. What the map() function allows us to do is to adjust a number that exists in a certain range so that it fits into a new range. A good real-world example of this would be converting a number (0.5) that exists in a range between 0 and 1 into a percentage:

50 = map(0.5, 0, 1, 0, 100);

We can take any number inside any range, and map it to a new range. Here are a few more easy examples:

500 = map(5, 0, 10, 0, 1000);
0.25 = map(4, 0, 16, 0, 1);
PI = map(180, 0, 360, 0, 2 * PI);

In our sketch, the list of numbers that we’re using ranges from 13.4 to 34.3. This means that our rectangles are pretty short, sitting in the 500 pixel-wide sketch. So, let’s map those numbers to fit onto the width of our screen (minus 50 pixels as for a buffer):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  //Draw two rectangles
  rect(0, 50, map(numbers[0], 0, 34.3, 0, width - 50), 20);
  rect(0, 100, map(numbers[4], 0, 34.3, 0, width - 50),  20);
}

void draw() {
  //instructions in here happen over and over again
}

Two bars! Wee-hoo! Now, let’s use a simple loop to get all of our numbers on the screen (this time we’ll use the max() function to find the biggest number in our list):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  for (var i = 0; i < numbers.length; i++) {
    //calculate the width of the bar by mapping the number to the width of the screen minus 50 pixels
    var w = map(numbers[i], 0, max(numbers), 0, width - 50);
    rect(0, i * 25, w, 20);
  }
}

void draw() {
  //instructions in here happen over and over again
}

We’re still firmly in Microsoft Excel territory, but we can use some of Processing’s excellent visual programming features to make this graph more interesting. For starters, let’s change the colours of the bars. Using the map() function again, we’ll colour the bars from red (for the smallest number) to yellow (for the biggest number):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  for (var i = 0; i < numbers.length; i++) {
    //calculate the amount of green in the colour by mapping the number to 255 (255 red &amp; 255 green = yellow)
    var c = map(numbers[i], min(numbers), max(numbers), 0, 255);
    fill(255, c, 0);
    //calculate the width of the bar by mapping the number to the width of the screen minus 50 pixels
    var w = map(numbers[i], 0, max(numbers), 0, width - 50);
  	rect(0, i * 25, w, 20);
  }
}

void draw() {
  //instructions in here happen over and over again
}

This process of mapping a number to be represented by a certain dimension (in this case, the width of the bars along with the colour) is the basic premise behind data visualization in Processing. Using this simple framework, we can map to a whole variety of dimensions, including size, position, rotation, and transparency.

As an example, here is the same system we saw above, rendered as a radial graph (note here that I’ve added a line before the loop that moves the drawing point to the centre of the screen; I’ve also changed the width of the bars to fit in the screen):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500);
  background(0);

  //move to the center of the sketch before we draw our graph
  translate(width/2, height/2);
  for (var i = 0; i < numbers.length; i++) {
    //calculate the amount of green in the colour by mapping the number to 255 (255 red &amp; 255 green = yellow)
    var c = map(numbers[i], min(numbers), max(numbers), 0, 255);
    fill(255, c, 0);
    //calculate the width of the bar by mapping the number to the half the width of the screen minus 50 pixels
    var w = map(numbers[i], 0, max(numbers), 0, width/2 - 50);
  	rect(0, 0, w, 20);
  	//after we draw each bar, turn the sketch a bit
  	rotate(TWO_PI/numbers.length);
  }
}

void draw() {
  //instructions in here happen over and over again
}

So far we’ve been keeping things very simple. But the possibilities using Processing and Javascript are really exciting. It’s very easy to add interactivity, and it’s even possible to take advantage of Processing’s 3D functionality in the browser.

Here’s our numbers again, rendered in 3D (note the change to the size() function), with the rotation controlled by the mouse (via our new friend the map() function):

var numbers = [13.4, 14.5, 15.0, 23.2, 30.9, 31.3, 32.9, 35.1, 34.3];

void setup() {
  //instructions in here happen once when the sketch is run
  size(500,500,P3D);
  background(0);

}

void draw() {
  //instructions in here happen over and over again
  background(0);
  //turn on the lights so that we see shading on the 3D objects
  lights();
  //move to the center of the sketch before we draw our graph
  translate(width/2, height/2);
  //Tilt about 70 degrees on the X axis - like tilting a frame on the wall so that it's on a table
  rotateX(1.2);
  //Now, spin around the Z axis as the mouse moves. Like spinning that frame on the table around its center
  rotateZ(map(mouseX, 0, width, 0, TWO_PI));
  for (var i = 0; i < numbers.length; i++) {
    //calculate the amount of green in the colour by mapping the number to 255 (255 red &amp; 255 green = yellow)
    var c = map(numbers[i], min(numbers), max(numbers), 0, 255);
    fill(255, c, 0);
    //calculate the height of the bar by mapping the number to the half the width of the screen minus 50 pixels
    var w = map(numbers[i], 0, max(numbers), 0, width/2 - 50);
    //move out 200 pixels from the center
  	pushMatrix();
  		translate(200, 0);
  		box(20,20,w);
  	popMatrix();
  	//after we draw each bar, turn the sketch a bit
  	rotate(TWO_PI/numbers.length);
  }
}

Thirty lines of code, and we have an interactive, 3D data visualization (you can see this sketch running inline in the header). Now, I understand that this isn’t the best use of 3D, and that we’re only visualizing a basic dataset, but the point here is to start to imagine the possibilities of using Processing with Javascript in the browser.

For starters, Javascript lets us very easily import data from any JSON source with no parsing whatsoever – this means we can create interactive graphics that load dynamic data on the fly (more on this in the next tutorial). On top of that, because we can write Javascript inline with our Processing code, and we can integrate external Javascript functions and libraries (lie JQuery) to our sketches, we can incorporate all kinds of advanced interactivity.

I suspect that the release of Processing 2.0 will lead to a burst of Javascript-based visualization projects being released on the web. In the meantime, we can use the basic template from this tutorial to work with Processing.js – have fun!