#reflection-on-action

WHAT?

We have the past few weeks run several rounds of experiments in a reflective practicum. We have explored the richness of just one-pixel using JavaScript and tweaked with parameters as hue, lightness and saturation and different interaction modalities. Despite several design tasks, as for example how interaction can form the experience of an adventure using one-pixel, the problem space was never specified:

“[…] it is clear that a ‘problem space’ is not given with the presentation of the design task; the designer constructs the design world within which he/she sets the dimensions of his/her problem space, and invents the moves by which he/she attempts to find solutions” (Schön, 1992: 11).

Accordingly, we had to create our own problem space, which the theory of attributes helped us to do by outlining how you can think about developing interactions. It helped building a body of knowledge that both motivated us but also served as a reflection-before-action. Reflection-before-action is something I miss in Schön’s theories that concerns “reflection-in-action” and “reflection-on-action” - a “now” and a “after”. I find the critique relevant in the beginning of a process, where the problem space is very complex and you do not have much existing knowledge and know-how to draw from. Here, the theories gave us a starting point and a pair of glasses, that helped us with a (temporary) focus in our practice. This was along with how the code vocabulary restricted our possible actions.

SEEING-MOVING-SEEING

After narrowing our problem space, we began to manifest our theoretical ideas (e.g. the selected attributes) in material form by sketching with code. Following Schön (1992) this is a process where we sketch something with the code and afterwards judge it. Maybe the blinking of the one-pixel is to fast, then it becomes a problem that we want to solve. We change the code to solve the problem and then take a look at it again. Now the previous drawing has become the reference point, which we merge with the new drawing. Based on the comparison we make a judgment – is the problem solved? In that way it becomes a mutual conversation between us and the material. From that we learn, so we are better at predicting these consequences ahead of time. So if we undertook the same tasks again, hopefully the process would be less complex.  

REFLECTION-IN-ACTION

When carrying out “reflection-in-action” - doing something to correct something, we are under a time pressure (the lectures short period of time). Sometimes this results in the inability to distance ourselves from the situation and reflect, which therefore erases many of the design steps from our memory. You most of all remember where the code went wrong. It caused less reflection on the interaction modalities (mapping the in- and output), and more on making the code work (e.g. the one-pixel project “adventure”). This lack of focus was spread to the show and tell, where some of the other students had a hard time figuring out how the program worked by listening to our “tell” (instructions). They understood it at bit better after they tried to interact with it themselves. Which is interesting, as it is a strong example of how meaning is created during physical interaction (Djajadiningrat, Matthews, Stienstra: 2007) and how the interplay between mind and body co-produce reasoning.  

REFLECTION-ON-ACTION  

However, the interaction was not thought through, since we had a hard time explaining why we in our project suddenly is changing modalities (from scrolling with the arrow keys to the touchpad). I guess we wanted to materialize the computer by forcing the user to explore other hardware modalities. But the shift did not correspond strongly to our adventure story. Instead interaction as “the user stops to scroll” could have provoked the danger, so the story was depending on the user’s interaction and not controlled by us. Moreover “scrolling fast” could have corresponded to running and could have been the solution to getting away from the danger zone.

LEARNING