Processing for Kids : Part 1
Setup and Draw.
Part One: Where to Begin
A few months ago, I walked into an office in the lab where I work and was asked by a co-worker if I’d be willing to mentor a kid who had shown interest in learning to do something creative with programming. My co-worker, Andy, has a large amount of teaching and research responsibilities, so he felt that I could better serve the child’s interests due to my active arts practice and the nature of my day-to-day creative research at the lab. I then tapped Arthur, a computer science Master’s student, research assistant in the lab, and enthusiastic user of Processing to help out with the mentoring. Arthur and I have collaborated in the past with success, and I thought he could provide a different and complementary perspective.
Arthur and I will be mentoring the kid through the Spark program, a “national (USA) nonprofit that provides life-changing apprenticeships to youth from disadvantaged communities. Spark one-on-one workplace apprenticeships empower young people to succeed in their education and beyond,” and I’ll be blogging about it here for the next nine weeks. The mentoring culminates in an exhibition called “Discovery Night,” which seems to be part art show, part science fair.
The child in question is named Elonzo. Elonzo in many ways seems to be a typical 12-year old boy: he likes video games, sports, and super heroes. I was told that he has a reserved personality, which accounts for the lack of much speaking on his part when we meet. During the ideation phase of the initial mentoring session, he indicated (after some prodding) that he would like to make a simple game. His interest in creative programming is what brought him to us; at the Electronic Visualization Lab (EVL), where I work, we do a lot of creative research and we teach a popular video game course each spring. We talked about the complexity of even the simplest game and we discussed some compromises that might mitigate the disparity between his ambition and his ability (based on his lack of programming experience and the eight short weeks we had to accomplish this).
I have a bit of experience teaching Processing to kids from disadvantaged communities, so I had a few ideas about how challenging this would be and about how to approach the task. I personally use Processing for a lot of my work, and I feel that it’s an ideal platform for someone who is interested in programming to get started. As has been demonstrated by dozens of books and tutorials, it’s remarkably simple to get something interesting going in a surprisingly few lines of code in Processing, without some of the hurdles that one must leap when programming in other environments (e.g. compilers, linking libraries, memory management). Add to this the enormous Processing community, with the endless number of tutorials and resources, and the fact that Processing is open source; it’s difficult to imagine a more ideal environment for beginning to program. One could argue that Elonzo would be better served by learning something geared toward kids, such as Scratch, but I think that’s a subject that can best be debated by those with experience in both Processing and Scratch (which isn’t me).
One of the toughest things about teaching someone the basics of programming is getting started. To a beginner, many of the primary tenets of programming are very odd. For example, the concept of a for loop is difficult to grasp at first, but once you think about how you might ask a computer to, say, draw a bunch of lines and then stop, it makes sense.
When Elonzo and I sat down to the Processing IDE for the first time, I decided to take a different approach than I had in the workshop last year. Rather than beginning with, “This is an int, which is a whole number or integer,“ I started by showing him around the IDE. Just a few basic things, like the “play” and “stop” buttons, how to save the sketch or open a new one, and where to find the treasure trove of examples that’s built into Processing. I opened the “Loop” in the examples under Libraries>Video.
My hope was to show Elonzo something relatively interesting, yet simple that would grab his attention, while not overwhelming him with complexity. We talked a bit about what was happening with the code, but rather than unpacking the sketch line-by-line, I opened a new sketch and started from scratch. Instead of my usual approach of talking about data types, I immediately went into the difference between setup() and draw(). When I think back to the first time I learned the difference between these two, the moment of clear understanding that I can recall is when some wise person told me to try moving background(0) from draw() to setup(). I think I was busy at the time happily drawing a line that begin at the center of the sketch and ended wherever I moved the mouse. Following their advice, I commented out background(0) in draw() and then added it to setup(). After staring at the screen that was rapidly filling with lines, the difference between setup() and draw() really began to make sense.
So, with that seminal moment of basic clarity in mind, I wrote out a basic sketch on my laptop while Elonzo followed along on his laptop beside me. We talked about size(), and I took that opportunity to discuss width vs. height in computer graphics terms (0,0 is at the top left corner), as opposed Cartesian terms (0,0 is in the “middle”). I added a background() into my setup(), and asked him to do the same. From there, I talked about the RGB color model, and I was pleased to see that he immediately started changing the background of his sketch, trying different combinations to see what they would do. I then added draw() to my sketch, and we talked a bit about drawing a rectangle and how to use fill() to color it. Again, he jumped right in and made his rectangle long and skinny, and a dark blue (as opposed to the light red I’d originally showed him).
Trying to capitalize on his enthusiasm, I quickly replaced the x and y coordinates of the rect I’d drawn with mouseX and mouseY and asked him to do the same in his sketch. As I watched him fill the screen with long rectangles, I figured this was an opportune time to go into setup() vs. draw(). Moving his background() from setup() to draw(), he quickly got the difference visually, if not conceptually.
To further cement the concept, Arthur suggested that we print the coordinates of mouseX and mouseY, which provided another simple example of what looping means in terms of draw(), and what happens when you ask the computer to do something once, as opposed to constantly. At this point, we’d been at it for about an hour, and I thought this was a good place to stop. I showed him where to find his saved sketch after he’d saved it, and how to quit Processing.
All of this is a far cry from the first-person shooter he dreams about creating in nine weeks, but the great thing about Processing is that we were able to create an extremely simple, interactive sketch in less than an hour–and with minimal frustration. In the weeks to come, I plan on showing him how to record sounds and scan drawings and load them into his sketches, and to continue introducing basic programming principles. This means that we will of course need to have the “this is an int” talk, but hopefully I can leverage the visual aspect of Processing to show him what he gets when he has a basic command of ints, floats, strings, etc. Based on my own experience, I doubt we’ll be showing a complicated game at Discovery Night, but I think with our help, Elonzo can create an interactive work that has some goals (like a game). As much as I hope that he’ll be proud of what he’s made, I hope he’ll be able to understand and even explain what’s at work behind the full-screen sketch, and build on that knowledge when this mentorship is completed.