You’d expect it to be easy to find ways to listen to live streams on a radio station’s website. But this hasn’t always been the case for a lot of public radio stations.
While almost every station’s web site has some mechanism for listening live, it often involves asking the would-be listener to navigate through a list of links with names like .pls and .m3u, or selecting from buttons for a “flash player,” “windows player” or “itunes.” Obviously, it shouldn’t be so hard.
For this project, I worked with a small team tasked with getting something out to stations relatively quickly. Something we could test, learn from, and improve upon over time. I always like these kinds of projects, because the focus is on moving quickly from research to prototype to design and build — and because it was a small team, I got to be involved in all aspects of the process.
In the first week, I spoke with stations and to a panel of public radio listeners — and did some quick guerilla research out in the field (a local cafe where I asked strangers for their thoughts). In the prototypes I showed, people generally understood how to start and stop the player; they understood the name of the thing they were listening to; they understood there were other listening options.
Working with paper prototypes, I was able to try a lot of ideas quickly — different copy; different information; different arrangements features. We found that the phrase ‘Live Radio’ communicated clearly to most people the difference between listening live and listening to on-demand — more clearly than “listen live,” at least with our panel of public radio listeners.
We wanted the player to be persistent but we also had reservations. Creating a player that could live on station’s existing sites and be persistent would be a difficult problem, both technically and in terms of usability.
Further — and critically — it wasn’t at clear to us that our audience actually wanted or needed a persistent player. If you’re listening to a news/talk program like Fresh Air or All Things Considered, how likely is it you’ll want to be browsing a site and reading at the same time? If it’s a music stream, the possibility seems more likely, but it was still just a guess.
We decided to split the difference, creating a player that would reside in its own browser window. Users who wanted to listen could go to an uncluttered, focused listening experience, where they could browse between different sorts of audio content. Putting the player into its own window also enabled us to take the first steps toward building persistence without having to solve the various challenges of working on an existing universe of drupal sites.
We used Backbone.js, jQuery, and jPlayer to get it up and running quickly.
Over a few weeks, we built a player that let users select from among various live streams, see appropriate information about what they were listening to, and listen to a selection of on-demand clips.
Was it any good? It was okay, a lot better than the stations had before. But it was only a first step, one that enabled us to work out various challenges, learn about audience and user-needs, and try out some ideas — like, did people actually care to listen to on-demand clips in this context? (Answer: a little bit). Or, would stations be able to sell underwriting against a player? (Answer: yes).
Following are screenshots of different ways I thought about handling branding and the UI. In the end, we decided to use a visual style that would align better with existing station designs at the time.