I find that it’s hard to have focused and effective conversations with non-technical people about open data, in large part because one of the key concepts involved is often described with an acronym (API) that abbreviates a phrase (application programming interface) which is itself totally ambiguous. This is the kind of problem that sometimes only gets worse as more words are thrown at it. Sometimes, more words aren’t what we need to better understand something.

So, I conducted an experiment at TransparencyCamp, and it turned out pretty well! The experiment was called “Draw An API,” and the instructions were:

• Someone describes what an API is.
• People draw what they think they’re hearing.
• Everyone discusses the results.

To make things more interesting, we threw in some PRIZE MONEY! (I started this off with five dollars for the very best drawing of an API. Quite a few others doubled down on this offer, to the point where we had a $70 prize pot. I’d previously had no good illustrations of APIs and I wanted one very badly. Now I have several good illustrations of APIs. These could be the best five dollars I’ve ever spent.)

Some of the results included: An API is a portal to magic, APIs are robot orifices (this one was mine), API is a helpful server, An API is like a cake factory (where you submit the right order, robots make a cake and you get a cake). The winner of the contest was API as a robot bartender, followed in second place by API as church (where people pray and, if their prayers are answered, things fall out of the sky).

In the top left corner of “API as a robot bartender” is documentation indicating the various kinds of valid inputs. In the bottom right, a patron has incorrectly requested ‘PONIES!’ and receives an error message, so it must be reformatted.

There you have it! Draw an API is easy, fun and educational. We saw lots more ideas too, like APIs as librarians and APIs as contracts.

An observation: The drawings seem to fall into two broad types. On one hand, we saw a lot of simple technical metaphors — very useful. On the other hand, we saw a lot of depictions of APIs as fantastical mystery — this is also useful! The challenge of technology education (for adults, at least) is often one of demystification. An important step in that direction very well may be to make it safe to laugh at our own mystification (or, for the wizards among us, to be reminded how mystification feels). The next step may be to draw some more.

This Sunlight Foundation training video on what an API is also very helpful in explaining how APIs deliver government data. Thanks to all of our participants and thanks especially to Amy Cesal, Josh Tauberer and Gray Brooks for facilitating our conversations about APIs.

(NB: No government officials gave or received any money during this exercise. Hugs, however, were administered freely.)

I’m sorry I was a poor session leader and neglected to collect names of the drawers — if this is your drawing, please be in touch so that I can credit you.

If you conduct this exercise with your own community and come up some great results, please share! Some of these ideas went into the federal government’s own summary of all things API, at 18F’s Github repo — check it out and add your own here. Check out 18F’s great Github page about APIs here.

Greg Bloom is a community organizer and cooperative developer who works on researching commons-based approaches to community wealth-building. You can reach him at greg.bloom@gmail.com or @greggish

Interested in writing a guest blog for Sunlight? Email us at guestblog@sunlightfoundation.com