How I learned to stop worrying and love the crowd

This past week, as part of the Knight-Mozilla Ideas Challenge learning lab, we heard from presenters Mohamed Nanabhay, the Head of Online at Al Jazeera English and Shazna Nessa, the Director of Interactive at the Associated Press.

Shazna reminded us of something that Aza Raskin had stressed in his presentation, that 

"the hardest part about software is neither design nor software, it's culture."

She also reminded us that 

"not everyone is going to be great at everything and to know what people are good at and what they're not."

As my Public Radio Roadtrip project has the potential to elicit collaboration between different members of a news organization, each with differing skill sets, I have been thinking about how to best approach this issue. 

I was inspired by Al Jazeera English's recent success with their coverage of the Arab awakening.  In particular, I was inspired by how their news gathering strategy evolved to one which gathers and incorporates citizen content and where they discovered that 

"much of the most popular content was raw video with natural sound"

I was also inspired to discover that Al Jazeera English been offering their coverage with a Creative Commons license on YouTube at http://cc.aljazeera.net/ and on flickr.

Nanabhay stressed that he was amazed by the many ways in which their content has been used beyond newscasts and documentaries such as within video games or in public service announcements.  And it could be said that when you publish your media elements unbundled to the world  that you could also be serving your own newsroom as well.

What this idea drives home is the idea that different people with different strengths can be enabled to collaborate on a single project using disparate online resources.  For instance, a photographer could put their photographs on flickr while a reporter could write and produce their finished piece as audio and upload this to SoundCloud.  All this, while the data visualization expert could compile these disparate resources within the finished app.  The idea that not all content needs to go through one tool to find its way to the web is subtle and empowering at the same time.  And this is one thing that has been baked into the Public Radio Roadtrip, that media elements can come together from virtually anywhere on the web.

