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 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.


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.

Mobile App Use Studies Across a Decentralized Research Library

The University of Illinois’ team of IT diversity interns are working on departmental-specific mobile app modules and user studies of those app modules this Fall semester. The Illinois library is a decentralized system of nearly thirty departmental libraries serving diverse needs of staff, researchers, scientists, graduate students, and undergraduate students. Given such a diverse population, we wondered if it was possible to turn our prototyping pipeline to connect with other unit specific needs outside of our own space, the Undergraduate Library.

Specifically, this fall we wanted to understand how departmental collections and other library locations would use our already developed RESTful web services –which serves as the core component of the prototyping pipeline– for departmental and subject based mobile application modules.

This blog post describes the methods we used to quickly gather feedback on new and exciting features for department collections.The mobile application modules we studied include enhanced wayfinding support of multi-story buildings and collections (originally designed for an undergrad space of one level of collections), a reserves module for all libraries, and hours integration into book information data elements.

Enhanced Wayfinding in a Departmental Library

library wayfinding help
We studied the implementation of feature requests in mobile wayfinding apps


This module includes a navigation rose in the upper left corner of the mobile interface. Included is functionality for line segments that draw your current location to the location of your desired book in the stacks. The user can get their current location in the book stacks by using the barcode scanner module to scan the book nearest them, which then sets their current location. After setting their current location, any additional book that is then searched for in the library will generate a line segment path to the location of the searched for book.

Turn by turn directional support based on user location is a new enhancement, though we’ve been getting requests a few times in our previous user studies, from 2010-2011 use studies on maps and library wayfinding using mobile devices.

Reserves Module

Reserve access is one of the most requested mobile app features
Reserve access is one of the most requested mobile app features

This reserve program offers the student access to library reserves from an Android device. The multiple drop downs allow the student to select her course reserves by either course, department, or major.

Hours of library locations integrated into book data

hours module
If the item is in a library that is closed, this item may not useful to a student.

Most OPACs will let you know if the book is available. This is not always so straightforward in OPACs that inventory multiple locations. Some of the departmental collections actually have business hours of 9-5, or other limited hours during the weekend, yet the OPAC will show an item as Available so long as the book is not checked out. We tried to address the problem in our display module by adding a location status to the library — this checks against an hours database to let the user know if the library is actually open for the student to check out an available book. 

Rapid use studies

With a number of feature enhancements to our core set of mobile app modules, we wanted to gather empirical data that could inform production services. The fastest way to get user input into modules that may be in the early design phase is to approach users who are currently in the building. In the case of these modules, we were experimenting with the idea of location services in department collections, and the wayfinding support was specific to the ACES library and so we made this our test location.

Once here we approached users with a test set of questions around the modules. We asked what parts of the app are useful for helping the students integrate library resources into their work. We also asked and observed what doesn’t help, and additionally what features would be worthwhile to further develop.

We asked these questions about app modules:

  • Please describe any previous experience finding items in the Funk ACES Library?
  • What software modules help students integrate library content into their course work?
  • How easy to use is the application?
  • Does the student need time to learn how to use the software?
  • What unexpected things occur?
  • How do students react when the application does not work as they expect?
  • Do students make use of the location-based features?

Follow up

After collecting initial use data the team is reshaping a few of the modules to make them easier to use while at the same time brainstorming ideas for making some of the features more evident. One of the key findings of this last round of user studies was that although we implemented a number of requested features, students could not always locate, and then use or in some cases understand the features and how they would help. So we need to think about making the help features more helpful, and more engaging, overall. We theorize that another reason they couldn’t always find the help tools we designed into the ACES modules was the fact that the modular offerings of our experiment have become a bit cluttered.

If you take a look at any of the above screenshots you will notice their were eight included modules in the bottom of the mobile interface for this study. We did put many options in front of the study participants, so the next round of user studies will be more focused on areas we think are worthwhile to develop: particularly the engaging elements of wayfinding, but also the reserves module was called out as the one part that students considered would be most helpful for integrating library resources into their work.

