What is Needed to Ignite Mobile Commerce?

The mobile world still has not broadly adopted a technology that will play the equivalent role that HTTP and Web Browsers did in igniting the Internet. Even though the Internet existed for years before it exploded into mass usage, even though there were standards like Gopher, Usenet, FTP, WAIS – the combination of HTTP Servers and Web Browsers put all the pieces together that ignited the chain reaction that yielded the modern Internet.

Yes, there is WAP, yes there are mobile Web Browsers that try to be smart about effectively presenting full size web pages on a small device – but these approaches do not respond to the key issues facing broad practical deployment of mobile applications.

Here are the key issues that must be solved by a standard if it is to allow broad deployment of mobile applications:

1. Disconnected Operation – Applications must continue to work as the user goes in and out of coverage. Encountering gaps in wireless coverage – in buildings, in suburbs, behind mountains – is a fundamental characteristic of business users and business applications. Coverage may be truly ubiquitous sometime in the next 5-10 years, but not next year. Broadly supported thin-client approaches like WAP and mobile browsers just plain fail if you are out of coverage. While seductive in leveraging the model and enormous content base of the desktop Web, these approaches fail to go mainstream because they can’t respond to this fundamental characteristic of the wireless world. It is not surprising that the only broad use of WAP and mini-Web Browsers – delivering news and entertainment – are applications where there is no cost to losing a transaction. If a disconnection occurs, the user just tries again. The core technologies are store and forward and publish-subscribe, not thin client.

2. Forms-Based, Transactional Applications – Wireless business software in inherently transaction oriented. Examples like making purchases, querying status, updating status, filing a report, and similar operations all involve taking existing real-time data from and existing server, working with that data in the field, and then making updates to that data from the field. Now, most mobile workers do such transactions with paper forms. Someone at the office prints out the form, hands it to the mobile worker, the mobile worker does the work in the field, filling out the form, brings it back, and finally someone at the office enters the new data. Mobile commerce standards must address how to mobilize this work flow. Publishing news articles, ring-tones, and games is the easy part. Collecting real-time results from inspection reports tailored to the customer's site or taking a customer order and immediately committing inventory is more typical of business applications.

3. Easy-To-Build – Posting a forms-based transactional wireless application on the wireless internet needs to be as easy as posting a static content filled web page.

4. Automatically Manageable From the Sponsor's Site– Access to, deployment to, and management of a mobile application and its users needs to be manageable from the application sponsor’s server and built into every application automatically. This goes hand-in-hand with easy-to-build: these access, deployment, and management features need to be a part of the “easy-to-build” feature set.

5. Works With a Wide Range of Devices– There are currently many programming approaches to supporting multiple devices, but nothing as simple to use, deploy, and manage as HTML. I believe that a programming approach is only useful if it is widely supported and essentially free. J2ME comes closest. Microsoft has the right idea with the .Net Compact Framework, but of course is only going to support devices that licence from them.

My company, JumpStart Wireless, has a complete solution to these issues. Currently we use it to drive mCommerce for to a wide variety of businesses in the Construction, Field Service, and Transportation segments. This solution is not a broadly adopted standard, so we are only in a position to benefit our own customers. Other solutions than ours are certainly possible. The real key, however, is the industry adopt SOME standards that address these requirements.

(JumpStart is interested in putting key parts of our technology into the public domain, but don’t see that as practical without a larger player as a sponsor. Write me if you are interested in joining in such an effort.)

Comments

[Rohit Arora]

Hi,

I feel, hand-helds by their very nature are resource constraint devices which in turn implies that the applications that are available to the end user should have a small footprint. Desktop browser applications picked up when the user felt he was connected and was empowered to do everything from his home/office PC.

We would need similar applications on mobile phones which would empower the end user. The applications that are available today hardly provide this to the user.

I completelya agree with the author on the need of such mobile applications with these features. Along with this, there is a need of middlewares, agents that could act as proxies for mobile phones, mobile users. These proxies would be powerful and could host more resourceful applications. At the same time, mobile applications would be simple with a small footprint.

We have to develop an End-to-End application to bring up that revolution.

`RoHiT.