Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Delivering Content to Handhelds: Page 2 of 7

Dedicated applications that run on handhelds typically operate in an always-on (connected) query-response mode, or they synchronize the handheld's data with back-end resources and let the user work offline. The key is to keep the query-response data short and the time between synchronizations long. This way, users get fresh content quickly over slow connections and can display it on their devices or work offline easily.

It can be awkward to surf and navigate a Web site with a handheld device. A PDA, for instance, typically comes with limited memory, processing power and storage. So when you configure your pull architecture for delivering content, you should present data in a small window and limit user navigation to a few simple stylus clicks. Bottom line: Serve up only Web content that won't tax the bandwidth, memory or processing power of a handheld device. That means limiting page sizes to 30 to 50 KB, eliminating unnecessary graphics files and removing any JavaScript, style sheets and multimedia content. Even with powerful handhelds sporting Intel 400-MHz processors and 802.11b network interfaces, you're at the mercy of a service provider's network, where bandwidth may dip well below 1 Mbps. And you're limited by the handheld's RAM, which may range from 8 to 64 MB.

Configuring a pull architecture with HTML is no picnic either. An HTML document requires a default window of approximately 80 characters--nowhere near a handheld device's screen capacity of 10 to 20 lines of text deep by 20 to 40 characters wide for displaying text or graphical bitmaps.

To set up your content for handheld devices to display, you can use one of the three main languages for wireless devices to reformat the content: WML (Wireless Markup Language), HDML (Handheld Device Markup Language) or cHTML (Compact HTML), depending on what the target devices' minibrowsers support. Palm's Neowar minibrowser, for instance, supports WML but offers only limited support for HDML and HTML.

WML is an XML-based language and uses its own scripting language, WMLScript. Both WML and HDML present information in groups of data sets. A "card" is the basic data element that houses a screenful of information, and when a minibrowser requests data, cards are downloaded to the handheld device. There's no browsing; it's a transactional approach in which the cards let users navigate using data-entry boxes or via lists of options, such as to drill down to a sales forecast or price quote, using WAP (Wireless Application Protocol). (See www.w3schools.com/wap/wap_demo.asp for an example of WML source code displayed on a Nokia 7110 via WAP.)

But there are other ways to deliver content. Most minibrowsers support cHTML (sometimes called iHTML, or i-mode HTML), which uses NTT DoCoMo's i-mode protocol. Developed for mobile-phone communications, i-mode is used primarily in Japan, but its use is increasing worldwide. And cHTML is simpler to use than WML, because it is a subset of HTML, without JPEG images, tables, image maps, style sheets and other code. So it's bandwidth-friendly and can support tight displays.