Continuations: Mobile (App) Development: Android's Missed Opportunity?
Vladimir Vukicevic
· 6 months ago
The big limitation for mobile browsers in the U.S. is still network speed - 3G penetration is still quite low (although the iPhone is helping to grow that). Apps can give a better user experience for now.
Also, it's still somewhat murky how well browsers can actually connect to the phone's hardware, but if that is optimized then it could definitely open the door to what you're talking about.
albert
· 6 months ago
I am not sure how important network speed is - the browser could aggressively cache the Javascript and possibly even the HTML to provide essentially the same behavior as an app.
Vladimir Vukicevic
· 6 months ago
That's possible with newer smartphones which have the memory and processing power to support this - if that's your sandbox then you might be ok in the near-future.
But the reality is that the vast majority of phones in the U.S. aren't smartphones yet and most phones don't support 3G (especially the corporate flock of older BlackBerries, who are the most frequent users of data services).
Also, a lot of bigger brands are very afraid of a bad user experience especially in relation to more sensitive tasks that can be accomplished on the phone (e.g. money matters, health, etc.). The current reality is network limitations don't offer a good experience - hence the tide has gone in the other direction.
I'm not arguing against the possibility of more powerful browser capabilities, just trying to figure out why it hasn't happened yet and what the short-term barriers might be.
albert
· 6 months ago
Those are all good observations. Just trying to figure out if/how/when this might tip.
Vladimir Vukicevic
· 6 months ago
On the macro U.S.-level we are getting to a very important point when it comes to smartphone penetration and network speed - both are quickly growing.
As I mentioned on the USV blog, fragmentation (of handset types, operating systems, and even core technology) is still an issue and will be an issue preventing scalability of solutions for the near-term. More capable browsers might be a better solution than applications for this fragmentation.
P. Moehring
· 6 months ago
Seeing that they use Gears in Chrome Lite on Android, it seems that they are looking to integrate web apps deeper. As far as I understand, they also already use html5 stuff in the newer mobile gmail and calendar applications. Since the html5 specs were rapidly changing, they probably have not yet rolled them out to their full potential in Android. Security might also be a point here, especially since the web apps are in no way controllable like in the store or market place (where at least developers can be held accountable).
albert
· 6 months ago
The rapid changes of HTML5 may well be a reason. For instance HTML5 does already have a location spec. Not sure though about specs for some of the other critical capabilities, such as say camera access.
As for security, I am sure folks will bring that up but it might be a bit of a red herring. If Javascript wants access to say location there should be a user prompt allowing or denying access. That prompt can show the origin domain for the script. So there is no risk of people having their location snarfed without their permission. Malicious behavior is much harder in the Javacript world as there is no native code execution. That leaves the traditional class of web attacks such as XSS and CSRF but not sure that those are any more dangerous here.
farhanlalji
· 6 months ago
Not sure why Google's not doing it that way. But I do think that's what gives' Yahoo!'s mobile strategy and the operators a chance to climb into the race for mobile web market share.
Mark Essel
· 6 months ago
I wish I knew. I've been struggling with a choice about a mobile upgrade in hopes of finding the right open architecture to invest in (voting with dollars). Hopefully we can get a decision maker from Google to chime in here (go go social media power).
albert
· 6 months ago
That would be great - we are in the voting with dollars business also - but I am not holding my breath. You hit the nail on the head with the desire for an "open architecture"!
fredwilson
· 6 months ago
albert and everyone else reading this thread - pls go read boy genius' rant on RIM
he nails it. consumers are going to follow developers in the long run. and RIM is not giving developers a great platform to build on.
aaronklein
· 6 months ago
BoyGenius nailed it. They have done mobile e-mail in the model that Apple followed with iTunes + iPod...it's one integrated system that just works, and works FAR better than anything else on the market.
But it's dead right that BlackBerry OS is aging. The question is...do they have an ace up their sleeve we don't know about?
Lots of game changers they could implement.
- do a deal with Microsoft and develop Windows for BlackBerry
- do a deal with Palm and launch webOS for BlackBerry
- take android open source and build a new BlackBerry OS around it
- build BlackBerry OS 6 from scratch on top of Linux or something else
- buy Opera and make the app infrastructure completely web as suggested in this post
Kontra
· 6 months ago
...while the rest of the industry, especially Apple, waits around for RIM to get up to speed? Steve Jobs wasn't actually kidding when he said Apple was a few years ahead of the industry when introducing the original iPhone. In tech, you snooze, you lose.
fredwilson
· 6 months ago
I like the idea of webOS and android on blackberry
Barry Engel
· 6 months ago
I'm always worried about battery life. It seems a browser-based app would increase drain with constantly going back to the server
albert
· 6 months ago
With the right setup these things would mostly execute locally without needing a lot of roundtrips to the server.
aaronklein
· 6 months ago
the other problem with a browser-based app (as we think of it today) is using the app with no data coverage. that's a huge advantage with many of my apps. blackberry is the best at queuing stuff up to go once you come back into coverage.
not sure why you couldn't have protocols for preloading html-based apps onto the phone and executing them locally. I think what we're really talking about here is language and platform...you wouldn't actually want the app displaying in the browser cause you use up valuable screen space for no reason.
you want an "apps mode" for your mobile browser that hides the browser...just like Chrome with the "create app shortcut". check out how that feature implements to see how Google is viewing the future of apps on the desktop.
albert
· 6 months ago
Interesting - have Chrome but don't run it as my default browser - will check out this feature. Agree with you on this not being about the browser but the languages and open delivery mechanism.
andrejk
· 6 months ago
html5 has a feature to cache web resources, so you can start your web application without a network connection. This is currently supported in safari, i think in firefox, and also through google gears.
Also the html 5 widget specification (implemented slightly differently on nokia) allows you to download and install html applications, as if they were native applications.
kareemk
· 6 months ago
That is exactly what PhoneGap does (http://phonegap.com/). It exposes the native phone functionality through javascript allowing an app to be developed once and deployed everywhere (with a little tweaking). There are still a few minor issues (e.g. scrolling doesn't work as smoothly as it does in a native app) but these are known issues that the community is working on fixing.
That's what we used for our iPhone App for Coovents (coovents.com) and its what we'll use for our mobile apps for Hapnin (hapnin.com).
albert
· 6 months ago
Had seen phonegap and am glad to hear it works - hope Apple doesn't try to throw a wrench into that!
Barry Engel
· 6 months ago
Great idea. At trainlogic.net we would need all the TBD capabilities for BlackBerry.
Peter Cranstone
· 5 months ago
PhoneGap is actually a little limited (see their matrix) in what they allow you to access.
jasonspalace
· 6 months ago
i believe Google realizes how early in the game it is. don't want to massively promote an underdeveloped product. i bet we will see native client on Android soon enough - http://code.google.com/p/nativeclient/. there is only 1 set of iphones. there are going to be MANY Android powered devices. all sorts, and watch, we will even get Android on our television in the future. watch, we will get video Google Voice on broadband phone sets in the future powered by Android. As for RIM, Fred points out what i see as an inevitable downfall without critical change. Still waiting to see how Nokia and Palm handle the next couple of years.
albert
· 6 months ago
It may be early in the game but if Apple becomes a de facto standard because they have the most cohesive device base that will take many years to overcome.
Great posts -- really enjoyed reading them. Completely agree on the huge value of the payment and actions for a large number of consumers.
andrejk
· 6 months ago
I don't think they will become the defacto standards. This would be that all other mobile phone manufacturers would disappear. What are sony-ericsson, nokia, thc, samsung, motorolla, and all the other going to do? I think the iphone is only going to become a standard if apple is going to license it's operating system.
albert
· 6 months ago
It is not necessary for the others to disappear but just to be fragmented enough that developers don't bother writing for them.
andrejk
· 6 months ago
hopefully android can avoid that.
jasoncrawford
· 6 months ago
I'm an iPhone app developer and I agree that the performance isn't there yet for mobile webapps. It's not just bandwidth, it's also *latency* and CPU/memory. The iPhone 3GS is the fastest mobile JavaScript engine out there, and it's still more than an order of magnitude slower than laptop/desktop: http://www.techcrunch.com/2009/06/24/iphone-3gs...
That said, we're rapidly approaching the point where webapps will dominate again. A few more generations of devices and network and it will all go back to the web, except for games and maybe a few other types of apps. So I don't know why Google isn't pushing for HTML5/JavaScript extensions.
cphenner
· 6 months ago
I liked best the 'jasoncrawford' answer, which confirms in developer horsepower why apps beat WAPs in terms of good app/service development. For those who have ever held and used a 0.0.1 version and watched it morph into 1.0 after multiple iterations, you can appreciate the share-of-dollar in early days that goes to performance improvement (not UI). Animated transitions and slick overlays can only happen on the back of a lot of time spent grinding away at performance improvements.
But this debate is framed from a 'supply side' look at what languages and tools are available at what level on the OS stack, and says nothing about consumption in the form of users and usage. If you sell a good or provide a service via WAP and then one day release an app-based version of that same offering, the degree of user engagement you see in a side-by-side comparison is likely staggering. It's like when Google had to triple-check its logs because it didn't believe the volume of per-user search activity from iPhone -- this was the result of the (thin) layer of app instead of WAP-only that was offered.
USV has all the data (for free) at its fingerprints to do a user-facing analysis, which is where I think energy is better-spent than pontifications around Jscript v. compiled languages -- this worries about the wrong things -- users and usage are the answers.
Try a post that looks at the following:
- Top 100 WAP sites as mesured by m:Metrics (comScore), and - Top 100 iPhone apps as measured by Pinch Media (USV portfolio) - Prune and find those services that offer both WAP and App versions - See what user-based metrics (that matter) can be gleaned from these figures
If users clearly respond more to Javascript/HTML 5 (which I doubt), then you have your 'living peitition' to Google/Android's team. But this discussion is a socratic exercise of conjecture about why one language might be better than another until user data is entered into the mix, and Flaitron/USV has always invested early and often in that arena -- share some knowledge and do some analysis!
albert
· 6 months ago
That is a great suggestion. Will see what kind of data we may be able to find. But existing consumer behavior can often be a bad predictor for future behavior. For instance people didn't know they needed google before it came out and there were search offerings in the market already.
cphenner
· 6 months ago
Flawed logic: We didn't have Google (or Twitter) before those services existed for the first time, so no doubt 'we don't know what we need sometimes,' but I am saying something that is much more basic (and measurable) than that, to wit:
- We have Google on the web. - We have Google on the WAP. - We have Google on the app.
And your post is essentially: 'Why app when you can WAP?'
And the answer should live in whatever degree of measured, meaningful engagement is seen via app vs. via WAP. In the case of Google, that metric is likely a blend of (i) queries per month, (ii) eCTR per user and (iii) eCPC per user.
This is actually a very rearward-looking question for which there is good data, or at least there should be from m:Metrics/comScore and Pinch Media.
albert
· 6 months ago
Not quite. The post is not Why App when you can WAP? But rather Why can't you WAP the way you App?
Vladimir Vukicevic
· 6 months ago
I don't think it's that simple. Prior to the emergence of the iPhone, the consensus among mobile developers was that Thick Applications (apps) were essentially dead. Development was too difficult due to OS and Handset fragmentation and the Mobile Network Operators were very stubborn gatekeepers that made life for developers very difficult. Thus the Thin Client (browser-based) development was quite popular - e.g. the Opera browser emerged, etc.
If we had done the same analysis that you mention before the iPhone, the WAP delivery channel would have won hands-down both for general usability and for actual number of hits. This was the perfect example of people not knowing what apps can really offer without the limitations in place at the time. No study at that time could have predicted the re-emergence of the app as the dominant method for content delivery, communication, and innovation on the mobile.
That's one of the reasons why it's hard to predict whether a new, more powerful browser-experience can re-take the lead.
aaronklein
· 6 months ago
But think of the possibilities if developers can write one app with one code base that works in the browser or preloaded on the phone -- and can shift between different types of phones?
If Apple wants to play the game of who has the most apps, then cool. If the rest of the smartphone industry were smart, they'd all get behind one super-HTML5/JS standard and have their apps portable to each other's phones.
Then developers would write for two ecosystems: the open platform and the closed platform. By unifying all of the other platforms into one, it could very possibly break or at least strongly compete with Apple's monopoly because then it turns into "do you want to be able to move your apps between phones, or buy into a closed system?"
Vladimir Vukicevic
· 6 months ago
I think you're on the right track here - i.e. that an open platform will be necessary to compete with the iPhone closed ecosystem, particularly for apps development and sales.
But it's important to remember that the mobile landscape is quite different from the one PCs ever faced. There are a lot of very entrenched handset manufacturers who desperately want to keep control over their hardware and thus hardware margins. You have the OS developers who are much more scattered and diverse than PC OS developers ever were. You have the mobile network operators who are usually huge companies that move extremely slowly and are also very protectionist. Finally, you have confused consumers which can essentially be broken up into two main groups - those that use non-voice features and those that don't.
This ecosystem is quite complex so developers can't just pick a standard and run with it. A collective agreement is usually needed for major change.
suthakamal
· 6 months ago
So there're a handful of reasons... the first is that JavaScript interpreters are still slow. They're getting a whole lot faster, but writing complex application logic in JavaScript is still quite slow for many platforms... work needs to be done here before the web becomes a first-class mobile app platform.
The second is that Google's strategy seems to be mixed between HTML5 and Gears: Gears was initially going to provide a lot of the deeper hooks into the OS that a web app would need. Gears let's Google skip all the delays associated with standards bodies, but it relies on platforms that'll let Gears plugins work, and so far that's been hugely limited (i.e. Windows Mobile, and of course Android), so it's been a far-from pervasive way to get additional capabilities.
Ultimately, HTML5 is making great progress... but waiting for standards bodies up-front is a pretty great way to waste time and kill innovation... and that seems to be what's happening in mobile at the moment.
albert
· 6 months ago
That's a good point. They are sort of in a tough place between pushing Gears and supporting but waiting for the HTML5 standard. What will be interesting to see is if some coalition will emerge that has everyone except Apple or if the other players will fight among themselves.
suthakamal
· 6 months ago
So I was looking at building a startup to effectively build the browser-based infrastructure that would allow deep, native hooks into the OS for web apps. We thought about a few major components: - push messaging (for efficient network use, and background tasks) - native access (i.e. making native device capabilities available to JavaScript through the DOM) - Native-code runtime (i.e. something like the Silverlight CLR to let apps break free from the requirement to use JavaScript, and the performance issues that come with it)
Ultimately, much of the technology to do this already exists... Though, the actual go-to-market is the tricky bit... i.e. you could build such a plugin and get it out for Windows Mobile and Symbian devices. It would then require either a re-write in Java (a huge undertaking) to get it to work on BlackBerry. Then, you'd either have another Java variant for Android, or take the original, native codebase, and donate an open-source version to the Android alliance, and hope that it made it into the main branch that everyone adopts.
As far as an alliance... maybe... I think Palm's WebOS and Mojo approach is a good one, and actually, alliance or not, guys like RIM ought to seriously look at implementing chunks of Mojo (forget standards, just embrace the de-facto standards that other people have shipped).
Another approach might be for Google to take the already open-sourced Dalvik JVM, and Chrome Lite browser, wrap them as an Android-independent chunk of code and help the other OEM's just integrate that into their platforms... Come to think of it, that wouldn't be a terrible starting point for a startup either... :)
albert
· 6 months ago
That does sound like there would be a lot of work to get folks to actually adopt. So maybe RIM buying Palm as another comment suggested is a possibility - although I have not checked the respective market caps.
suthakamal
· 6 months ago
RIMM's market cap is ~40BN, and Palm is around 2. RIMM has about $1.3BN in cash as well.
That said, I don't think the acquisition makes a lot of sense. RIM needs to improve their browser and app platform, not get a new set of devices (that they'd throw away) to manage that run a number of different operating systems (that they don't want).
If RIM got itself away from just Java as the OS, moved to WebKit as a browser, and acquired a small team w/ WebKit experience, they could build a WebOS competitor for a whole lot less, and get it done without having all the overhead of a full-on acquisition and product integration.
Sachin Rekhi
· 6 months ago
I completely agree that Android should have focused on the web browser as the mobile app platform of choice. Would have fit very nicely with Google's existing emphasis as the web as the most important platform. Palm with their WebOS seems to be making this their bet to an extent, as they are allowing app development in HTML/CSS/Javascript.
I wrote my thoughts recently on how I think the Palm approach of using existing technologies instead of re-inventing a new platform and libraries to be used like all the other native app platforms:
I appreciate all the technical comments here but the reality is that customers don't trust web-based applications on the device. I tried -- believe me. I developed our latest app as a web-based one and got un-ending flack for it. Our customers insisted on native. They don't trust the connection, let alone it's speed.
This could be overcome if the mobile platform considers the "server side", say a Ruby on Rails runtime. Then it could support HTML/CSS/JS on the front end while providing the back-end support required to run sophisticated apps. Palm's closest but they are missing any semblance of "server side".
And even when we get all the technical details, there's still a mentality that needs to be overcome. Most mobile developers are too small to battle this perception problem of "everything in the browser needs an Internet connection." It's a fight that has to be done by Google or Palm or RIM.
I will promote one very relevant post here. I wrote about how to beat Apple at their own game in August 2008. Included was a discussion of web app development that would work wonderfully. It's here: http://bit.ly/17uUR3. No one has done it yet but the one who does can be the major player.
albert
· 6 months ago
Customer trust is an interesting angle that I had not considered. What was the app?
eliafreedman
· 6 months ago
Thanks for asking, Albert. We are developing FastFigures, an application for capturing and analyzing data. Any of our customers can create a template or use an off-the-shelf one, save data and sync it to our web app for more detailed analysis. Spreadsheets were an amazingly powerful tool for desktop systems. They allowed anyone, with or without programming experience, to write an application for analyzing data. But this form factor is horrible on mobile. FastFigures will do this for mobile and web.
We are still pretty early, releasing in stages. Our first FastFigures versions are on iPhone. Over the next few months we will be adding customization, filling out the web capabilities and adding data sync to the cloud. You can check it out in it's alpha/beta form at www.fastfigures.com. The first iPhone version is available at www.fastfigures.com/apple.
I've been hovering around this business opportunity for the past 12 years, as I started writing mobile software for the Pilot 1000/5000 in 1997. When Palm OS was king, we distributed over 15 million software products, had partnerships with leading providers in tech, industry and education, and almost had a break-out success in 6-12 math education.
albert
· 6 months ago
Sounds interesting - will check it out!
eliafreedman
· 6 months ago
I love feedback. We are still so early in development and planning, we can use all the feedback we can get. If you have any thoughts or comments, please email me: elia at infinitysw dot com.
Ryan
· 6 months ago
Great post. I think the browser on mobile devices is playing a much more pivotal role than anyone had imagined and mobile devices are slowly seeing this, hate to sound like an Apple fanboy but Steve Jobs envisioned this from the initial launch of the iPhone and they are slowly adding more access to more things in later releases.
If Android capitilises on this and allows for native like access to the file system through the browser the others will be scrambling to play catchup and this can only mean good things for developers and users.
albert
· 6 months ago
That's what I am hoping to see. Agree that iPhone browser was complete breakthrough.
Edwin Khodabakchian
· 6 months ago
Interesting post. In think that the API access to some of the phone services are only half of the problem (the easy half). The harder side of building web application is the performance and memory footprint of HTML and Javascript on the browser (and this is despite Apple exposing some hardware accelerated transformations through CSS). If you look at some of the best iphone apps (facebook, tweetie, etc..) you will notice that they take advantage of the native capabilities to do some very advance caching and rendering. That is the only way you can deliver great experiences to the phone today. You are going to need a couple of additional hardware+memory upgrades on the iphone to have a viable web as a platform story and apple is as well positioned as anyone else to drive that transition (complete HTML 5 support + great CSS tricks). Between now and then, we are prisoner of Objective C and Cocoa!
cranstone
· 5 months ago
One word... "Privacy".
(Full disclosure here... we're just getting ready to release a free mobile app for BB and WM that allows you to extend web services to mobile and access any device side capability and then share that with the web service. )
It's taken a lot of time to design the right privacy controls while allowing the customer the flexibility to share data with a single click or not.
The only way we could figure out how to do was to extend the native browser to support a new "tab" (if you like) In there you have access to control the meta data you want to share with the web service. These fields include location (GPS, Cell Tower ID) Device capability and also user information (preferences, keywords etc). All this is customizable and can be extended.
If Google was to suddenly open up their Android browser to allow JavaScript to get access OUTSIDE the sandbox you can just imagine what could happen to the customer experience. The mobile user has to be in control of his/her privacy for this to succeed. Basically it all boils down to Trust. If you trust the web service (whitelist) then share my data - if not then if should not be accessible.
Currently HTML5 and or JavaScript to not support this level of granularity. So you have to do it a different way. Our approach was to simply extend the HTTP protocol to include additional meta data (RFC 2616 says that this is permissible). Then all you have to do at the server side is read the incoming data.
albert
· 5 months ago
Agree that privacy and trust are critical here. Seems to me though that Google could have opened up the browser and still had exactly the same kind of one time or forever approval dialogs on a per domain basis.
cranstone
· 5 months ago
Yep. The issue then becomes - access to what? and how do you design the user control mechanism. It's all doable - someone just has to figure it.
All Comments
Also, it's still somewhat murky how well browsers can actually connect to the phone's hardware, but if that is optimized then it could definitely open the door to what you're talking about.
But the reality is that the vast majority of phones in the U.S. aren't smartphones yet and most phones don't support 3G (especially the corporate flock of older BlackBerries, who are the most frequent users of data services).
Also, a lot of bigger brands are very afraid of a bad user experience especially in relation to more sensitive tasks that can be accomplished on the phone (e.g. money matters, health, etc.). The current reality is network limitations don't offer a good experience - hence the tide has gone in the other direction.
I'm not arguing against the possibility of more powerful browser capabilities, just trying to figure out why it hasn't happened yet and what the short-term barriers might be.
As I mentioned on the USV blog, fragmentation (of handset types, operating systems, and even core technology) is still an issue and will be an issue preventing scalability of solutions for the near-term. More capable browsers might be a better solution than applications for this fragmentation.
As for security, I am sure folks will bring that up but it might be a bit of a red herring. If Javascript wants access to say location there should be a user prompt allowing or denying access. That prompt can show the origin domain for the script. So there is no risk of people having their location snarfed without their permission. Malicious behavior is much harder in the Javacript world as there is no native code execution. That leaves the traditional class of web attacks such as XSS and CSRF but not sure that those are any more dangerous here.
http://www.boygeniusreport.com/2009/06/30/what-...
he nails it. consumers are going to follow developers in the long run. and RIM is not giving developers a great platform to build on.
But it's dead right that BlackBerry OS is aging. The question is...do they have an ace up their sleeve we don't know about?
Lots of game changers they could implement.
- do a deal with Microsoft and develop Windows for BlackBerry
- do a deal with Palm and launch webOS for BlackBerry
- take android open source and build a new BlackBerry OS around it
- build BlackBerry OS 6 from scratch on top of Linux or something else
- buy Opera and make the app infrastructure completely web as suggested in this post
not sure why you couldn't have protocols for preloading html-based apps onto the phone and executing them locally. I think what we're really talking about here is language and platform...you wouldn't actually want the app displaying in the browser cause you use up valuable screen space for no reason.
you want an "apps mode" for your mobile browser that hides the browser...just like Chrome with the "create app shortcut". check out how that feature implements to see how Google is viewing the future of apps on the desktop.
Also the html 5 widget specification (implemented slightly differently on nokia) allows you to download and install html applications, as if they were native applications.
That's what we used for our iPhone App for Coovents (coovents.com) and its what we'll use for our mobile apps for Hapnin (hapnin.com).
iPhone OS 3: The moat strategy vs. features-fetishism
http://counternotions.com/2009/03/19/moat/
Apple The Storekeeper
http://counternotions.com/2009/05/19/storekeeper/
I think the iphone is only going to become a standard if apple is going to license it's operating system.
That said, we're rapidly approaching the point where webapps will dominate again. A few more generations of devices and network and it will all go back to the web, except for games and maybe a few other types of apps. So I don't know why Google isn't pushing for HTML5/JavaScript extensions.
But this debate is framed from a 'supply side' look at what languages and tools are available at what level on the OS stack, and says nothing about consumption in the form of users and usage. If you sell a good or provide a service via WAP and then one day release an app-based version of that same offering, the degree of user engagement you see in a side-by-side comparison is likely staggering. It's like when Google had to triple-check its logs because it didn't believe the volume of per-user search activity from iPhone -- this was the result of the (thin) layer of app instead of WAP-only that was offered.
USV has all the data (for free) at its fingerprints to do a user-facing analysis, which is where I think energy is better-spent than pontifications around Jscript v. compiled languages -- this worries about the wrong things -- users and usage are the answers.
Try a post that looks at the following:
- Top 100 WAP sites as mesured by m:Metrics (comScore), and
- Top 100 iPhone apps as measured by Pinch Media (USV portfolio)
- Prune and find those services that offer both WAP and App versions
- See what user-based metrics (that matter) can be gleaned from these figures
If users clearly respond more to Javascript/HTML 5 (which I doubt), then you have your 'living peitition' to Google/Android's team. But this discussion is a socratic exercise of conjecture about why one language might be better than another until user data is entered into the mix, and Flaitron/USV has always invested early and often in that arena -- share some knowledge and do some analysis!
- We have Google on the web.
- We have Google on the WAP.
- We have Google on the app.
And your post is essentially: 'Why app when you can WAP?'
And the answer should live in whatever degree of measured, meaningful engagement is seen via app vs. via WAP. In the case of Google, that metric is likely a blend of (i) queries per month, (ii) eCTR per user and (iii) eCPC per user.
This is actually a very rearward-looking question for which there is good data, or at least there should be from m:Metrics/comScore and Pinch Media.
Why can't you WAP the way you App?
If we had done the same analysis that you mention before the iPhone, the WAP delivery channel would have won hands-down both for general usability and for actual number of hits. This was the perfect example of people not knowing what apps can really offer without the limitations in place at the time. No study at that time could have predicted the re-emergence of the app as the dominant method for content delivery, communication, and innovation on the mobile.
That's one of the reasons why it's hard to predict whether a new, more powerful browser-experience can re-take the lead.
If Apple wants to play the game of who has the most apps, then cool. If the rest of the smartphone industry were smart, they'd all get behind one super-HTML5/JS standard and have their apps portable to each other's phones.
Then developers would write for two ecosystems: the open platform and the closed platform. By unifying all of the other platforms into one, it could very possibly break or at least strongly compete with Apple's monopoly because then it turns into "do you want to be able to move your apps between phones, or buy into a closed system?"
But it's important to remember that the mobile landscape is quite different from the one PCs ever faced. There are a lot of very entrenched handset manufacturers who desperately want to keep control over their hardware and thus hardware margins. You have the OS developers who are much more scattered and diverse than PC OS developers ever were. You have the mobile network operators who are usually huge companies that move extremely slowly and are also very protectionist. Finally, you have confused consumers which can essentially be broken up into two main groups - those that use non-voice features and those that don't.
This ecosystem is quite complex so developers can't just pick a standard and run with it. A collective agreement is usually needed for major change.
The second is that Google's strategy seems to be mixed between HTML5 and Gears: Gears was initially going to provide a lot of the deeper hooks into the OS that a web app would need. Gears let's Google skip all the delays associated with standards bodies, but it relies on platforms that'll let Gears plugins work, and so far that's been hugely limited (i.e. Windows Mobile, and of course Android), so it's been a far-from pervasive way to get additional capabilities.
Ultimately, HTML5 is making great progress... but waiting for standards bodies up-front is a pretty great way to waste time and kill innovation... and that seems to be what's happening in mobile at the moment.
- push messaging (for efficient network use, and background tasks)
- native access (i.e. making native device capabilities available to JavaScript through the DOM)
- Native-code runtime (i.e. something like the Silverlight CLR to let apps break free from the requirement to use JavaScript, and the performance issues that come with it)
Ultimately, much of the technology to do this already exists... Though, the actual go-to-market is the tricky bit... i.e. you could build such a plugin and get it out for Windows Mobile and Symbian devices. It would then require either a re-write in Java (a huge undertaking) to get it to work on BlackBerry. Then, you'd either have another Java variant for Android, or take the original, native codebase, and donate an open-source version to the Android alliance, and hope that it made it into the main branch that everyone adopts.
As far as an alliance... maybe... I think Palm's WebOS and Mojo approach is a good one, and actually, alliance or not, guys like RIM ought to seriously look at implementing chunks of Mojo (forget standards, just embrace the de-facto standards that other people have shipped).
Another approach might be for Google to take the already open-sourced Dalvik JVM, and Chrome Lite browser, wrap them as an Android-independent chunk of code and help the other OEM's just integrate that into their platforms... Come to think of it, that wouldn't be a terrible starting point for a startup either... :)
That said, I don't think the acquisition makes a lot of sense. RIM needs to improve their browser and app platform, not get a new set of devices (that they'd throw away) to manage that run a number of different operating systems (that they don't want).
If RIM got itself away from just Java as the OS, moved to WebKit as a browser, and acquired a small team w/ WebKit experience, they could build a WebOS competitor for a whole lot less, and get it done without having all the overhead of a full-on acquisition and product integration.
I wrote my thoughts recently on how I think the Palm approach of using existing technologies instead of re-inventing a new platform and libraries to be used like all the other native app platforms:
http://www.sachinrekhi.com/blog/2009/01/12/palm...
This could be overcome if the mobile platform considers the "server side", say a Ruby on Rails runtime. Then it could support HTML/CSS/JS on the front end while providing the back-end support required to run sophisticated apps. Palm's closest but they are missing any semblance of "server side".
And even when we get all the technical details, there's still a mentality that needs to be overcome. Most mobile developers are too small to battle this perception problem of "everything in the browser needs an Internet connection." It's a fight that has to be done by Google or Palm or RIM.
I will promote one very relevant post here. I wrote about how to beat Apple at their own game in August 2008. Included was a discussion of web app development that would work wonderfully. It's here: http://bit.ly/17uUR3. No one has done it yet but the one who does can be the major player.
We are still pretty early, releasing in stages. Our first FastFigures versions are on iPhone. Over the next few months we will be adding customization, filling out the web capabilities and adding data sync to the cloud. You can check it out in it's alpha/beta form at www.fastfigures.com. The first iPhone version is available at www.fastfigures.com/apple.
I've been hovering around this business opportunity for the past 12 years, as I started writing mobile software for the Pilot 1000/5000 in 1997. When Palm OS was king, we distributed over 15 million software products, had partnerships with leading providers in tech, industry and education, and almost had a break-out success in 6-12 math education.
If Android capitilises on this and allows for native like access to the file system through the browser the others will be scrambling to play catchup and this can only mean good things for developers and users.
(Full disclosure here... we're just getting ready to release a free mobile app for BB and WM that allows you to extend web services to mobile and access any device side capability and then share that with the web service. )
It's taken a lot of time to design the right privacy controls while allowing the customer the flexibility to share data with a single click or not.
The only way we could figure out how to do was to extend the native browser to support a new "tab" (if you like) In there you have access to control the meta data you want to share with the web service. These fields include location (GPS, Cell Tower ID) Device capability and also user information (preferences, keywords etc). All this is customizable and can be extended.
If Google was to suddenly open up their Android browser to allow JavaScript to get access OUTSIDE the sandbox you can just imagine what could happen to the customer experience. The mobile user has to be in control of his/her privacy for this to succeed. Basically it all boils down to Trust. If you trust the web service (whitelist) then share my data - if not then if should not be accessible.
Currently HTML5 and or JavaScript to not support this level of granularity. So you have to do it a different way. Our approach was to simply extend the HTTP protocol to include additional meta data (RFC 2616 says that this is permissible). Then all you have to do at the server side is read the incoming data.