Poetry in the Post-Now
Bowery Poetry Club
308 Bowery, New York, NY
May 8th, 2010, 12pm-2pm

This is going to be an amazing event. There will be performances, demonstrations, installations and readings from two ITP classes this semester: my Reading and Writing Electronic Text class and Nancy Hechinger’s Writing and Reading Poetry in the Digital Age.

This event is intended to be a showcase for the many text-, language- and poetry-driven projects at ITP, which are sometimes unsuited to the noisy glamor of the regular ITP show (which you should also attend!). I have been overwhelmed by the quality of student projects in both classes, and I’m excited to see them presented and performed.

A sampling of projects from my class: Ramones lyrics interpreted as code, Semaphore Hero, “tagrostics” (procedurally generated acrostics built from word frequency analysis), reading the Ramayana with regular expressions, procedurally generated Vogon poetry, poems composed by weather conditions, self-conversation mangled by Markov chains, physical interfaces for remixing movie subtitles, and more! It may not actually be possible for there to be a better way for you to spend your Saturday afternoon.

Here’s the poster in PDF format. Promotional materials designed by Ted Hayes.

The tally: the Twitter API holds steady with 26 nouns and 15 verbs. The Graph API, meanwhile, has 35 nouns* and 3 verbs—a tremendous improvement on Facebook’s old (so-called) REST API, which has 43 nouns and 24 verbs. The Twitter API and Facebook’s REST API average around 1.7 nouns per verb; the Graph API has almost 12 nouns per verb. What’s especially interesting? The Graph API has managed to sidestep any verbs that aren’t HTTP methods.

The Graph API is a big deal, and an important step forward for Facebook. Here are a few reason I think that’s the case.

First of all, the Graph API is dead simple, especially compared to Facebook’s old REST API. Just as an example: the old API has (by my count) seven nearly synonymous verbs (set, create, add, register, upload, send, publish) that all essentially mean “add content for a user.” These verbs aren’t interchangeable; each works with only a subset of nouns (or even just a single noun). Each verb has idiosyncratic behaviors, arguments and error messages. The Facebook REST API is, in short, a mishmash of conflicting conceptual models. It’s tough to get a handle on all of it.

Not so with the Graph API. Every resource has exactly the same interface. Once you understand what each noun is, it’s easy to understand how to manipulate it—there are only three possible verbs, after all!

The complexity of the REST API necessitated a client library to perform even very simple operations. The Graph API, on the other hand, is so simple, I think that most developers won’t even use a library at all—it’s easier to just hit the URLs directly. Simply put: if you know how to make HTTP requests, you know how to use the Graph API.

That’s the second thing that makes the Graph API so important—it’s the web. The Graph API isn’t just a bunch of function calls for retrieving information; it’s a set of URLs to representations of the data itself. The data is all in JSON format, so it’s easy for browsers to consume it directly. Image URLs return the images themselves, so they can be thrown right into img tags without an intermediary API call. Most importantly, the resources returned from the Graph API are hypermedia: they include URLs to related resources. An example (from the documentation):

{
   "name": "Facebook Developer Garage Austin - SXSW Edition",
   "metadata": {
      "connections": {
         "feed": "http://graph.facebook.com/331218348435/feed",
         "picture": "https://graph.facebook.com/331218348435/picture",
         "invited": "https://graph.facebook.com/331218348435/invited",
         "attending": "https://graph.facebook.com/331218348435/attending",
         "maybe": "https://graph.facebook.com/331218348435/maybe",
         "noreply": "https://graph.facebook.com/331218348435/noreply",
         "declined": "https://graph.facebook.com/331218348435/declined"
      }
   }
}

The URLs are right there in the document, meaning that you don’t have to know anything else about how the Graph API works in order to get information related to a resource. Pretty slick. It’s an idea that (I think) every web API should incorporate.

There are, of course, a few factors that mitigate my enthusiasm for the Graph API. First off, it doesn’t quite model the entirety of Facebook’s functionality yet—notably, there aren’t any resources (so far) representing Facebook applications themselves. There are also privacy concerns that need to be addressed (for example, event listings).

Overall, though, the Graph API is beautifully constructed. It’s just as robust as the Facebook’s old API, but simpler, more convenient, and easier to integrate. As a developer (and programming instructor), my opinion has always been that Twitter’s main advantage over Facebook is its developer-friendly API. The Graph API has the potential to erase that advantage.

* There are a number of verb-like words and verb participles in the Facebook “noun” list. I classify them as such because, to my eye, they’re clearly presented in the API documentation as things you can act on, rather than actions you can take. For example, attending means “users who are attending something,” and acting on that resource allows you to fetch or manipulate that list of users.

Text lathe prototype from Adam Parrish on Vimeo.

