Order the book from O'Reilly

Previous PageTable Of ContentsIndexNext Page

In this chapter:

 1.  The Palm Solution

Palm Computing has single-handedly defined the handheld market with the PalmPilot and Palm III pocket organizers-people just go nuts over them. The question is why. Why did this little company succeed when so many giants failed? The answer is that they got the magic formula right-they figured out what customers really wanted and how much they were willing to pay for it.

Understanding how to design an application for this platform requires a bit of backpedaling and a look at the history of these devices. Helping you understand that history and what made Palm such a skyrocketing success will help you know how to design good applications for them. We want you to attack the design of your application with the same magic formula that Palm Computing used. Design does not happen in a vacuum. If you ignore the features and characteristics that made Palm a success, your application will bomb.

Why Palm Succeeded Where So
Many Failed

Top Of Page

Not everybody knows that the PalmPilot was hardware born out of software, and not even system software, at that. Its origins are in Graffiti, the third-party handwriting recognition software developed for Newton and other Personal Digital Assistants (PDAs).

In 1994, Palm Computing came out with some handwriting-recognition software that promised accuracy and speed in recognition on PDAs at the price of a little bit of shorthand. Many industry experts thought such software was doomed to fail, as it required too much work from the user. They were proved wrong. Speed and accuracy were more important-Graffiti was able to offer enough to compensate for the relatively minor work required to learn the new strokes.

No One Would Make a Good Enough Device

Buoyed by its success with Graffiti and frustrated by other companies' inability to get the platform right, Palm Computing decided to create its own handhelds. The result was the release of the Pilot 1000 in mid-1996. It and its closely following mate, the Pilot 5000, rapidly made headway. So popular was this product that with the release of its next device 18 months later, the company topped the 1-million-unit mark and clearly dominated the market.

Not only that, but Palm Computing has since been acquired by U.S. Robotics and then again by 3Com. Not to undercut 3Com's new ownership of the Palm OS, but we will continue to refer to the makers of the Palm platform as Palm Computing.

It would be good to stop at this point and ask yourself why this company succeeded when so many other companies failed. How was it alone able to produce a successful handheld? It wasn't experience in hardware design-companies like Apple, Casio, and Hewlett-Packard clearly have more. It wasn't breadth of features-Windows CE and Newton devices have more. It wasn't price-Texas Instruments's Avigo is cheaper. So what does the Palm offer that all these other companies weren't providing? The answer to this question (because Palm Computing figured out what customers wanted) is simple to articulate, but complex to understand. Some insight can be gained by looking at the evolution of Palm devices and their OS relative to other handhelds.

Palm Device Size and Weight

As you can see in Figure 1-1, Palm Computing (and its licensees) has had a steady progression of products.

-Figure 1- 1. A brief timeline of Palm OS products from Graffiti to the Qualcomm pdQ

Each of these devices differs in some respects and remains the same in others. One of the most striking similarities is the size or form factor (see Figure 1-2). What differs is the memory, storage space, and the addition of some hardware features like IR support on the Palm III and barcode support on the Symbol SPT 1500, the Palm device from Symbol Technologies. Indeed, there are only a few changes in outward design between the PalmPilot and the Palm III and even less between the Palm III and the SPT 1500. Compared to the PalmPilot, the Palm III has a slightly tapered base, a little bit larger power button, and a sliding serial port cover, and the two scroll buttons have been folded into one seesaw-type button-minor design changes by anybody's measuring stick. The Symbol device differs from the Palm III only in its slightly increased length (to accommodate the barcode reader) and the two green buttons at the top that are used to activate the reader. Figure 1-2 shows most of these differences, plus the Qualcomm pdQ, discussed later.

Figure 1- 2. Differences in physical design of Palm OS handhelds (from left to right): PalmPilot, Palm III, Symbol SPT 1500, and Qualcomm pdQ

