[...] Nos parece que esta característica es a menudo pasada por alta, posiblemente por resultar demasiado obvia, y es por ello que compartimos totalmente con MobHappy que no por evidente es menos importante y queríamos también sacarla a la palestra …

I’ve argued for a long time that only Sun should provide KVMs, and they should be ready-to-go (no need for the manufacturer to optimize or anything), but that’s not taking into account the various platforms phones run on (and they are plenty), which also affect how compatible the CLDC/MIDP functionality will be, and in terms of multimedia, to a quite large degree.

“However, the fact remains that many companies still do use JME as the platform of choice and it’s led to a stifling of innovation, as the whole iteration process is just so damn complex.”

There’s simply no alternative in many cases, so stifling is not the right word. What I agree with though is that many service providers naively deploy MIDlets, while maybe WAP 2.0 and even SMS or MMS might be enough as service frontends. E.g. MMS is excellent as a frontend for photo albums, UGC services etc.

Peter Cranstone mentioned DOM editing etc. Most phones simply don’t have such advanced browsers, and should service providers wait for PC browsers to come to all phones? Of course not. Business is always now, n-now, n-n-n-n-now (there’s a movie reference in there somewhere).

Paul Coulton mentions widgets, but almost all widget engines are based on … you guessed right … CLDC/MIDP. To the widget developer that’s not visible, and hopefully the widget engine provider has ironed out most phone differences. Similar to this are abstraction frameworks that are deployed in application projects. Costly as h*ll, but might get the work done.

Jordy Mont-Reynaud mentions SMS-based service access, which is an interesting point, as I made the same conclusion when I needed to set up a mobile marketing platform a few weeks ago. I concluded that to reach the masses a requirement for downloading a MIDlet wouldn’t fly. It could be a complement though.

Note also that even though the phone might have the most powerful browser in the world, you still can’t access the camera, Bluetooth etc from it, as long as there’s no standard for such access. Sure, you can do a lot of things via Javascript and DOM editing, like widget engines, chat, e-mail, social network service frontends, etc, but most phones today max support WAP 2.0.

I’ve gone for the standards approach though, with the aim to implement just enough of AJAX to result in really valuable widgets – if you try the app you can see that the RSS reader is implemented completely in XHTML & AJAX but running on lower end Java phones.

As an earlier commenter pointed out – it’ll take years for mobile devices to iterate to the level where there is a clear platform – and I hope that this kind of standards based development around J2ME could provide a springboard..

Alex.
joemoby.com

So here we are over 1.5 billion Java/internet ready mobile phones. Sure porting, provisioning and finding applications are painful, but the Web existed and thrived before broadband and the plug and play setup that we experience today and from the users point of view it is really no harder to find an app and use it on a mobile phone than it is a download on Windows. It’s just a question of getting familiar with a new process.

Whilst browser based applications are probably the future, don’t be so quick to write off the opportunity that exists today. Given a killer application with mass compelling appeal and the right environment of flat rate/low cost data, today’s mobile phone user will learn how to find applications and use the mobile internet connections on the phone in their pocket just as they already did with “Crazy Frog” ringtone (and subsequently learnt to side-load the same for free).

What would a killer app look like? Well the killer apps of the Web were initially email, IM, and now search and social networks. Mobile phones are primarily communication devices with voice and text. Maybe there’s a clue here?

An application could make voice cheaper by using VOIP and routing/call back technologies. These might appeal to the calling card and international calling market but are surely not the killer app.

The killer app will be better messaging. Messaging that lets the user stay connected with everyone they know everywhere they go. Anyone who has tried messaging on WAP/Mobile Web knows that it is just not compelling. The killer app must indeed be an app!
Like Hotmail, MSN, Facebook, Bebo and MySpace a killer app will need to be free to promote mass adoption – something like trutap perhaps.

In conclusion, it is in the interest of the entire value chain to promote pioneering application developers and mobile service providers. Mobile operators will benefit from new revenues, mobile handset vendors and retailers will benefit from increased demand for mobile phones with bigger screens, faster connections and better battery life. Online services will benefit as mobile access drives user interaction, loyalty and eye balls and Mobile Web services will benefit as more people will start using the mobile internet. A bigger, healthier mobile internet industry for all stakeholders.

Very interesting post, however I would challenge the 80% stat – if you know what you’re doing, you can plan in all the variations from the start. We certainly do this and porting of a normal networked app takes very little time at all, the only time porting really kicks in is when the app has to start using new APIs (which all stretch well beyond the capabilities of a webapp on current mobile devices). Unpredictable changes to the app do require updates of the app which can be confusing for users, but for repeated user the user pays less in terms of data cost than using an equivalent webapp.

If you’re doing a fair comparison, with a nice looking app in both mediums, then you are still going to have to test the app on every device and you are still going to have to redesign the graphics a bit for every different size of screen. The only reason JavaME would have more graphics work is that you can achieve so much more graphically in JavaME than on a wap site (check out our Flick stream for some examples, http://www.flickr.com/photos/masabi/).

The problem with web clients on phones right now is that they suck. I was very interested to hear SoonR talking at the MoMo Global conference recently – they created a simple web app and a Symbian smartphone app for their services and said they discovered that no-one ever used the web app, which has led to a complete change in direction for the company (who appear to be doing very well now). They have a very specific business but it seems to touch on all the bases of what you might want to achieve with a non-trivial app.

At the same conference, Dan Applequist (Vodafone) claimed that mobile web browsers could do better looking apps than JavaME these days. I was unfortunately unable to ask which handsets he was referring to, because I have yet to see any mobile browser on a mainstream phone that comes close – from what I recall when I briefly played with the iPhone it can make a pretty good go, as can some smartphones, but in the mainstream it’s simply not true.

JavaME is certainly not perfect – far from it. It also cannot compete with the browser for some types of application. But for many others, particularly those that are intended to be used regularly which rely on interaction, good looks and/or security, it is the only mainstream medium available for mobile phones and will remain so for a good long time. This is something which rather kills Peter’s very nice ideas in the comment above. You can check out my recent blog post on the subject for some more analysis on this at http://blog.masabi.com/2007/08/thick-vs-thin-clients-in-mobile-today.html

Another thing to consider: rapid iterations are very nice, and if you’re rapidly moving little bits of XHTML around a page then there is no problem. Once you start adding anything graphical or AJAX-style scripts, you start to create a huge weight for your users though. Data is not cheap in mobile despite the current “unlimited” tariffs and it certainly isn’t fast, so forcing your user to redownload big libraries etc every time they use the app will have limited appeal and thus limits the scope fo your webapp greatly. Limited cache lifespan exacerbates things, though rapid iterations can have a similar effect. This will not change soon.

There are two things your points really reveal, once taken to their full conclusion: firstly that mobile development is very complex and is still requires a lot of expert knowledge, whatever you are trying to achieve. Secondly, there is no magic bullet which will make this go away because we are dealing with a vast array of devices with different specs, and that creates headaches that make the desktop browser wars pale in comparison – whatever the medium.

Cheers,
Tom

“all” you have to do is figure out a business model that allows you to send (and pay for sending) those SMS. (which is a big deal) that’s the one trump card mobile web will probably always have, it’s essentially free to develop for and scale your product.

The problem of course is that the mobile web *sucks* right now. patchy 3G and far too slow in most cases. Furthermore it suffers from just as much fragmentation/testing as Java ME (how many browsers, how many markups?)

The million dollar question is how long is the “long run” before this gets better. IMHO I think it could be a number of years yet, at least > 3.

Bravo on the award.

Richard