#device prototyping

Experience

This week in studio, we had to chose from a multitude of scenarios to generate three potential concepts and prototypes using Little Bits. I had never used Little Bits before, but after watching a quick introductory video, I anticipated the prototyping process to be reasonably simple. After playing around with the different pieces of the Little Bits, my partner and I chose to design a prototype that focused on when your roommate played music too loud. We knew that all of our prototypes would need the sound detector piece from our Little Bits, so our first step was to think about how we could bring attention to the roommate.

Figuring out how to use Little Bits for our chosen design challenges and brainstorming concept and prototyping ideas

Our first prototype set the sound sensor so that when a certain sound level was reached, the device would ring an even louder buzzer to notify the roommate. Another concept was a counter that kept track of how many times the roommate’s music volume met the level of sensitivity of the attached sound detector, as more of a form of documentation.

Top: The scenario drawing for our first prototype concept with a sound detector and buzzer

Bottom: A closer look at the individual pieces to the mentioned prototype (left to right): battery (power source), sensitivity adjuster, sound detector, and buzzer.

Our last concept was a little more mischievous because we decided to have some fun with the speaker attachment and MP3 player. If the roommate’s music met the sound detector’s level of sensitivity, the other roommate could blast their own music right back! 

Our Prototype Video!

My partner and I drawing out our scenarios for each concept of our design challenge

Reflection

This was my first time using Little Bits and it was definitely a pleasant experience. It exercised my creativity and imagination and was especially fun to play around with! I have never liked working with physical technology, favoring software in comparison, but this sprint was eye-opening for the fact that I witnessed my mind and hands create and recreate original things out of these Little Bits that I didn’t know I could. A problem my partner and I had with this sprint was thinking outside of each concept and not coming up with convergent ideas, like different forms of notification for the roommate. I think the next time I use Little Bits I’d like to have a bigger box set with more pieces to work with since the one’s in studio were limited to a set number.

What did I like most about this experience?

I think the simplicity and creative liberty that comes with using Little Bits is what made this experience so enjoyable for me. In the fifteen minutes that we had to experiment and explore the possible sequences and devices we could make out of these magnetic parts was so much fun, even humorous when different groups discovered how to make the little high-pitched buzzer work. I especially liked how the lack of complexity, creating little devices for a multitude of uses, managed to shed light on the bigger concept of low-fidelity prototyping and little ideas can grow in advancement and design to become something remarkable.

Device Prototyping

Overview

The purpose of this studio session was to build a low-fidelity prototype using littleBits, an intuitive electronics kit, in order to gain experience and familiarity with device prototyping principles.

What I Did

During this studio session, my group focused on building an anti-theft device prototype that would simulate vibrations and a sound indicator in order to show that the item had been stolen, which would hypothetically be remotely activated by a wireless control. My experience with the LittleBits kit was for the most part extremely intuitive, though we had some difficulties in sorting out some technical complications. For instance, when we were testing our function with our prototype, we weren’t sure how to actually activate the wireless functionality, which required some troubleshooting. We also had some difficulty simulating our scenario. We showcased a situation where someone would try to steal a user’s belonging, only to have their identity as the thief be tipped off by the activation of the anti-theft device by the user. This ended up being someone hindered by the portability of the wireless functionality being limited by the devices needing to stay plugged in, in order to work, which made the execution of the scenario itself a little more awkward than it could have been.

Here is a link to the video demo created for our device prototype for this concept.

Reflection

If I had the opportunity to do this project again, I would likely invest more time in coming up with ideas for a more interesting project beforehand. We ended up simply extemporizing on the base idea with the wireless functionality demonstrated with the littleBits in class, and adapting it to a marginally different situation, which isn’t terribly interesting or innovative at all. This may have been because we were fairly constrained by time, so we were more concerned with finishing the project and getting it done, rather than exploring littleBits and its capabilities to its limits. Having a solid, prior idea of what to do would have made it so doing the latter would actually be plausible, and would have made our prototype more intellectually engaging.

What I Liked

