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:
Small (fits into a shirt pocket)
Inexpensive (doesn’t cost more than a few hundred bucks)
Able to integrate seamlessly with a desktop computer by placing the handheld in a convenient cradle
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.
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.
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 160 × 160 pixels in a 6 × 6 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 160×160 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.
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.)
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:
Offer the user data viewing anytime and anywhere
Allow the user to somewhat modify the data or arrange it differently
Do tasks with as few taps as possible
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:
A conduit can transfer data from the handheld to and from a corporate database that exists on a remote server.
A user might fill out a search form on the handheld that the conduit would read and use to do a Web search. The search result would then be transferred back down to the handheld for the user to view.
A conduit could sync the Address Book to a web-based Personal Information Manager (PIM). Thus while the data may reside far away, the web-based storage ensures that this information is available to a user who travels anywhere in the world.
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
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.
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.
Get Palm Programming: The Developer's Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
