BostonPocketPC

During our Boston/New England Windows Mobile User/Developer Group meeting this past Wednesday, we had a wonderfully interactive discussion during my presentation “State of The Union: Mobile Device Application Development”. A common theme/concern during the presentation revolved around the effort involved in creating a single logical application that runs on multiple devices across platforms like Windows Mobile, iPhone, Android, WebOS… and on and on. We talked in great length about development tools, programming languages, learning curves and the like. During the presentation, one consistent message I tried to impart the audience with was simple…

Don’t dismiss the possibility of leveraging the mobile web for your application.

I think the greatest example of this came from one of our attendees, Jim Travis (thanks, Jim!). He gave an example of an iPhone application currently available in the iTunes App Store (and a quite popular app as well). This application, focused on mobile banking, is quite nice and has the visual appeal expected when using iPhone applications. Jim then pointed out that by using this bank’s mobile web application, you received a similar visual appeal with similar functionality. No application download required. It is this very example that brought me to writing on this subject.

Any seasoned application developer will tell you that there are times when a web-based application simply will not work. Usually, it is business-critical requirements like offline access to the application, detailed interaction with hardware and/or system resources or local storage of information that becomes a “show-stopper”. I understand this entirely, having experienced this far too many times myself over the years. I believe, however, that when it comes to mobile application development, we have become conditioned in an almost Pavlovian way to assume mobile application equates to native application.

Part of our conditioning when it comes to mobile application development comes from the evolution of mobile devices themselves. For so many years, mobile web browsers were well behind there desktop counterparts in capabilities. In fact, it was not that long ago that the only “safe bet” when developing for mobile browsers was to keep it as simple as possible, falling back to WAP standards to guarantee that the application would work. Times have changed in this regard; today’s mobile browsers are quickly gaining the ability to render desktop web sites with near-desktop fidelity. Unfortunately, these capabilities have led to yet another aspect of our turning away from mobile web application development.

With today’s mobile browsers supporting near-desktop browser capabilities, many have come to assume that there simply is not a need to mobile web equivalents. I frequently hear people say “let the user go to the ‘regular’ web site if they want <fill in the blank>.” Sadly, simplistic statements like this forget an oh-so important principle of software design – accessibility and/or readability do not equate to usability. While I can see my bank’s web site on my mobile browser, the process of using my bank’s web site to manage my finances is fraught with challenges – zooming in and zooming out of a page, panning, scrolling, doing data entry, etc. All this typically leads to frustration and (inevitably) abandonment. If the banking site is optimized for my mobile browser, however, I can perform the tasks I require with improved readability, navigation and data entry. Result – a workable application that, when crafted correctly, can support a user base using different devices.

The techniques for supporting mobile mobile web browsers have existed for a long time. In fact, those who have developed web applications long enough can recall having to use the same techniques for desktop browsers (remember the first “Browser Wars”, with IE 4 and Netscape 4?). Interestingly enough, desktop web application developers are finding themselves in a similar situation today with IE 8, Firefox, Safari and Opera. To best provide rich web application functionality using “browser sniffing” (the web application determining the browser being used) and appropriate rendering of the web page, one can leverage a single base of common business application logic and customization only for the user interface. If you are developing using this technique today for your desktop experience, why not simply extend it for your mobile experience? While this approach requires a greater development effort, I think it is safe to say that it is usually far less effort than the alternative of learning multiple programming languages, investing in multiple toolsets and trying to keep everything “in sync” from a feature/functionality standpoint.

Another major challenge with native mobile applications lies in the process of distribution. How do you get your application to your users? Every mobile platform currently has one or more ways to deal with software distribution, but managing this when complicated by one logical application having multiple device-specific implementations is complex, to say the least. One compelling reason for the explosion of web applications in the past decade has been around this challenge. Simply put, web applications have no distribution issues to address, at least from a mechanical standpoint. New features? No problem. Bug fixes? No problem. Simply update the web site and voila! Bottom line – distribution of software is almost always a major complication for any type of application; web applications practically trivialize this issue.

All of this may sound like I am minimizing the importance of native device applications. I most certainly am not. I recognize their importance as well as scenarios where they are the only option. What I want to make clear, however, is that they are far from the only alternative for building solutions that support disparate multiple device platforms. When the idea for developing a mobile application first arises, you should be asking yourself some simple questions…

1. Is there a compelling business and/or technical reason why I cannot design the application for the mobile web? Sometimes, a legitimate business reason may trump technical reasons. An example – the exposure of a native application to the public through a distribution channel provides more marketing ROI than a web application would. I think the mobile banking example mentioned previously could support this scenario.
2. Can I provide the functionality for the user that meets the business and/or technical requirements with a mobile web application? While this used to be a blocking factor for the mobile web, it is increasingly becoming less so. Remember – the same mobile browser functionality that allows for the rendering and interaction with desktop web sites can be leveraged with a mobile web site; it is the design for usability on mobile devices that makes the extra development effort worth while.
3. Is the extra cost associated with multiple versions of the same application for different devices worth it? Back to the ROI discussion. If there are no blocking factors for a mobile web application, it is crucial to address the costs and benefits of going the native application route to make sure that there is a very real reason to “go native” (held off using that phrase up until now ).

As a presenter, I love discussions that make me think in the same way that I hope to get my audience to think. This past Wednesday’s meeting/presentation was one such discussion. I really believe that the diversity of mobile devices and associated platforms may in fact be a greater driver to mobile web application adoption than anything else prior. By simply being open to the idea of cross-platform mobile web applications, we can potentially see a new world of opportunities for all mobile device users.