Delivering Content to Handhelds

Content delivery depends on a handheld device's network connection, speed and security, and the type and volume of the content. Pushing a product brief with high-resolution graphics or a software update to a handheld requires more bandwidth than sending a new calendar entry or an e-mail message.

So how do you get enterprise content to PDAs and other handhelds? The answer is to pull and push: Have your customers or clients pull Web pages for purchasing specific products or obtaining service and support, while your organization pushes content to employees and partners who need up-to-date information to sell your products and services or support them in the field. Use mobile application-development tools (such as AppForge's Mobile VB and Antenna Software's A3) to configure your applications to deliver mobile content, and use a content-delivery package.

Keep It Simple

Make sure your users' handheld devices can support push and pull delivery. Although many PDAs come with enhanced resolution, strong processing power and plenty of memory, some still suffer from low-bandwidth connections (28.8 Kbps in some cases), small screens, limited memory and an awkward stylus input method. Some don't even have color displays.

Because handheld devices clearly weren't made for aimlessly surfing the Internet but for getting specific information--driving directions, stock quotes, sales data, support for a system problem at a remote site--you don't want to reproduce your entire Web site for them. Use Web site analysis tools to determine the type of content that different handheld browsers and operating systems require, then prioritize and format that content to fit the target applications and devices. Whether it's an HTML page or XML output from a back-end data repository, deliver the package in small windows and format it to display in tight spaces.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.If you have static Web-site content and a large number of remote employees, clients or partners using handhelds, you can offer an alternative site using WML source code or cHTML. Or you may want to consider using a new content standard for handheld devices: XHTML (Extensible HTML). XHTML is an XML-based language for content that interoperates with HTML 4. You can view, edit and validate XHTML pages with a standard XML tool, and you can use scripts and applets that support the HTML Document Object Model (DOM) or the XML DOM, letting you leverage XML's portability across platforms and applications.

You don't have to recode your entire site for handhelds, however. Instead, there are server-side transcoding services from service providers, portals and software packages such as IBM's WebSphere that translate HTML to WML and other formats on the fly. A transcoding service automatically rearranges content for you, so you will still need to test and tweak the presentation to appear satisfactorily across the specific handhelds used by your customers, clients or employees. A more efficient way to get content to your salespeople or others using handheld devices is to push, or pitch, it to them rather than having them retrieve it from a server. E-mail and SMS (Short Message Service) are popular methods for pushing content to handheld devices. Both store messages while a user is offline and then deliver them when he or she goes online. A subscriber can read e-mail anytime, anywhere, as long as network coverage is periodically available. Neither method requires much bandwidth or device RAM. The user merely turns on the device and content gets pushed and refreshed.

Pushing content is akin to using a subscription service. With a subscription service, content owners or publishers make content available in "channels" to users or subscribers, who need not be connected on a regular basis. A content-dispatcher tool queues content for delivery when the subscriber goes online. The dispatcher creates, manages and sends the content via the subscriber service's channels. This same technique is used by most desktop-management packages and content-delivery mechanisms.

Handheld devices receive content in three different modes: local, pass-through and roaming. A local handheld may be connected to a PC or a laptop via a Bluetooth, infrared serial or USB connection. A desktop e-mail package such as Lotus Notes or Microsoft Outlook receives e-mail and PIM data from a server and then synchronizes it to the handheld device. This is an easy way to deliver data to remote handhelds if their synchronization software supports your enterprise e-mail package, but if not, you may have to find a synchronization tool that can do the job (see "Synch IT," page 92).

With the pass-through method, handhelds receive content through the PC or laptop, and an application on the desktop passes the data to the handheld device. This can be faster than roaming, but only if your remote users can connect their PCs or laptops to the enterprise network via a high-speed serial or direct Ethernet connection. If not, roaming is better.To deliver content to a roaming handheld device, the PDA or other device must be directly connected to the enterprise LAN via a wireless connection or a service provider's network utilizing GPRS (General Packet Radio Service) or CDMA-2000 1xRTT. This tends to be slower than the local and pass-through methods, but it gives mobile users the freedom to get content from any location within the service provider's network territory.

Getting Rolling

If you don't deliver, or push, data to handhelds, or if you've outgrown the local synchronization method using your e-mail package, consider a synchronization software package such as Extended Systems' Mobile Business Solutions and Synchrologic's Mobile Suite. Desktop-management products, such as Novell's ZENworks, meanwhile, manage mobile devices and deliver content, but they don't have the rich features that packages from Mobile Automation and XcelleNet do. These tools deliver content over low-bandwidth connections to devices with minimal memory resources and small display size and resolution. We tried content delivery with XcelleNet's Afaria 5.0 (read our report .

