´óÏó´«Ã½

Now onto the most contentious issue. Why would we do this at all? In some ways we’re breaking the rules of the web. Specifically, creating multiple URLs for the same resource (a podcast ‘keepnet’) and we’re customising our markup for a discrete number of devices. In essence, this against everything we’re trying to achieve, but there's are some practical reasons why.

Firstly, the mobile world is strange, and not at all like the desktop world. Different devices have wildly different capabilities, and targeting them all with a single codebase means we’d miss out on a number of features – the iPhone for example requires media to be embedded in a very different way to an N95. It’s not just the data too. As the devices capabilities change, you need to structure your navigation differently and provide different messages to the user. There comes a point where conditionally building your pages using XSSI, Apache Includes and patchily-supported mobile CSS becomes way too hard. At that point, you need to pick a few high profile devices and optimise your experience for them. Not that we’ve forgotten the rest of the devices out there – we’ve built a generic XHTML version which most devices with a browser can display. However, it might link to features and content which your device can’t play or read – enhanced podcasts, and RSS for example.

Secondly, the ideal solution would be to have a single URL and change the extension for each device type. This is quite a tricky task in our current serving infrastructure, and something we couldn’t achieve on this project but its certainly the direction we are moving in. There was also the requirement to allow people to browse the desktop version on their device as well as the optimised version if they wanted to. This meant we couldn’t so silent rewrites based on user agents, and we had to replicate the resources and different URLs.

Lastly, why just podcasts? Well, over the last year or so, we’ve seen Podcasts become a ´óÏó´«Ã½ product offering in their own right. They transcend radio networks and particular shows. Some of them aggregate content from a number of programmes, and others are compilations and aggregations, like the ´óÏó´«Ã½â€™s NewsPod. It also seems that these downloads are content in a condensed shape which people like listening to on the move. They’re not 3 hour programmes, they’re typically 15-30 minutes long – ideal for downloading in a train station when you have wi-fi for 5 minutes at a time. Also, they’re mp3 files, and thus non-DRM. Pretty much any device and play them. Heck, my car’s sat-nav can, and my mate’s fridge can too. That makes them easy to develop with and syndicate.

A quick word about our future plans. Currently our podcast directory is a little silo of data, all on its own – its only very loosely tied to our other mammoth database of programmes and on-demand content which powers iPlayer and /programmes - PIPs. This is not good. It's content, but its not that findable, and from a podcast, you certainly can’t find the original on-demand version of a programme. We want to change this. Soon, we’ll be working on moving our podcasts catalogue in with our big PIPs database. Then podcasts might be available in iPlayer, /programmes etc, and best of all, you’ll be able to create your own feeds based on tags, genres, presenters, contributors and so on – that will be properly powerful. It also means we can create a dynamic podcast directory and overcome all the technical limitations I mentioned earlier.

This is some way off – we have to change our production workflow to make it happen, and right now we’re busy getting all radio into iPlayer proper, but watch this space – when it happens, Podcasts will become even better. For now, get out your mobile devices, and get listening on the move!