One additional way where the Public Radio Roadtrip enables news staff (or even citizens) to easily use this tool, is that a finished roadtrip can be published anywhere using only a simple embed (as emphasized by presenter Burt Herman's experience with Storify).

One last point, lest we come away thinking that the solution for eliciting collaboration across a news organization is solely a technological solution, Shazna also emphasized the need for communication, the need to listen and to

learn how to talk tech to non-tech people. Don't assume people don't know anything.  They may not know how to talk [in technical terms].

Towards an understanding of popcorn.js

This past week, as part of the Knight-Mozilla Ideas Challenge learning lab, we heard from speakers Christian Heilmann, a "developer evangelist" at Mozilla, as well as John Resig, the lead developer of jQuery . Christian's presentation was dramatic in many ways for the way it exposed that working solely in the browser with native html5 technologies was possible and important to an open web. But Heilmann also served as a subtle introduction to John Resig's presentation in that he impressed upon the group the importance of understanding how the code you are working with works:

Don't practice pixie magic... If you use someone's code, make sure you understand it... Don't just take it

As a bookend to this idea, John Resig's presentation showed how deliberate and thorough one needs to be to treat "every user [of your project] as a potential, future, contributor" and to lead them towards that goal.



Resig stressed that you should assume your users have little in the way of background knowledge and to make your documentation as explicit as possible. e.g. "Open text editor..."

With this in mind, I have decided to take a closer look at Popcorn.js, an amazing JavaScript library that allows you to create multimedia presentations in the browser using html5. (See these demos for some inspiring examples). Previously, I had created a presentation with popcorn.js using the authoring tool at butterapp.org, but I wanted to follow Heilmann's advice to not rely on "pixie magic" and to gain a better understanding for how the underlying code worked. I also wanted to use this as an opportunity to see how explicit the documentation for popcorn.js was, especially when held up to Resig's rigorous standards, and to write this blog post which could possibly serve as an aide to other users, like myself, who are approaching popcorn.js for the first time.

Digging into the source code of popcorn js

1. I first downloaded the complete project as a zip file.
2. I then unzipped this archive into a folder on my computer.
3. Next I uploaded this to a directory on my web server.
4. I then made sure to edit the .htaccess file on my web server so that the mime-type are configured properly for html5 video

I was familiar with how to make minor modifications to the source code based on my experience with what I had created at butterapp.org. I knew the format of the page looked something like this (as described in the documentation Popcorn 101):



I knew that the page contained "popcorn commands" which could be as simple as "pop.play()" or could be configured like this:

pop.footnote({
start: 2,
end: 6,
text: "Pop!",
target: "footnotediv"
});

I also knew that the the properties target: "footnotediv" corresponded to a div with the id "footnotediv" within the body of the html page.

Getting ready to make your own plugin

1. I read the readme file and noted that I could get in touch with other popcorn developers by way of the mailing list or the IRC channel (irc://irc.mozilla.org/popcorn).
2. I skimmed the documentation and also found that there was a step-by step guide to Getting Started with Popcorn.js Plugins.
3. I read the plugin guide and it kind of made sense, but I'm more experiential, so I went into the plugins folder and made a copy of the "footnote" folder and renamed it to my plugin, which I called "styler".
4. I then renamed the four files within the styler directory from popcorn.footnote.html to popcorn.styler.html (same for popcorn.footnote.js and so on).
   
5. Since the JavaScript and html pages resided in a different directory than the footnote directory, I had to adjust the path the JavaScript file in popcorn.styler.html from
   

   <script src="popcorn.footnote.js"> 
   to
   <script src="../footnote/popcorn.footnote.js">
   <script src="popcorn.styler.js">

6. I uploaded my "styler" directory to the web server under the popcorn-js/plugins folder and could test this by going to my web site at the url http://johntynan.com/scripts/popcorn-js/plugins/styler/popcorn.styler.html . Note the format of the path in the url. For your plugin, you should be going to a similar address.
7. This gives you a fully functioning page containing a working footnote demo that you could edit, build upon and test out your own ideas.

Making your own plugin

1. Remember to check out the Getting Started with Popcorn.js Plugins guide.
2. If you plan to contribute your plugin back into the popcorn.js community, you may want to be familiar with the recommended workflow. It will probably also be helpful to read through the popcorn.js styleguide.
3. In your text-editor, set your "tab setting" to use two spaces instead of tabs.
4. Next, I edited my popcorn.styler.js renaming all instances of "footnote" to "styler" (making sure to use the match case parameter and to perform this same search and replace for all instances of the uppercase Footnote as well).
5. Note the sections of both the popcorn.styler.html page and the popcorn.styler.js script. In particular, note how the popcorn.styler.js script has a five main sections: the description, the manifest, the setup and the start and the end.
6. Next, change the description and the author information to reflect the name of the plugin and to describe what the plugin will do.
7. You'll also want to change the example and the manifest to match the parameters that you'll be placing in the popcorn.styler.html page for example:

Making your plugin change some things on the page

1. Rather than create a div on the page (as the footnote plugin does), let's let popcorn select the target object that we would like to change by changing the options._container variable from

   options._container = document.createElement( 'div' )

   to instead read
   

   options._container = document.getElementById( options.target )

2. Next, in the start function, change
   

   options._container.style.display = "inline";

   to read
   

   options._container.style.color = options.color;

3. Lastly, make the following change to the popcorn.styler.html file
   

Viola! There it is:
You should have a video that plays, some text that displays on the page 5 seconds into the video, and then this text should change color 10 seconds into the video!

Next steps

If you're like me, you should be asking yourself, what else can I do on the page? Is this really just javascript? Can I change things by way of CSS or the DOM? And what about popcorn.js? How does this popcorn.js file work? To what extent does this one file hold together the entire framework and what exactly does this file do? Which functions that I used in my HTML or my JavaScript file actually reside in popcorn.js? And what more can I do with this file and with this framework? Do they have an API... why yes they do. The work is just beginning. And while this exercise has dispelled some of the "pixie dust" I have a feeling that there is quite a bit of pixie dust left in store for developers wanting to explore what can be done with popcorn.js .

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).