During our week-long course with Bert Bongers; Maria, Valentina, Dominika and I redesigned a toaster. You may also want to read part 1 and part 2 of this series of posts to learn about the concepts that we put into practice. Part 3 presents our analysis of the current toaster, and our redesign.

I’m not going to say that were doing our device parsing when we came across something interesting. I’m not going to do that because everyone knows that after you’ve toasted a first pair of slices of bread, it requires superhuman ability to get a second pair equally toasted. However, I’d like to point out that, had we though that this randomness was part of a “surprise me” feature in our toasters, we would have realized that something was wrong with the interaction anyway, when doing the device parsing.

The image on the left shows how there’s something wrong with the mapping between the input and the output, between an action on the part of the user (setting the timer) and the desired outcome (how toasted the toast is). This is a gulf of execution problem.

Depending on how hot the toaster already is and some technical characteristics, the outcome for the same knob position varies. Suposedly you can tell this because you had a look a the components, which is not really needed in the case of a toaster because I guess most people know how it works already. But, in any case, even if the output didn’t vary with variables other than the input, numbers on a knob don’t actually tell you anything about how toasted the toast will be. If you encountered this toaster for the first time, how would you know which number to choose?

So we went on to redesign the toaster for the mapping to make sense. To help the mapping, we kept the knob, but instead of having numbers we introduced the coding in the picture on the right. This is very nice as an interface, no room for ambiguity. But… how would it actually work in terms of the components of the toaster? The current toaster has a timer associated to the knob, you set it and after a while the toast is “ready” (whatever that is). Changing the numbers on the knob for pictures above will solve the mapping problem, for example for first time user of a toaster that doesn’t know what the knob is for, but will not help with the “random toastedness” factor, something inside the toaster has to change: the timer. This is the prototype for our “deterministic toaster”:

There you can see our Flash toaster (in the laptop’s screen) for which you enter how much you want to toast your bread with the knob on the bottom of the picture (to the right of the center) using the coding showed in the previous paragraph. The flashlight (blue thing on top of the plastic cup) lights the toast (green paper thing) so the webcam (white thing) can read the RGB values for the color of the toast . As bread  gets toasted, it emits different amounts of red, green blue and total light, so if you read these values you know (or the toaster knows) how toasted your bread is. We measured this in real toast, obtaining the curve on the right.

Now, replace the flashlight with well mixed RGB light, the webcam with a RGB sensor, compensate for the red glow of the resistor inside the toaster and the initial color of your bread. And when the toaster determines that the color of your toast matches your settings it can pronounce your toast “ready”.

When I looked for information on device parsing on the Internet, I found several slightly different definitions (for example, this one). I think that the idea is still evolving, and Bert Bongers says that he’s still working into validating it, which is why it’s probably still changing. Anyway, I’ll just refer to what we did in the lecture.

Device parsing is a method that consists on taking apart some device in order to understand its functionality (and potential functionality) through the analysis of its components. The goal of this is to eventually, once you have understood it, build it up again taking the user into account.

So, we started by thinking about what people may want to use the device for (its functionality):

In the case of the alarm clock, primarily:

• See what time it is
• Wake up to it (it is an alarm clock)

But also:

• Check the date (it has that functionality)
• Check the temperature (it has a thermometer)
• Use the light  to see in the darkness of their rooms

You probably note that some of these are weird, like checking the temperature. At least I can’t imagine why I would like to check the temperature in my own room, I mean I’m not relying on temperature measurements to see if I want to put on a sweater or not, for me it’s just a matter of am I warm or cold. However, for some reason someone felt it should be there. Others, like using the clock’s light to look for something in the dark, are weird because they were probably not intended by the manufacturer. But I’m sure I’m not the only one who clicks on the light button to help me look for stuff when I don’t want to turn the lights on.

Then, we took the clock apart to take a look at the components, finding (no surprises here) that alarm clocks are in their electronic, and more precisely digital, technological stage. Why is this relevant? Because every technological stage has it’s own interaction constraints and capabilities. The interaction that you can realistically introduce at each stage is different and, even if you decide to leap on to the next one, you may want to know why you’re doing it.

Next, we took a look at the input and output devices (in the clock, mainly buttons, but also the screen, the buzzer, etc.) and the different components. We analized how the input and output devices relate to the components inside and the functionality, determining the way in which the tasks associated with each function are performed. The idea is that you get to know why things behave the way they behave. Was something the designer’s choice or was it a technological constraint? Could it have been built otherwise? Why does the same button serve as snooze and light on button? What would it take to make things differently?

Finally we put it together again and took a look at the feel: how the interaction is affected by the components. In the case of the clock, the light/snooze button (on top) had haptic feedback, but the others (on the front, used to change the settings) made a noise when touched, for example.

So, this was it. Now we know why this clock behaves the way it does, what are its technological capabilities and what would take to make it behave differently and we’re ready to undertake it’s redesign putting it together with the user in mind. I agree that it doesn’t make much sense with a clock, probably you can tell what’s inside without opening it up. However the concept looks interesting and I’m looking forward to using it if our suggestion to redesign a mobile phone’s interface goes through (fingers crossed :)