What I appreciated and liked best about this studio session was how it really demonstrated how quick and dirty device prototyping actually is. The idea of actually working with electronics to make a workable prototype seemed very intimidating, initially. Although our ease in building a workable prototype is largely, in part, due to the extremely intuitive and easy-to-use electronic kits we were given to work with, it did show that making a highly sophisticated, refined prototype isn’t necessarily required in order to showcase a concept. 

The colloquial idea of what a prototype actually is, from pop culture, movies and television, is very closely tied to the sort of prototypes we would expect from military construction and mechanical engineering. Although often highly experimental, rudimentary and flawed, these prototypes are still very close to the finished product, with strong visual and functional similarities. In contrast, what we built in studio session are were comparatively low-fidelity prototypes that would likely be very far removed from a final product, only conceptually demonstrating or representing certain functions. 

For example, in regards to the anti-theft prototype that we created, we used the moving rotor to simulate the function of a stolen object “vibrating” as an indicator that it had been stolen. The paper prototyping that we utilized in a previous studio session is another good example of this: although the prototypes were visually representative of what we would expect, they weren’t very durable or very functional.

Jeff discussed a research project that he worked on with one of his graduate students regarding determining the similarity of different disciplines based on algorithms constructed through Jeff’s work with machine learning and through consulting other professors with experience in neuro-linguistic programming; namely, in isolating and comparing similarity in sentence structure and words used. This aspect of the project, the subject of study, stood out to me. I thought the subject matter was interesting and worth investigating, and the data and relationships derived could be used to illustrate and determine many interesting things, such as the level of influence certain disciplines have on each other, based on observing how the bulk of academia in a particular discipline shifted over time.

             This research project’s investigation was accomplished by comparing and contrasting the determined similarities by disciplinary PhD research papers from Stanford from the past 16 years, and portraying the various relationships through a number of visualizations. One such visualization was a distance matrix which was very difficult to interpret, but contained all of the raw data in its most complete form. In order to make this more readable and distinct, through a process called dimensionality reduction, this data was reduced down to the form of a scatterplot. Unfortunately, this data seemed to have some complications. Although it demonstrated some interesting changes over time, it seemed to suggest certain relationships and conclusions that weren’t necessarily true when you examined these disciplines on an individual, focused level. Petroleum engineering, for example, was suggested to have a closer relationship with life sciences than it actually did, because of how the visualization portrayed the distance between the various disciplines in the scope of the scatterplot. This individual visualization analysis unfortunately had flaws as well – it would portray relationships that didn’t seem quite cogent in comparison to what was reflected in reality. For instance, English was portrayed as being virtually identical to other humanities fields and having no remarkable difference, which clearly isn't reflected in reality. All of these issues were accounted for in the final incarnation of the visualization for the data, which included both a comprehensive scope with an individualized focus by having individual papers and their relevance to different fields indicated. Additionally, in order to account for erroneous relationships being displayed when they shouldn't have been, experts in various fields would be consulted to ensure that the relationships being displayed were realistically and logically consistent.

Kristine discussed device prototyping in several stages and versions in regards to her own independent study project, EMAR, a robot designed to assess stress levels in students and teenagers as an alternative to the inaccurate data provided by surveys, which have been shown to be inconsistent with captures of real-time data. In designing EMAR, Kristine frequently referenced her user research skills; for instance, surveying the design and structure of robots already built in the real world and how they appealed to her target user group: adolescents. This was done in order to inform the final decision on shape and structure for EMAR. It was important to decide and isolate this design early, as making an early prototype was important and necessary. Early prototyping for EMAR was useful, because it would allow Kristine to close the gaps in data, due to lack of substantial research done on how receptive teenagers are to robot interaction, and see whether or not the idea is in itself a viable one.

One particularly interesting thing that I observed with Kristine’s methodology and research was that, although user research was an important contributor to creating and informing EMAR’s design, the prototyping process and feedback received from that prototyping, in turn, helped to facilitate her own user research, in informing what students wanted out of the robot, the sort of data to prioritize, and considerations that need to be made in regards to their mental health, how to incentivize usage of the robot, what should be changed about the voice, appearance, personality and interactions, and other things besides.