Whose client is it,
anyway?

Pure browser apps won’t cut it for real-world business applications.

Wireless e-business applications—or so-called m-business—have been heavily touted over the past couple of quarters. Vendors have been making all kinds of bold claims about what their solutions can deliver. Market analysis firms have come out with inflated predictions about mobile use and transactions over the Web. In fact, the hype got so bad that backlash set in, and stories are now appearing in leading trade publications about just how vaporous the m-business segment really is.

While hypesters and nay-sayers battle it out, it makes sense to look at some issues that need to be resolved for the mobile Web to become a mainstream phenomenon.

A lot of attention is being paid to 3G networks as an infrastructure requirement for more robust mobile applications. Service providers have gone into debt financing the construction of these networks. They’ve done this just as the market as a whole has been contracting—an unfortunate bit of timing that’s likely to leave many wireless providers hurting for some time to come.

Another aspect of m-business infrastructure has received somewhat less attention, even though it’s also vital to the delivery of compelling m-business content and services: the client-side platform.

Mobile client platforms are important because simple browser-based apps won’t cut it in the real world. Browsers are very limited when it comes to interface features like scrolling lists and “child” windows. And applications that rely exclusively on a browser require an active connection at all times. If your wireless connection gets flaky for a moment—which it inevitably will—a browser-based app evaporates.

Also, mobile users want to do things with their data, even when they’re not connected. That requires intelligence on the hand-held device, whether it’s a PDA or a “smart” phone.

JAVA TO GO?

If you want to build smarts on a mobile client today, you have to do it in C++ or some other language, and write it specifically for the operating system on the device—whether that’s PalmOS, Windows CE or something even more proprietary. That’s a hassle for developers who need to support multiple devices in order to ensure good market coverage.

That’s where Java 2 Micro Edition (J2ME) comes in. J2ME provides the same layer of abstraction for hand-held devices that desktop Java provides for PC platforms. Theoretically, this means that developers can write once client-side apps that can run on any device that has a compliant Java Virtual Machine (JVM).

That’s the theory. The reality is very different. J2ME is still immature, so deployments are still more “write once, debug everywhere” than they are “write once, run anywhere.” Also, J2ME is a functional description rather than a true standard. Device vendors can select which subset of functionality they want to deploy on their devices. That creates an additional potential for inconsistencies from platform to platform.

Actually, Sun may not be able to maintain control of the J2ME standard at all. Developers want to write to the largest possible installed base. Thus, they’re more likely to be moved by what service providers like Japan’s DoCoMo, which boasts hundreds of thousands of users, are using as a client-side architecture than by what Sun tries to dictate.

TRIVIAL PURSUIT?

In DoCoMo’s case, that architecture includes a browser, some proprietary operating system APIs, and a subset of J2ME. Such a hybrid platform gives developers plenty of options, but it’s also very DoCoMo-specific—which is exactly what DoCoMo needs to keep itself differentiated from its competitors.

All of this makes for a very fragmented marketplace that offers m-business developers relatively high development costs with unclear potential returns. That’s not a formula for success.

What does all this mean to corporate communications managers? For one thing, it means that decision makers shouldn’t commit to any individual platform or development technology. It’s important to keep your powder dry until a real winner emerges in the wireless application space. For another, it means that buyers should be wary about wireless application server vendors or wireless ASPs who pledge support for “all popular wireless platforms.” Does an application run on a Palm device if it simply works with the Palm browser? Or is a native C++ client provided? Does it use the Palm JVM? Which version?

These questions are more than just technical trivia. They ultimately determine the functionality that mobile apps provide. Users who have been spoiled by desktop Net access won’t be satisfied with crude interfaces and limited capabilities. To give them what they want, the industry will have to come to an agreement about wireless client architectures. Otherwise, mobility will remain the domain of voice calls and short message service.

Comments for publication should be sent to to liebmann@comnews.com.