November 24, 2003

Teaching Computation as an Expressive Medium

by Michael Mateas · , 12:40 pm

I haven’t been blogging much the last couple of months; this semester has been overwhelming. As the semester winds down and I begin blogging again, I thought it would be interesting to reflect on my experiences teaching Computation as an Expressive Medium.

As I described before, this class is a graduate introduction to programming for students coming from arts and humanities backgrounds. It contains a mixture of students in LCC’s Information Design and Technology program, as well as students in the HCI master’s program (many of the HCI students come from non-programming backgrounds). For the theoretical component of the class, I’m using Nick and Noah’s New Media Reader.

The initial syllabus was far too ambitious, both in terms of programming projects and readings. We ended up doing only the first four projects, not six, and reading about half the readings. Class presentation of the programming material took longer than I had initially planned.

It was challenging coordinating the readings with the projects. I tried to coordinate the readings with the conceptual backgrounds of the assignments. For example, while working on Project 3, the “build your own image manipulation tool” project, we read:


For Project 3, the idea was to explore the idea of the tool, how tools create new ways of relating to machines, how tools contain the dreams and biases of the designer and thus constrain as well as enable, and what it means to make your own custom tools. I wanted to denaturalize the notion of the GUI tool. But, even with a conceptual link between readings and projects, I think the urgency and anxiety some students felt about learning to program made it difficult to focus on or think about the readings. If alot of mental energy is going into understanding the difference between Swing component containment (subcomponents) vs. parent-child relationships in the Swing class hierarchy, it’s difficult to think about the historical origins of the graphical user interface and its relationship to cybernetic discourse while connecting this back to the nitty-gritty details of writing code. I still need to find ways to tie the theoretical big picture and the nitty-gritty of code together – I’d love to hear any ideas.

A related difficulty was leading interesting class discussions with the more technical readings. It’s great that the New Media Reader situates so many seminal technical articles within the historical and theoretical framework of new media. But the rhetoric of technical articles, a rhetoric of univocal clarity, makes it difficult to dig below the surface. It’s too easy to read an article such as Man-Computer Symbiosis or Augmenting Human Intellect and say “Yup, it’s amazing how well they predicated the future”, and “Wow, what we have today is still only a portion of their vision”, and “Yeah, he’s a visionary”, and “Oh, I think so too” and so forth. Not exactly a scintillating discussion. Of course what you really want to do is a deep read of the articles, moving below the simple rhetorics of progress to the deeper biases and assumptions being built into hardware and software. But doing this requires bringing in additional historical and critical knowledge (and readings). For example, the discussion of cyborg discourse in the first part of Kate Hayles How we Became Post-Human would nicely situate many of the technical readings. In any event, I need to work harder the next time I teach this class to help students dig below the surface of the technical readings. It’s interesting that one of the best class discussions we had was discussing The Cyborg Manifesto. For many in the class, this was the first time they’d encountered the language of cultural theory. Thus, for some of them, on first read the article was completely incoherent. And this sense of incoherence forced deeper thinking and opened up more avenues into the reading.

I wish there were articles in the New Media Reader about the process of coding itself, about what code is, about the distinction between a program as static writing and a program as dynamic machine, about coding as craft, about the experiential aspect of programming, about debugging as a fundamental part of programming (it’s not a bad, avoidable thing, but a necessary, good thing), about reading code (several levels of the word “reading”). The next time I teach this, I’ll sniff around for readings from the emerging fields of software studies and the theoretical discourse building up around software art. Does anyone have some interesting readings to recommend?

The increment from Project 1 (write a program that reads from and writes to the console) to Project 2 (write a screensaver) was too large. To do Project 1 students had to learn about control flow, working with Strings, and basic text I/O, but didn’t have to necessarily learn about objects, classes and methods. It was possible to write Project 1 entirely within the static main() method of a single class. But Project 2, since it involved using Swing classes, required understanding the Swing class hierarchy (to some degree), creating your own child classes of existing classes, and method overriding. Much of the schedule delay relative to the syllabus came between Project 1 and Project 2 as I struggled to teach all of these concepts. The idea behind the ordering of the projects was:

I’m not sure how to deal with the large increment between projects 1 and 2. One way would be to provide a more developed infrastructure for the students to use for project 2, so the project consists more of small modifications to existing code. But, if I took this route, at some point I’d like them to understand the scaffold and be able to modify it more deeply. When should this occur? Also, the issue of providing framework code is tangled up with another issue; how targeted or open should the projects be?

One of the motivations for teaching programming from an art and design perspective is to motivate programming concepts by teaching them in the context of expressive projects. And, in order to be maximally motivating, the students should define and develop the projects themselves (within some conceptual framework provided by the assignment). But, to the degree the assignment is open, then it is difficult to teach the programming material students need to finish their projects (because there is a such a wide range of skills needed across the range of projects), difficult to ensure that all the students cover some minimal core of concepts, and difficult to provide framework code for all the students to build upon. To the degree that the assignments are highly targeted, one can provide code that everyone is able to modify to accomplish the assignment. But, one of the goals of my course is to introduce students to the dialectical relationship between the craft of programming and developing art and design concepts. Targeted assignments don’t give students enough conceptual room to develop this connection. At the 4S Conference a month or so ago I had a nice lunch conversation with Phoebe Sengers and Warren Sack about teaching programming for artists, at which we discussed this exact issue. Warren said he’s tried both approaches (more targeted and more open assignments) and is still searching for a happy medium. In my class I provided example pieces of code for “typical” things that students might want to do with assignments. Most students built on one or more of these examples, while needing to learn some additional stuff on their own (e.g. how to use some class) to complete their specific assignment. But I still don’t feel like I’ve really found a way to balance these two extremes.

Many students found the Java API documents difficult to understand and navigate. Given the huge wealth of classes provided by the Java runtime, learning to navigate these documents is essential. As I told my class, the trick is not to have to write reams of your own code, but rather to build cleverly on existing code. I tried to model using the docs by doing some programming in front of the class, talking out loud as I moved through the API docs to look up classes and methods, and encouraging the class to interrupt me with frequent questions. I’ve tried to use this model of writing code in front of the class alot, to demystify programming, to show that I need to debug too and to talk through and model how I debug, and to demonstrate that you can get interesting effects in relatively few lines of code. This approach worked for some students but not for everyone. I wasn’t expecting reading the API documents themselves to be such a difficulty – I’m still searching for good ways to teach how to read documentation and code. To help with teaching how to read code, I’ve tried providing heavily documented (i.e. 2-3 lines of documentation for each line of code) code full of my own explanations for how things work. For students who engaged the projects early (spent time just learning the code, playing with it) I think this was useful. I tried to encourage a playful attitude towards the code (like any craft practice, you just have to spend time fooling around well before the project is due), but this didn’t work for everyone. For some students I think more targeted assignments would have been useful (i.e. take this code and change it to do x), but this relates back to the whole tension between targeted and open assignments.

I’d love to hear comments and ideas from anyone who has taught programming for artists and designers.