Finally, as we poured over a few of the software choices we made to construct the Android layers, we realized they were not quite modular enough, and so this caused errors in overall functionality of the app during the study. To correct this we are thinking about definitions for the core aspects of modular design.

A final step for our work this semester is to showcase all of our software prototypes to the library staff at the University of Illinois. To that end we are having an open house during finals week, where we are inviting all staff members into our prototyping space and asking also for their feedback on the software developed, and ask staff to try out some of the newest ideas in mobile technology, including our in-development augmented reality shelf browser, which is being coded with funds from a Sparks! IMLS grant. A user study for mobile augmented reality applications is planned this Spring 2013.

Another information technology problem we will work on in the Spring 2013 semester is how to incorporate our RESTful feeds into the library discovery layers. The Music and Performing Arts library location is likely our next collaboration for stacks based wayfinding support inside of the OPAC.

We would like to integrate our wayfinding feed into the OPAC to help students get from the book information to the stacks location, using the RESTful web-services we’ve designed for system efficiency from the onset. The next step for our fledgling prototyping initiative is system integration, which involves taking this prototype work and injecting its most useful and used components into production environments like our VuFind search and our Primo discovery layer.


See also:

Huang, Y.M., Wu, D.F., Guo, Q. (2009), “Build a RESTful Web service using Jersey and Apache Tomcat,”

Jones, T. & Richey, R. (2000), “Rapid Prototyping methodology in action: a developmental study,”Educational Technology Research and Development 48, 63-80

Prototyping as a Process for Improved User Experience with Library and Archives Websites:

Rapid Prototyping a Collections-Based  Mobile Wayfinding Application:



Effectively Learning How To Code: Tips and Resources

Librarians’ strong interest in programming is not surprising considering that programming skills are crucial and often essential to making today’s library systems and services more user-friendly and efficient for use. Not only for system-customization, computer-programming skills can also make it possible to create and provide a completely new type of service that didn’t exist before. However, programming skills are not part of most LIS curricula, and librarians often experience difficulty in picking up programming skills.

