When mobilizing media content, there are a variety of approaches. For the best possible user experience, it is often necessary to use a client solution, such as an On Device Portal (ODP). Various companies offer these, like Wecomm (with heavy Mobile TV focus - they provide the Sky Mobile client) and SurfKitchen. There are many solutions on the market and no real sign of a standard approach. They remain proprietary because of the speed at which the market continues to move. There is money to be made if you’re willing to provide an ODP that works with as many devices as possible, until such time as a standard device “footprint” arrives, if ever.

An ODP usually preloads the content, at least the previews anyway. This necessitates “short head” selection, as opposed to long tail, although this is still supported via search engines. As network speeds improve, preloading of content becomes less of an issue. For example, with a category 12 HSPA device (i.e. the “slow” category), a sample 500K music file can be downloaded in seconds. Even so, I still believe that some preloading is useful because the instant responsiveness will be compelling and much more likely to increase content sales overall.

There are a couple of problems with the ODP approach. Firstly, the preloading isn’t necessarily done in the background totally and utterly transparent to the user. In its most crude form a user might even have to press a “refresh” button to see the updated catalogue. Moreover, if the ODP is in Java, then true background execution is problematic. The other fly in the ointment is accessing the long tail. Searching can be tedious on a mobile, especially now that the user has to keep popping back to the network to get responses and download previews. Again, HSPA will speed things up on the download side, but many ODP solutions push the user out to a WAP browser to access the long tail. Once the user leaves the ODP client, the user experience can quickly become fractured and the user may give up. With mobile data services, we should always work to the assumption that our archetypal user is an attention-challenged kid on Ritalin. That may well be the case, but the point is that tolerance to delays with mobile interfaces is generally very low.

MIDP 3.0 offers us a couple of advantages here. Firstly, it supports MIDlet concurrency, so that means that our ODP client can remain running all the time and thus stand a chance of offering true background downloading of new content. Secondly, and this is my hope, we can expect to see better integration between MIDlets and the browser, thus giving the user the impression of one continuous experience even if two programs are used to achieve it.

Personally, I look forward to a DVB-H device with MIDP 3.0 and the necessary APIs to fully expose the DVB-H services to the J2ME environment. Even better, at least from a Java perspective, would be a DVB-H device based on JavaFX mobile with a rich set of APIs to allow any and all combinations of Web 2.0 services, TV services and phone services using JavaFX Script. Of course, it would have to be a HSPA device. This is the killer device platform. As for the killer app, well then……I know what I would like to see in terms of convergence with IPTV and the home hub, but that would be telling.