91Èȱ¬

It’s been nearly a week since we our first iteration of our podcast directory customised for the iPhone and iPod Touch, and the reaction as been great. It’s been picked up by , some industry news sites, and by Apple themselves who made it a staff pick in their webapps directory - as I write, we're up to 2nd most popular in their .

Of course, along with coverage has come comment, and we thought we'd try and answer some of the questions that have been raised in blogs and articles across the web.

Firstly, performance on EDGE. Some people have mentioned that there is no play button sometimes. All our test in the office on an iPod Touch and iPhone over WiFi have been fine. However, when testing on EDGE, we've noticed a number of issues. After a lot of emails and rooting around for info, it seems O2 have a proxy server that replaces content on the fly to speed up web-over-EDGE performance. This includes downgrading images, and removing any references to Mp3's - hence the lack of a play button. In the States, there’s no such proxy, so although its slower, US users get the full playback experience. We trying to see what we can do about this issue in the UK, but for now, we have to consider that our directory is WiFi only.

Some people have also mentioned issues with accessing music podcasts outside the UK. Due to rights restrictions, we have to block some of our content to those outside the UK. At present our technology only allows us to do this on a download attempt, or when you try to view the podcast's feed page. It’s been suggested that it would be more helpful to hide these podcasts from the browse lists for international users. We agree, and we're working to see how feasible this is, but its not something we can do imminently due to other project commitments, and the limitations of our technology infrastructure.

Another thing many people have asked it why we did this for the iPhone when its perfectly capable of displaying the 'normal web'? Well, we thought that although the podcasting user experience was already passable on the iPhone/Touch, a lot of work could be done to improve media integration - particularly embed code for QuickTime. Also, browsing was quite clunky - something we thought we could improve with a native iPhone-style interface, without losing any of the functionality. Chris Johnson came up with a neat hack enable e small embed control to play the mp3 files. This means a very small play button (on the right of the embedded control), but a much slicker transition from web to audio - something the regular directory was poor at.

Also commonly asked was "why this device, and only this device"? We've always said, this was a first step. We hope to bring our podcast catalogue to multiple platforms (including other mobile devices), and we've begun work on that already, but we had to start somewhere. The iPhone/iPod Touch were some of the first WiFi enabled mobile devices to be launched since we built our xml-based podcast directory - and we thought that made it a good target to tackle first. In addition, we did this as part of our 10% time allocation - the idea being we can work on things outside the usual constraints. We could have kept it internal and admired our own handy work - or we could release it to the public so they could share in the fruits of our labour.

Lastly, the ability to download, ...or not. This is a limitation of the iPhone and iPod Touch - they haven't got an accessible filesystem, so it's impossible to save web-based files of any kind. We're a bit powerless to do anything about this, but when Apple release the iPhone SDK in March, we may be able to do something more with the device's filesystem.

There are of course other issues ongoing: improving the browse functionally and the left/right page slide, making it lighter and more AJAX-heavy, working with Apple/O2 to improve EDGE performance, getting Apple to massively improve their support for embedded audio etc. But please be patient, we've got loads of other projects on the go, not least to bring this very service to the other platforms you've been asking for.

Right better go. Lots of typing to do and code to write...