Generating ROI Is A Top Priority For Data-Capable Networks

Wireless network operators, or carriers, are under intense competitive pressure. They must generate ROI on the massive investments that they've made to roll out data-capable networks. Specifically, carriers must compensate for flat-to-waning voice Average Revenue Per User (ARPU). Right now, they are counting on the fact that enticing data services will significantly drive ARPU growth. At the same time, these carriers must reduce the costs associated with providing data services and reduce churn. They can do this by identifying and offering services that present consumers and businesses alike with compelling value. Such services will then be deemed worthy of monthly recurring usage.

To date, wireless-data-service experiences have been intolerable. To put it mildly, they are slow, hard to use, and prohibitively expensive. To make matters worse, they have no applications beyond e-mail that can appeal to consumers, mobile professionals, and enterprise users. The end result has been abysmal adoption rates and limited usage.

Although the future seems bleak, all is not lost. The industry has recognized the technology shortfalls that have led to this predicament. It has responded with the introduction of foundation technologies, which are designed to enable sophisticated data applications. To prove this point, consider what happened in 2002. Last year brought faster GPRS/CDMA 1xRTT networks and powerful smart wireless devices. The devices are running full-blown operating systems with 1990s-class desktop-computing power.

These smart devices enable a variety of new software techniques. In turn, the techniques offer new opportunities for carriers to deliver data services. These services boast a phenomenal user experience and more affordable pricing through optimized network usage.

To craft a compelling customer value proposition, it is key to understand why users have been slow to adopt—or reluctant to use—wireless-data services on an ongoing basis. In part, the reason stems from the industry's failure to deliver on the key purchase drivers for mainstream wireless-data services. Customers want simple and convenient usability and affordable service plans. They are also looking for relevant applications that will target their unmet needs while they are on the go.

With regard to usability, the handheld devices connected to wireless networks have relied almost solely on browser-centric solutions. These solutions provided the primary method for accessing network data. Unfortunately, the browser model was specifically designed for the PC environment. It has inherent limitations when deployed on limited-capability handsets.

A browser must, for example, maintain a live connection to a server to be useful. It also has to maintain that live connection for the duration of time that it takes to complete any given task. Moreover, getting cut off mid-task requires the user to go back to the beginning and start over. There is simply no way to store information "offline" or for the user to resume where he or she left off.

Ease of use, on the other hand, demands access to a keyboard, mouse, and full-size monitor. Imagine reducing the screen size, however, from full screen to approximately a tenth the size of a traditional full screen. Browsing was specifically designed and optimized for rich data-entry mechanisms and a full-sized screen. Consequently, browsing on a handheld device—without a sophisticated data-entry device or a large screen—presents an intolerable experience for most consumers.

These basic tenets serve as implicit requirements for the successful deployment and use of the browser client-server model. But in reality, it only truly "works" on a PC.

EASY DOESN'T MEAN USABLE Because they were motivated by time to market, companies targeting the wireless data market chose the easy and obvious path of placing browsers inside voice-centric handsets. That way, they could quickly offer a wireless data solution. Today, however, user frustration and abysmal adoption rates prove that this approach is fundamentally flawed when it comes to usability.

This result is a well-known fact in the wireless market today. It has led to limited new user adoption of wireless-data services, as well as limited uptake of wireless-data services from existing voice subscribers. In addition, carriers are currently unable to generate meaningful revenue from data services.

To solve this problem, developers came up with the alternative approach to enabling basic handsets. These handsets typically have less than 8-M Flash and 2-M RAM, along with minimal processing capability. Yet they would be enabled to download and run self-contained, "thin-client" plug-in applications. This idea caught on quickly and showed great promise. Unfortunately, virtually every handset manufacturer has created its own proprietary implementation for deploying these types of applications on their handsets. Moreover, many of them have chosen to write their own proprietary extensions so that they can take full advantage of their device capabilities.

For developers, this means that they potentially have to write very complex platform-specific code for every handset that they want to support. It is a huge challenge to write one application that can run on any handset. Due to this problem, the technique is now only targeted for simple, lowest-common-denominator applications, such as games and entertainment applications.

Aside from these usability and market-fragmentation issues, a more fundamental question remains: Can the previous generation of basic or "dumb" handsets provide the resources and horsepower needed to deliver on key carrier requirements? These requirements include:

