How Not to Build Highly Interactive Mobile Internet Applications

A new breed of Highly Interactive Mobile Internet Applications (HIMIA) is gaining a foothold in the marketplace. Many app designers and developers are curious to know the best practices that lead to building such apps. In this post, I will do the opposite - give you five tips on how not to plan your apps.

But first, let me begin with a brief history.

Several of the very early internet applications for mobile platforms were merely web pages delivered through a mobile browser. Whether you used Safari, Opera Mini, Internet Explorer or any other browser compatible with your device, the usability of such applications was minimal at best. The lesson was clear and obvious: what was designed for computers played best on computers.

I will skip the WAP part and move on to the early signs of interactivity on mobile - the traditional mobile apps. Several of these are natively supplied with the operating systems such as Symbian or Win Mobile. Many more are nowadays found in application exchanges such as the Apple App Store. A large number of these seem to be small form factor versions of desktop apps.

In some cases, however, you do encounter applications that take advantage of mobility inherent in the device. These are the forerunners of HIMIA - the Highly Interactive Mobile Internet Applications. There are several factors fueling the growth of HIMIA. You have a good screen size, high resolution, touch interface, GPS capability, accelerometer, camera, speakers, microphone, storage and processing power. And of course you can assume connectivity with a good bandwidth. Users are increasingly familiar with the use of internet while on the go, they are comfortable with thumbkeys and expect to stay connected at all times. No wonder, then, that a whole new generation of highly interactive mobile internet applications is round the corner.
So, then, what are the do's and don'ts when planning to build HIMIA? As I started to write this piece, it appeared to me that it will be easier define what a HIMIA designer should not do. So here is the DON'T list.

DON'T use a page-browsing metaphor
This should be obvious, but worth stating because many of us miss it. HIMIA are thick clients, with a rich user experience. Imagine the difference between a LinkedIn app on your iphone versus browsing Linkedin.com on your mobile browser.

DON'T mimic experiences similar to computers
Taking advantage of the unique capabilities of mobile devices enumerated above is critical. If the app simply emulates PC-like experiences, that is no fun .

DON'T think it is a standalone app, operated in a silo
A successful mobile app is usually a part of a bigger system, and therefore must integrate well with the backend.

DON'T hope to use the same app interface for all mobile platforms
This may be a holy grail, but it ain't going to work. Each platform has unique capabilities, and you need to contemplate variations in your app to take full advantage of unique platform capabilities.

DON'T cram all features of web app on mobile
That does not work. A judiciously selected subset of features works best. Try a Facebook app on itouch. You cannot do everything that you can do on the web app, but you will get by. It would have been disastrous of the mobile app version tried supporting all features.

This is a developing list. You are welcome to add more DON'Ts to this list.