I was planning on writing this blog entry tonight, but then Peggy asked for it as an assignment today. Ahhh, serendipity.
My Ikea cabinet mod was a photobooth. Specifically, it was an IMD photobooth - users open the cabinet door, smile for the camera, and the picture is uploaded to Flickr with the tag "IMD". Pressing a button on the inside of the cabinet would be the trigger to light the LED sticks, and take the picture.
We were assigned the project Tuesday evening. I spent Tuesday and Wednesday thinking about what I could do with the cabinet. I started off by thinking about what I liked and didn't like about last year's projects.
Lots, lots more after the jump
The two that stuck out for me were Noah's and Rick's. The former because it was repeatable, and reacted to the user; the later because it jumped beyond the platter. I wanted something that would be both of those. I thought about different interactions with the cupboard itself (really, just opening and closing it), and how I could build an experience around that. I also thought about things that the cupboard could represent, depending on the orientation of the cupboard. When I thought of what could happen if somebody stuck their face in to the cabinet, the first thing that came to mind was "photobooth". It just seemed like the right fit for this. So, for the record (Mark Bolas), I had my plan on Wednesday around 1:00 PM.
By 2:30, I'd found software online that was a demo version of a commercial photobooth software package. I'd ordered a good webcam, and was searching for a cheap printer. I was also playing with the software, and saw that it had a hook to automatically call batch files. That got me thinking about uploading the picture to flickr, instead of printing them. Once I found the uploadr.py python script that could handle this, I scraped the printing idea entirely. I also upgraded my flickr account to pro.
By Thursday morning (again for the record I.E. Mark Bolas), I had a prototype running. Photoboof would take a picture, and call a batch script that would upload it to my flickr account. I had 2 problems, though - Photoboof would stick the world "demo" all over the photo, and the batch file wouldn't run python properly when called from Photoboof. The first problem would cost $600 to fix, and the second one looked like a Photoboof specific issue.
In class, Perry suggested using Max/MSP to replace Photoboof. I had to use a PC in the lab to do this, because my aging laptop couldn't run the Max/MSP patch that would do the photoboothing. I used the PC at Brazil's desk, since Max wasn't running on my PC. I figured I could fix that later in the week. More about that mistake later.
On Friday evening, I had the Max/MSP patch up and running, but not talking to the Arduino board. I'd broken down the project in to three phases - Max/MSP & uploading, triggering max from Arduino, and physical construction. I wanted to finish the Max/MSP bit first. There is a Python plug in for Max, and I spent all Friday night and Saturday, wrestling with it. I used the Max forums to ask for help, and had an email exchange with the guy who wrote it (he lives in Austria, btw). I still didn't have it working by 11 PM on Saturday, when I left the ZML. Sunday was spent doing my first round of supply runs, so I didn't get in to the lab. I did, however, think of a work around. I'd already lost too much time with one component, and time was a really limited resource. I didn't need Max to automatically call the python script, I just need something to make the call. I found a free scheduler program, that ran in the background on the computer, and it did it every minute.
I'd also protoyped the physical aspect of the project on Saturday. Taking a break from programing, I set up my cabinet and went through the motions of using it. I tried it sitting down, and standing up. I thought about how I'd start the picture process. My initial idea was to have people be surprised by the photo, but I realized that I'd lose my "repeatable" goal. I also needed a button to start the process, rather than the door opening, so people could get ready for the pictures. Most importantly, this is where I learned I'd need instructions printed on the door, telling people to stick their face in the box. Without instructions, people would look at the box from outside, instead of getting inside it.
On Monday, I had the Arduino script up and running. Monday evening, I did all the spray painting and cutting I needed to do, since I'd need it ready for construction the next day. On Tuesday, Perry showed me how to build the circuit I wanted, and exactly how Arduino and Max talked. Tuesday evening, at 11:30 PM, my project worked. Perfectly. The user would press a button, Arduino would turn on the lights, Max would take a picture, the script would upload the image to flickr, Arduino would turn off the lights, and the whole process would wait until the next button push. I also had my cabinet assembled. That bears repeating - my project worked perfectly on Tuesday night. All I had to do on Wednesday was moved the equipment inside the box, sodder longer wires on to my button, and hook it up to Max on my PC.
Here's where I really screwed up. I didn't leave enough time on Wednesday to get this working. Just because it was working on Brazil's PC, didn't mean it'd work on mine. In the process of moving the equipment and setting it up inside my box, I shorted out my Arduino board. If Perry hadn't had a spare on him, I would have had to give up and transfer to Critical Studies. And Max /MSP wouldn't work on my computer. At all. It would crash when it tried to load jitter. I finally got it working, midway through the presentations, but then it wasn't running my patch properly. I was able to run the project manually, but it would have been much cleaner if it was running in the automated state that I had the night before.
The kicker is that Max was running my patch correctly. The problem was that I, panicking from desperately getting Max fixed, and running on four hours of sleep (I'd been up until 4 am the night before, playing with python, to see if I could get it to transfer to the IMD stream instead of just tagging the photos with "IMD"), wasn't thinking clearly. A simple fix (changing serial port from c to d), was bungled, and I wound up getting hopelessly lost.
Bottom line is I had my concept working (photobooth that uplaods pictures to flickr), but I didn't have it running as well as I wanted it to (automatic photobooth that uploads pictures to flickr).
I was tempted to blame my Max/MSP computer woes on not having Max readily availble on computers other than the Apple Mac's in the lab, but that's not the problem. I knew that I would have to get Max/MSP fixed on my machine. It was a critical component to my project. There were other pieces of my project that I dropped (LEDs lighting the instructions, clicking noises when the photos happen), but they weren't critical to it working. I should have got that fixed BEFORE doing any work. Leaving that to the last minute wound up embarrassing me during the presentations.
So, here's what I learned:
1. Make sure all critical pieces can work. Do this before you build any of them. I'm not talking about building each piece, I'm talking on making sure that you will be able to build each piece. I had other critical pieces to work on, besides Max/MSP, so I did. That was a major mistake.
2. Elegance in execution doesn't matter, it's what the user sees. If I'd thought about this while playing with Python in Max, I would have saved a frustrating day of work.
In terms of expectations, I'd give this a 9/10 if I was grading it on Tuesday evening (losing 1 point for not getting pictures sent directly to the IMD pool). If I'm grading on Wednesday during the presentation, then it's a 5/10.