To me, Processing is more than a tool. Through all of its contributors, and back to its predecessor, Design by Numbers, there’s an underlying aesthetic of simplicity in the tool, the language, and the work you can create. This thinking transcends any one tool, and gets to the heart of how to approach design problems systematically. As such, teaching Processing should really be more about teaching design – systematic design – than it is even about code or computation. The latter is the means to an end.

I’m teaching a first-semester course in Creative Computing at Parsons alongside three other talented faculty and their sections. Having had to condense “Processing 101” to as little as three hours or even five minutes, I’ve grown really interested in two things:

1. How beginners can get up and running quickly and comfortably, regardless of skill level
2. How us “advanced” users can get back to basics, and refocus ourselves on the fundamentals of design, to tackle our advanced ideas by breaking it into smaller, simpler problems.

To that end, I’ve begun a new journal on Noisepages – the venue we’re working on developing into a place for ideas and projects. If you follow along – particularly if you pick up a copy of Dan Shiffman’s superb book on the topic (a book I’m familiar with as I was a tech editor on it) – you can use this site to learn Processing. If you’re interested in how to teach Processing, it’s a place to see some of my perspectives and experiences and offer your own.

And to give you a feel for the tone, here’s Peter’s First Law of Stupidity – massive apologies to John Maeda’s more sophisticated Laws of Simplicity:

Law 1: Reduce everything to the point that you think it’s actually pretty stupid.

Take a look, and let me know what you think. You can follow the entries over the course of the fall semester.

  • Great !

    Ill check that out;D

  • Looking good so far, Peter, and I'm really interested to see how you continue to approach this.

    I do think teaching Processing by teaching design is key also. Last semester, I watched the vast majority of students in my course quite literally rebel against their teachers in what they saw as a just class about code, when they were quite comfortable digging around in Flash Actionscript or even Maya code – mostly because they could see the means justifying the end: employment.

    As one of just 4 students who continued on with the subject (from around 100) it was really disheartening to not see the importance of a tool like Processing expressed in a design course. I think you're on the right track here.

  • Thanks Peter,
    I just picked up Daniel's book and am only a couple of weeks into it. Not having any background in programming, I am amazed at how easily the basics of this can be learned, and how many online resources there are for n00bs like me.

  • @Scott: Wow. So, literally, 96 students rebelled and walked out of the class?! That's mutiny, sir. (Did anyone get any video of that?)

    I think some mucking around in code is impossible to avoid, but that's part of what I admire about Maeda's discipline in his book. He really makes it clear that this is about computational design, that it will be basic and elemental. It means there isn't this huge gulf between the first sketches you do to say "Hello, World" and what you ultimately want to create. What happens is you actually refine your design ideas with "Hello, World."

    @Isotope of Me: Terrific! Let us know how you do, truly, and if you have any questions / comments / stuff that's unclear / other things not in the book you'd want to cover.

  • !
    I have to think on this idea: I've been teaching Processing at the Fine Arts University for 5? years. Sometimes the students get really involved, sometimes they succeed, sometimes it is really too much for their artistic brains…
    A change of focus could be a good idea, as I am always thinking on better ways to trasmit this skills and this way of solving problems…
    I'll follow your course, of course!

  • Pavel Cervy

    Dear Peter,
    I've been reading your blogs for about half a year, since I've discovered them trying to find something about Processing.
    Now I've finished my first video with granular synthesis technique done in Processing. Here's a link: It's for Nadja's "I Am As Earth" song.
    I'm so much amazed, how clear you get to develop ideas with this tool. Few lines of code (usually) and suprising results.
    Quite satisfied with this first experiment. Looking forward to new ones.

  • @Peter – as spectacular as that would have been, they did stay to the end of the compulsory part of the subject – they just made their grievances loud and clear.

    It's interesting now when I tell other students about the projects I'm working on, that they're initially excited, but then follow quickly with "but do you *have* to use Processing?". Their learning experience has been that negative.

    Clearly, there is a lot of exciting work out there being done with Processing and it should be enticing to design students – as much as Flash websites that jump all over the place and 3D robots and aliens buzzing around in shiny spaceships.

    I guess it's making the connection between a text-based coding interface and artistic output that is being lost – at least at my university.

  • For those 96 people, was there some specific grievance – particularly in relation to Flash coding, which in terms of syntax and even (in some aspects) capabilities is more similar than different? I'm just wondering what it was specifically that turned them off so badly, what they were trying to do, and what they prefer to do.

  • @ Peter – There were quite a few people which had experience with Flash (some with and some without Actionscript knowledge) and wanted to continue in that direction, rather than learn Processing.

    Overall, there was a general perception that Flash was more likely to land you a paying job than Processing and so when the connection between Processing and successful work (commercial or otherwise) wasn't made, there was resentment toward being forced to learn code.

    I don't think there were specific arguments made about which language is 'better', simply that one software package is considered more of an 'industry standard' – which I personally see as counter productive at university.

    It didn't help that our course is quite broad, and so you already have a percentage of the student population who have absolutely zero interest in this world. Which is why I think it's so important to impress that Processing is a design tool, not simply a coding language.

  • Well, of course, that's just absurd. I'm very fortunate in my class to have students who are new to all these tools in general, so they haven't yet formed that kind of closed-minded opinion. There's a certain point at which you may not be able to convince people — if they're thinking "tool = job" and not developing their skills, I wouldn't want to have to teach them Flash, either! (You do what you can, but that means you have to first kind of convince people that learning is a good thing…)

  • I was just curious, though, if there was anything specific they found frustrating or that slowed them down, even having said that…

  • @Peter – If I had to take one consistent criticism that I heard a lot of, it was that for a non-programmer, it's difficult to debug in Processing. To many, there are no clues to what's going wrong.

    I know this is hardly something that is unique to Processing, and I have heard the horror stories of people that had to do this 10+ years ago in programming environments that gave zero visual prompts for syntax errors, but perhaps this is something that needs to be addressed?

    It may be as simple as really hammering home the building blocks to structuring code – which I think you're already on the right track with here for the Processing 101 page – or encouraging those working on Processing to establish clearer error reports in the Console.

  • Tom

    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.

  • Pingback: Create Digital Motion » Processing, Sketchbooks, and the Creative Ecosystem()