Adam Curry and Doc Searls slag on the iPod shuffle and its appropriateness as a device for listening to podcasts. In an article today in InternetNews, Doc comments on the device:
“It’s neither a boon nor a bust. It’s just not useful for listening to podcasts. Navigating inside a long podcast — and many are very long — is difficult even with a regular iPod, as it is with all players. So, rather than fix the one feature that’s lame about the iPod, they eliminated it completely.”
Adam echoes the sentiment.
“Apple hasn’t picked up on podcasting because they are thinking about how things work from Apple to the rest of the world. They are not seeing what is happening.”
Adam, Doc…I respect the hell out of both of you. But blaming the device is only looking at half the problem.
The other half of the problem is in the structure of the podcasts themselves. When a broadcaster podcaster constructs a long, monolithic podcast of, say, forty minutes or so, it is a black box. It is monolithic. The only current way around this is to create detailed “show notes” to give the listener (who is your customer, btw) some visibility into the inside of this black box. This is the core of the problem, not the device. This currently needs to be done separately from the podcast.
Let’s take a step back, and look at another example of monolithic content that is delivered digitally…DVDs. The DVD makers figured out early on that they needed to break their creations into “scenes” to make them navigable. Podcasters need to do the same thing.
Three solutions:
- The pragmatic one: Podcasters…break a monolithic ‘cast into parts, and post them separately. More work on your part, but solves the problem. And its doable today.
- The midrange one: Create a way to easily bundle the monolithic content with a cue file or the equivalent that tells where things are. If a customer is interested in better navigation, the customer can split the podcast based on the cue file prior to loading it to a device.
- The long range one: After the podcasters do their part to indicate the cues, Apple, Creative and others build devices that take into account the bundled MP3 and cue files, and allow random access navigation.
To dismiss the device is only looking at a small part of the issue. The onus is just as much on the creators of the content to provide clearer navigation clues into the things that they are creating.
(hat tip: nevon)
Update: Come to think of it, the midrange option could be handled inside of iPodder, iPodderX, or Doppler as well, I s’pose. Have the podcatching client split up the podcast on its way in, based on the cue file, and then automatically write out the component parts for easier navigation.