Choosing the Right Wireless Application Platform

Screen size. On these devices, 320x240 pixels (Quarter VGA or QVGA) represents the high end. Compared with a 1,024x768 display, this is 13 percent of the screen size.

Data input. Options include phone keypads, stylus input and miniaturized keyboards. All can work, but are much slower than conventional keyboards. Monitoring e-mail on a phone, for instance, is feasible; typing e-mail on a phone keypad is frustrating.

Connectivity models. Although cellular networks offer excellent coverage, you won't always be in a coverage area. The best applications allow some local interaction with data. A client-server model for e-mail, for example, is more effective than a browser approach because it lets you read and write messages even when you're outside a coverage area. Users can manage their contacts and schedules locally, occasionally synchronizing over the network.

So what types of apps are enterprises asking for? Our poll respondents, not surprisingly, rated e-mail most important. Other highly desired apps include calendar management, customer relationship management, database access, dispatch and job management, group collaboration, IM and highly targeted job functions.

If you want to test these devices, start by offering employees e-mail/messaging and contact/calendar management--these turnkey apps are available on nearly all devices. Then, over time, you can use these devices increasingly to make select data accessible.You can find applications for your wireless device through a number of channels. But you can't run the desktop versions them, with the possible (and painful) exception of using a remote-control thin-client approach. In most cases, platform vendors or ISVs (independent software vendors) have developed apps for the platform. Microsoft, for example, provides a version of Outlook on its Pocket PC and Windows Smartphone.

Unfortunately, many of these protocols are not well-suited to slower wireless connections, and in many cases, wireless middleware is more effective, whether supplied by third parties, such as Extended Systems, Synchrologic or Xcellenet, or from the company providing back-end services, like IBM or Oracle. The middleware approach, while adding complexity and cost, can solve the challenges of intermittent connections and streamline communications. Middleware generally involves client code, so you must make sure your specific device is supported. So far, we see relatively equal support from the major software vendors for Microsoft, PalmSource and Symbian platforms, but not for RIM.

An alternate approach, and one that doesn't require client code, is to use a browser, whether a microbrowser (typically XHTML with a mobile profile) or general-purpose HTML. Browsers simplify application deployment and make sense for smaller projects--say, those with 100 users--and where only a limited amount of data interaction is needed. All the systems we evaluated had competent browsers. The downside: Browsers are slower than local clients, and users need to be in a coverage area to use the application.

Another area to consider are third-party wireless application services. Although the market was rife with these providers several years ago, many of them have vanished. Now we see cellular operators providing gateways to facilitate mobile access to enterprise systems. AT&T Wireless, for example, offers an "Office Online" service that is a gateway to enterprise Microsoft Exchange or Lotus Domino/Notes servers. These services cost $5 to $10 per month, per account. If your needs are limited to just a few core applications, this can work.

Finally, should you buy something off the shelf or roll your own? Our reader poll showed just a slight preference for buying from an application or middleware vendor.If you do want to develop an application, you have a lot of work ahead. All these platforms offer sophisticated application-development environments, whether based on C++, C#, Java, .Net Compact Framework or Visual Basic. But you will face a significant learning curve, as well as the challenges of designing for small form factors, including minute screens, laborious user input, limited memory, fewer debugging tools than for larger platforms and less-than-reliable networking connections, thanks to the inherent vagaries of wireless technology. We expect few enterprises to develop their own applications. Those that do will likely choose a managed-code approach, such as Java or .Net. As our survey shows, the strongest preference is to use Microsoft development tools, followed by developing in Java. Least popular, though not by much, is to develop applications in native C++ for the platform.

As for developing in Java versus .Net, it depends on your general computing environment. .Net makes sense for Microsoft mobile platforms and for applications that demand integration with Microsoft servers. Java is well-suited for larger enterprises with heterogeneous computing environments. The same Java language you use on servers is used with Java 2 Micro Edition. What differs are the general constraints of the mobile devices, such as memory and user interface. Java currently comes in three flavors: J2ME with Mobile Information Device Profile (MIDP) 1.0, J2ME with MIDP 2.0 and Personal Java. These provide a reasonable amount of capability, but with greater memory requirements and increased device cost. Currently MIDP 1.0 is moving toward lower-end phones, MIDP 2.0 toward higher-end phones, and Personal Java is not used much yet. Furthermore, not all Java versions are available on all devices.

As an alternative to Java for some mobile phones, you can use Qualcomm's Binary Runtime Environment for Wireless (BREW), but this is most commonly used for entertainment applications.Should you take the mobile wireless plunge? Start with an ROI analysis. If you use the built-in applications that come with most of these platforms, your costs could be relatively low. If you assume an extra 30 minutes of productivity per day, that's a benefit of $5,000 per year for a typical employee. This means a break-even on a $500 device in about a month. However, things get more complicated when you start factoring in the cost of support, training, expanding your network security to accommodate these devices and so on. If you have to buy applications, deploy mobile gateways and middleware, or do any custom application development, costs can rise in a hurry. But if you target your apps carefully, you should still see a solid ROI for many scenarios. If the device can replace a notebook computer, all the better.