This is a little prototype for a textual interface that I came up with last week after receiving my nanoKONTROL. (I saw Jörg Piringer use one of these in a live electronic sound poetry performance last year at E-Poetry, and I knew I had to have one.) The idea is that two knobs on the controller determine how much text is cut from either side of a text fed to the program on standard input; another knob controls how fast lines of text are read in and displayed. It’s a very simple mapping, but I’m pleased with the results so far.

I’ve been in busyland lately, but I thought I’d post a quick update with a link to my appearance on Another Castle, NYC’s premier game design-related podcast. It was a really fun conversation! Charles and I discussed a number of things, including the Interactive Fiction scene, conversation (and language in general) in games, and games as texts. Here’s the audio file, but you really should go subscribe; the archives are amazing, and there’s a great new interview on a regular basis.

Gamerscore and achievements serve a similar purpose. They give you feedback on your play; they give you acknowledgment when you do something noteworthy; they let you know (in broad terms) how much of a game’s content you’ve completed; they let you compare the way you’re playing the game to the way your friends are playing it. Achievements are one of the reasons I prefer playing games on the 360 to playing games on (for example) the Wii: more feedback, more context, makes for a more fun gaming experience.

With a few notable exceptions, no one plays games just for the achievements. They’re not a goal in and of themselves. Likewise, no one “plays” Foursquare just to get the badges. Both badges and achievements are there to let you know that your activities follow a particular pattern. As an added benefit, badges and achievements you haven’t earned yet suggest what other patterns are possible.

I wrote this before I read Sirlin’s response to Jesse Schell’s lecture, in which we are urged “to be vigilant against external rewards” (such as achievements). “How resistant are you to letting others manipulate you with hollow external rewards?” asks Sirlin. Obviously, I am much more sanguine about achievements—I think that people like them because they are useful and fun—and hope to argue for this more effectively in a future post.

It’s pretty awesome.

Gizmodo has a good roundup of the technologies behind a number of commercial 3D displays. Take a look and you’ll see that none of this technology really has a chance of getting into the hands of artists, makers and hackers any time soon. Lumarca, however, is ready to go. Here’s the build instructions and source code.

• A quick post on Warp Skip concerning Nick Montfort’s recent work in the ludonomastics of Zork.
• Friend and colleague Brendan Berg posts an informative follow-up to my recent comparison of Pokémon and PHP.
• When Leonard Richardson and I recorded our conversation about Scribblenauts a while back, the portions of the conversation that concerned Earl Grey had to be cut for procedural reasons. Now that IFComp 2009 is over, Leonard recently posted the missing segment of the conversation, in which we compare the mechanics of Earl Grey and Scribblenauts.

The former is a matrix of arbitrary values intended to produce convenience. The latter is a matrix of arbitrary values intended to produce fun. In my experience, neither achieves its goal. But both follow an arbitrary logic, strangely twisted through history and culture, that might someday make a good subject for a Ph.D. thesis. (Why does a non-empty string equate with integer zero? Why is Psychic strong against Poison?)

A few of my favorites:

What kind of tree is nauseated?
A sick-amore

What do you call a cross between an emporium and a success?
A department score

What do you get when you cross a choice with a meal?
A pick-nic

More examples here, and an online version is promised soon.

I like to read programs like this—programs that generate text conforming to a specific genre—as a kind of ethnographic criticism. The Joking Computer describes a particular type of joke by observing how jokes of that type are formed and used in our culture, and then formalizing the jokes as a procedure. The procedure itself serves as a statement about how that genre of text works: its structure and its limitations.

The Joking Computer specifically, and text generators in general, also manifest the nature of the data that they’re built upon. Take this joke (please):

What do you call a washing machine with a september?
An autumn-atic washer.

This joke shows the gaps that exist in the program’s data, and the unique way in which the program uses that data. First, the program doesn’t have a way to know that a washing machine isn’t a kind of thing that is likely to be “with” a “September” (or that September isn’t a noun likely to be used with an indefinite article). Second, the relationship between “September” and “autumn” depends on the eccentricity of WordNet, which claims that there is a meronymic relationship between the two concepts. The joke is constructed on the basis of the fact that September is a “part of” autumn—which certainly makes a kind of sense, but isn’t necessarily something that most people would intuitively agree with. The joke, as a consequence of (at least) these two factors, seems stilted and alien.

Then again, stilted or not, I happen to think this joke (“autumn-atic washer”!) is hilarious, and that the humor stems at least in part from the gaps in the data and way the program uses that data. Jokes, after all, are funny when they provide surprising juxtapositions or reconceptualizations of things in the world, and the program delivers those in abundance.

Poems succeed when they make use of similar juxtapositions and reconceptualizations. I think that this is why generative text programs are most effective when they are designed to generate text in these genres (humor and poetry). These programs succeed just because they don’t perfectly model the genre they set out to emulate.

In other genres, like conversation or narrative, surprising juxtapositions are less valued, or even specifically forbidden. I think that generative algorithms in those genres tend to be less successful for this very reason. But that’s a subject for another post.

(The Joking Computer via, more info)