Category: Intro to Physical Computing

For this week’s lab homework, we were asked to create a simple application using digital or analog input and digital output. Since we were working on analog input in class, and already worked on button press input, I was interested in getting some more detailed input besides on or off.

I wanted to do a little “LED Meter” that could visually measure analog values. This way, I could plug in different kinds of sensors and immediately see feedback on if they were working or not.

LEDs! More LEDs! More more more!!!

I populated my breadboard with 8 LEDs, with the 8th and final LED being green. This would represent hitting the ‘top’ value.

Then I added a potentiometer with a knob to control the lights:

Yes, yes, I know my hand is in the way. I definitely had some issues with ‘jittery’ values. After playing around with the jumper wire, I developed a strong sense of superstition and paranoia about how I was touching my piece. Bumps and jostles seemed to produce ‘floating inputs’ as described in class:

0? 1023? 404? Back to 1023? Not what we want.

I wanted to move on and play around with a force sensitive resistor that is laid out like a strip. I changed up the code for the lights to more clearly depict a ‘position’ within the interaction paradigm. More or less pretty fun interaction as I had imagined it:

However, it seemed like my noisy, floating input issues were even worse while trying to set this up. From what I gathered, it didn’t seem like an issue with the circuit plan, but implementation.

At first I went with alligator clips to clip onto the FSR leads, clips to wire, wire to bread board. It worked ok… until I slightly nudged it and it all went to hell. Then I decided to use some special male to female jumper wire I bought a while ago. Which definitely seemed to help, but not all the way. Still needed to implement a sophisticated solution to reduce movement. That is to say, cover everything with tape.

 

After all of that, though for the most part better, I was still having issues with jumpy input. I managed to refine my code to exclude some of the lower, less reliable values. But I definitely will be asking in class about ways to securely connect sensors that don’t easily plug directly into the bread board. I was going to have a little more fun with this one, but the fragility of the system prevented me from moving the arduino/breadboard/sensor system around as needed.

We were asked to critique a public technology interface for our PComp homework. I chose a set of public facing glass, plastic and aluminum can recycling machines.

The broader shot of these machines is important for a few reasons. When you put in your recyclable items and finish, you are given a paper receipt. That receipt is redeemable at a grocery store to the left of the machine bank. Many people bring multiple kinds of items, meaning that they weren’t just using one “glass” or “plastic” machine, but might go from one to the other. All of this takes place on a larger than usual New York City sidewalk. The white and blue plastic barrels are almost always there, and reside close to the machines for a reason I will explain later. And finally, as can be seen in the photo, the grocery store has a basement storage entry port directly to the left of the machine bank.

My assumptions for critiquing this interface lied in how well the machine might work, if the buttons and interface were legible, etc. However, the more I watched, the more I realized there was a higher level issue with space around the machines themselves.

The interface is pretty straightforward:

As you put in items, the are accepted by the machine and tallied in amount on the screen. If there is an issue with the machine accepting the item it spits it back out.

When you are done, you press the green button to get your receipt and collect your money at the store next door.

 

More or less straightforward. One issue I noticed was that there seems to be some kind of internal limit for each receipt. If you pass that maximum amount, it would spit out a receipt abruptly and start a new transaction. This didn’t seem to phase people who hit that limit, as it seemed they expected it. The bigger issue was when a machine had trouble verifying the item entered, and then rejected it.

Most people seemed to use these machines for around 4-8 minutes. No one used it for less than three minutes, and the longest time was 19 minutes. However, in that particular case, that is strictly machine use. That does not count the wait to use the machine, and then an additional 5 minutes to get the money from the store next door.

There seemed to be more casual users that had less items and took less than 10 minutes, and then users that had lots and lots of recycling that would take longer than 10 minutes.

Everyone has to put in their items one by one, which seemed like the biggest design flaw. Because not only does it slow everyone down, but the people who line up to wait are also taking up lots of space.

The grocery store is next to a subway stop, so space is at a premium. As you can see above, when trying to take discreet photos, it was hard at moments just to get a clear shot. Many people would walk up to these recycling machines to use them, only to turn away upon seeing the scene. I assume this is because of the waiting time, if they saw a user with many recyclable bins and bags, but it also seemed that there was no real space for them to wait with their large collections.

 

I noticed a user with multiple bags, taking the most time and space 20 minutes into my observation. She started shaking the machine, rocking it back and forth. She knocks on the door the grocery store and calls for an attendant. Someone comes out, also shakes the machine, and then opens it up:

