It may not be obvious from, well, anything I write or do or say these days, but I started my undergrad freshman year in the Computer Science department of my university. I was going to become a video game designer after mastering the exciting world of programming, and I was going to do so by skipping half of my computer science classes and nearly all of my calculus ones in order to… play video games.
Needless to say, I did not do well in the Computer Science major.
Which is a good thing, because if I did well in Computer Science (or at least in showing up to class), I’d probably be absolutely miserable right around now. Not because that line of work is generally dreadful (although it very much can be), but because my brain isn’t wired for programming’s precise, mathematical reasoning.
My brain works best and happiest on loose problems. It shows in my teaching every day: we set out to answer a question—usually an impossible-to-answer one like “where does our imagination live?” or “How do we keep a reader interested? (and do we even care about readers in the first place?)” For me, it’s less important to actually solve a problem than it is to attempt to solve it, since that’s where all the enjoyment of learning and living comes from. I’m a perfect fit for a humanities department. Not so much an engineering one.
It’s with this in mind that I turned to my next step on my planned journey of digital storytelling after my Twine story: Encoding poetry.
This was something of a double bind for me. I’m not much of a poet—I’m not sincere enough of a person. And, well, the coding.
So it should come as little surprise that the first thing I did when trying my hand at Processing (a self-described “software sketchbook” for java and other visual-programming languages) was simply print the poem I’d written. The lines of code looked a little something like this:
The issue was moving from simply printing that code to then forcing it to come across the screen at the time I wanted it to. My goal was to reproduce the kind of forced interaction that I’d experienced in other encoded poetry, like Annie Abraham’s work. That meant two things: the text to appear on click (simple enough), and the text to appear “typed out.” In the poem, which you can read at the bottom of this page, the speaker is the machine itself, interfacing with you—that doesn’t work if it’s a single page of text that you can read at your own pace.
Digital storytelling is often about control. Here, it’s about wrestling control away from the reader.
The issue is that I had no idea how to do that second part. I looked at examples, and while there were methods of making Processing print each letter in a different font size or capitalization, the actual act of printing each letter individually was either going to be a painstaking number of individual print commands, or was simply outside my immediate wheelhouse. This was problem with a concrete solution for sure: the answer was in the code database, and if I found it, it would work just as I would want it to.
But, like so many of my students, I wasn’t yearning to go through that process.
So I didn’t.
I gave up.
Or, well, I gave up on Processing. Halfway through a ninth or tenth coding-wiki page, I’d remembered something a friend and colleague of mine, Spencer Bennington, passed on after a summer at DHSI (and which he’d learned from John Barber). The core idea was: If you know you can do something with a simple software, why would you use a difficult software to do it? If the most important thing is the story or poem you’re trying to create in the first place, why add an extra barrier to that story or poem’s birth?
So it’s with that careful consideration/desperation that I present to you, in Powerpoint, “Please Compute:” (this links to the Powerpoint Online version; the below should run just the same).