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 that different people are developing.
Here's a little bit of background on how the NPR Timeline Widget came about.
As part of my work as the webmaster for KJZZ 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 found the Google Spreadsheet JSON to SIMILE Timeline by Kiyohito Yamamoto. 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.
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 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.
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:
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 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. Additionally, the folks at pubforge.org (loosely affiliated with the Integrated Media Association) 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 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