A user experience that is optimized and tailored for each specific device offered
A consistent user experience across all devices offered by the carrier
The ability to drive incremental revenue by integrating connected applications with native applications, such as the phone, MMS, SMS, and e-mail services
The ability to write connected applications once and have them run on all of the devices offered by the carrier
The ability to finally provide consumers with cool, sophisticated, PC-class Web services that provide real day-to-day value

According to some, the answer to that question is obviously, "No." In the desktop-computing world, "connected" Web-based data applications didn't take off because of "dumb" terminals. They took off when it became more valuable and economical to provide users with a full-blown, "thick-client" computing platform on their desktop. A similar revolution seems to be beginning in the wireless device.

Last year bore witness to extraordinary advancements, which made it possible to address the previously mentioned carrier requirements in their entirety. Three crucial technologies have come together to deliver a new generation of smart wireless devices. These devices are specifically designed to make wireless-data services come to life. A smart device can be defined as any wireless device, regardless of form factor. It can be a PDA, convergence device, smart phone, or other product. To be defined as a smart device, however, it must consist of a general-purpose microprocessor, memory, and a fully functional operating system.

Every major carrier has launched or has plans to launch higher-speed 2.5G networks (GPRS or 1xRTT). Coinciding with this activity, Microsoft, Symbian (Nokia), and Palm Computing have launched smart operating systems. These OSs are designed to support rich data-oriented applications. Completing the picture, handset makers have launched smart devices based on those smart operating systems. Their devices flaunt 1990s-class processing power, ample memory, rich color displays, and higher-speed network access. They also have enough battery life to support a new class of sophisticated data applications, which was never before possible with basic handsets.

Meanwhile, carriers have teamed up with handset makers to launch smart devices targeted at mainstream users. For example, Orange launched a Microsoft-powered smart phone in the U.K. Called the SPV (sound, pictures, video), it features an impressive 32 MB of Flash, 16 MB of RAM, a SD Card expansion, and a 120-Mhz ARM-based processor. Its 2.2-in. TFT LCD screen displays 176 × 220 pixels and 64,000 colors. The product has a street price of $278 U.S. dollars. Contrast that price tag with the Ericsson T68—one of the best-selling phones in Europe. It launched last year at a street price of $310 U.S. dollars.

Clearly, an optimized hardware platform can be leveraged that delivers compelling wireless-data applications. Yet the software baggage of the past still remains. To fill this gap, a similarly optimized software platform is sorely needed. It should be designed to make integrated wireless-data services easy to use, affordable, cross platform, and easily deployed and managed.

One company that delivers such a solution is Action Engine. It employs techniques that leverage the local processing power of smart devices to improve usability and deliver convenience. These techniques also reduce the costs typically associated with creating, using, and deploying wireless-data services. Subsequently, carriers can now offer more affordable PC-class Web services, which motivate device usage by consumer, mobile-professional, and enterprise users.

TECHNIQUES FOR SMART DEVICES As a precursor to discussing the different techniques enabled by smart devices, it's important to understand the motivation behind them (see "JAVA: Write Once, Test Everywhere?"). The answer lies in the need for a native run-time layer that sits between the application and the operating layer (Smartphone, Pocket PC Phone Edition, Symbian, Java, Brew, Linux, etc.). This thick-client approach enables a number of techniques. Such techniques can significantly reduce network traffic, optimize native device integration, and provide a more enjoyable and easy user experience.

As a developer considering the employment of a native thick-client approach, it is crucial to understand the capabilities that it can provide for an application. Specifically, a native thick-client approach can:

Provide a user interface that is native-optimized for the native-device display capabilities
Provide always-available access to applications and data
Integrate with existing information databases already resident on the device, such as contacts and calendar
Integrate with native applications already resident on the device, like e-mail, SMS, MMS, contact manager, calendar, and the phone dialer
Integrate with the device's network communications capabilities to handle connection management and interrupt scenarios
Integrate with specific chip-set features, such as DSP, memory-management, and power-management capabilities
Provide client-side databases and cache the frequently used information that is shared across all connected applications

In other application approaches, significant parts of a client application reside on a server. Platform-agnostic XML applications can therefore reside entirely on the device. They work independently of the server without a persistent network connection. Developers should strive to perform a majority of the application processing on the device itself so applications can run independently of the server.

