[Image by HLundgaard]
There is a difference about how we thinks things will evolve, and how they do. I’ve been wondering about Mobile and app stores for a while – they seem contradictionairy.
Mobile has taken such a great flight because of lowered cost and increased availability of Internet for mobile, the old-fashioned telephone has turned into a smartphone with the power of a desktop
So, with all this ubiquitous Internet around, what is the next hootest thing for Mobile? App stores, where you can download applications onto your mobile! Isn’t that odd; why not browse to an app in the cloud?
Brian Katz wrote a great post on this, and I’ll to it here
HTML 5 is indeed brought as the panacea (hello there new panacea! Let’s have fun while it lasts, OK?) but as Brian rightly says, you have to start with business, not tech – top-down rather than bottom-up, if you like
Brian makes a neat distinction between native apps and web apps. Native apps are what you need when you want to operate on the device level, e.g. control the camera, peruse the contact list, modify storage, etc. Web apps are browser-enabled applications where your mobile would function as dummy terminal like in the goold old days of mainframe well before the client-server age
That answers my question in fact – we need to download native apps onto our mobiles when we want to use native controls. But wait – what about all the games we play? Those could easily be Web apps, right?
Wrong – HTML 5 is not nearly as consistently supported as we would like it to be. Dependent on OS and browser your mileage may strongly vary.
The expense reporting example Brian uses is a fine one, where the business case calls for offline use, GPS and mobile access. Brian concludes the choice for a pure HTML 5 app would be unwise, and then comes with the smart choice of hybrid app – now that I like
Basically the ubiquitous Internet is not so ubiquitous at all, especially when you often travel abroad. Roaming fees are still offensively high, e.g. my brother collected a 750 euro bill when on vacation for a week. He doesn’t even have an Internet subscription, but apparently Vodafone has some small print somewhere and enabled roaming Internet for him when abroad, and is now forcing him to pay the bill. Needless to say, he won’t do that, but it just goes without saying that roaming is a seriously expensive option. No wonder that European Commissioner Neelie Kroes is fighting hard for decent fees, and booked a great success a few weeks ago. It’s in Dutch but you can read there’ll will be a maximum of 70 cents per MB in Europe starting July 1st – it’s around 3-5 euros at the moment
Still, with my 2GB capped mobile Internet in NL that would come to a bill of 1,400 euros, whereas I only pay 10 euros for it – a factor of 140 difference.
In a few years from now the differences will be almost gone, I suspect, but up until then there’s indeed a great business case for native apps, hybrid apps and HTML 5 apps – in that order.
In my vision that would of course mean that in the ideal scenario web apps expose back-office functionality through an Adaptive Integrated Enterprise where this time the format would be highly likely JSON, maybe even HTML or XML, and the transport protocol used HTTP(S) or WDCMA / HSPA+.
Then, on the device level, you’d have a few different native apps to support the device diversity and give you control over the controls you want to control (rainy Sunday pun)
Together, those two would make a hybrid app, and it would be neatly tiered. You only have to update the native apps when their control operation changes (which is relatively unlikely given the rather infrastructural and static nature of them), and you’ll only have to change the web app when functionality changes, but you can do that server-side and it wouldn’t even need an update client-side (on the mobile itself).
So you’ll just treat the mobile as infrastructure, OS, in stead of application; that greatly pushes back diversity and dependency
I’ll end with the same end Brian used:
(…) know why you are creating an app, figure out what data you need to access and how you will do that securely and then worry about the best tool to use for building the actual app. Don’t spend so much time working it backwards, it will only make the job harder and in the end the app may not work the way you want it to because you confined yourself in how you were going to do it before you figured out the why and the what.
(Cross-posted @ Business or Pleasure? - why not both)
CloudAve is sponsored by Salesforce.com and Workday.
