Shattering illusions about the mobile Web browser

After years of hype and frustrated users, many question if it was ever alive. We beg to differ with industry experts who argue that improvements--such as better device form factors, network reliability and connection speed--will give new life to the mobile Web browser. The reality is that trying to use a mobile Web browser, regardless of the device, is like using tin cans to communicate--it just doesn't work. Mobile browsers are slow, clumsy and dependent on connectivity.

Uncompromised mobility requires a mobile experience that rivals the speed, power and ease of use of a computer; it can't work with mobile Web browsers and other mobile gimmicks. It means being able to tap the widest-available set of development resources to put applications and data on the widest array of devices, regardless of language and platform.

Even in 2007, networks and connectivity are likely to remain intermittent and unreliable. The only humane thing to do is to put the mobile Web browser out of its misery by harnessing the power of rich applications.

It's said you can never be too thin or too rich. In the world of mobile wireless, for forms-based applications, "rich client" is in but "thin client" is out. A thin client is minimal. A thin client demands a continuous high-bandwidth server connection. In the wireless spectrum, bandwidth is lacking and is unlikely to improve in the near future. While some may say 3G is the solution to this problem, adoption in the U.S. has been much slower than the rest of the world, and will likely continue to lag.

Last year, businesses built up their mobile work forces only to find that the mobile Web browser limited, rather than enhanced, enterprise productivity. While device access, performance and overall functionality have improved, few enterprises have been able to harness the power available for uncompromised mobility.

Businesses are planning to increase their use of mobile devices for applications well beyond e-mail, including field force and sales force automation, remote monitoring, customer relationship management and enterprise resource planning, and more. Yet, many will fail because of the complexity, labor and expense of developing their own enterprise mobile applications.

One common mistake organizations make is assuming that users will always have to be connected. The safest investment that organizations can make in mobile-application development is to create rich on-device applications that take into consideration the greatest range of device variables for today and tomorrow, and support connected and disconnected states.

Rich applications address the best elements of traditional and distributed computing models, and will enable the Web to evolve beyond the page-based structure found in today's browser model--and mobile applications to evolve beyond the confines of the browser.

The possibilities really are endless and, suddenly, device diversity is no longer a challenge.

Many organizations are already realizing the potential of rich on-device applications to solve the mobility conundrum. Hospitals are using applications to provide critical patient information to doctors while on rounds or on the golf course. Insurance companies are enabling their agents to process claims from the road, eliminating paperwork and improving customer service.

This year, I expect to see commercial banks and credit card companies increase their mobile offerings to include such applications as those allowing customers to check balances and search for transactions, as well as using a mobile "wallet" for payment from a credit card account.

These are not the unfulfilled promises of yesterday's mobile solutions. These are the realities of today's uncompromised mobility solutions made possible with rich applications and mobile-application development platforms.

And the mobile Web browser? Unnecessary. Enterprises can reach their customers through mobile applications into which only data is downloaded. It's easy. It's fast. It leaves the heavy Web graphics and images where they belong--on the Web page, not the device.