The reason Palm Computing didn't change the original design very much was because it was right from the start. The crucial elements that are essentially the same across the entire product line are size and weight (although the Symbol SPT 1500 is ever so slightly taller and heavier due to the addition of a barcode scanner at the top). From these specs, you can see that Palm designers believe that a handheld has to fit easily into a shirt pocket and rest lightly in the hand. This is especially clear when you evaluate the size and weight of Palm devices relative to those of other handhelds (see Table 1-1).

-Table 1- 1. Specifications of Various Handhelds

Qualcomm's pdQ, a combination wireless cell phone and Palm device, also has the same screen size as other Palm devices. The pdQ has a size of 1.4x6.2x2.6 inches and a weight of 8.2 ounces. This makes it twice as deep, 1.5 inches longer, 0.6 inches narrower, and 2.5 ounces heavier. Given the device's dual functionality, such modifications make sense. Comparing the pdQ in Figure 1-2 to other devices, you can see that it more closely resembles a cell phone than a standard Palm device. What makes this such a nice product, however, is the combination of complementary capabilities. The pdQ is a cell phone with Palm's easy user interface and it has a built-in address book with direct dial functionality.

Palm Device Cost

Moving from form factor to cost, we see another item important in the Palm's success. The price of the units is quite modest compared with other choices (see Table 1-1). It seems that a low entry price is a critical part of the equation in a successful handheld, along with size and weight.

Palm Device Features

The tasks that the handheld accomplishes are the final element in the magic formula of success. Table 1-2 breaks down the various configurations of the original devices from Palm Computing. Note that while there is some variation in memory, there are only a few new feature additions like IR support.

Table 1- 2. Palm Device Specifications

The original Palm Computing built-in applications included Dates, Address Book, To Do List, Memo Pad, Calculator and Password Protection. The PalmPilot added a backlit screen, more memory, and a new built-in application for expenses. The PalmPilot Pro added TCP/IP support, more memory, and a built-in mail application. The Palm III added new IR support and more memory.

From the beginning, Palm devices were extensible by adding applications. Later devices have much more room for third party applications, however.

What Palm OS Devices Don't Have and Why

Almost more important than what Palm OS devices have is what they lack. No Palm OS device has:

Now, reflect for a moment on why this is so. Adding any of these features requires changing the magic combination of speed, size, and price that has made the Palm devices so popular.

A keyboard

Designing a device with a keyboard is a double problem: it radically affects the size, and it changes the types of things a user will attempt to do. If there is a keyboard, a user will expect to be able to enter text easily. But in order to handle a lot of data input, you need a system that can support that type of activity and a processor capable of sorting and displaying it in a responsive way. Once you have both a system and a fast enough processor, the price has crept so high that users go get laptops instead; for just a few dollars more, they get a lot more capability. Windows CE device makers have been learning this lesson the hard way for a long time.

By removing both the keyboard and any real way of handling text input in quantity, Palm Computing kept its focus on what kind of device it was providing. Palm's strategy was to deliberately create a device that was an extension of a desktop computer. Think of the handheld as a "tentacle" (using the metaphor of the creator of the Palm, Jeff Hawkins) reaching back to the desktop. It is a window onto the data that resides on the desktop. Having this sort of window is so useful because it can be taken anywhere. Palm figured out that to be taken anywhere, it has to fit almost anywhere.

NOTE:

There is a really small device called the Franklin Rex, which is no larger than a business card and weighs in at 1.4 oz. It will be interesting to see how successful it is with its input limitation and size advantage relative to the Palm and other handhelds. Watch its progress.

Text recognition software

Besides removing the keyboard, Palm Computing did away with supporting true text recognition. Palm knew from Apple Computer's hard lesson with the Newton (painfully broadcast across the pages of Doonesbury comic strips) that the recognition algorithms were just not good enough. Apple ended up with frustrated people who spent far too much time trying to get their Newtons to recognize what they wrote. Instead, Palm made the nervy choice to ask users to spend a few minutes learning the stroke requirements of Graffiti.

No doubt Apple had many focus group meetings where it asked legions of users the question, "Is it important to you that a handheld device be able to recognize your handwriting?" If faced with this question, users probably universally said yes, it was very important. Palm decided to figure out what users actually wanted instead of what they said they wanted-not always the same thing. Users, it turns out, would rather spend a few minutes learning to write a "T" like "7" than spend three times as much money and have a device take a staggeringly long time to do even the most simple tasks.

