INTERACTION LAB
SPRING 19
“ChaCool” – Sarah Waxman – Young Chung
INDIVIDUAL REFLECTION:
My previous research exposed me to a variety of different forms of interaction, especially within the context of interactive design. Out of the many projects I encountered during my research, the one that resonated with me the most was Daniel Rozin’s PomPom Mirror, a project that truly clicked in my mind as the ultimate form of interaction design. It was through this project that I was able to narrow down the definition of interaction, by narrowing the term down to “interaction design.” This was due to the fact that the word “interaction” alone was too broad for me to be able to exclude any projects from fitting into the criteria. Ultimately, I defined it as the direct particular affectation of two or more subjects, events between which there is a period of “processing” — and, in terms of an interactive project, at least one such subject must be human (O’Sullivan and Igoe, 2010). Furthermore, I would agree with Tom Igoe in that “physical computing should ideally foreground the person’s input”, as should interactive physical computational projects (Igoe, 2008). A valuable lesson I learned from this midterm project, however, is the importance of the output’s timely manner. The practically immediate and tangible response from PomPom Mirror to the viewer triggered my understanding, as well as the way it forced the human to be a part of the project; the human and thereby the interaction was a necessary component for the system to exist as intended.
One summer that my partner, Santiago visited a hospital (Hospital Simon Bolivar) in Colombia, he noticed that the burn victims were struggling to blow into their hot drinks in order to cool them. He empathized with them and in light of his experience, we wondered what kind of product we would like to see readily available to them. The purpose of our project is therefore to provide a fun and interactive solution for children who suffer from the long term effects of severe burns as well as from facial paralysis. We created a machine that would apply air to the top of a cup filled with a hot drink in a way that would not any more than placing it in a certain place, as one would place a cup under their mouths to blow on it. The colorful LEGO design and structure is deliberate. We aim to attract children to this device, so that they enjoy using it rather than feeling like it is purely a necessity. This design also contributed to its our project’s originality. Another motive was to take the concepts and skills we had learned in class, such as the programming that would link a sensor’s detections to a potentiometer and/or LED, and design something meaningful with them. Ultimately, we took these skills to program a distance sensor and link it to a fan blade as well as an LED, which would both act based on the sensor. We were aware that our target users generally have perfect use of their hands and arms, so this would work well for them. At one point, we considered adding a base to the bottom of the machine where the user’s hot beverage cup would go, then decided against this due to the variability of the sizes of cups. We did not want to restrict the type or size of cup, a reason for which we also ended up rejecting the idea of a heat sensor which would have required a metal cup (or another quick heat-transferring material). Another reason we rejected this is because while it sounded great during our user testing – which is where the idea came up – we thought more about it and realized, through common sense, that a person could simply touch the cup and determine whether it is at the temperature they are satisfied with. Even simply trying the beverage would work, as that is what is normally done after one blows into their cup, and, after all, the idea of the machine’s functionality (excluding the aesthetic qualities) is simply to offer an alternative to blowing. Another decision we made was rejecting a laser cut or 3D printed structure for our design. Both would have limited us to their materials and available colors, which are not many and could not be made multi-colored during our time frame. Therefore we elected the LEGOs, as they fit into our criteria of colorful and cheery material that is relevant to children as well, and that gave us the flexibility to improve and tweak our design more often and effectively to allow us to eventually perfect it. Structurally, we also added a sort of “shelf” for the breadboard as well as for the Arduino towards the top and back, in a way that would make sense to connect the wires.
Many challenges were encountered and addressed before and after the user testing session. When we built the original structure and tested it ourselves for the first time, we realized the placement the fan resulted in the blades making contact with some LEGOs, preventing it from working properly. We then deconstructed and reconstructed the top of our structure too many times to count, until this issue was resolved. During the user testing, someone accidentally pulled on the cable connecting our project to its power source and half of it collapsed. We then understood we must either change our material or reconstruct it to be more of a firm structure, and decided to use portable power (i.e. batteries) in order to avoid a repeat of this type of mishap. Since received a substantial amount of positive feedback on our use of LEGOs during the user testing, we chose to keep the latter option. Briefly before the user testing session began, we had also added some short written instructions on the machine. Nevertheless, as we wordlessly watched people use our product correctly, we noticed that they were not even looking at the instructions and we consequently decided to remove them for the final product – we found something we could simplify in terms of user experience. The final steps were to further strengthen it, make it taller and cleaner, and generally polish it. A major challenge we came across was a delay in the response of the fan to the sensor’s detection of a nearby object. At first we thought it might be due to the fan blade, so we changed it to a different one and the problem persisted. We then realized it might be in the code, so we changed the distance at which the sensor would cause the motor (fan) to rotate from 16cm to 10cm, and later from 10cm to 5cm. The project then worked perfectly – that is, until the final presentation of our project during which this issue unfortunately reared its head once more. The advice we received then was exactly what we had done earlier: to adjust the distance in the code for the distance sensor. Perhaps, given more time, we could have figured out the core issue which undoubtedly went beyond the code.
Once again, the goal of our project was to offer an alternative to children who do not have the ability or have lost the ability to blow air out of their mouths as easily as most can, all while incorporating the skills and lessons learned in class and during various recitations. The final product aligns with my aforementioned definition of interaction design, as it requires a human input (placing a cup under the fan and in front of the sensor) to deliver a particular and simultaneous response of the fan spinning and blowing air into the cup. Nevertheless, due to the fact that the sensor will detect more than just cups filled with hot beverages placed their specifically by a human and the fan will work nonetheless, the product in that case does not fit into my definition of interaction design. In the end, the audience interacted with our project as expected – even their smiles fit into our further purpose for it to have a cheerful aesthetic quality. If we had had more time, as previously stated, we may have been able to reach the root of the delay issue which only sporadically came up. Moreover, given more time (and LEGOs) we could have cleaned it up a bit more and hidden the electrical components better within a larger structure, for which we would have also needed the time to obtain more LEGOs. Another aspect we might have changed would have been the planning and organization of the LEGOs, to perhaps stack them in a particular way that would create a cheery shape such as a smiley face. Our primary setback during this project was a mental barrier in the sense that, as both my partner and I had no previous background in circuits, programming, or design, we felt at a disadvantage. By the end of this project I learned that this was an artificial setback as we were able to accomplish something that a few months earlier I could not have even imagined myself doing. Furthermore, I learned that there is no such thing as failure if one sees it only as an extra step to success: all the challenges we encountered we managed by being flexible with our design and idea. I therefore learned the value of not marrying the original idea and constructive feedback can be very helpful, as long as one is resilient and flexible.
Works Cited:
Daniel Rozin, Daniel Rozin, PomPom Mirror, 2015 from Bitforms Gallery on Vimeo, 4 Jan. 2016, www.youtube.com/watch?time_continue=2&v=yIx8RODt6F8.
Igoe, Tom. “Physical Computing’s Greatest Hits (and Misses).” Code Circuits Construction, TIGOE, 27 July 2008, www.tigoe.com/blog/category/physicalcomputing/176/.
O’Sullivan, Dan, and Tom Igoe. Physical Computing: Sensing and Controlling the Physical World with Computers. Course Technology, 2010.
Some images showing our progress/process:
