Abstract:

Interaction designers who operate both in the physical and the virtual domain often need to write programs to try out interaction ideas through interactive physical prototypes. To be able to validate these interactive ideas and behaviors successfully, knowledge related to programming is essential. Programming knowledge is fundamental for understanding the technical possibilities and limitations of interaction. Understanding programming is like understanding a new material; we believe that a designer needs to know both the limits and possibilities to be able to design successfully.

Many of the contemporary tools for interaction designers, such as Arduino or Phidgets, emphasize the ability to sketch in the physical domain of interaction design (sketching in hardware). However, there is little support for the interaction designer to sketch in the virtual domain (sketching in software).
While there is a large body of work about bringing programming for nonprofessional programmers, our analysis leads us to believe that the hardest problem interaction designers face is the abstraction and translation step that goes from concepts and behaviors to functioning code. We believe that the abstraction and translation step is much more problematic for designers than, for instance, syntax. Based upon our observation of interaction design students creating interactive sketches and prototypes, we believe that most students are able to grasp individual statements of the language. Most problems occur at the level above individual statement but below a completed program.

This paper attempts to characterize this step of abstraction and translation in an interaction design process and proposes a first rough design for a toolkit that bridges the gap between code and idea. This toolkit is called the Code Companion and contains two tools: the Blueprint, and the Pattern Dictionary. The Blueprint is a paper tool that is inspired by programming plans and guides the interaction designer to think how a computer represents behavior or interaction. The Blueprint has four steps: program description, defining inputs and outputs, defining tools, and finally sketching the path from input to output using these 'tools'. The Blueprint was exposed to students in two interaction design workshops, one at the University College of Antwerp and one at the Glasgow School of Art. The Blueprint was used after the students defined their idea of interaction, but before writing the code in Arduino. The students in both of the workshop seemed to have a better overview and had a better understanding what they had to program, because of the Blueprint. Students frequently drew 'tools' in the Blueprint they were unable to reproduce in their code. Students were able to come up with patterns in the Blueprint, but were unable to translate them into working code. To solve this, the Pattern Dictionary was designed, which is a dictionary of common programming patterns. Throughout the workshops, many of these patterns emerged, such as compare, timer, repeat, or sensor input.

We believe that the combination of these two tools will reduce the gap between idea and code, and allow interaction designers to be able to better sketch in software.

Keywords:

Interaction, design, programming, prototyping, sketching, toolkits.