Inside of the machine is a plastic bin with the shredded recycled contents. The man then empties that into one of the big plastic barrels in front of the machine bank, returns the bin to the machine, and locks the machine up. This means that the plastic barrels need to be close enough to the machines for the attendant to dump the contents into them, but that means they are directly in the way of the users. Because many people with large volumes of items use these machines, I saw this process occur two times within 40 minutes of observation.

Also note in the images that the basement access hatch is open, and the user’s cart with big bags attached is next to it. Definitely impeding flow and access to the machines.

There are some interesting workarounds to a machine rejecting an item. Plastic bottles seem to have an issue when crushed too much, so people will put their mouth to their hand, and then their hand to the bottle and re-inflate it, which usually worked. Also, a specific user showed up with rubber gloves. When she had issues getting a bottle to be accepted, she combed through the broken glass bin to find an intact bar code label. She carefully peeled it off the broken glass, spit onto the backside of the label, and then attached it to the other rejected glass bottle. It got through.

On the surface, this machine and its interaction work fine. If you walked up to it with a bottle you wanted to recycle, it would most likely be a decent user experience. You would put in your bottle, and the machine would verify it. If confirmed you could immediately press the only green button on the machine, have a receipt printed out very quickly and walk immediately next door to have it redeemed. If rejected, you could try a couple more times. If it didn’t work after more attempts you would know that it wouldn’t take your bottle and you would move on.

However, the average people who use these machines have many, many items. There should be a more efficient way of verifying them, ideally in bulk or maybe a conveyor belt type system. No one is really using these machines for a few cans. It is a garbage bag full, at least. Every delay adds to the line, which reduces the space, which makes flow more difficult, and all this make users give up before they even reach the machine.

Even users who are done, like the one who took the longest at 19 minutes, can still impede the process through no fault of their own. Because the adjacent basement doors were open when she was finished, she didn’t bother to move her things to the left to go to the store. It was plain to see it would have been too much work, so she just left her things there while she waited for her money.

People seem to go to great lengths to get money from this machine, so it seems like common decency to make the design as seamless as possible. But besides that, I think that there is a class of user that is so familiar with the process that you might be able to make the interface somewhat more complex in the interest of saving time and/or space.

Crawford might call out a an excessive lag in response; if you didn’t account for hundreds of items you might think that a second or two delay in processing was acceptable but in the long term it isn’t. Norman might call for physical affordances that accommodate space needs; making space for multiple people with large carts and multiple stuffed bags. I imagine that both would account for the actual user population’s needs and knowledge level; repeated bulk deposits from repeat customers, not one off small deposits.

This week’s blog for physical computation was a request to document our lab work. After having gone through the basics of electricity flow and Ohm’s law (and maybe re-reading some of the concepts a few times…) we have started turning on LEDs, and are moving into making switches. But before we get excited about all the shiny possibilities, let’s set up our board properly.

What is the equivalent of “Measure twice, cut once,” but for electronics? Benedetta has done a great job warning us about consistently removing the power while working on our circuits. First, I want to make sure that my LED lights up without too much juice, so I have the trusty ol’ 220 Ω resistor protecting it. And with power, it lights up.

Now we can add a button in the middle of this chain and to see if we can create a light switch.

And the test…

Success!

Now that I know the LED can turn on (without any smoke or funky melting plastic smells), and get toggled on and off with a normal push button switch, I went about to creating my own switch type mechanism.

 

I like the idea of switches that aren’t necessarily buttons or levers or toggles. Conductive surfaces can allow for a kind of “presence” sensing that is effectively seamless. I came up with an idea of a switch that might work like an ID that you would dip into a card reader. When the ID was successfully entered into the machine, a light would confirm.

Materials: card stock wrapped in tin foil, a folded piece of cardboard, some tape, and some wires to bring signal back to the breadboard. I assumed that tin foil was conductive, but just to make sure I wanted to test. (Who am I kidding? I just wanted to try out my fun new multimeter)

 

Next, the wires are placed where the switch was. Coming off of the resistor, one wire is punched through the bottom right of the cardboard enclosure. Then continuing onto the LED, one wire is punched through the top left of the cardboard enclosure. Differing heights and sides made sure that the two wires would not accidentally touch each other on their own, complete the circuit and create a ‘false positive’ for lighting up the LED.

Fun stuff! Easy to forget that you can make all kinds of interactions with tape, paper and foil. After I made this, I definitely kept thinking about all the different variations and elaborations that are possible when working from this basic concept.

For our first Physical Computing reading, we were asked to respond to Chris Crawford’s first two chapters of his book “The Art of Interactive Design”, and then a blog post from Bret Victor titled “A Brief Rant on the Future of Interaction Design”.