So if you want to empower your remote clients with access to up-to-date corporate information or resources, make sure your content-delivery tool or package gives you secure, fast access to data and applications over spotty networks. Then you can cash in on what the handhelds can do.

Sean Doherty is a technology editor and lawyer based at our Syracuse University Real-World Labs®. Write to him at [email protected].Post a comment or question on this story.

How do you keep data residing locally on a handheld synchronized with the central data store? Use a synchronization package. These tools come with handhelds or you can buy third-party applications such as Pumatech's Intellisync, Extended Systems' Mobile PIM Solutions or Synchrologic's Mobile Suite.

Synchronization can be done one-to-one, one-to-many, many-to-many, or a hybrid of these. The one-to-one setup is the simplest and the most common method--the handheld is connected directly to your PC. All changes made on the handheld are sent to the PC (which is acting as a server), and vice versa.

It gets more complicated when you have to synchronize CRM (customer relationship management) or ERP (enterprise resource planning) application data, for instance, with more than one remote user. In this one-to-many scenario, data on a central server is propagated to multiple handheld devices. These devices then exchange data with the central server. The trade-off: The central server can become a bottleneck and a single point of failure, so you need to build in redundancy and failover features just in case.

Many-to-many synchronization is the most complex. It's like a peer-to-peer network: Each remote user has a client and server on the handheld device, and the client gets updates from other clients. This setup requires more processing power on the device and can lead to confusion in large environments, because you can't tell, for example, if all clients have received an update. This method works best when you have a number of remote technicians out in the field without network connectivity. Each technician updates his or her data with that of other members.Getting content to remote handheld devices is not easy, but there are software packages that can do the job. Desktop management packages from Mobile Automation, Novell and Xcellenet offer both desktop management and content delivery tools. Others, like Appforge (www.appforge.com) and Antenna Software, specialize in mobile applications.

We took Xcellenet's Afaria version 5 for a test drive to see how a desktop management application can deliver content to a handheld device. Afaria has features to publish content and let users push or pull it from central servers, but it lacks synchronization.After a default installation on a Windows 2000 server with IIS, we created a new database on a SQL Server for Afaria. Xcellenet did not include a scripting tool for setting up a database for either Oracle or SQL 2000, but it ships a copy of MSDE (MS Data Engine) to get you started.

Once the database was up and running for Afaria and we had installed the run-time version of CrystalReports that came packaged with Afaria, it was time to create document channels, which contain instructions for exchanging or delivering content to handhelds, like Win32, Palm, PocketPC clients, what specific content and whether to deliver it compressed or encrypted, for example. Aside from handhelds, you can create channels for Windows 98, 2000 and XP-based PCs and laptops. If you deliver a document to a PC or laptop, you can then use a local delivery mechanism such as MS ActiveSync or Palm's HotSync to synchronize it with a handheld device.

Once a device is running Afaria, you can distribute software updates through a distribution channel. You can also distribute other software packages and maintain a catalog of software for each handheld device.

Wherever You May Roam

To see what Afaria could do for roaming clients, we set up a Hewlett-Packard Jornada running PocketPC with a Linksys 802.11b compact flash card. We downloaded the client file from the Afaria server and installed it to the Jornada from a laptop. Then we could run the client application to query the Afaria server for available channels. We used a Web browser to create the channels.Although Afaria channels can also deliver software applications and configure and perform inventory scans on handhelds, we stuck with content delivery. Afaria supports channels for content delivery only to Palm, PocketPC/Windows CE, and Windows PCs. We set up a channel to push Word, text, HTML and bitmapped files to the Jornada, and an alternative channel for other documents that clients could pull from the server.

Document distribution is a one-way affair with Afaria. If you want your clients to edit and return documents to the server, then consider synchronization tools from vendors such as Acuity Software Technologies (www.acuitysoft.co.uk) and SyncML (www.syncml.org). If you want remote handhelds to interact with enterprise applications such as PeopleSoft or SAP, then packages such as Antenna Software's A3 Solution (www.antennasoftware.com) make sense.

As for security, Afaria provides encryption for content distribution with Certicom's Elliptic Curve Cryptosystem for Windows and Pocket PC clients. It also supports SSL, LDAP and Windows NT domain authentication. Afaria's client/server connections also include compression and checkpoint Delivering content to handheld deviceS is not like setting up a Windows share or mounting an NFS file system. You'll need specialized software, such as Xcellenet's Afaria, that not only delivers content but manages handhelds and the applications that run on them. That lets you identify content and place it in a delivery channel configured for specific handheld devices.

Note: Xcellenet's Afaria was Network Computing's Editor's Choice in a competitive review of mobile device management software in 2000. We followed that up and looked at its most recent version 5 in a Sneak Preview.