[Update to the Serial Lab Part 2 exercise at the bottom of this post.]
Our observation exercise blog assignment involved picking a piece of interactive technology in public, used by multiple people, and then describing the context in which it’s being used. We would then watch people use it, preferably without them knowing they’re being observed, taking notes on how they use it, what they do differently, what appear to be the difficulties, what appear to be the easiest parts. Then we would record what takes the longest, what takes the least amount of time, and how long the whole transaction takes.
Okay cool, so I could have done an ATM machine or something. And I will, later. I promise. But I just HAD to write something about that god damn elevator in my building. See, it’s not that the elevator is broken, or that it is so barely functional that you’d be better walking up the 7 flights of stairs of the small building. The problem is that it’s just annoying ENOUGH to make you think about it incessantly. I’m not even OCD and I swear, using this thing is like dealing with some ornery cat or with a freaking mule at a water crossing. I mean, don’t you hate it when you’re trying to drag your fucking mule across the river?
I’ll get in the elevator during non-peak times and it’ll work fine. I was warned by the woman I rent from NOT to touch the gate. Here I am thinking that it’s going to trap me like in Alien or like that Tom Selleck movie where the robot spiders are after him. DON’T TOUCH THE GATE. The elevator has a gate! That’s enough to make you stop and pause because it was probably made back before they had building codes against crushing tenants in faulty coal mine-era gate technology.
So you press the button to pick your floor and the gate closes on its own. You’re in a small box. More than 3 people fitting inside? Nope. 2 people with bags? Forget it. I’m not really sure there’s a ceiling panel to get out of the damn thing if it stops between floors. No John McClane exits.
Fair enough. Things start to go wrong when multiple people are involved. I’ve been puzzling over the internal software logic in the thing. Did someone actually code this? I’ve gone from the 1st floor, pressing 7, and then the elevator stops at 5 and someone is there waiting to go down. I’m not sure that it’s going up to 7 after because I had to hammer the button while on 1, and it didn’t light up to give me feedback about whether it was pressed or not. So I’ll get out at 5 and walk up the 2 flights of stairs, only to see the person who got in at 5 up there because the elevator kept going up. Sometimes the elevator will stop at a random floor, like 4, and no one will be there. Was anyone there to begin with? Did they just figure they’d walk down instead? Or was it a poltergeist?
See? I accept that it’s an old elevator. But I’m not sure I can comprehend some engineer working out the logic and saying, “You know what’d be good? If anyone on any floor could interrupt the elevator’s direction at ANY time.” The other part is that the floors are not far enough apart that walking up and down is completely out of the realm of possibility. So when you and someone else are trying to figure out which floor the elevator will go to next, you’re feeling guilty about being a lazy son of a bitch who didn’t want to walk two flights of stairs extra.
I heard a tale about the elevator (it even has tales!) that it broke one time and they closed it for a week because it wasn’t up to code. Apparently when it re-opened, the tenants could only see that they added wooden paneling inside, and no larger changes for the whole shaft. I should have asked what’s behind the panels — metal spikes?
Here’s the video. The elevator knew it was on camera unfortunately and decided to work just fine. Bastard.
Look! The gate is held together at one place with a couple plastic zip ties! Spray-painted black!
Alright, so also I remember reading about a Wells Fargo ATM design a while back and the write-up (now gone, but saved on Wayback Machine) was brilliant.
What I love about it is it addressed all those dumb concerns we have at the ATM. Different heights see the arrows on the sides in different locations, so a taller person has to stoop over to make sure he’s pressing the right side button. Then the button design is often too colorful and distracting and you feel like you’re Indy Jones in The Last Crusade stepping on the trap letter stones to spell Jesus in Aramaic.
Touchscreens and hardware durability have improved the process considerably. While some people are just not inclined to use ATM machines, other tech-savvy folks like me should not have difficult using the things. Ideally, no one will have difficulty using them, and I think the design team did a good job by making the buttons larger and simpler, and using the whole screen as possible inputs while keeping the interface clean.
The thing about the elevator and ATM machines is that they employ infinite hardware configurations and can’t be changed uniformly at one time. Technology is a gradual process in the real world, while it’s a luxury taken for granted online now that web apps can be deployed immediately and (with improving standardization of protocols and webdev kits) without large variation across browsers/operating systems in many cases. But tech and hardware, especially for such oft-used things as elevators and ATM machines, must be improved gradually.
For my serial lab I wanted to turn the serial reader graph into a beach wave, with Mr. Wilson the volleyball from Cast Away. It would have taken some wrangling, though, to keep Mr. Wilson on a wave, being drawn across the screen, without leaving a trail of Mr. Wilsons and so I didn’t follow through on it. The fact that the SerialEvent() function seems to be overwritten by draw() (like, when redrawing the background) complicates matters.
Below is a video I made of a crude mouse-like device from the example, employing a potentiometer, a switch, and an FSR. If you notice the readings, the switch’s reading would not change from 0, so I didn’t bother pressing the switch during the video. The code was supposed to fill the moving circle on screen when the switch was pressed, but for some reason I could only get readings (just fine) off an Arduino serial test. When I moved over to Processing, it was like the value was getting truncated off the end of the line.
Update: I sort of solved my problem with why Processing was not picking up the value of the 3rd sensor, the switch. In my Arduino sketch, I divided the other two sensors’ analog values by 4, so they’d fit within 1 byte (2^10 = 0 to 1023, while 2^8 = 0 to 255). I suspected that the last value (the switch’s digital value) was being truncated and thus wasn’t being picked up by Processing. The math was a bit of a mystery of me at first, but I think I figured it out, though I’m unsure of the language. Serial.println(“1024,1024,1”) sends a total of 13 bytes, and a baud rate of 9600 is not enough to send that many bytes. It can only transmit 12 bytes. Is it 12 (bytes) * 8 (bits/byte) * 9600 (updates/second) = 921600? Still a mystery: if I send “1024,1024,1”, why would Arduino show it fine in the serial monitor and Processing wouldn’t receive the same result?
I just know that when I divided the values by 4 in Arduino, then the switch’s values of 1 or 0 showed up in my System.out in Processing.