A Peek Under the Hood of the NPR API

Public broadcasting is in a moment of experimentation, moving beyond traditional broadcast platforms and structures and trying to reach publics where they live and work, through issues that they care about. Large structural innovations—like the release of the NPR application programming interface (API) in late July—are combining with experimentation by stations, staffers and audiences to create new uses for public media content. An open API is a wonderful thing for making content public: it provides a simple way to query an online database and extract things from it for display. An open API allows anyone to access, reuse, and "mash up" photos, text, audio and other digital media in any way that he or she can imagine. As an example, I've been working on a widget that uses the API to display selected NPR stories in chronological format (see sample below)—just one of a variety of NPR widgets [2] that different people are developing.

Here's a little bit of background on how the NPR Timeline Widget [3] came about.

As part of my work as the webmaster for KJZZ [4] 91.5 FM in Phoenix, I was invited to take part in a station advisory group led by Joyce Macdonald and Zach Brand at NPR to discuss a few key initiatives such as the NPR API and social networking. To prepare, I searched for examples of what other people were doing with similar APIs. I had heard that the BBC was working on an API, and on the BBC developer's blog [5] found the Google Spreadsheet JSON to SIMILE Timeline [6] by Kiyohito Yamamoto. [7] As soon as I saw it, I said, "That's it! That's what I'm going to do!"

The timeline widget offers users and storytellers the chance to look beyond the familiar laundry list of stories. The chronological presentation provides the selected stories with a context and gives timeline creators the ability to convey information about a given subject as it develops. It also allows them to easily embed timelines on their web sites, highlighting particular angles of coverage.

In addition to these storytelling benefits, the timeline widget presented some interesting technical benefits. As soon as I saw that the timeline accepted data in JSON [8] format, I was doubly excited, since I knew that the NPR API output in JSON format. I could put this thing together only using javascript, and hopefully make something entirely portable, something that was not dependent on any specific flavor of server-side programming, and something that could be used as the nucleus for other javascript based mashups.

The upshot is that the NPR API allows users to get highly specific search information into their browsers (or even desktop applications) with maximum flexibility and minimal dependencies. This also pairs up nicely with the open source zeitgeist—not only is the data freely available, but so are the conversations around what can be done with that data, and the crowdsourced/open-sourced creation of these tools.

This results in a development process that is strikingly "public"—that is, both transparent and inclusive. For instance, if you have a look at the issues list [9] that I am using to collect people's suggestions and bug reports for the timeline widget, you will see that a lot of these ideas are not my own. This offers enormous potential for the development of applications around public media data. For example, I asked a friend at the Google offices in Phoenix if he could have one of the coders on his staff review the NPR Timeline. This developer made an excellent suggestion which, in my mind, actually eclipses the importance of the timeline. He suggested I "embed the NPR Query Generator in an iframe and scrape its results (or even better, just reuse the code and change its presentation)." As a result of this feedback, I have started working on an additional project which we're calling the Query Generator Lite (QGL). You can see a working example of the latest QGL here. [10]

If all goes well with this, we will will also have a portable query generator which will allow people to create their own dynamic searches of the NPR database without going to the NPR site. Additionally, since this javascript will be portable and pluggable into other applications this will relieve developers from having to re-invent the wheel every time they want to use an interface to make queries of the NPR API. Daniel Jacobson, co-creator of the NPR API (along with Zach Brand) told me "we hadn't even thought that people would want to do that." He was very excited about the idea, so he and I and several members of his team have been chatting about this as the initial prototype is getting put together. And all of this came about through simply asking for feedback.

However, the idea of the programmers at NPR collaborating on code with station staff and developers at large is in its infancy. Such increased collaboration presents some growth issues for a broadcast network which has been built on the premise that information flows primarily out towards listeners and not so much the other way around. Through my work developing the NPR SIMILE Timeline widget, I can see several useful next steps that would push up against the boundaries of our current thinking:

1. It may be advantageous for public broadcasting organizations to provide a reliable, scaleable hosting service for user-contributed scripts specific to public broadcasting (similar to the idea behind Google's AJAX Libraries API [11]). This hosting service could enable permanent URLs to commonly accessed libraries and scripts.
2. Similarly, it would be helpful if there were a shared concurrent versioning system for public broadcasting related code, a mechanism for code review and the ability to submit bug reports and feature requests.
3. Discussion groups could be be set up around individual widgets.
4. The community and national organizations could work together to develop scripting standards in the form of a style guide that we could use as a model, and thus facilitate better collaboration.

It is safe to say that NPR is not ready to roll out this kind of collaborative system just yet, but Daniel Jacobson has told me that "these are the right questions, and NPR is working to get there." He also impressed upon me that the way these things are done are "all up to me." The folks at NPR are really open to talking about process and are wanting to help, but it seems they are also just as open to letting development around the API take on a life of its own and be managed by the public.

There have been numerous attempts to facilitate discussion around collaboration in public media in the past. For instance, I was at the Beyond Broadcast [12] conference in Boston two years ago where participants explored the potential for technology sharing among public media organizations and individuals. As a result of Beyond Broadcast 2006, there also was a Google group formed called Public Broadcasting Open Source Best Practices or PBOSBP [13]. Additionally, the folks at pubforge.org [14] (loosely affiliated with the Integrated Media Association [15]) have been long-time advocates for providing resources for web developers across all of public media, and have been renewing their efforts lately, mostly as a result of the Knight Foundation's Radio Engage [16] initiative. Right now, only individuals and small groups of co-conspirators are working to build and share tools and solutions for making media truly public. However, the potential for individuals and groups like these to be useful to developers around public broadcasting may become more apparent in the future.

The launch of the NPR API has been beneficial in many ancillary ways. It's not just the excitement surrounding the API itself (although, it's big, and what people will do with it will be even bigger.) This development arrives at a propitious moment. A cultural shift in the public broadcasting world is leading to a deeper understanding that truly public media is now technically feasible. As David Liroff (formerly of WGBH/Boston) says, "technology has caught up with our mission, and web developers at public TV and radio stations [as well as the developer community] aren't waiting for permission to use it."

NOTE: Jack Brighton from WILL also contributed to this post