Rethinking the problem for creating the Public Radio Roadtrip

In response to Aza Raskin's suggestions about writing down and refining a problem statement for a project so that the solution could be better understood, I wrote a problem statement for the Public Radio Roadtrip:

I want to curate stories from multiple sources and associate geolocation information with these stories.  I want to organize these stories into collections.  I want to publish these collections of stories onto an embeddable map.  I also want to publish these collections to additional destinations automatically, like a person's mp3 player (via podcasts), like Google Maps, Layar  and more...  I would like to easily create printed flyers of these stories with an accompanying qrcode which links to the audio.

Is this really the problem?  It sounds more like a description.

Aza quotes engineer Paul MacCready in his article "You Are Solving The Wrong Problem"

“The problem is we don’t understand the problem.”

Aza notes that "the problem was the problem".  The problem was the process itself, and to arrive at the solution the process needed to change.  Both Aza and Bert Herman said that repetition, that iteration was key.


So, perhaps rather than describe what I have now, perhaps the problem is, how can I better refine the process?  How can I better test the app, gain feedback, refine my assumptions and my work and try again.  What will my problem statement look like then?

Refining the Concept of the Roadtrip App

Bert Herman in his recent presentation to the Knight-Mozilla learning lab came across as an unassuming person with a wisdom born from experience.

He stressed that in order to devote yourself to making a successful large-scale project, you have to ask yourself if you are the right entrepreneur for the project.  This has prompted some soul-searching on my part, and for the Public Radio Roadtrip my answer came back "yes." I'm irrationally and tenaciously passionate about this app and I see it as meeting a need both in the newsroom and in the community.

Herman then went on to stress that for any project to be successful, you "need to listen to what people are saying."  He stressed that "you need to find the unsaid idea behind what people are saying" and that you need to "do [that] one thing head on."


And this got me thinking about audiences, I wonder if we also need to be more clear who our audiences are...  I've been thinking a lot about this quote from the article "Investing in the future of news" A contributed chapter for 'Page One' edited by David Folkenflik 

We found that projects made greater headway when they established an identity as part of a specific, tightly-defined community or interest group to attract passionate, repeat users. Journalists doing such outreach were more successful when they made themselves active members of the community, constantly asked for advice, showed that they were listening and made changes based on community input.

I wonder if one potential audience for my app (outside reporters in the newsroom) would be a biking group, a car club or a geocaching interest group. I think they would clearly be the ones to give feedback on using maps and following routes.  I think it would be great fun, it would be incredibly social to mash-up journalists and bicyclists in this kind of a way and see what happens.


Bert Herman mentioned having "as little possible barriers to adoption as possible." For Storify, one of these barriers was solved by simply allowing users to publish their work from Storify directly on their own web sites, within their own pages using a simple embed code.  The Public Radio Roadtrip currently requires people to install a bookmarklet (intended to help make it easier for people to place stories from NPR.org on the map).  I have a feeling that this bookmarklet might actually be a barrier to adoption.


Herman talked about the importance of design and for making things clean as the key for getting people to use your apps.  With this in mind, I started working on a playful, two-minute mock-up of how the interface for the Public Radio Roadtrip could be cleaner and easier to use:



Oh, and I wasn't sure if it was Bert or Aza who gave us carte blanche to "steal!"

But really, the idea behind this graphic was to pose the idea of lowering barriers of adoption by brining a search inteface into the app (and eliminating the need for the bookmarklet).  The other thing that this image meant to impress was the idea that the Public Radio Roadtrip intends to allow the user to curate points on the map from multiple sources, something that Herman's Storify does amazingly well.

Bert Herman advised us "when you find your passion, build your community."  In addition to "dating" my co-founders as he cheekily but earnestly suggested, I can see myself alongside journalists and tourists, virtual tourists and bicyclists, graphic designers and marketers, bringing public radio stories out into the physical and digital streets and into the world.

QR Codes and Geolocation on the Cheap

Okay, so my last post was inaccurate... well, wrong.  And Aza said we'd be wrong on the first pass.  So I'm not worried.  This naturally leads me to consider ways where I could refine and iterate my sketch of the experience and to highlight more accurately the value that the Public Radio Roadtrip holds for listeners and for stations.

And while this first pass did paint a suggestive experience, and one that does fall within the experience that one might have using the Public Radio Roadtrip, I wanted to be up-front in pointing out that everything I described in these initial sketches could be pretty much done without using the app itself.

I didn't want there to be any smoke and mirrors here.  I did not want to expend people's time and attention on an incomplete picture... that wouldn't get me any closer to selling the experience (although I will say that the experience of getting QR Codes of public radio stories out into the world is exciting to me).

So, with that in mind, let me describe a very simple approach for associating QRCodes with radio stories.  This approach is so simple that everyone can and should give this a try, and then they should walk outside and take these stories out into the physical world for others to find.

For example, let's say you're a grocer.  Let's say you want to entice people to pay a little extra money to buy some of your savory hydroponic tomatoes from Canada.

Let's say you want to appeal to your customers' qualities as enlightened NPR listeners.  So, you go to NPR.org



Then, you search for Tomoato.



You find the perfect article about why tomatoes don't taste like anything and you find that it mentions hydroponic tomatoes from Canada. Great! Now, you right-click on the download link for the story and select "Copy Link Address".



Next, in another tab or browser window, go to createqrcode.appspot.com.



Then, paste the link to the audio story that you just copied into the textarea at createqrcode.appspot.com. Then, click "Create QR Code".



Voila! You got it. Now, print this page.

While you're at it, print the page from NPR.



Then, using some scissors, cut around the QR Code on the printed page.



Then, using some tape, paste the QR Code to the printed article.

Finally, take your poster out into the world and tack it to a pole or post it to a community bulletin board (or in this example, by a tomato display at your business).



Now, people can use their smartphones to scan the QR Code and listen to the story, right there where they find it, wherever they find it, out in the world!

A First Pitch of the Public Radio Roadtrip Experience

This past Monday, as part of our first week of the Knight-Mozilla Ideas Challenge learning lab, we listened to Aza Raskin talk about How to Prototype and Influence People.

I was struck by Aza's challenge to "Sell the Experience" of your app, as opposed to selling the list of features. See slides 6 and 7, as well as the lead up to slide 50 below:

How to prototype and influence people

View more presentations from azaraskin

So, with that in mind, I thought I would sketch the experience that I envision a successful and happy user of the Public Radio Roadtrip would experience:

The Station's Experience

The Story's Experience

The Listener's Experience

So, now, my immediate step is to:

• ask potential users of the Public Radio Roadtrip... "Well... Is this how you see the experience of creating 'roadtrips'? Is this what you want to do with your stories?"
• The next step is to listen
• The next step after that is to iterate fast and adjust the app. To iterate the solution as well as the understanding of the problem. (See slide 34).

Refining Assumptions about a Public Radio Roadtrip App

My wife Rene has always encouraged me to create a "Public Radio Roadtrip" app. When I posed this idea several months back during a #pubmedia twitter chat, this seemed to provoke significant interest. And I've found that this a common reaction: people seem to think this would be a great idea. The phrase "Public Radio Roadtrip" strikes such a suggestive, emotional chord that in talking with people about this idea, I have heard many excellent ideas about how this app would work. So, I decided to put this idea to the test.

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 and there is also a small issue right now getting Google App Engine to recognize the kcrw.nprapi module python module (although if you download the code and run the app locally, the module can be used just fine). If using a kcrw.nprapi module proves to be too difficult, another alternative would be to use the javascript widget provided by NPR to display information about a story.

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.