Russell writes about some of the problems of J2ME development, and the slow pace of innovation in the mobile space (echoing some of the things I've been looking at in comparing mobile to fixed): "One of the challenges of mobile is that the mobile web just doesn’t provide the same user experience as its cousin the PC web, forcing many companies to implement a Java application, or JME, as it’s not been rechristened by Sun, to give users the full intended functionality."

At FP we're big on the mobile web at both a practical level (powering mobile campaigns, building microsites), and in assisting W3C, .mobi, the WURFL project and the like in pushing things forward; we have dot-mobi certified developers on board and we do a lot of work in this area.

But I don't believe that the future of mobile apps is completely browser-based: mobile web makes sense in many cases (and being easier to work with, certainly contributes to a groundswell of mobile content), but there are some things for which applications are much better: anything involving persistent storage (say, a messaging service), very customised interfaces (like games), or deep integration with the handset (using Bluetooth and GPS, for instance).

So I don't see the mobile web as competing with Java - there's room for both. Where I do see it clashing is with Flash, which hopes to bring mobility to the same group of developers (web guys and girls) but has so far failed to deliver on its promise. This is in part thanks to poor distribution of the (excellent) Flash player, but also I suspect thanks of apathy amongst Flash developers - who are forced to give up many recent advances in Flash to develop for mobile. I was quite surprised when we ran a local, well-advertised competition for mobile Flash content and received only a single entry from across a large, skilled community including many top-notch Flash developers.

Where I feel Russell is spot on is in his criticism of the development process for Java: "Yes, you can make changes easily, but the deployment cycle makes rapid deployment almost impossible, leading to small and large changes being introduced as part of regular updates, like software".

Too true, and there's a few things this brings to mind:

1. To do mobile Java development well - in any sort of reasonable timeframe - you need to have tools that help you build and port across a range of devices. We go from a standing start to launching across 100+ handsets when we add a new puzzle to the Puzzler Media portfolio, but the only way we can do this is by using Cactus, our in-house toolkit for J2ME. There are open source kits out there to do this, like J2ME Polish - obviously I think ours is niftier, but I'm biased ;)

2. You need to automate as much as possible, including UI testing. If you make a fix to the Motola V3 port of a product and it breaks the Samsung D600... you need to know this. And to do this with complete confidence, you need to test on real devices, so there's a manual burden too. I'm going to write about testing strategies for mobile in due course.

3. And one final thought: why not start out with a less monolithic product? If you can add, build and evolve your product over time (using a porting framework and automated testing), then there's less risk in tweaking features or adding to your product on the basis of observed user behaviour or explicit demands from your customers.
   

Having said all this, I'd completely agree with Russell when he suggests that "you need at least a stripped down mobile web version"; mobile web might not provide as much control over the user experience as an application, but it lets you mop up all those customers with handsets you didn't port to, comparitively cheaply.

Comments

[C. Enrique Ortiz]

Good post Tom.

This debate of web vs. local is getting kind of old. Yet, it still need to be preached.

And you are right on the spot.

It is not about web vs local. It is about the right approach to the mobile application and the requirements. Some apps are fine being pure texting, or mobile web or local apps, or just one or two of those methods. For applications, there is an order to consider: 1) texting followed by 2) web followed by 3) local, all depending of course on the the level of richness and integration w/ the handset, and the application requirements -- for example, texting may no make sense at all for some applications due to the high number of back and forth interactions.

On the comment: "leading to small and large changes being introduced as part of regular updates," well, that is true for *any* software, local or web, where applicable changes will always be squeezed into a release. Sure deploying changes to web apps is much easier.

On the comment of "you need at least a stripped down mobile web version", yes, but it doesn't have to be stripped down -- different app views: i.e. text, mms, web, or local, all offer different user experiences, and it is about delivering the the best experience, as it applies to each method.

Now, we all agree that the best experience is offered by local applications. What we really need to figure out is how to make "provisioning/downloading" very very very simple. I believe people WILL download applications if they bring value. But the process today is just too painful still.

Anyways, ...great thoughts/feedback... right on the spot.

ceo