The Problem with Processing
At the beginning of December, I embarked on a project, Processing December, with much enthusiasm and high expectations. I looked to Processing as a panacea for all my data visualization wants and needs. I lamented the lack of programming prowess amongst museum professionals, journalists and knowledge workers.
A couple months later, I’m singing a different tune.
Processing may make programming more accessible to artists, designers and researchers, but it’s still a programming language full of logic and math. And for my experience with it, the only thing my programs accomplished was drawing and animating shapes. Maybe I read the wrong books, or maybe I ran out of time just when things were about to get really practical and useful, but I think more likely is that I took a poorly understood concept and unfairly turned it into a magical solution to a complex problem.
Processing doesn’t give you good data, or good questions to ask of it, or an awareness of human perception, or design sensibilities. It can take those things and draw or animate data in a way that some static representations of data cannot, but it can’t serve much good at all without them. The last thing I want to do is create powerfully bad visualizations.
As Brent said early on, learning something new gives the learner a sense and appreciation of her own limitations as well as a respect for the strengths of others. And that’s exactly what learning processing did for me. For our bird data exhibit, I’ve designed some graphs and commissioned a programmer to create the code that draws them.
I have so much to learn about data and perception and design – and a have a natural enthusiasm that motivates me to do so. I’ll leave the programming to the programmers, now with more appreciation and respect for their craft.
