Chatting with Keiran from Reporo(who are going great guns, I’m pleased to report) last night at the Mobile Entertainment Awards (AdMob won again - yay!) I managed to articulate a thought that’s been nagging at me for some time, specifically about mobile applications. It might be obvious to some, but I haven’t actually heard it expressed, so I thought I’d share it.
One of the reasons for the rapid development and success of the PC web has been the ability to rapidly iterate, test, perfect and iterate again in a matter of hours. Some websites have completely changed their business model in this way and design, user experience and functionality have changed out of recognition from the early days, even taking into account the influence that faster speeds have enabled. I mean just look at eBay back in 1998 via the Way Back Machine and today.
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.
The problem with JME is that while it’s a great development platform, its a complete nightmare to port over the the many devices it needs to be used on. So a developer finds themselves having to do 80% of the work after the development is finished and before roll out can begin. For this reason, Sun is going to lose its domination in the mobile apps market, either to a new pretender or to the emerging power of the mobile web itself. Indeed many companies are abandoning JME altogether, accepting the compromises that go with a mobile web-only product. As far as Sun is concerned, this is like a marathon runner getting beaten to the finish line, despite having 26 mile, 384 yard head start. Some would argue that the issues are caused by networks and device manufacturers, but surely it’s Sun’s job to set and maintain standards so that JME could have been a feasible platform in the porting process.
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. 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.
There’s a strong argument to suggest that if the web evolved in a similar way, with regular 6 monthly (or so) refreshes as opposed to daily iterations, we’d never have seen the rapid changes ushered in with Web 2.0.
I conclude that if you must have a JME application to give the user the full experience (and consider long and hard if you can’t actually do it on the mobile web alone), you need at least a stripped down mobile web version. That way, users can flirt with the idea without committing the marriage involved in a download and it gives you an playpen to innovate, iterate and test new ideas.
Good blog. Right on the money.
So what’s the solution?
Simple - don’t go there. Why bother developing mobile apps. Why not use the model that works on the desktop - Web Services.
All you need is a thin client to mimic application like behavior in the browser and support access to current client side apps (SMS, Address Book) and then integrate that data feed into the document object module in the browser.
Result - Mobile web services which are contextually based off the information coming in real time from the current mobile device.
I have been somewhat of a sceptic about widgets but having recently devloped a mobile game as a widset widget with a colleague (I can see distinct advantages to the platfrom.
1. Its relativly quick to develop and then test directly on the device.
2. The distribution is taken care of and its easy to customise your widset desktop.
3. The inclusion of advertising should be straight forward.
It only really going to be applicable for less computationally intensive applications but if they open up access to device functionality it would .
Incidently the game is called Bombus and will hopefully be raised to main widsets site from devloperssite soon.
Right on!
Excellent piece that is very similar to ones I’ve written along the same lines here: http://www.linkedin.com/answers/technology/wireless/TCH_WIR/92827-237939 (scroll to my answer) and here: http://amir4.blogspot.com/2007/08/mobile-getting-application-on-phone.html.
I want to make a couple of notes:
1- Sun should seriously consider getting all stakeholders to the table to facilitate a reasonable process that will allow developers to become productive and stop this nonsense. whether its Sun’s fault, the vendor or the operator, having the same device different from one operator to the next, or not having two devices identical J2ME characteristics is feeding poison to the developer community.
2- It’s not only the standards: The implementation behind the J2ME APIs is completely up to the vendors. As such, competing on priorities at the vendor, the quality of the implementation is the first to suffer. The camera API is a good example of real weird stuff you can see on phones
3- To the point of going for WAP sites if you can avoid a client app: right on. The issue is: sometimes you can’t. You have to build the app because of certain functional requirements (ex.: LBS) or much higher perceived value by it being on the phone. the reliance on the web to provide the functionality is still not solid, to me, essentially because data plans and access to web are still not that common amongst users, I don’t think.
Anyway, great post…congrats on the award.
Java ME will lose out in the long run just as the majority local applications have on the desktop.
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
Many people never change the software on their phones or computers. Whilst a computer may be upgrade every 5 years or so a phone will be upgraded every 18 months on average. If the prebundled software on the phones was to constantly improve then we’ll be in a far healthier state.
Spot-on. I would go even one step further, and encourage developers to build SMS apps even before they do mobile web apps… just as mobile web beats downloadable client in terms of ability to iterate quickly, SMS beats mobile web.
“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.
Hi Russell,
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
In the long run maybe Java will lose out to a browser based experience. In reality though, this really is a long run. Renewal and propagation of new technology always take longer than visionaries would like.
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.
I’ve been trying to address this issue with a standards-based J2ME widget engine that supports XHTML/CSS/AJAX (http://www.joemoby.com). The idea is similar to Nokia’s Widsets that developers can more easily write their apps against a common framework (er, like a browser..) and then publish them to all.
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
Mobisy, an early stage startup in Bangalore, India has found a way to depoly web apps for smart phones with capabilities like Native apps(even more powerful than J2ME). You can check
http://www.mobisy.com/products.html
for some more info or get in touch with them on how they have managed it !
Sunder
“it’s Sun’s job to set and maintain standards so that JME could have been a feasible platform in the porting process.”
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.
[...] of MobHappy discusses the iterative development and process in the PC web world and compares it to similar processes in the mobile world. He also offers a [...]
Fomentando la Iteracion…
[...] 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 …