The cellular industry has repeatedly attempted to port popular consumer services to the mobile environment. Internet became Mobile Internet. Television became Mobile TV. Despite the investment of billions of dollars in data networks, spectrum, devices, and marketing campaigns, very few services have ported a course in miracles.
Yet digital music and podcasting prove that users will go to great lengths to mobilize entertainment, including actively connecting a media device to a PC and transferring to it content downloaded from the internet. But can podcasting become a cellular service enjoyed on handsets? Clearly, podcasting has certain attributes which make it suitable for the mobile environment. First, it is an “on-the-go” experience. Second, enjoying audio content is not effected by the handset’s small display screen. In fact, given the prevalence of mobile phones, coupled with the ability to deliver content directly to the handset without any user action required, the mobile industry might be hard-pressed to explain a porting failure.
Indeed, one may argue that such failure should challenge hyped concepts such as convergence. This article outlines a few of the critical issues that must be addressed if podcasting is to see even minimal mass-market penetration. First, what are some of the inherent “mobile-environment” constraints and how will they impact and define the service?. Second, is there a user willingness to pay for, and operator desire to launch, such mobile podcast services?
The manner in which mobile users discover and receive content will have a huge impact on the nature of the service. There are two alternative models: network-based solutions, and client-based solutions. Network-based solutions offer users access to podcast menus on the Operator’s WAP Portal. Users, locate the appropriate podcast, then initiate a download or stream of the podcast in real-time.
Network-oriented delivery models have failed to appeal to the mass-market user. The click and wait, menu-intense experience of Mobile Internet has proven unappealing. It is doubtful whether posting podcast files on a Portal will be an effective way of increasing awareness and usage of the service. Furthermore, given the relatively large size of a podcast file, adding a lengthy download wait to a cumbersome Portal experience will kill the experience all together.
Podcasts can also be streamed off the Portal. Here, however, in addition to the cumbersome Portal-Pull issues, the user-experience becomes dependent on consistent and sufficient data transmission during the stream. For reasons beyond the scope of this article, providing bandwidth for short streams, not to mention lengthy podcasts is technically challenging. A user listening to a podcast while commuting by train will frequently lose coverage. Securing bandwidth in peak-hours or in congested areas is very difficult. It is thus doubtful whether streaming can deliver the mass-market with an acceptable level of service.
Whether downloaded or streamed, obtaining content via pull assumes that a user will regularly poll for content. Not only does the active user concept runs counter to the Podcast model of automatic content delivery, but a compelling mobile experience must be simple and automated. One must consider that the potential mass-market mobile user is not as “early-adopted” oriented as a current podcast user. Thus, the user-experience on mobile user must be as good, if not better than the iPod experience for the mass-market to accept it.
Client solutions reduce the amount of browsing associated with content discovery, delivery and consumption, and provide a more immediate, user-friendly experience. The first type of solution, offered by Pod2Mob, involves a client that displays a catalogue-list of available podcasts. The user scrolls down the list and selects one, which initiating a content delivery session (download or streaming). Content discovery is easier than in Network-based solutions, as WAP browsing to the portal is avoided. However, real-time delivery is required, resulting in either consumption delays, streaming-related problems, or coverage loss. With this solution, an active user is assumed, as a consumption decision must be made daily.
