If this is the case and webapps are the way of the future, why doesn't Android include a way to package a web app for deployment through the market and to have an icon that can be used on the device like any other native app?
As far as I know, right now web apps have to be accessed through the browser, which means setting up bookmarks and web apps have very little access to the hardware on the device.
Perhaps what the article should be saying is that we should develop for WebOS because it's all HTML/CSS/JS and therefore much easier to develop for since it's all web-based.
While I would agree that Chrome, in some flavor, should be a part of Android, I wouldn't assume that Chrome is destine to be a part of Android. The Chrome and Android projects seem to be dueling strategies at Google.
Check out http://www.phonegap.com/ for packaging html based apps for the platforms. As a added bonus you get access to native app features through javascript.
I suppose my point was that if HTML5 was important for Android, that Android would include the support for web apps in the platform with no outside dependencies.
There is very little depth to this. And what is there is ostly opinion and conjecture.
Prsonally, I think that Google has had some of the best android apps available (though having their api access would make most competant devs improve their apps). It's also the only time vie heard anyone suggest that chromes would take over android. Nooooo way this is happening for at least a number of years. They are two very different platforms attempting two very different goals.
they are not different goals, android and ChromeOS have the ultimate Google corporate goal of placing a moat around their search/ad business by giving way $1 billion in r&d through android Os and Chrome OS
And a hammer and screwdriver both are there to secure things, that doesntmean they do it the same way or are interchangeable. Neither or replacing either anytime soon.
Its interesting a friend of mine runs the team that does the Netflix PS3 app. The "app" is actually a webkit implementation with one destintation - Netflix". They love it for embedded devices. Particularly platforms where you have to go through a certification process. They get the "browser" cleared once and then can update the app on a regular basis. It allows them to do a lot of A/B testing, they get quick updates out etc.
Netflix's web developers might enjoy working on the HTML5-based app, but (at least on iOS) the user experience is poor:
- Scrolling is slow, jerky, and is less useful than standard scrolling (for instance, there's no inertia).
- The application uses none of the standard UI components, and the components they use are poorly implemented and difficult to use; Netflix is failing to take advantage of the UI R&D you get for free when you use standard OS components (eg, see inertia above).
- The application's UI is very very slow to load compared to native apps; since nothing is local, everything has to be fetched.
There's a lot more that a proper critique of their UI would involve, but in short, I'd say that Netflix is placing the enjoyment of their web developers over the happiness of their actual users.
Those are not issues that will stop the spread of webapps though. One major impediment into the mobile market is the fragmented environments. Using a common environment (ie open web) would allow much more flexibility to develop multiplatform apps. At that point, most people would be willing to give up some of the platform specific features (inertia, etc) to run across platforms.
edit: this is my opinion as a web developer who is thinking of getting into the mobile market, not as a mobile developer.
Unfortunately phones have lots of useful features that aren't exposed in the browser.
For instance, I just installed an app on my Android that creates a blacklist of phone numbers to reject, both calls and SMS and also cleans up the phone's logs. Basically once you add a phone number to that app, it may as well not exist anymore. I love this little app so much that I would rather do without all available web apps out there on my phone ... because the main purpose of my phone is to connect with people and not having API integration with its core functionalities, like voice calls and SMS would make whatever "smartness" it has basically useless.
I'm still baffled as to why this isn't a standard feature in phones, but whatever, at least on Android you can add it (versus the iPhone, which requires rooting).
And exposing these low-level features in the browser through proprietary extensions wouldn't help the fragmented market. It also doesn't help that each environment has its own look&feel, so you'll have to add lots of platform specific stylesheets and Javascript for emulating standard behavior.
The best combination for me (as in fast development, not the best user experience) is building native apps with a web interface exposed through an embedded web view.
As a mobile developer, our clients are either in the business of selling products/services to users, or selling users to advertisers. Either way, our clients need people to download and use their application. In turn, we must provide the best possible user experience for those prospective users; If our application provides a worse user experience than the competitor's, users will choose the competitor.
In some cases, you might get away with a worse user experience -- if you want Netflix's content, you have to use Netflix's application, and a competitor can't edge out Netflix without providing replacement content, as well.
However, this is unlikely to be to your benefit if another competitor does offer content of equivalent value to users, and they choose to spend their attention on an application with a superior user experience.
I don't see that those disadvantages are inherent to using an HTML 5 based application at all. After all, the browsers on my desktop use native scrolling, widgets, etc. There's no reason Netflix couldn't spruce up the browser side of things to make it more "native", and continue to enjoy the benefits of having most of the application logic server-side.
Between Qt, Swing, and even SWT's attempt to expose native widgets, you'd think that it would be well established that emulating native components (especially behind a generic API) never produces a result on-par with an application written against the real native APIs.
I just quickly tested the Sencha demo on an iPad 1. In terms of just the scrolling, Sencha Touch seems unable to implement glassy-smooth scrolling of a simple text-only list view -- something that was achievable on the original non-3G iPhone. On top of that, their UI looks like a poor clone of Apple's, is slow to respond to interaction events, implements jerky-at-best animations.
In short, it is obviously non-native, to the detriment of the user experience; it performs poorly, provides a lesser user-experience, uses non-default widgets, and will constantly be playing catch-up with the native APIs and UI.
Emulating native UI is definitely the wrong approach; it only highlights your apps weaknesses. However I think you're overstating the important of things like scrolling inertia; users do not mind this too much. It's shown by the fact that they all choose "inferior" experiences on the desktop when they log into their Yahoo Mail and Hotmail account; or worse, just use pop3.
Users will choose a solution 1) That they know about, 2) that meets their needs, 3) that is easiest. UX is probably 4th. Trivialities like page transitions and scrolling inertia only matters to the SXSW crowd.
Trivialities like page transitions and scrolling inertia only matters to the SXSW crowd.
Scrolling inertia is about utility -- being able to easily flick through a long list (such as Netflix's movies). It's a real, intentional user experience feature, not just some easily dismissed "SXSW crowd" aesthetic.
That said, I agree that foremost, users choose products that solve their problems. However, that doesn't mean that a quality native application isn't a significant competitive advantage.
If there are two products that solve their problems equally, they'll choose the one with the best user experience. If users are choosing a product with a lesser user experience, chances are good that the competition with a seemingly better UX isn't actually solving their problems.
As far as I know, right now web apps have to be accessed through the browser, which means setting up bookmarks and web apps have very little access to the hardware on the device.
Perhaps what the article should be saying is that we should develop for WebOS because it's all HTML/CSS/JS and therefore much easier to develop for since it's all web-based.