During a recent session of our Art and Science Teacher Workshops, I engaged in action research by implementing and reflecting on a lesson on the use of computers for creative means, namely creating visual art. The participants explored the work of Sol LeWitt, who created instruction based works intended to be carried out in a variety of contexts. Brain Pickings has provided an overview that shows how various artists have approached this idea. LeWitt’s instructions can be implemented using traditional technology, but in this lesson I chose to use two newer tools, Scratch and Processing, to introduce how computers can be tools of creative expression through programming and play.
I made modifications to the lesson since I originally developed it. My major change was emphasizing Scratch more than Processing with teachers who are likely novices at programming. The main advantages of Scratch for beginners is that available instructions are presented in the form of graphical blocks that can be snapped together to create a program and that errors will not prevent the program from being run. This is in contrast to Processing, that requires using a reference to know what instructions are available and even small errors in syntax will present the program from executing, which can be frustrating at first. Only when larger, more complex programs are created do the benefits of Processing become more relevant. In the lesson, I only demonstrated Processing to the teachers on my own computer instead of having them modify the program. Everything also took longer than I anticipated, but this was mostly during the active learning sections, so I was not discouraged by this. There also was less emphasis on applying area and perimeter understandings.
Due to time constraints, I piloted the lesson with eight K-8 teachers from northern Michigan districts during the workshops and then tried a more in-depth implementation with a local second grade teacher. Although the lesson was done during the last day of a week of workshops and everyone was exhausted (including me), my overall impression of how teachers responded to the lesson was positive. One teacher commented that she “felt like a genius” and others mentions how the workshops expanded their perspective of the media that students can use in creating art. I concluded that there were varying levels of receptiveness to learning programming, not just in adapting to a new tool but needing to using specific problem solving skills, namely the computational thinking abilities I’ve been exploring throughout the MAET program.
The achieved learning goals were varied. The overall intent of the workshops was finding ways to integrate art, science, and technology, so this experience modeled to teachers one way this could be achieved. It also intended to introduce them to new tools or discover new ways to use them to apply both art and math understandings. There were also broad goals of understanding that art can be created using computing technology and realizing the role of play in creating a variety of art. An explicit assumption was that knowledge is best constructed in an active fashion. Since teachers were working with partners and group discussions resulted from their experiences, the social aspect of learning was also made apparent. Implicitly, it was demonstrated that some tools are conducive for engaging in play and applying certain types of knowledge.
Some affordances of approaching the lesson in this way was the connection between art and programming was made accessible by allowing teachers to create simple visual works themselves. They were also given the freedom to play in order to see its importance and no group ended up with the same result in Scratch as a result. We were constrained by relying on groups working well with each other and not having the time to go in-depth in terms of background knowledge.
Learning took place by doing. While the end products of what was created in Scratch were simple, the experience provided an entry point in integrating these techniques in their classrooms. My direct instruction when discussing computational thinking, LeWitt, and the programming tools fit with the behaviorist tradition, but transitioning to allowing teachers to engage in the practice of creating art through programming allowed for a constructivist approach. Teachers misconceptions on the nature of programming were able to be addressed as they tried to program the result they were looking for. Constructionism also played a role with the creation of an artifact.
I would classify the lesson as supplementing the curriculum, as not many classrooms would have the opportunity to try this, whether constrained by lack of computers or expertise in the tools. However, there were connections to existing art and math curricula that would be typically taught, such as geometry and shapes. I hope a further emphasis on computing in classrooms will make this topic more common in curriculums.
Since teachers came from a range of backgrounds and taught different grades, I had to make some assumptions on how they might use these ideas in their classrooms. The greatest difference I observed was differences in comfort level in programming. Even having one person in a group that approached programming with an open mind permitted for greater success, but if frustrations were shared in a group, then it quickly became difficult to engage them. The differences in attitude played more of a role in success than background knowledge, but those who had used Scratch or used the Hour of Code in their classrooms had a much better starting point. A basic knowledge of thinking algorithmically and using a coordinate system were assumed.
I was able to gauge gained understandings by moving from group to group and see how the experience was changing their perceptions of programming and problem solving. Their final Scratch program demonstrated increased familiarity of the tool, but attitudinal changes were harder to assess and mostly came out of our post-workshop surveys.
As mentioned earlier, instruction-based art could be done using simpler technologies, but the use of Scratch and Processing allowed for the ability to make changes to the instructions/program and get instant feedback when running the program. This was central to the idea of play that would have been difficult with other technologies. By having the graphical blocks visible within Scratch, there was implicit scaffolding that allowed teachers to be successful. The multitude of options did make it intimidating for some participants. The tools also connected the process to the product, which is not otherwise visible in many works.
I intended the provided tools to allow teachers to see how art can be created algorithmically and allowed for the application of computational thinking to create a final artistic product. I also hoped they would adapt these technologies for use in their own classroom. Some of the participants were self-sufficient and remained engaged when using Scratch, but other quickly became lost and needed more support. The multitude of options available to them was overwhelming to those teachers, Many of the questions were of the “How do I…” variety, as teachers tried to map what they wanted to do from the mental problem space to the program space of Scratch. Often they needed to break down the problem to manageable parts in order to be able to tackle it, so I would aid in the decomposition process and use my familiarity with the tool to help guide them.
The easily changeable nature of these tools allowed the teachers to make sense of the role of play in computing and art. Since their programs made use of math and art understandings, both tools provided context for applying these knowledge in meaningful ways. They were also well suited for applying computational thinking, in considering how both artists and programmers solve problems in similar ways. While I wouldn’t describe the use of these technologies as transformative, they were conducive to achieving the intended goals of the lesson and make use of the affordances that computers provide.