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!