The demo app is available here: http://publicradioroadtrip.appspot.com/publicradioroadtrip/
The code is available here: http://code.google.com/p/publicradioroadtrip/
And while this app is not completed, it is suggestive enough to raise interesting questions and presents interesting processes worth discussing.
First, I have long believed what the NPR API really needs is an "Editorial Layer" where you can tailor queries or make editorial decisions on stories that do or do not belong in a listing of results from the NPR API. For instance, if you want to show a group of stories about a certain topic, a search of the NPR API may give you many of the stories that you are looking for, but they also may produce a few erroneous results... how do you edit the list of stories that are returned?
The Public Radio Roadtrip was my first attempt to allow users to create bundles of stories by manually surfing npr and bookmarking stories using a "bookmarklet". To add the bookmarklet to your browser, just drag this "
Add to Roadtrip!" link into your browser's bookmarks bar. (In Internet Explorer, right-click on the link and choose "Add to favorites").
The interesting thing about the way this bookmarklet works (pictured above) is that it sends only a "StoryID" and the Title from the story page at npr.org. By using a bookmarklet the process of adding stories to the public radio roadtrip app sidesteps the NPR API (at least at the start) and allows people to add content to an app directly from a story page at npr.org (as opposed to going from search results of the NPR API). This seems intuitive. Find a story you like... click on the bookmarklet and add it to a roadtrip. But this approach also has its challenges as well. One thing that using a bookmarklet has made apparent is that not all stories at NPR.org are audio stories. Not all stories at NPR.org are NPR stories... sometimes they are stories from the Associated Press or other content providers (which I'm sure brings up rights issues). Additionally, if this app is going to assume that the goal is to serve a podcast to users that they can download into their mp3 player, how do you account for text-only blogs at NPR.org? Also, depending on storyid to be in a uniform place in a url from npr.org is not always straightforward.
These hurdles makes me think that it might be good to provide an additional means for adding / editing stories within a roadtrip. I am thinking about providing an interface to "add stories via search" by extending the work I did with the NPR Simile Timeline app; and rather than creating a timeline with the results, creating a table of stories with links to add them to a roadtrip. This may take some work, but I think it will approximate more closely the idea of an "Editorial Layer" for working with NPR stories that I am envisioning.
On the other hand, part of me wonders if this approach of querying the NPR API may not be entirely the way to go as well... I mean public radio is more than NPR, right? How would we get stories from local stations like KCRW into the app... In the future, perhaps relying on a standard like oembded as described by Chris Beer in a recent article might provide an additional way to display resources about a story. Or perhaps with NPR/Public Interactive's Core Publisher project underway, a common API among public broadcasting stations might be just over the horizon.
Either way, this approach of bookmarking npr stories using a bookmarklet has brought these questions into sharper focus.
This app attempts to present a mapping interface for people to add geotags to stories which builds on this Address Locator Example. But I'm not sure.. is this the right interface for adding geotags to stories? Should this process even be placed in the hands of users; would users really only want to choose from "published roadtrips" that had been edited and curated by national/local station staff who have more of a vested interest in the publishing process.
You will notice that the display of a roadtrip is not completely finished. The reasons for this are partly technical and partly non-technical. Here, for instance, is one technical issue that I'm facing. In relying on only a "StoryID" it requires that one employ further server side processing to get additional information about a story via the NPR API (using the kcrw.nprapi python module or the NPR javascript widget) to allow for displaying the teaser text, links to audio, datestamp and more. I'm still working out the details for placing stories on a map with javascript
One of the non-technical reasons why this app hasn't yet taken shape is that even though people have an instant, emotional reaction to how a Public Radio Roadtrip would work, it's likely that different people might have several different ideas for how this would actually work in practice. As a matter of fact, I'm not even sure myself precisely how a roadtrip would actually function. A lot of my questions about the Public Radio Roadtrip app actually are now starting to get a bit less technical and are starting to point in the direction of wanting to understand how the app should work from the user end of things... Questions like, how would a roadtrip work? Would it be a podcast? Would it be a route on a map... if a user was driving through Yellowstone National Park, for instance, how would they know that a particular public radio story was relevant to the breathtaking vista that they were taking in; would there be a printed guide to accompany a set of mp3 files?
One possible way to get at the way a roadtrip app would be used could be through the exercise of creating "user profiles". I remember in 2009 at the Public Media Conference... there were some folks from PBS Games that had us all walk through making user profiles for an app. It was a great exercise. We started by writing qualities of individuals we knew onto posted notes. Then we mixed up these post-it notes and brainstormed about an app that would meet this new, imagined user's needs from the start (as opposed to forcing the user to make accommodations to adjust to this technology).
I also wonder if using a tool like Google Moderator might help to facilitate this kind of discussion of precisely how this app might work. With this in mind, I put together a list of ways where this app might work which potential users could vote up qualities which make the most sense to them. I'm not sure where this conversation would take place... perhaps at the upcoming PubCamp in DC at the end of November. Or perhaps this will take place online over the coming year.
At some point, I'm hoping that I can talk to the folks at PBS Games again. or at least get in touch with other people with similar expertise. If you or anyone you know might have an interest in providing input on how a "Public Radio Roadtrip" app would work please feel free to put them in touch with me.
