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.
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.
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.
The Apps We Built
There were eleven products at day’s end:
- a workflow for integrating DPLA content with existing Drupal modules;
- a new Drupal module;
- Follow that Cab!, an IFTTT-inspired system allowing users to design a query and be automatically notified of new results (design, code)
- A Ruby library and command line tool for interfacing with DPLA
- Catalog the Whole Earth, a site for letting users submit pictures and metadata of anything;
- a design for Cuttr, a crowdsourced question-and-answer site where users can get their questions answered using DPLA materials, rate answers, and earn karma;
- A PHP class and web interface for DPLA integration;
- A site using DPLA geographical metadata and browser geolocation to show you DPLA collection items sourced near you;
- A browsable map for exploring DPLA items near you (beta, code);
- BiblioGrapher, a tetris-like visualization of DPLA metadata
- DPLA Plus, an engine using probabilistic record linkages to deduplicate and recommend content (documentation, code).
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.
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.
#DPLA Appfest is honestly the most productive hackathon I’ve ever been to. More groups shipping near complete things than I’ve ever seen
— Dave Riordan (@riordan) November 9, 2012
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.