We need the athletic client: a client that can use the power and bandwidth available

Software Magazine, Summer, 2002 by Iain Gillott

The wireless device client is too thin and needs more horsepower.

For the last ten years or so, the accepted bottleneck in the wireless data experience has been limited bandwidth. The cry has been for more bandwidth and more speed. While the cable modem and DSL experience has shown that users can never get enough bandwidth, the wireless networks have been severely bandwidth constrained.

Things are changing, though. Wireless LAN "hot spots" are sprouting seemingly everywhere, from Starbucks to Admirals Clubs and schools. Just a few weeks ago, we experienced the latest Express network connection and devices from Verizon Wireless here in Austin. Using cdma2000 lx, the Verizon Wireless network gave us about 50 Kbps on a handset, PDA and laptop, and over 400 Kbps with compression on a laptop. E-mail, imaging, graphics, audio and video downloads become reality at these speeds.

Many mobile operators fear that the majority of devices lack sufficient horsepower to make use of the new network's increased capabilities. In short, the industry is moving the bottleneck from the air interface to the device. While a laptop will always have sufficient memory and processor power to effectively use available bandwidth, the number of laptops on wide-area wireless networks is very small. As mobile handsets get smaller and more attractive, the laptop is increasingly seen as "luggable" rather "portable."

In the Wide Area Protocol (WAP) age, the thin mobile client was all the rage. Following the lead of desktop Internet devices, manufacturers raced to put thin client browsers on all of their devices. Mobile handsets receiving text messages, small images and cartoons are now all the rage in many parts of the mobile world.

But we do not need 400 Kbps connections to download pictures of Britney Spears--DoCoMo's much-copied I-mode service uses a packet data connection of just 9.6 Kbps to enable many basic multimedia applications.

For the enterprise and business user, however, things are a little different. Many enterprise applications can easily consume bandwidth. And most were designed with the ubiquitous desktop in mind.

Application-development languages such as Java and Brew allow the mobile device to do more than simply make phone calls or send messages. And many newer mobile devices are arriving with great screens and embedded wireless connectivity (such as the AudioVox Thera shown here). Processor speeds of 206 MHz are common) with promises of 400 MHz within 12 months. Memory also is becoming less of a problem. Compact Flash and microdrives promise up to 1 GB on a PDA or smart phone within a year.

So what is needed now is a client environment on the mobile device that can use the power, bandwidth and memory available. Mobile clients are thin in the extreme and some would say they are almost anorexic. While we do not need to emulate the truly fat software environments loaded onto desktops and laptops, we need something in between. Hence the "athletic" client--a client that has the power, grace and speed to do what is required in the mobile environment, but can still make efficient use of the space available.

And just as an athlete requires a custom-fitted suit, our mobile client is unlikely to be based on existing designs. WAP worked on small-screen devices with limited memory. Full browsers work on laptops and desktops. For the new generation of PDAs and smart devices, we need something in between.

If the industry does not respond (and I believe it will), then the billions invested in new networks will effectively have been wasted. Given the current constraints on capital investment, that would be both a monumental shame and a waste.

Iain Gillott is the founder of iGillottResearch, a market strategy consultancy focused on the wireless and mobile communications industry, offering a range of services for IT buyers and suppliers. For more information, visit www.igillottresearch.com. E-mail the author at iain@igillottresearch.com.