Public media needs coding collaborators
_Public broadcasters — National Public Radio, the Public Broadcasting System and their local affiliates — are playing a significant role in leading media innovation in the 21st century. This is the second of two guest posts about the various projects of “pubmedia” — by which the author refers mainly to public broadcasters and their related Internet efforts. Here’s part one.
_
The major public radio movers and shakers have undertaken several ambitious Internet projects. The results will take years and cost millions of dollars. Networks and large stations, with the staff to implement these often complex, time-consuming solutions, will benefit most.
But what of the mid-to-small size stations and independents who need simpler, smaller apps? We, the little pubmedia people, need not be left out in the technological cold. What follows are some schemes for co-developing apps and how-tos — approaches that will help the online operations of every pod/broadcaster.
Pubmedia Papers
Say a station journocoder has a few free afternoons, and wants to check out some new technology. She learns how it works. Then gets it working at her station. Then . . . well, that’s often the end of it. Her research-time investment does nada for the next station(s) interested in that same technology.
That is unless we as a community began to collect these bits of techno-insight, sharing them in white papers and tutorials. Some topics might spring from individual effort. For others of widespread interest (e.g., Content Delivery Networks or HTML 5 media streaming), we might commission the research, as a system. We could find out . . .
What’s Out There
Here are examples of two services for which pubmedia-specific API how-tos could inexpensively and immediately help hundreds of our sites:
1. Value Added News describes itself as “News DNA for searching, sharing and protecting.” With a simple set of standard web tags (XHTML), a station/producer can “help people find and assess news content on the web.” Their hNews microformat lets both people and search engines sift thru all the information and ads on a page, and extract a story’s vitals: author, source, geo-location, rights, date, even journalistic principles (PBS MediaShift post).
Check their short slideshow and this “Tech and Law: hNews tutorial”. Two-hundred sites already use hNews, including AOL and AP, which co-founded the standard, along with Tim Berners-Lee. (You may have heard his other invention: the World Wide Web.)
2. oEmbed — also a widely adopted protocol — provides and displays embedded media, such as audio and video. oEmbed-ing your site makes it easy for others (blogs, press, etc.) to discover and share your multimedia. The oohEmbed format makes using the API even easier. There’s a Drupal module; and oEmbed is now part of WordPress’ core.
YouTube, Flickr, Vimeo, and Hulu are all oEmbed providers. Plenty of pubmedia sites could (should?) be too — if only we had our own tutorial explaining how to make use of it. Hmmm . . .
Pubmedia could take advantage of so many other existing solutions: Amazon Web Services, FOAF (Friend of a Friend — suggested by WGBH’s Chris Beer), Mechanical Turk (a guest post here at H/H linked to ProPublica’s guide to using it) — a good start on what these Pubmedia Papers could be.
One big barrier to using these services is the staff time it takes to figure out how-to. Instead of each of us individually immersing ourselves in every new API, what if we sent a couple people on a tech-checking mission? They could then share their experience: sometimes as research results, often as an easy to follow step-by-step tutorial. The collective savings and benefits would be enormous.
What’s In Here
That’s right: Think inside the box. We in public media have created a staggering amount of innovative code ourselves, for news reports, music streams, and multimedia presentations.
Look at the Flash work of 360degrees from a decade ago, or what MediaStorm is doing now. Many us spent our early online days huddled around KCRW’s music feeds. WFMU’s Beware of the Blog is a treasure-trove of archival audio/video esoterica. Transom (the first website to win a Peabody) was blogging and social-sharing before there was a WordPress or MySpace.
Why not have a way to compensate stations to dust off their code, wrap some narrative around it, and present it to the pubmedia world? We’d encourage breaking scripts down into reusable elements (a.k.a., abstraction).
Sharing Code and Community
A next step would be to take on some small communally coded projects. We’d ask: “What simple online tools does every pubmedia site need?;” then develop them together. These would be small-scale, open-source solutions that complement, not conflict with, the large projects (PMP, PBCore, etc.). Examples:
- A WordPress plugin and Drupal module that one-click insert pubmedia content into blog posts.
* Maybe even a Pubmedia Player, in HTML5 with Flash fallback, suited for both audio, video, and slideshows, with embed/download/share options. One that reports stats on not only number-of-plays, but also on location-of-pauses — logging where a user stopped play. It would have a common look and functionality, but be individually brand-able by stations/indies, and skinnable by users. People would learn to use it once, at any of our sites, then know how to use it everywhere.</ul>
The [Pubmedia Commons][22] screed expands on this concept. For insight into how collaborations might help journocoders, I talked to two who’ve spent countless spare hours on side projects: Chris Beer made [NPR/Solr][23], a “more like this” tool for retrieving related stories. And John Tynan created the [NPR/Simile Timeline][24].
#### Code
> Peer review — an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities — is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.
> —Karl E. Wiegers, [“Humanizing Peer Reviews”][25]
>
> Peer code reviews are the single biggest thing you can do to improve your code.
> —Jeff Atwood, [“Coding Horror: Code Reviews: Just Do It”][26]
Even within large pubmedia orgs, journocoders rarely have opportunities to inspect each other’s code. Chris Beer works with dozens of other developers at WGBH, but, “with heads down in our own project,” rarely does one team look at another’s scripts. “On-the-ground web-devs don’t have a place to talk.” And not just tech-talk: “We don’t know what’s needed.” Chris would like anyone in the system “be able to say ‘we want this,’ and roughly what ‘this’ should do.”
John Tynan agrees: “The questions I have are mostly not technical,” he says of his new [Public Radio Roadtrip App][27] (“crowdsourcing the process of putting pubradio stories on a map”). His concerns are “mostly about usability, finding out how users might use the app we want to create.”
He imagines a place where “users can kick the tires,” and where pubmedia people connect “not only across silos, disciplines, and programming language camps, but also with non-programmers: to gain all types of expertise. I want to get in touch with people who **don’t** think like me.”
Q: So how do you foster a community?
A. Look to the librarians.
#### Community
As part of Chris Beer’s [PBCore][28] work, he often consults with the healthy, active community called [code{4}lib][29]: “coders for libraries, libraries for coders.” They have an email list, a conference, and an always humming [IRC channel][30] ([#code4lib][31] — login any weekday and you’ll see scores of folk chatting code).
Pubmedia already has plenty of places to collaborate (see Jessica Clark’s [“Guide to Rising Public Media Networks in the U.S.”][32]):
* [PubForge][33] discussion maillist.
* [Public Media][34] Google Group.
* [#pubmedia][35] twitter tag (and weekly [tweet meet][36])
* [PubCamp][37] unconferences
* [Help.HacksHackers][38] (“a place for journalists and technologists to solve technoproblems”)
What we don’t have is the habit of collaboration — at least not amongst ourselves. We participate in outside interactions — Stack Overflow, WordPress forums, etc. But sharing code within pubmedia is not as instinctual — yet.
Chris Beer wonders: “What counts as useful? Code-dumps are not inherently useful; you need a road map, a community around a project — one person often cannot possibly support it alone.”
I talked to PBS social strategist, [Jonathan Coffman][39], about this. He sees software projects in “two tiers: the code, and the use.” The code must be “handed down in packaged way. We need education and evangelizing: getting the word out.” Also vital is “showing the value to superiors” of this open-source ethic. All these aspects are part of “supporting the people dealing with putting public media into online environments.”
#### Sharing
John Tynan points to how coders have used the [NPR API][40] as an “example of what could be done.” To make his NPR [Roadtrip App][27] he used [KCRW’s python NPR API library][41] (with generous advice from NPR and KCRW). One by-product of John’s apps is his [portable query generator][42], a compact form for making API calls to NPR’s archives, “which can be extensible: other people can incorporate it into their work.”
He says a next step would be taking the time to “show how our scripts can by used by others in their apps: encouraging people to think there are resources out there — you don’t need to build from scratch.” He envisions a set of “living documents” that grow with use, reuse, and refinements.
His first step, though, would be “making people aware of fact the code exists; and that help is available for their work.” Along the way “we’d get a feel what expertise is out there” — who mixes a mean social media salsa, and who’s got jQuery juice; who’s a Python [Parselmouth][43] and who’s a promotion ninja.
John’s testing [Google Moderator][44] to get input into “how specific functions are working. People can vote ideas up or down. A monitor can survey topics, and say ‘Nobody’s answered this one, could someone take a look.’ Similar tools have been suggested using Stack Exchange for [public media][45] and [broadcast][46] conversations.”
Chris Beer’s NPR/Solr project stumbled because he needed server resources for other projects, so he had to remove the app. That could be avoided in the future if we have “somewhere for large projects to live,” such as a collective [Amazon’s Web Services][47] account (which has inexpensive instance/hour auto-scaled micro-fees).
Pubmedia online in the USA presents itself as set of separate fiefdoms, not a unified presence made up of distinctive personalities. For front-end display that might be fine. But that doesn’t mean we back-end dwellers can’t confab, conspire, and co-create.
The [Pubmedia Commons][48] hopes to help make that happen. We’ve started by aggregating a [river-of-news feed][49] of blogs on public media matters, archiving the weekly [#pubmedia chat][50], and documenting our [WordPress customizations][51]. It’ll take a little seed money — we’ll be applying to the [usual suspects][52]. But most of all, we need your participation. Please enter your comments, ideas, and related efforts below.
_Barrett Golding is Fearless Leader of the [Hearing Voices][53] producer collective; and keeper of the [PubMedia Commons][48], where we share code and community. He offered two posts to Hacks/Hackers in an effort to build interest in technology development that supports the mission and goals of public media._