Tools from the Pros #1: Miriah Meyer on Processing

by Enrico on September 2, 2011

in Guides,Interviews

miriahI am really excited to announce my first interview for the “Tools from the Pros” series! We start with a very good one: Miriah Meyer talks about Processing.

Miriah is assistant professor at University of Utah. I met her only briefly during a couple of conferences but I am a huge fan of her research work on interactive visualization systems for biological data analysis (be sure to check them out!) Her tools are a rare example of well-crafted design studies in interactive data visualization and, as far as I understand, they are all developed in Processing.

I really like this interview because it covers many of the things beginners (and more advanced users) need to know. One above all: the rapid prototyping approach Processing makes possible and the whole mindset behind copying and pasting code to explore alternative designs.

Thanks Miriah! I think people has a lot to gain by reading this interview.

How did you start using Processing?

I started using Processing in 2008 when I helped design a new undergraduate visualization course at Harvard. We chose Processing as the language for the course, and I learned the core bits of the language putting together homework assignments. I quickly came to appreciate how Processing got rid of all the annoying parts of graphics programming — setting up a rendering window, registering callback functions, dealing with linking and libraries and compiling to multiple platforms, that ridiculous gluPickMatrix, and not to mention the headache of type.

We had Ben Fry come to the class to give a guest lecture that spring, after which we went out to lunch. I’ll never forget his answer to my question of why he created Processing. He said (well, I’m paraphrasing here) that he wanted a sandbox to play in, to quickly develop prototypes without getting bogged down in the architecture of the code. He emphasized Processing as a language to try different designs, with real data and with real interaction. And that cutting and pasting code in Processing is totally cool if it gets a design up and going faster. He wanted a language that lets people totally focus on the visualization concept and design without having to think too hard about the code underneath.

Well, that sounded great to me. And I quickly became a total convert, cutting and pasting code until things got so messy that I had to just rewrite an entire project. I found this philosophy totally liberating and that my work benefited immensely from rapid prototyping. Processing is a language that supports this style of development.

What’s the best and worst aspect of Processing?

In short, the best aspect of Processing is the amount of code it takes to get a simple scene with callbacks going — it is a small fraction of what it would take with OpenGL. Simple primitives like circles, squares, text, etc. are nicely abstracted into one-line function calls. Mouse and keyboard callbacks are automatically handled. There is a wide variety of common graphics helper functions available, like lerp-ing colors. Full-screen apps work without having to grab weird OS handles. The PDF library that exports the current scene as vector-graphics has forever changed figures for papers for me. And the ability to export an application to a variety of operating systems in a single go is absolutely invaluable when working with users on a variety of platforms.

Despite all the simplification of the underlying graphics library, Processing still feels like you are in complete control of every mark you make on the screen. I almost never feel like I need to find a way around a function to get the sort of control I want. The design decisions that went into creating the Processing API are fabulous. Really.

As for the drawbacks, there aren’t any really great libraries (yet) for basic user interface widgets. Which for me is ok because I’m kinda neurotic about how my scroll bars look and act. But for graphics beginners this can be a real time-sink. Same goes for more sophisticated types of visual representations like basic charts, maps, and networks. Other languages like Protovis provide built-in algorithms for handling these very common types of representations. In Processing, you’ll have to implement your own graph layout algorithm (or, find one on the web). Again, this can be a hurdle for people with less programming experience.

And as a small gripe — Processing has implementations of Bezier and Catmull-Rom curves … but where is the love for b-splines???

Ok, I am a beginner and I want to learn Processing, where do I start?

Go to www.processing.org. Click on the Learning tab. Explore.

On the Learning page you’ll find a whole series of tutorials and examples that can walk you through the basic functions of Processing. The next step is to peruse the inspiring demos in the Exhibition, many of which will include example code. When you see a function you don’t understand, the Reference page has wonderful documentation for the language.

If you are new to programming or graphics programming the two books I recommend are:

You can work through the Getting Started book in a day. It’s short and sweet. If you find that you need more help, the Shiffman book includes more details on how to program and lots of paper and pencil, and coding, exercises. Daniel Shiffman wrote this book from course notes he created in teaching design students at NYU about coding and Processing. It’s intro to programming via Processing.

If you are an experienced graphics programmer all you need is what you can find on the Processing website.

How is the learning curve vs. return-on-investment of Processing?

If you know OpenGL and are familiar with Java, the learning curve is super short and shallow. If you are new to graphics, it will take you less time to wrap your head around Processing than OpenGL. And if you are new to programming, Processing is a really fun way to learn the basics.

With that said, it is still a programming language. Reading in data from a file requires basic coding skills, as does just about any interesting interactive visualization. You have to be comfortable with for-loops and arrays. Processing makes graphics programming way easier, but it doesn’t automatically generate visual representations of data. You have to code that.

If you want control over every aspect of your visualization and interaction designs, then you really just have to program. Processing is one of the best languages to use for that. If you just want to see what your data looks like, then there are other tools that can do this quickly with built in visual representations (like Tableau, ManyEyes, Matlab, R, etc).

What other tools would you recommend other than Processing?

I’d recommend any of the tools and languages I’ve mentioned previously. Another gem is ColorBrewer for selecting great colormaps.

Still, nothing beats OpenGL for truly understanding how graphics works. If you are serious about developing interactive visualizations, I think that taking an intro to graphics course that uses OpenGL is invaluable. Understanding the rendering pipeline and how it is implemented in a computer will make the seemingly quirky aspects of even a language like Processing make sense.

Previous post:

Next post: