It was my intention to take the Mad Libs / Karaoke machine I created for my interactive narrative assignment and deploy it in a public space.
The first problem with this is that it would require a bunch of equipment. Perhaps I could do a performance with it in a bar, but definitely not in Washington Square Park.
I started thinking about ways to move the program online and enable the collaborative “storytelling” gag I used in class. One of the ideas I had was a simple web site that would ask each successive visitor one of the questions. When all of the questions for the current “story’ were exhausted, I would be notified by email and could perform the song in a video recording and upload it, which would then notify all of the participants.
PHP and Me
The site would be driven by some PHP code, I thought. After breaking the problem into a number of small pieces, I spent a bit of time trying to work out the little prototypes:
- Loading items from a text file residing in my web directory
- Displaying a form on a webpage that could post its results to another portion of the script
- Saving users’ answers in another text file and keeping track of the current question (later working out how to deal with multiple simultaneous users)
- Automatically generating email when all questions were answered
How hard could PHP be, I thought? It was easy enough to find documentation about reading and writing files, and I got pieces of that working without too much trouble.
This is not how I should have begun, however. Eventually, I had the sense to recall Amit Pitaru’s strategy for moving forward on a project: figure out how hard it is going to be to do something before doing it. This, coupled with Wendy Richmond’s strategy to keep doing easy things, led me to type “madlibs php” into Google. No sense in learning how to write madlibs if it’s already been done. I’m not here to learn another programming language. I’m here to learn how to prototype things quickly. So… I dumped code onto my site and within moments I had a PHP-based madlibs game running. I hated it immediately. It lost the feeling it had when I performed the first version of the piece in class. I could no longer experience the entertainment of people shouting out goofy answers to the questions. The web was not a good setting for this performance — at least not as I was envisioning it.
Again, a personal admonishment that bears repeating over and over again: when prototyping, look first to find out how hard something is going to be — and whether there is already something that will get you close. Hack!
Back to the Drawing Board
I decided to search for other ideas for public pranks / performances. The following are images from my notebook. If you want to see captions, please click on the images.
I would like to play around a bit more with the LCD screen idea, since I spent some time over the summer working with character LCD screens. I’ve also started putting together my first XBee radio breadboard.