Operation: Stick Figure Army is a project that will provide tools for converting 2D imagery (as typically found in many introductory computing texts) into 2.5D representations: physical tiles with raised and textured surfaces that represent one or more diagrams from a text. This lets us explore, as a group, image processing, 3D printing, and the process of creating usable software for a target class of user.
The project is being carried out by two students at Allegheny and one student at TCNJ. Sara and Stephanie (Allegheny) have spent this semester learning Python and basics of image manipulation, recently posted their experiences while exploring Blender’s Python API (so we can automate the process of 3D object generation), and are beginning construction of their Cupcake CNC 3D printer. Cory (TCNJ) has also begun looking at Python, and is (at the moment) providing critical reflections on what it is like to be a blind student of computing.
His most recent post on the project blog, How to cope with the design phase?, explores the notion of visual representations in computing. I found his reflections interesting for two reasons. First, it reminded me of a paper by Marian Petre and Alan Blackwell titled Mental Imagery in Program Design and Visual Programming (PDF) (International Journal of Human-Computer Studies, 1999 (51) p7-30). They explore the role of visualization and visual language in expert programmers, and while the paper is too rich to summarize concisely, I’ll pull most of a paragraph from the conclusion here:
There has been a great deal of confusion in the visual languages community about the relationship between mental representations of a design and the programming notation. As noted by Green, Petre & Bellamy (1991), the superlativist position (claiming that visual languages always improve performance in programming tasks) is not justified by experimental evidence. Blackwell (1996a) has analysed the variety of beliefs among visual language researchers about the cognitive effects of using different notations. These tend to range far beyond the practical benefits of the notation or the programming paradigm, but their statements about mental representations bear little resemblance to our findings in the present studies.
Put simply, we tend to get all hot and bothered about visual tools, but research doesn’t imply that this is always a Good Thing.
The second aspect of Cory’s post that I thought was important to reflect back was the importance of verbal communication in software design and development. Whether it is aural or written, being able to express ideas about the design and implementation of software is critical to students of computing today. In some circles, this comes out in the context effective communication and collaboration in teams (Begel/Simon, Struggles of new college graduates in their first software development job (PDF), ACM SIGCSE 2008). Regardless of whether it is a software team at Microsoft or a distributed, community-driven effort surrounding open source software, the overwhelming majority of our communication and collaboration regarding software developing is written/verbal, not visual. That is, we’re not shipping pictures back-and-forth 24/7—we’re chatting on mailing lists, IRC, and blogs to get things done.
I think these ideas say a lot about where we are failing in terms of computing education today, but that will have to be the subject of another post. For now, I found Cory’s words thought-provoking, and wanted to reflect a little bit on what he had to say.
