Monday, November 28, 2011

Web2py Caching and Google App Engine

With the recent billing changes to Google App Engine, I was presented with a practical and monetary incentive to optimize my web2py app running on GAE.

At the suggestion of Jason Brower, I decided to look into implementing caching.  As a result, I found that this is one amazingly simple way of reducing costs and improving performance of my web2py app.

While there may be other ways of going about this that appear to be more involved, implementing caching can be as simple as adding the following decorator at the start of a function within your controller:

@cache(request.env.path_info, time_expire=3, cache_model=cache.ram)


You can read more about putting this into practice in Chapter 4 of the web2py book.

Here is a visual representation of the results:


Here, the blue line represents dynamic pages being served and the orange line represents pages served out of cache.

Enabling caching resulted in faster page loads for users, reduced costs, less stress on Google App Engine and a dramatic drop in errors messages (bringing them to effectually zero over a 12 hour period).

Where you are really going to gain performance with this are the functions which contain costly database queries.  That said, there are also some issues that you will need to look out for.

After enabling the caching decorator, you will want to test all your views using GAE's dev_appserver.  To catch errors and obtain a traceback, I found it useful to start GAE's dev_appserver.py with the -d command line argument to enable debugging.

While testing the app within web2py's built-in web server natively produced no errors, when testing the application using GAE's dev appserver, I found a few instances where certain views returned an error.  In particular, I found myself dealing occassionally with a PicklingError.  Fortunately, the great folks in the web2py group (anthony, howesc, massimo and Bruno Rocha) really came through, as they often do, with some great advice on resolving this issue.

In particular, rather than returning the dictionary (using return dict() ) like we usually do, using response.render(dict()) helped in many instances:

return response.render(dict(yourobjectname=yourdictionary)) 

In two other instances, I found I had to use python to get around an orderby within a select:

pledges=db((db.pledge.segment==segment_id) & (db.pledge.read != True)).select(orderby=~db.pledge.created_on)


When I removed orderby=~db.pledge.created_on from the query, the error went away,

however, we really don't want to loose the ability to order our query and serve the most recent results first.  So, to achieve the same results, we now needed to enlist python:


    # pledges=db((db.pledge.segment==segment_id) & (db.pledge.read != True)).select(orderby=~db.pledge.created_on)
    # orderby=~db.pledge.created_on seems to cause an error in GAE when cache is turned on, therefore:
    pledges=db((db.pledge.segment==segment_id) & (db.pledge.read != True)).select()
    sorted_pledges = []
    for row in pledges.sort(lambda row: row.created_on,reverse=True):
        sorted_pledges.append(row)
    return response.render(dict(pledges=sorted_pledges))


Viola!  We now have arrived at the place we need to be, plus we have caching.

After testing this in GAE's dev_appserver checking for any errors (and presumably rebuilding any indexes that need to be rebuilt) you are now ready to simply deploy your web2py app on GAE with caching.


------------

That said, I still have a question about what the difference is exactly between return dict() and and return response.render(dict()), but I'm really glad about the results.

Saturday, September 3, 2011

Re-evaluating my relationship with public media

