I want to highlight a comment from a recent story in which I was reflecting on how to approach Processing, and – in a larger sphere – design simplicity. Tom writes:
My opinion – the problem with Processing is that is not part of a software ecosystem. Flash is aligned with Illustrator and After Effects et al., when the solution is not in one, it can help to rephrase the problem in another. When trying to create a piece of art I might sweep back and forwards between each, looking for the first jigsaw piece.
I always start with a vision of what I want to see and will then scribble it. The idea of code snippets as the START of something is just not interesting – I need to scribble, then refine. Processing reminds me of computer graphics from the bad old days pre – Amiga. Isolated and demanding.
While ‘industry standards’ are sacred cows, it’s also true that some packages are popular because they appeal to a variety of users: the painter and the programmer.
Tom has a point here, and I think offers good insight into how people work creatively with Adobe Creative Suite, but I want to address the relevance to the blank-slate, free and open source, code world of Processing. He raises some good questions – questions worth talking about.
There are two ideas here. One is that you need to start by scribbling. I couldn’t agree more – but speaking for myself personally, the place to do that is in a sketchbook, on paper, with a pen. I would choose Processing over Adobe Creative Suite for sketching because Processing’s window is truly a blank slate, because the ability to type in code that covers all the worlds of 3D, 2D, sound, pixels, video, and so on to me offers tremendous freedom, and because the syntax of Processing encourages you to try compact ideas – small haikus rather than expansive essays – at least when beginning an idea.
But Processing versus paper? Sorry, no contest. I’ve found I’m massively more productive in Processing if I have a paper notebook handy, if I walk away from the computer and sketch an idea on a subway, if I start drawing an outcome before I begin to think in code. Also, perhaps it’s because I always had to work at math, but I find that I solve problems of geometry and structure much faster if I simply draw them. This moves you from the abstract to the concrete. Not sure how to structure an array, or how to rotate geometry, or why something isn’t working? Why not try working it out on scratch paper? In fact, I think Creative Suite is itself a selection of abstractions, not a tool in which you would want to sketch. I think it’s a myth that the Graphical User Interface makes things concrete; rather, it makes certain things concrete, certain things more abstract, and certain things more rigid. I’m committed to the computer as a tool. But even with sophisticated digital tablets, pen and paper introduce muscle and tactile sensations different from the computer, and for that alone, they’re valuable.
The value of Processing – or any code tool – is that you can conceive a structure, something generative, something interactive, something dynamic in ways that you can’t with graphical tools alone. In fact, back in Creative Suite land, Flash gurus like Joshua Davis do just the same – they try executing an idea that you can’t draw on the computer (though perhaps you can start thinking about that structure by drawing on paper). Without ActionScript in Flash and Expressions in After Effects, Creative Suite would lack this ecosystem, too.
That brings us to the second point Tom makes, which is the ecosystem. Processing certainly can be its own ecosystem, at least in terms of media, because it can deal with 2D, 3D, pixels, video, sound, electronics, hardware, type, data, and, with the larger Java library world, pretty much anything else. And in fairness, the heft of Creative Suite can be as much a liability as an asset, as you learn interfaces that are not always consistent, and workflows that are not always complete. Adobe is constantly working on closing those gaps, but the nature of these tools makes it a matter of tradeoffs – always a necessary evil.
But Tom is absolutely right. It’s not always more productive to code every tool from scratch. So it sounds to me like this is perhaps just a misunderstanding of the role of a tool like Processing, on two levels:
1. It is possible to use a code tool alongside non-code tools. Processing has long worked effortlessly with graphics, and via libraries and core development, is improving its import/export workflows with video, sound, and 3D models. Let’s take 3D as an example. An increasing amount of software is now supporting COLLADA, and one indepedendent developer (Matt Ditton) has built an amazing loader for Processing – GPL open-source; check out its Google Code page. There’s no Adobe to make these things magically happen; it falls to users. That also means that users determine priorities and features, and there’s no massive company with its own commercial goals. For that reason, I think it’s essential to ahve both. But you’re probably more likely to grab those photos from your digital camera using Google Picasa for touch-up and organization rather than writing a Java app to do it – of course, it’d be silly to argue otherwise. That said:
2. When you know code, you may find yourself scripting to save time. What if you want to take a 100×100 pixel square from three hundred vacation photos and assemble into a montage? Ah – yes, once you know how to code, you have an extra tool in your arsenal. Suddenly, tasks that previously required back-breaking manual labor for several hours can be accomplished in a matter of minutes. And you may find that big, monolithic tools – useful as they can be in some circumstances – aren’t the right tool for every circumstance after all. Things that seemed “powerful” or like “timesavers” may suddenly seem just the reverse.
Now, by “Processing,” what I really mean is “a code environment that is productive to you.” ActionScript isn’t quite as comparable here, because – see the two points above – it doesn’t have the kind of rich file system access or 3D capabilities or library support or language speed and functionality of Java and Processing. That’s not to say one is better than the other; ActionScript, Flex, and Flash are simply more focused on a specific task, and lack some of the extensibility of a truly open source environment.
But you could certainly apply this to ActionScript, Ruby, Python, OpenFrameworks, PHP, C… whatever you like to use.
I didn’t have the time to make this a concise story (I can write a rambling explanation in no time at all, and an elegant explanation only after hours of work). But hopefully this is food for thought.
I was once wary of le
arning programming, because I thought it was for specialized “progr
ammers” rather than “artists,” or that it’d be a time sink (well, okay, that’s true, but so are all technologies and many things worth doing). But what I’ve found is simply that programming – like drawing on my sketchpad – is a way of expressing ideas and solving problems that has no other replacement. And because it is so essential to the work I do, it’s equally essential that my primary environment be free and open source, have robust, flexible capabilities, and have a community around it. Any tool that fits those qualifications to me is a great choice. If you learn nothing more than drawing boxes, you may find it useful to your design.