Some guidelines for a successful deployment: First, start small. Forget about distributing PDAs company-wide until you've done pilot tests.

Next, decide what type of connectivity you want--WLAN, cellular or both? If you've deployed WLANs throughout your facilities, Wi-Fi may be a good choice. One day we may see wireless hotspots everywhere, but until then, cellular connections are your best bet for broad coverage. Are you committed to any particular cellular operator? This may dictate your choice of GSM versus CDMA and will also narrow the list of available devices. Remember that with cellular, your device choices are those the operator offers, not the ones in your computer catalog.For cellular networking, you'll be better off with devices that have integrated capabilities as opposed to wireless modems. This limits your choices, but the integrated devices are much more power-efficient and offer important features, such as the ability to receive data even when in standby mode.

Another consideration: Who decides which devices to purchase? Users are likely to have strong opinions about the phones or PDAs they use. Some may be attached to the user interface of a particular PDA or the looks of a smartphone. In our poll, 38 percent of readers indicated that device choice was solely a company decision, while 48 percent said it was mostly a company decision with some user leeway. We see this as the case for PDAs, but we expect that as smartphones are adopted for data applications, users will have greater say about the device, facilitated by the expanding family of devices available for each platform.

And don't forget about the actual applications of interest, which may be supported only on specific platforms, and sometimes only on some devices used by that platform.

Last but certainly not least, there are considerable security considerations. For instance, most of the platforms support VPNs, but are these compatible with the VPNs you're using? Larger enterprises will also need to institute a management system for software updates and asset tracking.

Bottom Line

Simplify deployment by minimizing the number of platforms you support. It remains to be seen, though, whether enterprises can limit their choice to a single platform, as many have done on the desktop with Microsoft Windows.

Use off-the-shelf applications whenever possible. The number of available applications is much lower than for desktop platforms, but that will change as the number of installed devices grows into the tens of millions and as enterprise application vendors look for new ways of augmenting and selling additional capabilities.

Realize that this is a dynamic and quickly evolving technology area. Existing platforms have strong enough capabilities, and there are sufficient application choices, that enterprises should clearly move forward, but with care. These platforms are far from the point of commoditization. Expect continued experimentation with new feature sets and vigorous jockeying for market position among vendors.

PETER RYSAVY is president of Rysavy Research (www.rysavy.com), a consulting firm specializing in wireless networking.

Related Stories"Lessons From Abroad,"

"Ericsson, Others To Fight Nokia's Control of Symbian"

"Easy Wireless, Tough Choices" Here are some additional items to consider when choosing a mobile device.

Usage: Does the device accommodate your predicted usage? For example, are major functions easily executed with one hand, or do they require two hands and a stylus?

Power management: Does it implement adequate power-management functions, such as maintaining data connections even while in a dormant or sleep mode? How often must you charge it in typical usage? Most devices should make it through a day of heavy use.

Browser: How well does the browser render complex pages? We were particularly impressed by the Palm Blazer browser and its ability to reformat complex content to make it usable on a small screen.

Size and weight: You may think a device is small enough until you have to carry it with you all the time. Make sure it's large enough to provide the user interface you need, but not a microgram bigger.

Radio performance: There is some variation in how radios are implemented between platforms. One device may be able to do voice/data communications in a low-signal or high-interference situation, while another can't. If you're doing side-by-side testing, include wireless communications in a variety of locations.

Phone-function integration: Are phone functions an add-on to PDA functions or are they tightly integrated? For example, can you scroll through a list of received calls and easily select numbers to add to your address book? Symbian is especially strong in this area.

Device as modem: For some situations, you may want to use your wireless device as a modem for a laptop. Does the platform support this natively? If not, can you buy a utility that makes it possible?If it hasn't occurred yet in your enterprise, it will: Some gadget buff will flash his new smartphone and brag about how he can answer e-mail on the golf course. Suddenly, you'll have the kind of grassroots enthusiasm usually reserved for the latest firing on The Apprentice. Next thing you know, you'll be determining the feasibility of deploying wireless devices companywide and furnishing employees with secure access to e-mail, instant messaging, databases and other key business applications.Before this happens, take the time to review our coverage of wireless application platforms. In "Device Diversity," we assess the functionality of these products and discuss what they'll offer in the future. These platforms vary considerably in shape, size and capability, so picking the right one depends on your usage and application needs. For "Making the Smart Choice," we devised a trio of common enterprise user scenarios--voice-, e-mail- and data-centric--and sent an RFI to Microsoft, PalmSource, RIM and Symbian, asking for details on their development environments, applications, communications support, browsers, security and more. We analyzed this data, added our take on Linux as a wireless platform and determined the preferred choice for each scenario.