Report from the Digital Public Library of America Appfest

Add one part stress test of the Digital Public Library of America’s API, one part conceptual exploration of how DPLA might work, and one part interdisciplinary collaboration contact high, and what do you get?  The DPLA Appfest on November 8 in Chattanooga, TN.  This day-and-a-half event brought together developers, designers, and librarians from across the US and Canada to build apps on the DPLA platform.  (For more on DPLA vision and scope, see previous TechConnect coverage.)

Our venue was the 4th floor of the Chattanooga Public Library.  This giant, bare-floored, nearly empty space was once an oubliette for discarded things — for thirty years, a storage space.  Now, mostly cleaned out, it’s a blank canvas.  New Assistant Director Nate Hill has been filling it with collaboration and invention: a startup pitch day, meeting space for the local Linux users group, and Appfest.

Chattanooga 4th Floor, waiting for Appfest
Thursday Evening

The first night of the event was reserved for getting-to-know-you events and laying the groundwork for the next day’s hacking.  With several dozen attendees from a variety of backgrounds, some of us were already good friends, some familiar with one another’s work online, and some total strangers; the relaxed, informal session built rapport for the upcoming teamwork.  Tables, sofas, snacks, and beer encouraged mingling.

We also started the intellectual juices flowing with project pitches, an overview of the DPLA API, and an intro to GitHub.  Participants had been encouraged in advance to brainstorm project topics and post them on the wiki.  People pitched their projects more formally in person, outlining both the general idea and the skills that would be helpful, so we could start envisioning where we’d fit in.  Jeffrey Licht from the DPLA Technical Development Team introduced us all to the DPLA API, to give us a sense of the metadata queries we’d be able to base projects on.  At Nate Hill’s request, I also did a brief intro to the concepts behind GitHub, one of the key tools we’d be using to work together (seen earlier on TechConnect).

Friday

Friday morning, we got to the library early, took advantage of its impressive breakfast spread and lots of coffee, and plunged immediately into hackery.  One huge piece of butcher paper on the wall was our sign-up sheet as whiteboards — one for team members to sign up for projects, and the rest quickly covered with wireframes, database models, and scribbled questions on use cases. The mood in the room was energetic, intellectually engaged, and intense.

Brainstorming and planning

The energy extended outside of the room, too.  An IRC backchannel (#dpla-api on Freenode), shared Google docs, a sandbox server that John Blyberg set up (thanks!) with an impressive range of language and tool support, the #dpla Twitter hashtag, and GitHub collaboration allowed for virtual participation.

The intense, head-down hackery was briefly interrupted by barbecue, cupcakes, and beer (a keg at the library, by the way? Genius).  Truly, though, it’s all a blur until 4:30, when the teams demonstrated their apps.

Hard at work.
The Apps We Built

There were eleven products at day’s end:

While the DPLA Plus proposer referred to his algorithm-heavy idea during pitches as “super-unsexy”, the judges clearly disagreed, as this impressive bit of engineering took home the prize for best app.

Glorious victory! Yes, that IS a repurposed Netgear router.
The Culture We Built

Appfest was a very different vibe from DPLA’s hackathon in Cambridge last April (which I also attended).  It featured a dramatically larger space, a longer and more structured schedule, more participants, and a much wider range of skills.  While Cambridge had almost exclusively software developers, Appfest drew developers, designers, UX experts, metadata wonks, and librarians.  This meant it took longer for teams to coalesce, and we needed to be much more intentional about the process.  Instead of April’s half-hour for project pitches, we spread that process over the weeks leading up to Appfest (on the wiki), Thursday’s pitch session, and Friday morning’s signups.

With such different skills, we also were familiar with different tools and used different vocabulary; we needed to work hard at making sure we could all communicate and everyone had a useful role in the projects.  Again, the longer timeframe helped; an informal dinner at the library Thursday evening and assorted bar trips Thursday night gave us all a chance to get comfortable with one another socially.  (So, admittedly, did the keg.)  A mutual commitment to inclusiveness helped us all remember to communicate, to break down projects into steps that gave everyone something to do, and to appreciate one another’s contributions.  Finally, organizers circulated around the room and kept an eye on people’s mood, intervening when we needed help finding a team that needed our skills, or just a pep talk.

And with all that work put in to building culture?  The results were amazing.  The April results were generally developer-oriented; as you can see from the list above, the Appfest products ranged from back-end tools for developers to participatory, end-user-oriented web sites.  They were also, in most cases, functional or nearly so, and often gorgeous.

Takeaways

There are some implications here for both DPLA and libraries in general.  The range of apps, inspired in part by earlier work on DPLA use cases, helped to illustrate the potential impact that DPLA could have.  They also illustrated both the potential and the limitations of DPLA metadata.  The metadata is ingested from a variety of content hubs and overlaid with a common DPLA schema.  This allows for straightforward queries against the DPLA API — you can always count on those common schema elements.

However, as anyone who’s ever met a crosswalk in a library school metadata class knows, automated ingestion doesn’t always work.  The underlying metadata schemata don’t always map perfectly to DPLA’s, and therefore the contents of the fields aren’t wholly standardized and don’t always provide what developers might be looking for (e.g. thumbnail images to illustrate query results).  This, of course, is why DPLA has these hackathons — both to illustrate potential and to stress-test its back end, find out what works and what doesn’t and why.  Want to help?  Go for it.  There’s a host of ways to get involved at the DPLA web site.

And for other libraries?  I keep coming back to two things: Dave Riordan’s tweet, above, and the digital humanities community’s One Week | One Tool project.  This was, essentially, a week-long 2010 summer camp in which a small, diverse team of digital humanists built an electronic publishing plugin for WordPress, from scratch, after a public discussion of their community’s needs.  In other words: we can do this thing.  Working, useful tools can be built in a shockingly short time, if we have open conversations about what would be useful and assemble skilled, diverse teams.

Let’s do more of that.