An industry-standard PC card slot

Palm devices don't have a card slot, because they couldn't do it and keep the device small and cheap. Palm did install a nonstandard memory card to give users the ability to upgrade the functionality. What the company didn't provide for users was a way to add storage, programs, or updates without being connected to another device (either to the desktop or by modem).

Palm-Sized PCs-Are They Palm Killers?

You can tell that Palm has a successful OS and device strategy because Microsoft has decided to copy it. In this industry you can depend on two things: (1) Microsoft will copy successful products, and (2) prices will drop. What it couldn't accomplish with Windows CE and larger devices, Microsoft is now trying to accomplish with its brand-new Palm-like device. Copying Palm specs almost completely, in January 1998, Microsoft announced a Windows CE-based PalmPC platform. Microsoft later retracted the obvious name ripoff, and the new platform became known as palm-sized PC.

Now these devices are rolling off the assembly line and being compared in the harsh light of reality with Palm devices. Many reviewers of these products ask the question of each new device, "Is it a Palm killer?" The answer seems to be that while each device may have a nifty feature or two, users are better off sticking with their Palm devices. The opinion seems to be pretty widespread that "palm-sized" PCs are no Palm killers.ü

Designing Applications for Palm Devices

Top Of Page

As you can see from the way its handhelds are designed, Palm Computing was convinced that a handheld device will be successful if it is:

These design decisions are only one part of the solution, however. The other part is the software. Palm devices are popular because they contain useful, fast applications and because they are extensible. There were lots of personal organizers before Palm Computing came along. The difference is that those old devices weren't easily extensible-third-party applications couldn't be added. The magic of Palm devices is therefore two-fold. The built-in applications cover a wide range of general activities, giving users access to names, a date book, a to do list, and so on. Crucial, however, is the second part: the platform is also open to other developers. Knowing how important other applications were, Palm provided tools and enough material to gain a wide developer following. These developers, in turn, have added lots of specialized applications. Everybody-Palm, developers, users-benefits.

Essential Design Elements

We spent so much time discussing the history of Palm devices, what makes them popular, and features they don't have because these issues are crucial to your understanding of the design philosophy behind a Palm OS application. These are the essential elements in a Palm application:

But there is all the difference in the world between listing these elements, and you knowing how to design an application using them. Let's address each point in turn.

Designing for a small screen size

As its history has shown, the form factor of Palm devices is absolutely essential. It's small so people can easily take it anywhere. You should assume that this screen size is here to stay. Unlike some other handhelds that have changed size this way and that, Palm devices will keep this form factor for some time. While you might expect to see some integrated devices with a different screen size, these will be for very specific uses and won't necessarily pertain to the design of most Palm OS applications.

The size of the Palm Screen is a mere 160x160 pixels in a 6x6 cm area. The data you present in an application needs to be viewable in this area. Because the area is so small, you will need to break data into parts. While keeping the data in logical groups and relying on different views to show each element will help, you will undoubtedly need to iterate your design several times to get it right.

Look at how the date book handles the presentation of appointments, for example. If the user has a bunch of appointments in a small period of time, that portion of the day is shown. The user doesn't have to scroll through large gaps or look at lots of blank areas. The application shapes the way the data is presented to accommodate a small screen.

Start the design process by mocking up a couple of screens of data. See if the data falls into logical groups that fit nicely in the 160x160 square. If you are requiring your users to continuously scroll back and forth, rethink the organization. Here is the first rule to remember: the screen size drives the design-not the other way around.

If you are continually making the user horizontally and vertically scroll through blank areas, redo your design. Trying to display too much data can require the user to do too much scrolling; too little can require flipping between too many views. You have to find the right balance.

Limit text input on the handheld

