On Sunday, April 27, 2014, I coordinated a hackathon focused on the DPLA API as part of the Texas Conference on Digital Libraries. The hackathon was sponsored by the Texas Digital Library and The University of Texas at Austin Libraries, with support from DPLA.
This was pretty overwhelming for me. I’d never coordinated a hackathon before. In fact, I’d never really attended a hackathon before, at least not one that produced actual code. The genesis of the event was a call for workshop proposals from the conference organizers in November 2013. As a DPLA Community Rep, I knew that I’d like there to be an event that focused on DPLA, and I wanted it to be a technical event to attract developer-types. In January 2014, I asked the conference organizers for their thoughts, secretly hoping that someone else had already proposed something. No such luck! While the organizers supported the idea of a hackathon (organized by “not-them”), they were limited in terms of options. We finally decided to squeeze the event into a half-day and to hold it on Sunday, the day before the conference was to begin. This meant that the event could be free and that people from outside of Austin could attend without having to pay for an extra night at the hotel, at least in most cases. However, it meant that the time available for actual hacking would be limited.
I did some research on hackathons before we opened registration. A few of the things I learned:
- Organizing a hackathon is not a one-person task. It’s best to have a group of people with a variety of interests and technical abilities. I was fortunate to get a great team of people together to help me with this. Special thanks go to Rachel Vacek and Sean Watkins, at the University of Houston Libraries, Ben Brumfield with From the Page, Jennifer Hecker from the UT Libraries, and Kristi Park from the Texas Digital Library.
- There are resources available to help with some of the simple organizational tasks, like registration, announcements, and project formation. I decided to use HackerLeague, which is free for this level of use. Information about our hackathon, Hacking DPLA at TCDL, is still available.
- A half-day is not enough for meaningful hacking. Most hackathons are a full day or longer; a day and a half seems like a nice option. To maximize our limited time, the organizers decided to do some pre-hacking so that we would be starting the session with some projects that people could join, if they so desired. This also meant that the organizers were familiar with DPLA and other projects that used the DPLA API.
- Organizers don’t get to hack. We actually bent this rule a bit, with various organizers leading small group projects, but it’s true that my time and attention was divided between the group I was working with and logistical issues that arose.
- Set a goal for the event in advance. Our goal: Introduce people to DPLA and the DPLA API, with an emphasis on how the API can be used to build neat tools. Hackathon will be a learning environment, and participants will have opportunities to work at their own pace through examples.
We announced the event and opened registration about a month in advance of the event. Soon after we opened registration, I started getting email from people who were interested in the hackathon but who were concerned that they didn’t have enough technical ability to participate. In March 2014, I’d had the opportunity to attend the LTG Summit, also held in Austin. At this event, I was made aware of the extent to which many women, non-white males, individuals with disabilities, and LBGT have been excluded from opportunities in the field of technology, even within the library profession. I didn’t want this to be an issue with our hackathon, so I reassured all people who contacted me that they were welcome and tweaked the wording of the event description to say that it was open to anyone interested in hacking. In the end, almost a third of the 19 people who attended described themselves as beginner coders or user and content specialists who didn’t do much, if any, coding.
My main personal contribution to the pre-hacking was the development of a beta tutorial showing how the DPLA API could be used. My example was a simple search form with results; I took ideas for the code from two existing DPLA Apps, the DPLA Search Widget developed by Dean Farrell and Josh Wilson, and the EBSCO Discovery Service and DPLA Highlights app developed by Eric Frierson, who was generous enough to send me the app source code. I modeled my tutorial on the Railsbridge for Women Intro to Rails tutorial, though I decided to use PHP as the basis for development since I’m more comfortable in that language. The tutorial is available at https://www.dcplumer.com/resources/handouts/dpla-api-tutorial-2/ and the complete code is available at https://github.com/dcplumer/dpla-search-tutorial/.
We got incredibly lucky with our hackathon, because Dan Cohen, Executive Director of DPLA, was scheduled to be the first keynote speaker at TCDL on Monday. He was able to come in early and attend the hackathon, although he had to catch an insanely early flight on Sunday to do it. Thank you, Dan!
Our half-day followed this schedule:
12:30-1:00 p.m. – Snack and socialize
1:00-1:15 p.m. – Introduction to DPLA
1:15-1:30 p.m. – Introduction to DPLA apps
1:30-2:00 p.m. – Sample DPLA app projects
2:00-2:30 p.m. – Break and Pair Up
2:30-4:30 p.m. – Hacking
4:30-4:45 p.m. – Reports from teams
4:45-5:00 p.m. – Closing thoughts and next steps
I learned some valuable lessons along the way:
- A half-day is just not enough. I think that if we’d been able to follow our half-day hackathon with a full-day of hacking, we’d have really gotten somewhere, though I suspect that only about half of the participants would have come back for the second day.
- Build in time for introductions and project planning. We jumped directly from reviewing the app projects that the organizers had prepared in advance to working on projects in groups. Participants reported at the end of the day that they wished that they’d had a chance to get to know the other attendees a bit more and to share ideas for projects and other activities during our hacking time.
- Terminology matters. The term “hackathon” is perhaps not the best way to describe this event. A few participants approached me quietly at the end of the day and asked about it. They clearly had negative perceptions of the term “hacker,” which is often used as a pejorative, sometimes with hints of criminality, in mainstream news reporting. I’m not quite sure what else to use, but it might be best to stick with the “AppFest” label that DPLA has previously used.
- Lead time. From start to finish, we had three months of planning time. The announcement about the event went out about four weeks in advance, which was not enough lead time for people who were planning to fly in to the conference. Depending on your audience, you should announce the event about three months out (with a reminder at eight and four weeks out). Other than the travel issues, I don’t think having additional time to prepare would have helped us.
- Room layout. A flexible layout is best. We were in a classroom with tables that could be rearranged, but even so people seemed to be awkwardly clumped around the room. Break-out rooms with space for 3-4 people each would be ideal, especially if they provided projectors to allow people to share their screens more easily. I had an extra projector with me, but I didn’t know until the end of the day that one of the groups had wanted to use one.
- Internet. The Texas Digital Library staff arranged for us to have wireless Internet, and it was thankfully robust. The day before the event, the question of whether we would have reliable Internet occurred to at least three of the organizers separately. Without robust Internet access, I think we’d just have gone home. How do you test an API if there’s no Internet?
- Promotion. I had intended HackerLeague to be the main entry point for our event, but I also created an event on Facebook and I thought about cross-promoting the event on Meetup.com and LinkedIn, as well, though I didn’t get around to it. I and other organizers also sent notices out to a variety of email lists. As a result, it was difficult to keep track of who might have seen what. People registered through HackerLeague and Facebook and notified me by email that they wanted to come. In the end, I was glad that I didn’t do the Meetup.com and LinkedIn cross-promotion, because it was difficult to manage all the different channels. Using a service like MailChimp or ConstantContact might have helped, but would have cost money. In future I would prefer that registration be handled though the main conference registration, though that, too, would apparently cost money.
- Registration and attrition. I counted a total of 26 pre-registrants before the event. I put together a separate information form about a week before the event, with the goal of finding out about the technical background of participants, but only about half of the people who had previously indicated interest filled it out. We ended up with 19 people at the event, though only 14 stayed for the whole thing. Those attrition rates, while high, are not unusual for a free event, especially one held on a Sunday, but it did make planning things like food and drink more challenging.
- Supplies. I provided supplies for participants in case the needed them. I had pads of paper, highlighters and markers, pens and pencils, post-it notes and dry erase markers. In the end, I don’t think any of them were used, but it is good to have those sorts of things available, especially for events that are more focused on designing new apps or functionality.
- Food and drink. I provided sodas (diet and regular), bottled water, veggies and dip, fruit, and a variety of cookies. The total expense came to about $3.00 per attendee, but in reality we had a lot of food and drink left over. We didn’t know what to expect, so I didn’t solicit sponsorships from grocery stores or other possible sponsors. I’d definitely recommend doing that and also not opening up everything at the beginning, so that unused product could be returned.
- Swag. DPLA provided t-shirts for the organizers and swag, in the form of stickers, for attendees. This was very popular. I suspect we could have sold t-shirts (I had one t-shirt left over that didn’t fit any of the organizers, and a participant begged me for it at the end of the day).
- Sponsorships. We did not seek formal sponsorships outside of the Texas Digital Library, who provided the Internet, The University of Texas at Austin Libraries, who provided the room, and DPLA, who provided swag and t-shirts for the organizers. In part this was because we didn’t know where we would need assistance. Our only expenses were for food, which came to a total of $75, and a few supplies that I provided. We could have used sponsorship funds to pay for these items, for parking vouchers for attendees (parking in a University garage cost about $15 for an afternoon), and to help defray costs associated with registration, etc. In future, I would budget approximately $25 per attendee per day for those costs. I’d prefer not to charge a registration fee, or, if we did to offer scholarships to help people whose institutions couldn’t support them.
Highlights of the event:
- Dan Cohen (@dancohen) talking about the DPLA platform and how events like this one help build the DPLA community.
- Rachel Vacek (@vacekrae) reviewing some DPLA apps and discussing cool concepts for future app building.
- Sean Watkins (@seanwatkins) showing off his DPLA Display proof of concept for using the DPLA API along with Web Sockets. This small web application displays images, much like a picture floating screensaver, on a remote display, while users control the images being viewed from a mobile device. https://github.com/seanlw/dpladisplay
- Eric Frierson (@frierson) showing off his EBSCO DPLA Widget that adds DPLA results to EBSCO database displays and DPLA Nearby Search Widget that uses the Geoplugin PHP Webservice and Google Maps API to display DPLA results tied to a specified location. https://github.com/ebsco/dpla-widget
- Sara Brumfield (@saracarl) helping beginners learn how to use Yahoo! Pipes to parse the DPLA API. Tutorial outline
- Danielle Cunniff Plumer (@dcplumer) releasing a beta tutorial for a DPLA Search Widget that walks new users through the process of creating a search widget in PHP with the DPLA API. https://github.com/dcplumer/dpla-search-tutorial
- Ben Brumfield (@benwbrum) and Jessica Wood working on a Respect My Authority app that builds from a suggestion provided on the DPLA Hacking Projects page. https://github.com/benwbrum/respect_my_authority
The consensus of the people who stuck with it until the end was that we should do this again. I’ve already started discussing time and space considerations with the Texas Digital Library staff, and they’re interested in sponsoring more technical opportunities like this one. If you’re interested in attending one of these events, or if you’d like some advice for planning for your own event, feel free to contact me at firstname.lastname@example.org.