What great readings! I found myself questioning my understanding of the concept of interactivity. Crawford seems correct when he says the word can be used carelessly, and I’m sure all of us in class may have a bit of fun critiquing each other’s definitions. Most likely because the word gets thrown around so haphazardly, as Crawford points out. Since we are in the Interactive Telecommunications Program, it seems worthwhile to define our terms (or at least investigate them).

Crawford’s cranky tone initially put me off, but he reveals the comedy in it with a great pace. He is opinionated, utterly convinced that he is objectively correct, but by the end of the first chapter is willing to let someone else step in with their own opinions and is willing to accept that he may be wrong.

This can be funny in one sense; “I am 100% correct and anyone who disagrees is objectively wrong… but what do I know? ::shrug::”. It is funny to make such an abrupt change. But I think it may also point to a broader point: there may be a certain amount of potential ambiguity about what “true interactivity” is, but if we’re going to roll up our sleeves and start building we should have some solid frameworks about what we should be trying to achieve. Make some definitions so we can focus on them and not get distracted by things that lie outside of that definition. Essentially, maybe at the end of the day these things are more “subjective”, but we benefit from treating them as if they are “objective” and fixed even if we know that they aren’t. Crawford isn’t necessarily contradicting himself, I think he believes both at the same time.

Bret Victor’s post was also very enlightening. It is easy to get wowed by “visions of the future”, especially with such slick production values as the Microsoft video he linked to. To watch that video first and then have Victor pull the rug out from under us is entertaining. So much of what we think of the future isn’t fantastic enough. Exploring a little bit of the history of tech speculation was great, and exposing the through line of the Microsoft concept demo was insightful interactivity critique. The current zeitgeist is “pictures under glass”. Such a succinct way to describe it.

I read Crawford first, then Victor. Crawford emphasizes his “Listen, Think, Speak” model of interactivity. To exclude things he says aren’t interactive, he uses the example of a rock. Just because you throw a rock and it makes a sound, doesn’t mean the rock is “interactive”. While reading I was taking notes and at this point immediately wrote down “book”. Would Crawford think that a book was “interactive”?

Sure enough, he went on to talk about books, but used what I thought was a bit of a strawman argument. Essentially his argument is, “Some say reading a book makes you have emotions, which they falsely describe as author/reader interactivity”. But that wasn’t what I thought of at all. And then when I read Victor’s blog post article, there it was:

“Notice how you know where you are in the book by the distribution of weight in each hand, and the thickness of the page stacks between your fingers. Turn a page, and notice how you would know if you grabbed two pages together, by how they would slip apart when you rub them against each other.”

I was having trouble putting my feelings into words, but I think this is what I was thinking when I thought of a book being interactive. But is that “true” interaction?

Crawford’s definition certainly seems to orient itself more towards computers and digital technology when he uses the term “think” in his second step of interaction. A book doesn’t think. A rock doesn’t think. Not interactive. But what about a drum? A guitar? A piano? It is hard to say they “think”. And at the end of the day, when you use them you are more or less just hitting them in certain ways. Maybe not so different than throwing a rock.

But are we really ready to say that a piano isn’t “interactive”? A piano can “listen” to the finger motions of the user, then might be described as “thinking” via the internal physical arrangements that are carefully placed to process the intent of the fingers, and then “speak” to the user by delivering the sound outwards.

Would Crawford think I was cheating? Or are the fingers simply hitting keys, and the keys pulling hammers, and hammers hitting strings? A cascading of rocks hitting things and making noises?

 

With all of this in mind: the homework questions.

How would I define physical interaction? When describing the listen/think/speak system for defining interaction, Crawford mentions that “think” is being used purposefully instead of “processing”. I might propose putting it back in: listen/process/speak. This might avoid some of the tangles when thinking about “analog” interactivity. Though, like Crawford, I’m ready to hear other opinions and change my mind!

What makes for good physical interaction? While Crawford warns us against conflating reactivity with interactivity, I think that reacting/response is at least a component of interaction. High quality responses seem to make for good physical interaction. Utilizing appropriate senses, maximizing amount of appropriate information delivered, minimizing time delivering information, all strike me as “high quality” responses.

Are there works from others that you would say are good examples of digital technology that are not interactive? This question was a little tough since my head is still spinning between Crawford and Victor’s thoughts. For now, trying to stick a little bit closer to Crawford, I mght use the example of a 3D printer. It doesn’t really “interact” with the user, as much as perform clockwork motions by rote instruction.