UX nerd

Finally, part 3: the toaster. A toaster is a small electric kitchen appliance used to toast slices of bread. It has been around, almost unchanged (in its mainstream version) for more than 100 years. Our interaction with it, I suspect, hasn’t changed much either:

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”.