In this post, I would like to share some effective strategies to obtain coding skills and cover common mistakes and obstacles that librarians make and encounter while trying to learn how to code in the library environment based upon the presentation that I gave at Charleston Conference last month, “Geek out: Adding Coding Skills to Your Professional Repertoire.” (slides: At the end of this post, you will also find a selection of learning and community resources.

How To Obtain Coding Skills, Effectively

1. Pick a language and concentrate on it.

There are a huge number of resources available on the Web for those who want to learn how to program. Often librarians start with some knowledge in markup languages such as HTML and CSS. These markup languages determine how a block of text are marked up and presented on the computer screen. On the other hand, programming languages involve programming logic and functions. An understanding of the basic programming concepts and logic can be obtained by learning any programming language. There are many options, and some popular choices are JavaScript, PHP, Python, Ruby, Perl, etc. But there are many more.  For example, if you are interested in automating tasks in Microsoft applications such as Excel, you may want to work with Visual Basic. If you are unsure about which language to pick, search for a few online tutorials for a few languages to see what their different syntaxes and examples are like. Even if you do not understand the content completely, this will help you to pick the language to learn first.

2. Write and run the code.

Once you choose a language to learn, there are many paths that you can follow. Taking classes at a local community college or through an online school may speed up the initial process of learning, but it could be time-consuming and costly. Following online tutorials and trying each example is a good alternative that many people take. You may also pick up a few books along the way to supplement the tutorials and use them for reference purposes.

If you decide on self-study, make sure that you actually write and run the code in the examples as you follow along the books and the tutorials. Most of the examples will appear simple and straightforward. But there is a big difference between reading through a code example and being actually able to write the code on your own and to run it successfully. If you read through programming tutorials and books without actually doing the hands-on examples on your own, you won’t get much benefit out of your investment. Programming is a hands-on skill as much as an intellectual understanding.

3. Continue to think about how coding can be applied to your library.

Also important is to continue to think about how your knowledge can be applied to your library systems and environment, which is often the source of the initial motivation for many librarians who decide to learn how to program. The best way to learn how to program is to program, and the more you program the better you will become at programming. So at every chance of building something with the new programming language that you are learning, no matter how small it is, build it and test out the code to see if it works the way you intended.

4. Get used to debugging.

While many who struggle with learning how to code cite lack of time as a reason, the real cause is likely to be failing to keep up the initial interest and persist in what you decided to learn. Learning how to code can be exciting, but it can also be a huge time-sink and the biggest source of frustration from time to time. Since the computer code is written for a machine to read, not for a human being, one typo or a missing semicolon can make the program non-functional. Finding out and correcting this type of error can be time-consuming and demoralizing. But learning how to debug is half of programming. So don’t be discouraged.

5. Find a community for social learning and support.

Having someone to talk to about coding problems while you are learning can be a great help. Sign up for listservs where coding librarians or library coders frequent, such as code4lib and web4lib to get feedback when you need. Research the cause of the problem that you encounter as much as possible on your own. When you still are unsure about how to go about tackling it, post your question to the sites such as Stack Overflow for suggestions and answers from more experienced programmers. It is also a good idea to organize a study group with like-minded people and get support for both coding-related and learning-related problems. You may also find local meet-ups available in your area using sites like

Don’t be intimidated by those who seem to know much more than you in those groups (as you know much more about libraries than they do and you have things to contribute as well), but be aware of the cultural differences between the developer community and the librarian community. Unlike the librarian community that is highly accommodating for new librarians and sometimes not-well-thought-out questions, the developer community that you get to interact with may appear much less accommodating, less friendly, and less patient. However, remember that reading many lines of code, understanding what they are supposed to do, and helping someone to solve a problem occurring in those lines can be time-consuming and difficult even to a professional programmer. So it is polite to do a thorough research on the Web and with some reference resources first before asking for others’ help. Also, always post back a working solution when your problem is solved and make sure to say thank you to people who helped you. This way, you are contributing back to the community.

6. Start working on a real-life problem ‘now.’ Don’t wait!

Librarians are often motivated to learn how to code in order to solve real-life problems they encounter at their workplace. Solving a real-life problem with programming is therefore the most effective way to learn and to keep up the interest in programming. One of the greatest mistake in learning programming is putting off writing one’s own code and waiting to work on a real-life problem for the reason that one doesn’t know yet enough to do so. While it is easy to think that once you learn a bit more, it would be easier to approach a problem, this is actually a counter-productive learning strategy as far as programming is concerned because often the only way to find out what to learn is by trying to solve a problem.

7. Build on what you learned.

Another mistake to avoid in learning how to program is failing to build on what one has learned. Having solved one set of problem doesn’t mean that you will remember that programming solution you created next time when you have to solve a similar problem. Repeating what one has succeeded at and expanding on that knowledge will lead to a stronger foundation for more advanced programming knowledge. Also instead of trying to learn more than one programming language (e.g. Python, PHP, Ruby, etc.) and/or a web framework (e.g. Django, cakePHP, Ruby On Rails, etc.) at the same time, first try to become reasonably good at one. This will make it much easier to pick up another language later in the future.

8. Code regularly and be persistent.

It is important to understand that learning how to program and becoming good at it will take time. Regular coding practice is the only way to get there. Solving a problem is a good way to learn, but doing so on a regular basis as often as possible is the best way to make what you learned stick and stay in your head.

While is it easy to say practice coding regularly and try to apply it as much as possible to the library environment, actually doing so is quite difficult. There are not many well-established communities for fledgling coders in libraries that provide needed guidance and support. And while you may want to work with library systems at your workplace right away, your lack of experience may prove problematic in gaining a necessary permission to tinker with them. Also as a full-time librarian, programming is likely to be thrown to the bottom of your to-do list.

Be aware of these obstacles and try to find a way to overcome them as you go. Set small goals and use them as milestones. Be persistent and don’t be discouraged by poor documentation, syntax errors, and failures. With consistent practice and continuous learning, programming can surely be learned.


A. Resources for learning

B. Communities