What <audio> means for public radio

Table of Contents

On Wednesday this week (May 30), I will be taking part in a "first of a kind webinar" through Media Engage about the state of audio and video on the web. I consider myself very lucky to be speaking beside some esteemed leaders from the public media technology community.

Although the webinar will address some of the technical issues regarding audio (and video, but here I am focusing on audio) on the web, it's a rather complex topic, and on Wednesday we will focus on some specific implementations by showcasing new audio players from PRX, NPR, as well as the new HTML5 audio player that we use on ttbook.org.

The underlying goal with audio players these days is to move away from proprietary plugins like Flash, Silverlight, or QuickTime, and make playing audio with the HTML5 <audio> tag as easy as displaying an image with the <img> tag. Among other benefits, this gives browsers a more consistent way to stream audio without needing any of the aforementioned plugins and makes it easier for designers to create a consistent look and feel on their sites.

While the <audio> tag offered a good start, it only provided limited functionality and was not nearly as sophisticated as something like Flash, so the Audio Data API and the Web Audio API are supposed to help bring the standard more on par with other commercial plugins.

A common phrase used to describe a modern audio player on the web is "HTML5 player with Flash fallback." The "HTML5 player" part of this description refers to using the <audio> tag, and if the browser does not support <audio>, it tries to play the audio with Flash (or Silverlight, depending on the player). One of the first, and most popular, players to offer this functionality was jPlayer, which launched in 2009. Other capable player projects that meet this general characterization include MediaElement.js, SoundManager 2, Speakker, and audio.js.

One of the fundamental impediments to using the <audio> tag on the web concerns the browsers used by our listeners. The website caniuse.com provides up-to-date information about what browsers support the <audio> tag. This highlights a problem at the station where I work because nearly a quarter of our visitors are using IE8, which does NOT support the <audio> tag. So we're hoping they have Flash installed. Thankfully, the majority of our other visitors use browsers that support the <audio> tag.

This is just a taste of the technical issues concerning <audio> on the web.

In the webinar, we'll address issues that reflect how users consume the audio. For example, NPR differentiates between "engaged listening" and "distracted listening" to describe why they created their Infinite Player, which targets the latter type of interaction. The approach we used when building ttbook.org targeted the "engaged listeners," requiring somewhat more effort for our users while allowing them more control. On Core Publisher sites, such as wprnews.org, NPR advises a more "traditional" approach in that audio players do little more than reliably play audio files related to the story that is currently being viewed.

There exists, to be sure, a wide array of competing technologies in this space, and the knowledgable presenters on the webinar will have useful information to help us all provide the best possible experience for our users and listeners. I hope you will join us on Wednesday.

Comments