HotSync technology makes text input far less necessary on the handheld. The small screen size and lack of a keyboard make text entry difficult. All this leads to an ironclad truth for you to remember-a Palm handheld is not a manual text input device. The user has a nice desktop computer that contains lots of good things to facilitate text entry: keyboards, big screens, and fast processors. A Palm handheld has none of these things. These facts lead to another rule in designing for the Palm OS: data is entered on the desktop, and viewed on the handheld.

Obviously, we are not excluding all data entry or even trying to limit some types. For example, the application we create in this book is an order entry application. In this case, the handheld user is not required to enter text, but instead picks items from lists. This works nicely because picking things is easy, while entering text is hard. It is also clear that there are some very obvious places where users need to enter data on their handheld, such as in the to-do list. Apart from effortless data entry, you should steer your user toward adding data on the desktop.

NOTE:

A great example of effortless data entry on a large scale is finally available with the arrival of Symbol's SPT 1500. With this device, the user has a way to enter data (via the barcode reader) quickly and easily while not sitting at a desktop. It will be interesting to see how this new device shapes the development of applications with text input options on this platform.

Where your app does allow the user to input something, you will need to support the system keyboard, Graffiti input, and cut, copy, paste, and undo in the standard manner as outlined in the documentation. Likewise, you need to support any shortcuts to text entry that the documentation describes. (These are covered in detail in the Palm OS documentation.)

Seamlessly sync

The bold stroke of providing a convenient cradle and an easy-to-manage connection with the desktop has been crucial to Palm's success. Palm engineers designed these devices to exist in a symbiotic relationship with another computer. As a result, an enormously important part of your application is the conduit-this is code that runs as part of HotSync on the desktop and transfers information to and from the handheld. In a symbiotic relationship, both organisms rely on each other for something, and both provide something to the other-just as in our Palm OS application and our desktop conduit.

The conduit will handle communication between the handheld and the outside world. The handheld portion of the app will:

Syncing commonly occurs between the handheld and a corresponding application on the desktop. But syncing is not limited to this model. Here are other scenarios for syncing:

Make the application small

The handheld portion of the application needs to take up as little space and memory as possible, because there isn't much heap space and storage to go around. You must be absolutely ruthless about this to end up with a good design. Trim the size, and keep the number of tasks your handheld application performs to a bare minimum.

Later we will talk about ways to optimize your application programmatically. For now we simply want to get your thinking clear about the tasks of the handheld application and the conduit

NOTE:

We pray never to see an Office/Works type of application on the Palm handheld. Rather than make one application do a bunch of tasks, create different apps.

Make the application fast

Handheld users measure time differently than desktop computer users. One is moving; one is sitting still. Handheld users are usually doing more than one thing-whether that is talking on the phone or walking through a store with a list. Contrast this with the desktop user who is sitting at a desk and will most likely be there for a long time.

The desktop user will wait patiently for an application to launch, in contrast to the handheld user who is on the move. If you make the handheld user wait a minute before your program is ready to use, you won't keep that user. Speed is absolutely critical. This is true not only at application launch time but throughout its use. If you make that process too slow or require flipping between too many screens, your user will give up. The Palm is a lively little machine, so don't bog it down with slow apps.

Always remember that there are enormous problems attempting to do things on a handheld that you could do easily on a desktop computer. It has a pip-squeak processor with no more power than a desktop machine in the mid-1980s. As a result, you should precalculate as much as possible on the desktop. The stack space is so abysmally small that you have to be careful of recursive routines, or large amounts of stack-based data. The dynamic memory is so paltry that your global variable space must be limited and large chunks of data can't be allocated in the dynamic heap.

If that were not enough, the amount of storage is tiny. For that reason, your desktop portion of the application needs to pay attention to which data the user really needs in this sync period. In our order entry application, we should download data only on customers that the salesperson is going to use in the near future. Customers that won't be visited in this time period should be left out.

Rather than bemoaning the sparseness of your programming options, however, you should keep in mind two things: (1) it's a great programming challenge to create a clean, quick handheld application under these conditions, and (2) the very existence of these conditions is why Palm devices are outselling everything around. If you design for the device instead of beating your head against the wall for what you can't do, you'll end up with an application that literally millions of people might want.

