Pubmedia Commons

Open, Shared, Scaled

Pubmedia is in a forward-looking frenzy. A glance backward, though, would show us some core internet elements we may have missed; simple, inexpensive enhancements that could:

1. Improve our online multi-presences,
2. Save the system money, and
3. Prepare us for whatever platforms — known & unknown — that come our way.

The system is now contemplating several large, lengthy, and quite engaging Internet enterprises. On this page we ask to also consider some small, low-risk solutions that may have equal impact. This post presents some problems; the next starts work on solutions…

Image Is Everything

What size is a thumbnail image for a public radio program? Every station site designer must answer this question. Turns out, tho, there’s no standard, neither in image size nor aspect ratio.

Pubradio has lots of squares (1:1), from NPR’s 138×138 to WYNC’s 100×100 to PRX’s 50×50. PRI’s thumbnail is 80×60 (4:3), KQED’s 113×54 (2.09:1). Program listings at NPR Stations (login required) call for 120×120 and 75×75, neither of which NPR.org uses; nor do NPR programs (ATC 100×93, ME 100×155). Confused?

This seemingly inconsequential decision can devour web-dev hours: searching for examples at other sites, experimenting locally. No one would be forced, nor even asked to use a standard size. But if one existed, many station/network/producer sites would adopt it — one less decision to make, one more thing to count on.

Commonalities like this scale up well. Site designers would expect program producers to kick out logos in this common size, and could layout pages with those dimensions in mind. Series producers could create widgets for stations with updated-weekly episode image & text that flawlessly fit station sites. Automated image uploaders could be set for this thumbnail-size, simplifying image-processing for producers and stations. Perhaps someday a common repository of pubmedia audio/images could adopt the standard, along with an API providing publicly accessible, mashable audio with accompanying predictably sized images. (See NPR’s API and the new Public Media Platform.)

The above advantages apply to other collective agreements: What is the size (number of characters) of a short program description? A longer program summary? Even…

Pubradio Play

What is the audio player for public radio programs? Every station, network, and producer must decide. Some still rely on Real and Windows Media players; most now use Flash and MP3s. Several roll their own (NPR Media Player, APM). Many rely on Longtail’s JW Player (NPR Blogs, WNYC, KQED, PRI, NCPR). The 1 Pixel Out Audio Player is popular (APRN, HV, Transom, StoryCorps, WBEZ). There’s the delicious Playtagger (WFMU) and the Flowplayer (PRX) and, again, a confounding lack of commonality.

As a system we’ve spent a staggering number of web-development days individually choosing, testing, customizing, and, in effect, confusing users: Pubradio site visitors must learn/guess how these different GUIs work: how each plays & pauses; how/if each embeds, downloads, or shares (emails, socials, etc.).

If we all invested some small fraction of this effort co-designing a player — likely based on an existing one, what a bitchin’ bangin’ audio app it’d be. We’d share scripts and skins. It’d throw off all kinds of JavaScript calls, e.g., logging how many listened to what when for how long. And we’d donate the fruits of our Flash-work to the open-source community, who’ll likely fix our frailties and return it to us.

We could also plan for a post-Flash world, as much of mobile land already is. Lucky for us, the HTML 5 <audio> tag is ready to go, and recognized by iPhone’s Safari. For the non-Flash-y among us, our scripts will just substitute audio-tag code, and, voila, the mobi-device’s default player presents.

<audio controls autobuffer>
     <source src="John_Denver_-_Annies_Song.ogg" />
     <source src="John_Denver_-_Annies_Song.mp3" />
     <!-- now include flash fall back -->
</audio>

The scripts and player could be commonly housed (e.g., at Google Code or Public Interactive): A visitor who used it at one site would already have it cached/downloaded for other sites — radically reducing page-load times.

For one person, or even one organization to undertake this would be Suicide-by-Code. But together we could create and update browser-aware auto-audio-options for all current and future forms of Internet access. Which brings us to…

Everyone’s Invited

Why aren’t pubmedia sites more accessible? You’d think pubcasters would pioneer accessibility. Instead, many pubmedia sites don’t follow even basic rules of Web Accessibility. Maybe because they’re hard to understand.

One major pubradio failing is how we deal with Flash and audio; the above-suggested player could solve both. We could also collectively compose easy-to-follow accessibility best-practices. And push each other towards related standards:

1. Separating structure and content from presentation,
2. Then separating behavior from structure (unobtrusive JavaScript),
3. And moving from graceful degradation to progressive enhancement.

None of which there’s time to go into here, but all of which will make our sites better, faster, easier to maintain — not just on screen-readers for the blind but also in search engines, and for every browser ever made, from the most primitive to those not yet invented.

A joint effort will add up to significant $US system savings (and keep .gov licensees from breaking the law). Our visitors would see familiar tools wherever they ventured in pubmedia-ville.