I’ve finished my work with the amazing Knight-Mozilla Ideas Challenge and have been thinking about how things went. While there was an amazing amount of ideas around innovation, some of the advice that I took to heart late in the program was not aimed at fostering pure innovation as it was aimed at developing and strengthening an established idea or business; in particular, I had focused on the ideas of:

  • iterating, constantly updating your product, based on feedback 
  • and of listening, deeply to the goals of your audience (as suggested by Storify's Bert Herman)

With this in mind, there was one comment from Patrick which I had downplayed early on as I had been developing the Public Radio Roadtrip, but here it is, and it had still remained unforgotten:
It would we sweet if we could put [the public radio roadtrip] on our sites as a widget and define a certain starting area, such as our service area or state. I suppose the stories pulled would have to go back far enough to populate the less written-about regions.
Listening to this request had me re-thinking my approach and deciding that what I needed to build was an import/sync tool to update stories from NPR and then creating an automatically updateable, easily embeddable map that stations could use to show stories from NPR based on coverage area.

I was assuming, in the absence of significant use and regular feedback on the Public Radio Roadtrip in-which I could base frequent iterations of the product, that this one comment was indicative of a larger segment of my target audience.

Additional benefits of building an import/sync tool is that I could build upon KCRW’s NPR API module purely using python and contribute back to the project and possibly help other developers as well.

Yet, part of me thinks that all this is just me spinning my wheels.

And yet another part of me hopes that my work has at least added something relevant the larger conversation about public media, or even specifically around discussions regarding location-based audio. I wonder, for instance, if my post on Navigating Public Media Stories via GPS might well have been a footnote in the discussion that Zach Brand and others at NPR have likely been having leading up to their proposal for a presentation at SXSW entitled Auto Meets Mobile: Building In-Vehicle Apps.

While another part of me thinks I should refocus my efforts altogether.

Let me explain. Recently, in creating my Final Project for the Knight-Mozilla Ideas Challenge, I had a great experience with using the popcorn.js javascript library for syncronizing audio and images.  I found the process to be exceptionally fun. Here is a link to the presentation http://johntynan.com/presentations/nearbynews/finalpitch/ (Please note that, at the moment, this only runs in Firefox 4 and Google Chrome).  In working on this, I was reminded about how voicing for radio is about writing!

But I also was inspired about using this JavaScript library in other ways. Just like I had used proprietary animation tools to create an animation for an interview that Rene had done with me, I can see how this particular tool could be used to present existing radio stories visually, like what the Rauch Brothers are doing with StoryCorp, or Sarah Vowell’s collaborations with an artist friend using post-it notes (I wish I could find a link to these, they’re brilliant and inspiring), or the playful animations for KUT's O'Dark 30, or the excellent and inspiring New York Times' One in 8 Million project. I’m sure there are other examples that could be found in public media, and if you have them, I’d be glad to hear your suggestions.

So, I feel like I’m at the crossroads for my public media work.

I have found over the last year, that being an independent web developer with an interest in public media presents some interesting challenges.  While twitter, direct email and other avenues of communication give some glimpses of the goings-on of the industry, I wonder if  by not working at a station, or in coordination with a station, removes the independent developer from an important part of the dialog and presents a distinct distance from people who actually who would benefit from your work.  Supporting this idea, I was heartened by a recent post at NPR Digital's Core Publisher blog outlining the Program Director at Michigan Radio Tamar Charney's experience in Transforming our Web Strategy as one of organizational change.  Following twitter updates or following tumblr blogs give brief hints at larger changes, but I am pretty sure they are no substitute for being an integral part of the conversation happening at the station/national level.

And that's why I think it's pretty advantageous that the good folks at AIR and the CPB are sparking up a new new MQ2-inspired initiative “designed to pair inventive producers with local stations to increase the capacity for innovation in public media.”  I believe I can see the benefits that such a program would present for stations and for creative producers and developers.

But perhaps there are additional ways for developing my interests and talents within public media.  Perhaps joining AIR and pitching stories to news outlets or picking up tape syncs (especially while we're in Paris) might be a good direction to take.

Given that my family and I are projected to spend five years in China starting in 2013, I wonder if there are ways where this could be turned into an opportunity for both my friends and colleagues in public media, for their audiences and for myself?

Sunday, August 7, 2011

NearbyNews - Mozilla NewsLab Final Project

The Pitch



Design document


High-level architecture of NearbyNews components and processes

NearbyNews requires almost no installation.

NearbyNews leverages the newsroom’s existing infrastructure in that stories are fed into the NearbyNews database by way of the news organization’s RSS feed.

News organizations are also required to place one simple block of JavaScript into their page template and NearbyNews maps for all of their stories will automatically appear on the appropriate article pages.

Settings can also be configured to have newly published stories mapped automatically.  After an initial import of stories into the NearbyNews database, organizations may also opt to manually add new stories by hand.


(The interface for the NearbyNews story tool)

To review and edit maps, reporters and editors would login to a web-based dashboard.  A browser-based web app will be available guide news staff through the complete geolocation process using the story tool.  The can also map multiple stories within a series using the series tool.

Detailed documentation and on-site training will be available, as well as remote support by telephone and on-line chat.


NearbyNews is built collaboratively with reporters and editors


NearbyNews will be built for the newsroom, in the newsroom.  And understanding the newsroom culture of any participating organization will be part of the project.  Getting to know journalists and news directors and listening to them discuss their views on mapping is an important step in the process.  Journalists and editors may be asked to talk out loud while they use the NearbyNews tools and notes could be made regarding any difficulties or additional functionality that is requested.   Reporters could also be videotaped using the tool (with care to recognize excessive hand movements).  Adjustments to the interface could be made iteratively based on feedback.

NearbyNews will be built collaboratively with newsroom and open-source developers.  This code will be fully open-sourced.  A special fork of the program will be made for each participating news organization.  Enhancements made by newsroom or open-source developers can be merged back into the base product for the benefit of all.

Building an active, happy developer community depends on writing highly usable, high-performing, quality code along with quality documentation that anticipates the developers needs at every step and reduces as many barriers to adoption as possible.


NearbyNews leverages the following apps and platforms

A prototype of the NearbyNews can be found at publicradioroadtrip.appspot.com and the code can be found  on Google Code.  NearbyNews is currently built using Python and Web2py and can easily and cost-effectively be deployed on Google App Engine.  It uses GoogleMaps and jquery and KCRW’s NPRAPI Python library.  Future enhancements draw inspiration from Guilhem Vellut’s tutorial on Text Geotagging with Open Calais and Chris Heilmann’s GeoMaker and more.

NearbyNews aims to explore and resolve the following issues and challenges

The process of extracting location information from news stories based solely on a description or transcript (using Yahoo Placemaker and OpenCalais) is not entirely accurate.  Refining geographical information by a reporter or other staff member may be preferred.

The question of what to do with stories that are "not mappable” is a good one. The question of what to do with stories which, by their subject matter, are more general or conceptual should be considered in more detail.

The benefits of integrating geolocated stories into location-based services like Layar or Google Latitude still needs to be explored.  What will be the benefits to the news organization in terms of strategy, time?  Best practices around this strategy should be published.

How to best use location information to increase revenue?  How effective is advertising targeted to a neighborhood or region.  Would this really add value to advertisers?

How to create a user experience in the physical world around news?  Best practices for organizing, for example, a “walking tour” based on a particular topic or series of stories have not been established.  Would this kind of community engagement increase audience?  These experiments need to be tried and refined and the results published.



Business Brief

Mapping stories is an important part of framing a story and helping listeners relate to your reporting and to their world, yet this is a feature that is noticeably absent from many news stories online.  NearbyNews provides a news mapping service as well as an easy to use set of tools that are tailored specifically for journalists.  Rather than focusing on complex data visualizations, NearbyNews aims to provide a fast, practical way to geolocate the stories coming out of your newsroom.  NearbyNews works equally well as a way to map collections of stories in a series; such as your newsroom's coverage of seasonal wildfires.

There are a handful of mapping tools on the market, but none are tailored specifically for news organizations.  Some tools are more general like Google Maps, some are specific to disaster relief like Ushahidi’s CrowdMap, some cater more towards data visualization like TileMill.  Other tools focus more on crowdsourcing like broadcastr.com.  However, NearbyNews is the only mapping tool made specifically for journalists where speed, simplicity and ease of use is a premium -- and NearbyNews comes at a price-point that any newsroom can afford.

NearbyNews easily integrates with your existing tools and workflow, places little demand on your reporting staff and yet can be used to create in-depth maps as the story or series requires.

NearbyNews also provides many additional benefits and opportunities.  Your audience will benefit by discovering your stories serendipitously via their mobile phone (using a familiar Google Maps interface) in the places that are relevant to the stories and relevant to them.  Your sales departments and your local business partners will benefit from using NearbyNews in that advertising can be targeted to specific neighborhoods or regions.  Your organization may enjoy increased visibility and perceived value in your community by having your stories positioned in the physical world as location-based services become more widespread.

Friday, July 29, 2011

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

Sunday, July 24, 2011

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.

John Resig - JQuery - Watch the full process

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 .

Sunday, July 17, 2011

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:

Placeify

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.



Thursday, July 14, 2011

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

qrcode1

Then, you search for Tomoato.

qrcode1_1

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

qrcode2_3

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

qrcode4

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

qrcode5

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

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

qrcode6

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

qrcode7

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

qrcode8

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!

Wednesday, July 13, 2011

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:


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


Your Experience

The Story's Experience


Your Story's Experience

The Listener's Experience


Your Listener's Experience

So, now, my immediate step is to:

Saturday, June 4, 2011

The Public Radio Roadtrip: A Proposal for the Knight/Mozilla Drumbeat/MoJo Challenge

I have a great project for the Knight/Mozilla Drumbeat/MoJo challenge. It's geared specifically for curating, sharing and discovering media (and could also be geared for user generated media). At it's core, it's GPL licensed (both the web app framework as well as the code itself). To my knowledge, it doesn't use any proprietary technology (mostly python and javascript). It aims to promote good coding (and has the potential to be a great example of html5 coding). It's reproducable (on practically any operating system, or via Google App Engine). It's easily customized for media organizations. And I think there are software and processes that are being used (notably web2py and google app engine) which could be instructive for coders, media organizations to know about. And it's fun!

Okay, what is it? It's called the Public Radio Roadtrip. It incorporates location-based-audio (or other media) and mapping. It doesn't aim to be a cms. It allows media organizations to continue to use the publication tools of their choice. However, it provides an "editorial layer" between disparate web sites (or apis) and it leverages the power of geolocating stories.

I've been working on this app for almost a year now.

You can view the code here: http://code.google.com/p/publicradioroadtrip/

You can try out the demo here: http://publicradioroadtrip.appspot.com/publicradioroadtrip/

I've blogged a bit about the concepts and ideas behind the app here:

http://opensourcebroadcasting.blogspot.com/2010/10/refining-assumptions-about-public-radio.html

and here: http://opensourcebroadcasting.blogspot.com/2011/05/public-radio-roadtrip-request-for-beta.html

and here: http://opensourcebroadcasting.blogspot.com/2011/06/navigate-to-public-media-stories-via.html

I've had significant input from practicing journalists and technologists from within public media such as Krissy Clarke at KQED, Javaun Moradi at NPR and Barrett Golding (at Hearing Voices).

I think this app has a lot of potential to grow in the coming year. I envision ways where journalists and citizens could inform the direction for the creation of this app. I envision ways where this app could be a useful tool for journalists working to define and discover ways in which location based stories are concieved and told. And I think this could be useful in promoting Mozilla's goal of openness, standards and innovation.

Thank you for your consideration.

John Tynan

Navigate to Public Media Stories via GPS

When you think of driving, it's a natural connection to think of listening to the radio, and then to listening to public radio. But also when you think of driving (especially on roadtrips) it's also natural to think of getting driving directions from a GPS unit. Well, why not put the two together... like chocolate and peanut butter: public radio and gps units...

Has this been done before? If so, I'm not aware that this is a prevalent practice, but why not? Has this been a first? I don't know...

However, last night, I went to a recent post of stories about Childhood Homes from across public broadcasting (and beyond) and exported the listing of stories as a .gpx file. You can try this yourself, look at the top of any of the Published Roadtrips at the Public Radio Roadtrip site.

What is a gpx file? A gpx file is an xml file that is recognized by Garmin (and other?) GPS units.


While maybe not the most intuitive process (at this point) the pictures below show that the process actually works:

Download the GPX file:


Process the file using Garmin's POI Loader:


You can choose to connect directly to your gps, or you can move the file to your gps unit manually.


Once on your GPS unit, you can open the roadtrip and see a listing of the individual stories.


You open an individual story and ask your gps to navigate to this place.



You can also view additional details about the story itself.

One detail, while the urls to the audio are included in the gpx file, and even though the GPS I am using has the ability to play an MP3 file, I have not (as yet) been able to get the actual audio for the story to play within the gps unit. Further testing of this is necessary.

However, if we combine the ability of displaying audio with the ability to print pages containing QRCodes linking to the audio for a story, we have at least the makings of a process for "pubcaching" for combining geocaching and public media. Combine this with journalistic storytelling and perhaps theories about gaming, this could be a powerful process for informing people about their communities and points of interest, of engaging people who may not be public radio listeners, and for raising the visibility and value of public media.

Now that we are able to get stories placed on a map, are able to view them within a gps, if we are able to get the audio to play we could be onto reaching new audiences and creating a new format for discovering public radio out in the world.

Sunday, May 29, 2011

Location Based Audio - A Wikipedia Example

While not strictly an example of location based audio, this is exactly what I was thinking about when I wrote last week about "the idea of printing roadtrips and posting a paper copy of a story in a physical location."  Note the QRCode in the lower right corner.  



This is an example from the Jardin des Plantes in Rennes, France.  Note the viewport from which to direct people specifically to the subject of the article.


It appears that vandalism is an issue.  So perhaps, paper copies of stories are more pragmatic.

Imagine your station's reporting placed in prominent areas of your community, where people could gain insight into their neighborhoods and where the value of your reporting could be visibly reinforced.

Saturday, May 21, 2011

Public Radio Roadtrip: Request for Beta Testers


I've been coding away on the public radio roadtrip app
http://publicradioroadtrip.appspot.com/publicradioroadtrip/

with some interesting additions:

  • Podcast downloads
  • ability to sort roadtrips by date or by a user defined "sort value" (1,2,3 / a,b,c / 0.1, 0.2 etc.)
  • Ability to view roadtrip in google maps
  • Ability to view in Layar mobile app (by way of a "mediarss gateway" which could also be an interesting idea for other pubmedia projects)
  • ability to download a printable pdf of roadtrips and individual stories
  • display of QRCode scans which link directly to the audio for each story

I'm particularly excited about the idea of printing roadtrips and posting a paper copy of a story in a physical location (as well as providing gpx/kml downloads for use in gps units to promote the use of stories as caches for people interested in geocaching with publicmedia).  I think the idea of printing a flyer containing a QRCode for the url directly to the audio could allow for some interesting possibilities for listeners and stations.  I think this could be a low-tech entry for getting location-based audio out to mobile phones without, at this point, building a dedicated app.

I'd like to experiment with placing flyers about a specific news story out into the physical locations that are relevant to the story and where a person could gain insight into a place by listening to several stories about an issue.

But I'd like to work with some of you to refine this process.  In particular, I'd like to work with content experts on the kinds of stories that would be best grouped into a roadtrip.  I'd like to test and refine displaying these stories and to learn and adapt from these experiences.

I'd like to work with pubmedia coders who are used to working with an app in progress and I'd like to adapt the public radio roadtrip app to these experiences and to post the code for others to use and adapt to best suit theirs, their reporters' and their constituents' needs.

Already, I've incorporated input from Barrett and Patrick on the public media coders list, as well as generous input from colleagues Krissy, Javaun and Andrew into the issue tracker here: http://code.google.com/p/publicradioroadtrip/issues/list .But I think there are ideas, uses and possibilities for this app that have not been discovered yet.

Let me know if you are interested in giving this a try and I'd be glad to work with you.

Feel free to create an account and put your favorite public radio stories on the map!
http://publicradioroadtrip.appspot.com/publicradioroadtrip/

Monday, March 28, 2011

Are there Best Practices for Pubmedia Embedded Audio Players?

Lately, I have been testing different embedded audio players for requests from the NPR API.

I wanted to play the audio when someone clicks on a pin representing a story from NPR.org at a particular place on a map. When this information bubble displays, I wanted the audio to play automatically, like this here:



You can view and try this for yourself at http://publicradioroadtrip.appspot.com/publicradioroadtrip/default/view_collection/364006

(Also, if you want to see/hear something a little more interesting, drag and drop the icon of the person in the top left corner onto the pin on the map. If you click on the pin in street view, you should be able to listen to the story as you are looking around at the landscape).

I was interested in using a flash as a fallback player while also using the html5 audio tag (which I understand will only support mp3 (and wav and ogg... for a full description of the issue of html5 support for audio, see: http://html5doctor.com/native-audio-in-the-browser/ (thanks to my friend Barrett for the heads up)).

I was leaning towards using the flash-based JW Player (because this is already available as a plugin for the framework that I am using and can be cleanly and easily implemented). However, I found that while the JW Player does support a wide variety of playlist formats , it does not support m3u files.

( For the moment, I've opted for using the Open Source Media Framework's Flash Media Playback player which has a handy configuration page here: http://www.osmf.org/configurator/fmp/ )

So I asked the folks at @nprdigitalsvcs if it was possible to specify mp3 as an output format, as opposed to m3u. They swiftly and graciously replied by saying that at present, you can't request just mp3 audio. You can walk through all audio elements and find type=mp3. These mp3 files are specified within an m3u file.

So, my question is, what solutions have you arrived at when placing an embedded audio player on your site? Looking ahead to html5, is there an additional output format that we can suggest that NPR implement which would help people to best build pubmedia audio applications for the next generation of browsers and devices?

Would it be valuable for pubmedia coders to suggest some best practices for embedded audio players when presenting audio by way of the NPR API?