We’ve hit the midway point in the semester for Design Computing. And I must confess that my first teaching experience had a bit of a rough start. There were a bunch of factors that affected this—planning Emergence, not following last year’s model, Flash C3 being very different from the previous version—but to some extent inexperience played a role as well.

I struggled over what was more important to teach, Flash or prototyping with Flash. In trying to get everyone quickly up to speed to complete the semester’s assignments, I took a few too many detours into the coding aspects of Flash, and veered away from more interesting topics, like what are effective digital prototypes.

We started with a simple motion project whereby an emotion needed to be conveyed using a single black dot. That broke students into basic animation techniques while allowing us to also talk about the behavior of the animation.

The second project was a control redesign. Students were asked to find a single analog control and redesign it using Flash as the tool. This project yielded many questions from those unfamiliar with Flash. And while everyone successfully completed the project, the questions led me to pursue more instruction on Flash itself instead of the hybrid Flash/interaction design course I imagined.

Fortunately, I recognized this shift, with the help of insightful feedback from several of the students, worked back to my original intention. The third project combined necessary Flash skills for prototyping with a larger focus on communication and interaction. The submitted projects and the conversations around then were promising.

Those first three projects were warm-ups for the three larger projects, one of which began a few weeks ago and will finish up tomorrow. I thought it was important for students to learn about video sketching and spend focused time on creating them outside of their other design projects, where video sketching would only be a part.

I had the students propose a product or service and create a scenario of use that would be the basis of the video sketch. The lack of constraints may have been an issue for some. So I would maybe rethink that for future projects. But otherwise I’m really pleased with the work in progress and the conversations we’ve had surrounding the work. I’m hoping the focus now will mean better decision making for them later during crunch time in their other classes.

Next week we will start a mobile interface project. The final project will focus on emotion and play (or harm) for engagement or entertainment using a virtual pet as a starting point. This was also going to offer an opportunity to introduce object oriented programming, but I’m having second thoughts. I began the course with the idea that there are few ActionScript details one must know to prototype in Flash as an interaction designer. Object oriented programming isn’t really one of them. To add more fodder to my thoughts, tonight I stumbled upon Robert Reimann’s So You Want To Be An Interaction Designer, in which he says:

Designers seldom code—if you are attached to programming, all power to you: the world needs more design-sensitive programmers. But unless you have complete control over your projects, you will be short-changing your users by trying to design and develop at the same time—it’s a conflict of interest. So, if you can’t stomach the thought of abandoning programming, interaction design may not be for you.

So I will likely abandon the more programmy aspect of the final project, and instead focus on interaction. The students have a good handle on the tools already. What’s more important, at least as designers, is how they use them.