- Google Gears has been released (I noted this in an addendum)
- Apple has announced that the iPhone's only development platform is its Safari browser.
This has stirred up the silt of online commentary, but hasn't really changed the lay of the land at all. Mobile Web 2.0 is still a poor cousin of native clients. And here are the reasons why.
The Story So Far
In Part I, I looked at the history of web applications, and the special character of markets (or the Japanese market, at least) where they've been arguably successful. In Part II I presented three factors that are required for applications to be enjoyable and practical to use and that Web apps are, by nature, poor at: responsiveness, reliability and privacy.
Has the Story Changed in the last month?
Google Gears changes the reliability equation a bit, but the equation is still in favour of native clients:
R(native clients) = R(client app) * R(client OS) * R(client HW)
while a Google Gears based app has a reliability of:
R(GG app) = R(client SW) * R(browser) * R(client OS) * R(client HW) * R(GG framework)
It's easy to see that a GG app adds the (un)reliability of the browser and Google Gears framework into the equation. Thus, given the fabled instability of web browsers, and unknown stability of the GG framework, the client application code must be vastly more reliable in order to equal a native client application's reliability.
As for Apple's iPhone announcement, this has no impact at all. Some (presumably) ignorant commentators have waxed lyrical over how the delivery channel problems faced by mobile software vendors are magicked away by Apple's approach. I assume these commentators are merely ignorant (as opposed to plain dumb), since smart phones have supported this approach for some time, through recent releases of Opera mobile and Nokia's Safari-based web browser.
In any case, neither of these announcements really shifts the playing field much. Web apps are still much easier to deliver, but no easier to advertise or promote. And Web apps still have significant responsiveness, reliability, and privacy issues.
Is that the end of the matter, then? No, it is not. There is still one more critical factor to consider.
Usability
A major factor that I didn't talk about in the last post is usability. Anyone who has struggled with a complex web application like SugarCRM or even a simple one, such a Google Blogger, which I'm using now, will be aware of the peculiar user interface that Web APIs force on application developers.
Let's take the simple case of Blogger, as an example. Basically, Blogger is a text editor which saves to a type of bulletin board instead of a file system. Frankly, it is a terrible text editor. It has no styles, only two types of lists, no table editor, extremely primitive layout capabilities, and a very old fashioned spell checker (press a button to get your spell checking done). The problem is, Blogger doesn't allow you to use any old text editor, since the text editor is tightly integrated into the whole blogging framework. Tch, tch.
Even with its primitive features, the Blogger editor has terrible usability. The only shortcuts appear to be Ctrl+B, Ctrl+I, Ctrl+S, Ctrl+Z for bold, italic, publish (not save), and undo. There are no shortcuts for changing the font, there is no way to insert a hyperlink which has text different from its target without editing the raw html (shocking, I know). The editor is not even WYSIWYG! To access the various critical parts of the user interface, such as saving a draft, previewing (yes, previewing: no WYSIWYG here) the text, running a spellcheck, starting a list, etc. there are buttons to click with your mouse.
There is no menu bar, so any menus need to be attached to one of these on-screen buttons. Menu items have a very limited range of shortcuts to choose from, because the browser itself has already claimed many of the shortcuts.
In other words, what we end up with is a user interface with very constrained models of interaction, mostly point and click. There aren't even context menus to make interacting with objects easier. All of these useful UI mechanisms (keyboard shortcuts, menu bar, context menus, drag and drop) are either not available to the Web 2.0 developer, or they are very difficult to code (and thus lead to unreliable software).
How does this affect Mobile Web 2.0? Badly, as it happens.
The preferred UI interaction method for Web 2.0 app's is the on-screen button, clicked by a mouse. For touchscreen smartphones, this method of interaction may seem quite natural, until you look at how much screen real estate is needed for all these buttons. Ever tried to use Blogger on a VGA screen? It requires a lot of scrolling about, since Blogger only scales down to a certain size. This transforms simple movements of a pointer and clicking/tapping into the much more time consuming action of scrolling, pointing, clicking, scrolling.
Mobile devices have created whole different device interaction models (such as the softkey model), which Web 2.0 apps simply have no access to at all. (How does a Web 2.0 app register commands on the softkeys, or place commands in the browser's menu?)
Maybe the iPhone's touch interface will work with carefully tuned Web 2.0 apps, but I can't see them getting very sophisticated without becoming quite clunky. And all the cools effects of the iPhone's UI (zooming and sliding and scaling) will presumably be very difficult, if not impossible, to achieve.
The Alternative
So what is the alternative model to a Mobile Web 2.0 application? Clearly the "mostly connected" nature of a smartphone should be exploited, but so too should its native capabilities. So the obvious model is a native client application that synchronizes, when needed and as possible, with online services.
The native client application, with smartphone-resident data silo, has the benefit of:
- Responsiveness
Native client applications don't require bulky frameworks to start up or be kept in memory before they can run. I was reminded of how demanding this can be lately when using Google Maps on my P990i. It is a Java application, and Java takes quite a long time to start up, and chews up a phenomenal amount of memory. Of course, on some devices (such as Blackberrys) Java is the native framework, so it doesn't have such a hit. But on devices where it is not, it is a very poor choice of API. And so is a web browser. - Reliability
I think I've demonstrated pretty clearly why native applications are better at this, assuming that they are written with even a little attention. - Privacy
Native applications, with a local data store, can keep information private to the device. When information is sent to the online service, it can be encrypted (if it is merely to be stored) or anonymized (if it is to be used to generate a reply). Whether this is being done can be validated by a third party, which is something that is simply not possible with an online software service of any type. - Usability
Native applications can be developed to exploit the UI methods of the device. I was reminded of the importance of this, once again, by Google Maps. For some reason, Google Maps uses a UI that mixes its own menu style with the built-in style. It leads to constant cognitive dissonance as things react in unexpected ways. Even Opera Mini 4, which is a model of usability in its scrolling and zooming behaviour, suddenly gets weird when you tap on an input field or the like. (Oh, and it consumes a truly shocking amount of memory.)
When native apps have benefits in all these areas, which all have a direct impact on the end user, it's merely laziness or a very cavalier attitude to the user experience that encourages people to use the Web 2.o platform for serious application delivery.
Having said that, where the main focus is browsing, rather than manipulating, non-critical information, Web apps are great. And this is where Web apps belong: in making a better Web.