We could co-dev other tools too. Say we opt for a version of the social icons/styling/scripts NPR uses for stories:

We then might cooperatively code a way to share visitor-comments on a particular story: So any of us, at our own site, could display all the story’s comments, whether posted at a station, NPR, PRX, or producer’s site.

Opportunities for communal coding abound, once we get in the groove. Mobile browser detection is a pathologically mutating nightmare. No one pubmedia entity can keep on top of every new agent. Together, however, we could provide a common, dependable, well-tested pubradio experience for all our users, and another open-source contribution. We might go even deeper into content portability, exploring ideas like NPR.org’s innovative HTML Addressing.

Play Ball

Pubmedia online is currently a scattering of feudal fiefdoms, each desperately trying the keep people from leaving their borders. The suggestions on this page would imply a Pubmedia Commons, while preserving each entity’s identity and personality.

Four years ago IMA’s Mark Fuerst wrote an insightful article on “pubcasters’ second decade on the Web.” He pointed us to Major League Baseball’s web strategy. Each team has its own customized stats, stories, photos, videos, merchandise, and ticket sales. All teams, from redsox.com to dodgers.com, share a sophisticated set of inter-multi-active-media widgets. CNN reports: “The most successful, and most valuable, franchise in baseball in the last few years isn’t the New York Yankees or their rivals, the Boston Red Sox. It’s Major League Baseball Advanced Media, which is worth more than those two deep pocket teams combined — an estimated $2 billion to $2.5 billion.”

Fuerst finds pubradio projections bleaker: “Public radio stations, programs and networks had, by my estimate, invested more than $50 million in online services, with only modest results.” He proposes “A Big Hairy Audacious Goal” involving unified back-ends, articulated vision, traffic metrics, and many CPB $Ms.

But large pubmedia projects like this can sometimes lose impact as they approach completion. Consider the following two endeavors. Both were really good ideas. But both took a while, and in that while, platforms morphed. Despite $1M+ investments, neither has yet provided the public with the anticipated returns:

1. PBCore 1.1′s huge, hairy goal was a comprehensive metadata categorization schema for pubmedia programming. A coalition successfully created the beast.

Convincing people to adopt it has not gone as well. And, during the decade of its development, we moved away from a metadata web and towards a semantic web. Simpler solutions (like Tim Berners-Lee’s Transparency) may yield more public benefit.

(Should mention: the able PBCore folk are well aware of this and working to solve it in their version 2.0.)

2. Radio Engage and other Drupal media projects were well funded by Knight News Challenge. These ambitious efforts took a couple years to craft CMS suites (yes, plural) for pubmedia. Drupal can be admin-intimidating and user-unfriendly. But when these projects started, it was a far better CMS platform than the more popular WordPress.

That has changed. Those of us who use both would be hard-pressed to deem Drupal’s few remaining advantages valuable to any but the largest, full-time IT-staffed pubmedia ops. Perhaps that’s why these complete Drupal pubmedia suites have few folk using them.

Contrast that to Tierra’s WordPress plugins for WNET, a more compact but likely higher-impact effort. Well-known WP-ers now include: NASA and NY Times, .mil and MIT. Aka, it’s stable, secure and mature.

Many of us pubcasters, large & small, use WP (APRN, WNET, HV, Transom, StoryCorps — say, let’s pass around & improve each other’s pubmedia-specific WP hacks and plugs; Google Code or BuddyPress would serve nicely.)

Both above projects were well-conceived and well-executed (witness KALW News by RadioEngage, “aggregating more than 120 community blogs“). The reason more sites don’t use these products may be due to project scope and duration.

The Internet evolves faster than many large projects can adapt. Once we wanted metadata, now we need feeds. What’s next, NewsML? Value Added News? Who knows?

Grand endeavors are vital, but can depend on vision, crystal balls — certainty about an uncertain future. All a small, social, open-source effort needs is a community with some common coding interests.

A Pubmedia Commons (dare we call it Pub Med?)

Our system has invested millions, and is set to eject millions more into huge, hairy guesses as to where pubmedia might be going. What’s proposed on this page complements all these larger projects, will cost $Ks (vs $Ms), release results in months (vs years), and be agile enough to go wherever the public leads pubmedia.

Each idea can be an independent low-budget, low-risk part-time project. Most are platform independent.

The major players should continue to direct the major projects. At the same time, the many smaller pubmedia communities should get support in making more modest contributions. For those that speak buzzword, let’s be a bit more bottom-up than top-down heavy, more bazaar than cathedral:

While coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which feedback exploring the design space, code contributions, bug-spotting, and other improvements come from hundreds (perhaps thousands) of people.
—”The Social Context of Open-Source Software” from The Cathedral and the Bazaar

No matter what curve balls the Net throws next, these projects will help pubmedia swing and connect…