Last semester, we introduced Media Computation into our Introduction to Programming course – this course is designed to teach fundamental programming concepts and problem solving and assumes no previous programming experience. After having heard such great things about Media Computation it seemed like the ideal context to trial it!
We had a lot of fun using the Media Computation approach – we spent a lot of time developing problem solving skills using image manipulation, building up experience in algorithm design and debugging, before moving on to spend a couple of weeks playing with sound. The way that we teach our introductory programming course relies a lot on collaborative and active learning – we only 1-2 lectures per week, and the rest of the time the students spend in led workshops, or in practical sessions. The workshops are the key teaching opportunity, where the students progress through a sequence of demonstration and worked examples, interspersed with individual and small group activities. Adopting a new teaching approach meant completely rebuilding all of these sessions, and trying to identify a good sequence of lecture examples -> worked example & demonstration, followed by good problems that could be solved as a group and those that could be tackled individually.
I think the Media Computation approach worked very well in this context though – the more complex problem solving processes that image manipulations required meant that they worked well for group problem solving, and because the problems are not artificial and simplistic, it was easier to set problems that had multiple solutions, and that the students were genuinely interested in sharing.
Here are some of the positive things that I noticed in using Media Computation:
- The students were generally very engaged with the context – they really liked working with images, and could easily understand what the problem was that we were getting them to solve. It was easier for them to formulate a natural language algorithm for their solution as they could understand the context.
- Because they are working with 2-D arrays (images), the solutions are not necessarily that easy, and so without having to introduce a complex context, or multiple contexts, they were tackling very complex algorithms. Because of this, we had a genuine need to discuss and introduce problem solving processes.
- The students didn’t really like working with Jython as it was very slow, but this had an unintended consequence, in that they became aware of the efficiency of their algorithms. I don’t think I have ever taught a first year course where students introduced efficiency as a discussion point on their own initiative. However, when working with their own images, which could sometimes be huge, they had to start thinking about whether there was a better way of solving their problems. I think this was a big win.
And there were also some things that didn’t work so well (which were mostly in our implementation rather than inherent in the approach!):
- Some students really didn’t like working with images. They found Jython painful and wanted something more “vanilla”.
- We had a small amount of backlash about adopting a technique that had been developed elsewhere – this is an interesting issue and one that I think we will see more of as we are encouraged to use resources and materials developed elsewhere. We have had this occur before in courses – students complaining because they want a “UoA” education, not an education from “UoX”. I can see some of what they are saying, but to me, it translates into thinking that the content of the course is the value, where as it is the time you spend with your lecturers, and the discussions and problem solving skills they share with you that are really the value. It is the interpretation, the extra discussion and depth that extends beyond the provision of content.
- We had an interesting issue in terms of being able to understand programming constructs independently of their context. To give an example, the students learnt how to use iteration by using for loops to process image pixels and then moved on to using for loops to process samples in a sound object. At that point, it became very clear that the students had identified the for loop as something specifically designed for dealing with images, and they developed interesting mental models of iteration as a process explicitly connected with image structures. We then introduced some more generic examples to help promote the idea of iteration as an idea on its own, and gave them several exercises to help them apply iteration in different contexts.
This last point was the most concerning for us, as we hadn’t really used an approach that had such an engaging context before and we hadn’t expected the context to thread through so much of their understanding of the basic programming ideas. Although we had certainly introduced iteration (and for loops) as generic ideas, the focus on applying them so much in terms of images negated that and reinforced the wrong mental model that iteration was purely about images. This time through, we are introducing more generic application exercises from the beginning which I hope will address some of that.
Although – this was interesting as it made me think about Piaget, and the views of understanding something within a specific context from a concrete example, before moving on to be able to understand the concept in different contexts. Was this something inherent in this approach, or was it a result of us leaving it too long before we introduced enough generic examples. Did we encourage the wrong mental model?
So overall, a very good experience, with a few improvements necessary and adjustments to make everything run more smoothly. I’m interested to see how it goes!