At the core of any radio station’s website is the radio player. This is how users will primarily interact with your core product online. This player will typically play the live stream, and sometimes on-demand content. It’s not uncommon to have several versions:
- Website live stream popup player
- iPhone live streaming app
- Android live streaming app
Getting this experience right is crucial to the success of your website. Here, I outline the different approaches currently out there, core requirements, technical considerations, usability and design options.
This article is a part of my series on Building a Radio Station Website. Please check out the other articles for more information on creating a website for your radio station.
Radio Player Examples
Before we get into the details, let’s take a look at some of the players currently out there…
2Day FM:
ABC 702:
Hope 103.2:
BBC1 (UK’s RadioPlayer):
Nova:
KLove:
iHeart Radio (Z100):
Common Player Elements
Some of the common player elements we see in these examples:
- Play/Pause button
- Volume control
- Station branding
- Launches in new tab or popup window
- Current show & photo
- Current song & album artwork
- Previously played songs
- Advertising space (commonly a Medium Rectangle)
- Links to other content on the website
To me, these are the essential features and core requirements. Your requirements may vary, and that is something you need to identify. However, I would say that if in doubt: the standard player/song info combination is a safe bet.
Technical Considerations
The key technical consideration is getting the audio streaming reliably and across all browsers.
There are a number of ways you can stream audio to a web-based player. My recommendation would be to stream MP3 and AAC+ to an Icecast server. Bitrates are up for debate, but I would go 64Kbps for AAC+ and 80Kbps for MP3. Why? AAC+ sounds better at lower bitrates than MP3 and other codecs. You may also want to consider HTTP Live Streaming (HLS) as it is an emerging standard.
With these two streaming formats, you can safely use a HTML5 player with a Flash fallback. Player libraries such as MediaElement.JS make this easy for you. The browser support for MediaElement.JS is quite good, as it support a flash fallback:
Song Data is the other major technical consideration. There are two components to this:
- Getting Song Data out of your radio playout system
- Storing and sending that data to your web clients
I have found it necessary to build a custom software package to store and serve the data, as I’ve been unable to find anything else out there to do this. In my system you can also setup the on-air schedule so the player shows the correct show. It also matches the song with iTunes, Echonest, Last.fm, Spotify, MusicBrainz, etc.
How you handle this is up to you and depends on your requirements. At the very least your player will need to support pulling a XML or JSON file via AJAX at a set interval. Even better: WebSockets.
Radio Player Usability
When designing a player, it’s best to keep universal player functionality and best-practices in mind. What do I mean by this?
- Big play/pause button
- Volume control
- Everything else in secondary
Some players put the play/pause button at the bottom of the page, while others put it at the top. I personally prefer to put it at the top, as this is within the F-Shaped Pattern for Viewing Websites.
As you can see, this eye tracking study shows users tend to read across the top and side of the page, as well as part way down the page – in a “F” shaped pattern. It makes sense to keep key functionality within these areas.
Design Options for your Radio Player
There are plenty of ways you can design a radio player. Using the above example players for guidance, and what we know about usability, I would suggest something like this Wire Frame for your player:
Of course, this should in influenced by the content you have available and your priorities as a station. This wireframe is only a starting point.
A note about Mobile Devices
Mobile browser support for media streaming is lacking. For example, background audio streaming support isn’t great. I suggest developing a native application for the main operating systems to give users the best experience. I can have a similar design to your web-based player, but with the native code needed to stream correctly on a mobile device.
Finishing up…
Following these suggestions will help you develop a great audio streaming experience for your users. As always, make sure you study best-practices, run cross-platform testing and use usability testing to refine your approach.