Palm Computing has done research indicating that nearly all users are aware that they can load third-party applications on their Palm OS device. About two-thirds of the installed base has gone to the trouble of getting third-party software and installing it on their handhelds. This is an enormous user base for your applications.

User Interface Guidelines

The documentation that comes from Palm Computing contains User Interface (UI) Guidelines. These docs cover everything from which type of UI widget to use for each screen control to exactly where they should be placed relative to each other. Follow them.

NOTE:

Palm Computing provides several volumes of documentation on programming for the Palm OS. While not as wonderful as this book, it is nonetheless very useful. It also has a great price-it's free. You can get the entire set of Windows or Macintosh documentation at Palm's developer site: http://palm.3com.com/devzone.

Designing your application to behave like the built-in applications is also a good idea. For example, if you have an application that needs to display records similar to Names, then copy the format used in the Names application (including the location of items). Palm Computing has provided the source code to the built-in applications because it wants to facilitate your use of them. Mimic them wherever it makes sense.

The guidelines also discuss the display of different views in your application, navigating between views, and how to convey information to the user. Not surprisingly, the guidelines also emphasize the importance of speed and optimizing in your application. You should also check Palm's web site for system updates and the release of new Palm devices.

Elements in a Palm Application

Top Of Page

Now that you know how to design a Palm application, let's describe its two components. After that we will look at how they communicate with each other.

The Two-Part Solution

Most Palm solutions are composed of a handheld application and desktop conduit:

The handheld portion

The portion that resides on the handheld and allows the user to view and manipulate data. Part II, Designing Palm Applications, deals with the creation of this part.

The conduit portion

Here you have code that handles syncing the data with a desktop application. Part III, Designing Conduits, shows you how to create this part.

The handheld portion has an icon that is displayed in the application list. Users will usually use the Palm Install Tool from a Windows or Macintosh machine to install your application (it'll be installed on the next synchronization).

HotSync Overview

When a user puts a Palm OS device in its cradle and presses the HotSync button, the handheld application begins communicating with the desktop conduit. For example, the Address Book has a built-in conduit that synchronizes the address book information on the handheld with the address book information in the Palm Desktop PIM. If a new entry has been made in either place, it is copied to the other. If an entry has been modified either place, it is copied to the other. If an entry has been deleted in one place, it is usually deleted in the other.

Third parties provide other conduits that replace the Address Book conduit so that the device's address book synchronizes with other PIMs (Microsoft Outlook, for example). You'll usually want to write a conduit for your application's database that will upload/download information in a manner appropriate for your application.

For example, the Expense conduit reads the expense information from the handheld, fills in a spreadsheet based on the information, and then deletes the information from the handheld. From the users' point of view, this is ideal; they get their information in a standard, easy-to-use form: a spreadsheet on the desktop. The Palm OS application doesn't have to worry about creating reports; its only purpose is recording expense information.

If you don't want to write your own conduit, then a backup conduit is provided. It backs up any database that:

NOTE:

There have been four different Windows versions of HotSync shipped to users (1.0, 1.1, 2.0, and 3.0). You'll probably want to target HotSync 1.1 or later. It's also reasonable to target HotSync 3.0, since it is available by download from http://www.palm.com.

Summary

Top Of Page

In this chapter, we have described Palm devices, the circumstances that governed their design, and the history of Palm Computing's success with this combination. Then we discussed application design in light of the devices' history, design, and future directions. Last, we discussed the important elements in a Palm application and gave you some rules to help you in application design.


* The built-in applications common to all Palm devices are Address Book, Date Book, To Do List, Memo Pad, Calculator, and Security.

ü For an interesting set of reviews on product comparisons, check out PCWeek's web site, http://www.zdnet.com/pcweek/, where electronic versions of their reviews can be found.

Palm Programming: The Developer's Guide
Copyright © 1999, O'Rielly and Associates, Inc.
Published on the web by permission of O'Rielly and Associates, Inc. Contents modified for web display.

Previous PageTop Of PageTable Of ContentsIndexNext Page