Using this technique, users can create information requests entirely offline—without touching the network. Once created, users can review and edit their requests. They can then choose to save them in an Outbox if they have no network access. Or, they can send them to a smart server to be processed via the wireless network.

Network traffic can consist of lightweight, compressed, tokenized XML. It may represent both the request and its associate response containing the requested information. One network connection and client-server roundtrip results in a more efficient use of the wireless network. It also enables faster response times for gaining access to desired information. As an added benefit of creating requests offline, users don't need to worry about losing data or starting over if the connection is lost.

The following points highlight some other specific techniques enabled by the thick-client approach:

Developers can simplify the process of creating data requests by making it possible for users to build their own. This can be done using device-resident data, which is already present or cached on the device (such as contacts). Another approach is to use application-specific information databases, like a list of airports for a travel application. Or, it can be accomplished with frequently used data that is automatically saved and shared across all applications.
In contrast, server-centric approaches require multiple network transactions. The user interface, the actual data needed to build a request, or the associated application logic are all in some way tied to the server. As a result, the network must be used at every step. This approach compounds the amount of time and network traffic required for the user to obtain an answer to his or her request.
Take the graphical images, layout, and formatting information for presenting and rendering retrieved information on the device. Now, store them completely on the device as a part of each application. This method deviates from the others because the information doesn't have to be repeatedly sent across the network. The redundant transmission of this type of overhead results in unnecessary bandwidth usage and frustrating delays for the end user.
On some smart devices, it is possible to detect whether the device is in the cradle or not. By knowing this, developers can then determine if the PC is connected to the Internet. With this information, they can provide optimized content for the connection speed. In addition, they can execute software downloads or updates without using the customers' data "minutes."
Though alerts and notifications are not a new concept, they certainly apply for smart devices. In essence, this technique eliminates the need for a user to "poll" for information or important status updates. A "smart" server can keep track of the various event attributes associated with some data object. It can then push updates down to the client when new information becomes available. Picture purchasing an airline ticket, for example, and then later being notified on your device—via SMS—if the flight is delayed or canceled.
Developers should consider employing industry-standard data-compression techniques to streamline network usage. These techniques work by compressing and decompressing data exchanges between the client and the server in both directions.

BENCHMARKS The table compares the usage of these techniques versus other alternative approaches. The comparisons were performed using a T-Mobile Pocket PC Phone with a 206-MHz Intel StrongArm Processor and 32-MB RAM. The phone had a GPRS wireless connection. The AT&T mMode data was published on AT&T's Web site.

Table 1 compares actual data usage and published performance data (in kB) for the tasks listed. These tasks were accomplished using Action Engine's Mobile Web Services platform versus mobile optimized content, WAP, and a straight Web browser. Figure 1 illustrates the advantage in using a thick-client approach to deliver data.

Taking the cumulative amount of data needed to perform all of these tasks, the thick-client approach reduces data usage by orders of magnitude when compared to alternative methods. When talking about millions of wireless customers, this significantly impacts network performance. It also greatly influences the costs associated with maintaining and pricing data services. And carriers gain additional flexibility and data-usage predictability when pricing their wireless data services. They are in a better position to offer users faster and more responsive services.

WRAPPING IT UP The wireless-data-services market is at a turning point. It is undergoing a revolutionary transformation, which is being driven by newly available smart-device hardware architectures. Because these smart devices have the computing power of a 1990s-class computer, developers have the opportunity to create "real" data applications. Such applications were never before possible in the handheld market.

The good news is that carriers see great potential in these types of devices. After all, they have the ability to deliver on the promise of wireless-data services. Accordingly, carriers are pricing these smart devices to target mainstream users—not just mobile professionals.

Given these developments, the success of data services lies in the hands of innovative software developers. They must be willing to think "out of the box" to take advantage of the powerful capabilities of these new devices. Developers now have greater flexibility to provide carriers—and ultimately the end user—with PC-class Web services that deliver on ease of use, affordability, and compelling value. This combination will drive consistent, day-to-day usage by consumers. The result will be a lifestyle change that is as liberating as the market entry of the personal computer itself. Users will finally be able to take their most important and compelling data with them—or have access to it—anywhere and anytime.