a thing we are constantly weighing is whether to build components from scratch or buy off the shelf. before deciding to build our own enclosure, we listed the components that needed to fit inside the box and went to the container store to find something that would work off the shelf.
we found a few shapes we liked:
but nothing that was the right size. we discussed getting two of the index card boxes and attaching them. for the work it would’ve required, though, we thought it would just make more sense to build something to the right dimensions.
in the end, we found a box on the junk shelf that was half of what we needed. i went to home depot to get the remaining materials we’d need to build the top half:
actual vs. prototype
the remaining element was a piece of super thin birch wood to replicate the curve we liked from the container store’s wine bottle enclosure. we weren’t sure how laser cutting this material would go, so dhruv tested some buttons and vent designs:
button and vent designs
we are experimenting with a tape sealant on the back to keep the scent from being absorbed by the wood when it leaves the dispenser.
we just had another round of user testing. dhruv wrote about a previous round; head to his blog for in-depth explanation and analysis.
here’s my (briefer) take:
some users thought both smells were good
some users thought both smells were bad
most users wanted more feedback and/or visual feedback
most users wanted instant feedback
in general, i think users found our device frustrating.
i attribute this to a few things:
the subjectivity of good and bad smells
how the framing of the device as a “teaching tool” sets user’s expectations around type and frequency of feedback
our team has some design decisions to make.
we also discussed framing our device to users not as a teaching tool, but as a singing practice accompaniment. it’s a thing that should make you want to practice more because you like the things it does: it smells good and it looks beautiful when you take it out of the closet/cabinet/desk. a thing that encourages you to practice more is, of course, a teaching tool in the end, but i don’t think it’s helpful to discuss it in those terms anymore.
we have another round of user testing in a week, so we spent some time today thinking about the shape of the device. we decided that the spritzers should be angled (instead of lying completely flat or standing completely vertically) to dispense the scent to the user’s nose most effectively.
to start, i just cut up an old box and arranged the spritzers inside. a diagonal piece of cardboard was sufficient to elevate them.
ultimately, the box i started with needed to be larger, with more structural support and a hinged lid. the spritzers needed more height, so diagonal supports with a steeper angle. the junk shelf had everything i needed. this is where i left things:
we went back and forth for a long time about which scent-dispensing mechanism to use. initially, the motorized one seemed bulky and overly complicated for what we needed. the motor would rotate CCW to lower the dispensing arm and then CW to raise it back up and stop dispensing. we didn’t think we’d be able to preserve that functionality when we ran it off the arduino. but we ultimately did decide to go with the motorized one because
gears are cool, and
it was actually going to be simpler to hack the hardware in this one than to build a fan to dispense the car air freshener, build a mechanism to open and close its vent, connect the whole thing to the arduino, etc.
once we decided on the motorized air freshener, we had to figure out how to bypass the button activation on the air freshener and control it with the arduino instead. dhruv writes about the process here.
dhruv put together this system diagram to show our device’s inputs and outputs. what inputs go to the arduino and what outputs does it return? what inputs go to our music software and what do those inputs trigger?
i created this user interaction flow diagram to help us design for all possible user scenarios.
user interaction flow diagram
from the user diagram, we realized that there are more scenarios than we’d previously thought and that we need to get more specific about how many scents we’re using and when each one is triggered. the matrix below is a visual representation of all four scenarios:
possible user scenarios
user starts out singing the wrong note and eventually finds the right note *this is the ideal scenario and the one we’d designed for already
user sings the wrong note through the whole interaction
user sings the right note through the whole interaction
user starts out singing the right note but eventually changes to the wrong note.
how does the scent-dispensing mechanism behave in each of these situations?
i went to kmart to research smell dispensers. they generally fell into these categories:
heat disperses the scent of oil or wax
spritzer dispenses scented spray
a fan disperses the smell of scented goo that sits in a permeable pouch
kmart’s expansive scent section
i went with a motion-sensing spritzing dispenser and a dispersal mechanism that works with a fan. these two give us more control over when we start and stop dispersing smells; with a candle or another heat-based mechanism, dispersal is slow and hard to contain.
scent dispensed by fan
when i got back to the floor, i took apart the motion-sensing spritzer. the construction is surprisingly simple and elegant: a motion sensor or button activates a battery-powered DC motor, which turns a series of gears, which pull an arm into contact with the scented stuff and ~*spritz*~
well. an unexpected part of my pcomp final experience has been learning about group dynamics. melanie, zoe, and i have decided not to work together. our collaboration was frustrating, but we’re all grown-ups and aren’t taking the group incompatibility personally; we’re still buds and have a lot of respect for each other’s work. no, seriously!
i’m grateful to be working with dhruv and viniyata on a thing that’s out of my comfort zone in a bunch of ways—think scent, music, motors, and indian classical music. so far, way fun. group chemistry makes all the difference.
yesterday, we brought in prototypes for the final to test on our classmates.
danny and tom both insisted on this one thing:
“DO NOT TELL PEOPLE WHAT YOUR INTENTION IS.”
they encouraged us, instead, to note what people do with our prototype, how they move through it, etc., without knowing our big ideas behind the project.
they also said that if no one understands the project and it feels like a failure, that’s good feedback. we were not supposed to correct people. just like we wouldn’t adjust variables and constants in the middle of an experiment, we had to keep the same script for every person and adjust everything at once after a round of testing.
i really like these constraints. i wonder how the expectations around instant understanding change whether you’re making art for a gallery vs. building a puzzle game vs. something else.
related: i like that in all of our classes, we are encouraged to think about where our project will ultimately live—on the web, on the floor, in the street, in times square, in a newspaper?
danny also said this brilliant thing:
“it’s easy to complicate things; it’s hard to simplify.”
i liked that joy brought a form to fill out, not because it necessarily makes feedback easier to collect but because then there’s record that you got feedback. important when you’re working on a team or handing off a project to someone else who wants to know what your process was.
melanie, zoe, and i all ran into each other at the radical networks conference a few weeks ago and decided to work on a data infrastructure project together.
we’re thinking about possibilities for visualizing the flow of data that surrounds us. in terms of physical structure, we’re inspired by this computational sculpture and these rubber strings. another potential direction would be using fog and light, like the illuminator collective did for this bust of edward snowden. this second option would be conceptually stronger for working with the issue of cloud computing.
i’m also thinking a lot about this stuff i found called electrosafe coolant, “a non-toxic, clear, odorless, dielectric mineral oil blend.” it’s used to cool server racks that store our bytes. especially as i think about some of matthew coleman’s work drawing connections between nuclear production and data center infrastructure—and slick, shiny, flat, fast, mostly meaningless tech buzzwords like “seamless” and “frictionless”; and the erasure of the means of production as well as the parallel ecological destruction on which that frictionless sheen depends—the non-toxic, clear, odorless stuff feels like such an apt object to think with.
anyway, marketing video for that strange product here.