Seven reasons why embedding media players is bad.

I often wonder who it was that thought it would be a good idea to embed streaming media players into web browser windows. I can’t imagine that the public beat on the doors of software designers and told them, “You know, we like this internet radio thing, but hey – put it in a web browser!

Back in the days when streaming audio on the internet was just starting to become a commercial proposition (and don’t we all remember Xing), radio stations would put a link on their webpages, which, when clicked, would spawn a separate application to play it (based on the link’s mime-type).

Somewhere, along the way, this changed. Stations started embedding their players into web pages – hiding the url, in most cases. These days, I’d estimate that probably 70%25 of online radio stations make their listeners use embedded media players, and those who want to listen to the station with a dedicated application have to go hunting through the javascript source code for a link.

Here’s why I dislike them so much:

  1. It’s annoying for the user. Who wants a hulking great web-browser window on their screen, just to play music? The audio should be going on in the background, not sitting prominently on their screen, forcing the user to iconify it. Just let them run a separate application in the background, minimised.
  2. Most web browsers are unstable. Browsers are big, complex applications. They tend to crash, or hang, a lot. When this happens, embedded media players – which are generally just a bunch of shared libraries, dynamically linked at runtime, will die in sympathy. There’s nothing quite like having the White Stripes halt mid-chorus just as you accidentally click on some tweenie’s all-singing, all-blinking Myspace page.
  3. Most media players are unstable. They’re not big and complex like web-browsers, but I’ve found media players to be, by and large, pretty bloody awful. A bit of network lag, a stream pumps out something the player didn’t expect, and bang, that weblog entry you’ve been working on disappears with the player’s plugin.
  4. Not everyone uses a graphical browser. Good luck getting your javascript monstrosity in lynx – which probably rules out most visually handicapped users from accessing your stream. While most commercial radio organisations probably don’t care about this (although they should), government-funded broadcasters – who need to provide equal access to all – certainly should be taking it into account.
  5. Embedded players are often difficult to bookmark Want your listeners to return again and again? Well, they can’t, if your web pages launch a javascript window without the browser’s menubar on it. Let them bookmark the stream in their favourite media application instead.
  6. People want to use an interface that they are familiar with. I don’t care about that snazzy interface your web design team has dreamt up. My media player of choice is gxine. It’s small, light, and with libxine behind it, it works for the vast majority of radio stations I want to listen to. I have no desire to use any other application to listen to audio, certainly not one with your radio station’s logo plastered over it … and people who aren’t IT-minded will be confused with all the millions of different interfaces that these web-designers waste money putting together.
  7. Hiding the url makes life difficult for people with streaming appliances. There’s a bunch of products coming to the market that are effectively internet radios. It’s probably not far off from the day when mobile internet rates are cheap enough that people start listening to internet streams in their car or while jogging as frequently as they’d listen to a normal radio; as it is, I tend to use my wireless PDA as a portable radio, around the house. If you’re a radio station hiding your url behind a huge web of indecipherable javascript in an embedded player, you’re going to be bleeding listeners. Just provide a damned link.

Furthermore, should any radio station managers or CTOs read this article, please use an open codec, such as Ogg Vorbis for your station’s stream. There’s no good reason to be using a proprietary player – it’s as ridiculous as the sealed set scheme, which was used early in Australia’s radio history, where radio sets that could only be tuned to one station were sold to listeners. Needless to say, it wasn’t particularly successful. By using a codec that people are free to use without restrictions or patent fees, it will open the market to a wealth of new applications and devices, and allow your station to be accessed in ways you might not have considered. Consider how far radio would have gone if it had stuck with the sealed set model…

(And as an aside, there’s just no excuse for publically funded organisations like the ABC, the BBC, CBC, Radio New Zealand and RTE to be using proprietary streaming systems. I really don’t see why government money should be going to prop up one or two software vendors, thereby forcing the public to use proprietary products to listen to programs that their taxes have paid for).

Leave a Reply

Your email address will not be published. Required fields are marked *


Warning: Illegal string offset 'q' in /var/www/weblog.leapster.org/wp-content/plugins/quiz/quiz.php on line 60

Warning: Illegal string offset 'a' in /var/www/weblog.leapster.org/wp-content/plugins/quiz/quiz.php on line 61

Warning: Illegal string offset 'q' in /var/www/weblog.leapster.org/wp-content/plugins/quiz/quiz.php on line 179

Anti-Spam Quiz: