Documentation  |   Table of Contents   |  < Previous   |  Next >   |  Index

2    Fitting In

Palm OS® User Interface Guidelines

Palm OS® 68K SDK

In the previous chapter, you learned what makes the Palm platform unique, and you learned a process by which you can design a successful user interface for the Palm Powered handheld. This chapter documents the next step: making sure that your application integrates well with the Palm Powered handheld environment.

When users work with a Palm OS® application, they expect to be able to switch to other applications, have access to Graffiti® writing and the onscreen keyboard, access information with the global Find, receive alarms, and so on. Your application will integrate well with others if you follow the guidelines in this chapter. This chapter covers:

User Interaction with Palm Powered Handhelds ^TOP^

Before you begin designing an application, you need to understand the different ways that users interact with their Palm Powered handhelds:

  • Graffiti writing
  • Onscreen keyboard
  • HotSync® operations
  • External keyboards
  • Hard keys on the handheld
  • Icons in the Graffiti area
  • Controls in the application

This section covers each of these methods in more detail.

Graffiti Writing ^TOP^

Graffiti characters are written in the text area on the digitizer (see Figure 2.1) and appear on the screen at the cursor location. The user specifies the cursor location by tapping directly on the screen with the stylus.

Figure 2.1  Graffiti area

Onscreen Keyboard ^TOP^

When the insertion point is in a text field, the user can open the onscreen keyboard by tapping on the letters "abc" or "123" in the lower corners of the Graffiti area. The keyboard dialog appears (see Figure 2.2).

Figure 2.2  The keyboard dialog

The dialog displays any text currently in the field that contains the cursor. The user can then add to or modify the text as necessary.

HotSync Operation ^TOP^

To enter data into a Palm OS application, users can enter data into the corresponding application on the desktop computer and then perform a HotSync operation. The data is loaded into the appropriate application on the Palm Powered handheld.

Hard Keys ^TOP^

A Palm Powered handheld contains a minimum of four hardware application buttons (known as hard keys) plus two scroll buttons and a power button (see Figure 2.3). Some handhelds contain other hardware controls, such as a brightness or contrast adjust button or a jog wheel.

The four application buttons launch built-in applications such as Date Book, Address Book, To Do List, and Memo Pad. The exact list of applications launched by hard keys depends on the model.

Figure 2.3  Hard keys

Icons in the Graffiti Area ^TOP^

The four icons on either side of the Graffiti area (see Figure 2.4) display the Application Launcher, the current application's menu, the Calculator application, and the global Find facility. Some Palm Powered handhelds, such as handhelds sold in Japan, may have additional icons in this area.

Figure 2.4  Icons

External Keyboard ^TOP^

Many Palm Powered handheld models can accomodate an external keyboard. The keyboard attaches to the serial port. When it is attached and the appropriate software is installed on the handheld, users can type on the keyboard to enter text in any text field. They can also perform keyboard navigation such as tabbing to the next and previous fields.

Because external keyboards are an optional item priced separately, do not rely on your users having one. Instead, allow all lengthy data entry to be performed on a desktop computer.

Application Controls ^TOP^

The final way that users interact with their Palm Powered handhelds is by tapping the pen on controls in an application. Application controls are introduced in the section "Controls" and described in more detail in the rest of this book.

Integrating with the Application Launcher ^TOP^

The Application Launcher (see Figure 2.5) is the screen from which most applications are launched. Users navigate to the Launcher by tapping the Applications icon in the Graffiti area. They then launch a specific application by tapping its icon.

To integrate well with the Application Launcher, you must provide application icons and a version string as described in the following sections. In rare cases, you might need to provide a default application category as well.

Application Icons ^TOP^

Provide two icons for the Launcher: a large icon for the icon view (see Figure 2.5) and a small icon for the list view (see Figure 2.6). Choose a short application name and an icon that's easy to recognize.

Figure 2.5  Application Launcher icon view

Make sure that the large icon has an identifiable center so that the user knows where to tap. It's best, although not required, if the large icon is circular or has a circular background like the ones shown in Figure 2.5. The circular element is usually removed for the small icon.

Figure 2.6  Application Launcher list view

Make sure your icons blend well with the icons for the built-in applications in addition to presenting the marketing message your company wants to project. For example, using a 3-D style icon would not blend well with the icons for the built-in applications.

For further guidelines on presenting graphics on Palm Powered handhelds, see Chapter 8, "Color and Graphics."

Version String ^TOP^

Provide a short (usually 3 to 7 character) string that gives your application's version number. This version string is contained in the application's resource file. It is not the version you provide to the PalmRez post linker. This string is displayed in the Info dialog (see Figure 2.7).

Figure 2.7  Launcher info

A version string should have the format:

major.minor.[stage.change]

where major is the major version number, minor is a minor version number, stage is a letter denoting the development stage (a for alpha, b for beta, or d for developer release) and change is the build number. Remove the stage and change numbers for the final release.

Default Application Category ^TOP^

Launcher divides applications into categories. If you specify a default application category in the application resource file, the Launcher places your application into that category when it is installed. If no application category is specified, the application is installed into the Unfiled category, and each user chooses where to file the application.

Most applications should not specify a default application category. Only specify one in these instances:

  • Your application is intended for consumers and clearly belongs to one of the Launcher predefined categories (see Table 2.1).
  • Your application is intended for a vertical market or you've created a suite of custom applications that work together to provide a complete custom solution.

    In this case, you might define a custom category name. Launcher creates the category if it doesn't already exist in the Launcher database.

Table 2.1 Launcher predefined categories 

Default Launcher Category

Description

Games

Any game

Main

Applications that would be used on a daily basis, such as Date Book or Address Book

System

Applications that control how the system behaves, such as the Preferences, HotSync, and Security applications

Utilities

Applications that help the user with system management

Unfiled

The default category

Do not treat the default application category as something analogous to the Microsoft Windows Start menu category. On a Palm Powered handheld, the user is limited to 16 categories including Unfiled. Obviously, that limit would be quickly reached if each application defined its own category. Besides, placing your application in its own category only makes it harder to find and launch. Only assign a default category where it is a clear benefit to your users.

General Application Layout Guidelines ^TOP^

This section provides a general outline of what a Palm OS application looks like. The remaining chapters in this book provide more specific guidelines for the look of individual controls.

Main Application Forms ^TOP^

On Palm Powered handhelds, each screen of information is called a form. In general, the first form in your application is a base form that offers an overview of all available information and command buttons for the most frequently used commands. For example, the Address Book shows a list of all contacts (see Figure 2.8).

Figure 2.8  First form in Address Book

Applications with a base form tend to also need one or more details forms to display more information about a record and to allow the user to edit the record (see Figure 2.9). Many applications use a single form for both purposes. Address Book uses two different forms for display and edit because many of the available fields in the Edit form are often left blank. Using a separate form to display a contact means users are more likely to see the information they need without having to scroll.

Figure 2.9  Detail forms in Address Book

For more detailed guidelines on creating all types of forms, see Chapter 3, "Forms."

Controls ^TOP^

Controls allow the user to perform commands, enter options, and edit data. Table 2.2 shows the basic controls you might provide in your application and lists the chapter in this book that provides guidelines for the control.

Table 2.2 Controls 

Control

Name

Main Purpose

For More Information

Command button

Perform command

Chapter 4, "Executing Commands,"

Check boxes

Toggle state

Provide list of options that are not mutually exclusive

Chapter 5, "Presenting Options,"

Field

Display or edit text

Chapter 6, "Displaying Data,"

List

Display text

Chapter 6, "Displaying Data,"

Menu

Perform command

Chapter 4, "Executing Commands,"

Pop-up list

Display a list of mutually exclusive options

Chapter 5, "Presenting Options,"

Push buttons

Display a list of mutually exclusive options

Navigate to new view

Chapter 5, "Presenting Options,"

Scroll bar

Scroll the display

Chapter 7, "Scrolling,"

Scroll buttons

Scroll the display

Chapter 7, "Scrolling,"

Selector trigger

Display setting that user can change from modal form

Chapter 5, "Presenting Options,"

Slider

Adjust a setting

Chapter 5, "Presenting Options,"

Table

Display data

Chapter 6, "Displaying Data,"

Control Placement ^TOP^

Place the most frequently accessed controls near the bottom of the form. The user interacts most often with the Graffiti area, with the icons in the Graffiti area, and with the hard keys on the handheld. Placing controls at the bottom of the form puts them as close as possible to the Graffiti area, making them quicker and easier to access.

People from Western cultures tend to read the screen from top to bottom and left to right. Therefore, anything important for users to read (rather than interact with) should be near the top of the form. Horizontally, you should arrange controls so that the leftmost control is the most important.

Do not clutter the screen. Running out of space is a usually a sign that simplification is needed. Squashing a lot of controls on the form by reducing white space is usually the wrong answer.

In most cases, use spacing instead of lines and boxes to separate user interface elements into logical groups. Lines and boxes add to screen clutter and actually make the small screen harder to read.

Labels ^TOP^

Provide a label for any control or option that requires further explanation. Right justify the labels and left justify the fields (see Figure 2.10).

Figure 2.10  Label guidelines

Use bold font and title capitalization for labels. That is, capitalize the first letter of each important word in the label in the same way you would capitalize the title of a book. For example, use "Set Date" as a label, not "Set date." Never use all lowercase ("set date") or all uppercase ("SET DATE") for labels.


NOTE: This guide uses the term label to refer only to a textual label that appears outside of the user interface element. Sometimes, the text appearing inside the user interface element is also called a label. This guide refers to the text inside the user interface element as its contents. For example, "Daylight Saving:" is the label for the pop-up list in Figure 2.10. The word "Off" is the pop-up list's contents.

Fonts ^TOP^

Palm OS supports four different fonts: 9 point regular, 9 point bold, 12 point regular, and 12 point bold.

Use 9 point regular for the textual content of most controls, such as the text that appears inside of command buttons, pop-up triggers, and selector triggers.

Labels like those shown in Figure 2.10 should be shown in 9 point bold font.

When displaying textual data, consider allowing users to set the font they would like to use. The standard font picker dialog resource included in the system allows the user to choose between 9 point regular, 9 point bold and 12 point bold.

You can also create your own custom font and include it in the system. Use a custom font only for displaying textual data. Don't use a custom font for labels or text inside of controls. For example, a document reader might show the document text in a custom font, but it should still use the system fonts for control contents and labels.

Graphical Controls ^TOP^

The command button and push button controls allow you to substitute a graphic for the button name.

Only use graphics on buttons if there is a common, clear precedent in similar desktop applications that you can leverage. For example:

  • Web browsers use similar arrow buttons for browsing history.
  • Document readers often use arrows to move to the next page.
  • Most desktop applications use a a clipboard to denote paste, scissors to denote cut, and so on.

If there is not a clear precedent, avoid creating your own graphical symbol for a command. It's difficult to make a graphic small enough to be useful while clearly conveying its meaning. Desktop applications often have several graphic buttons, but desktop applications often rely on tool tips to help the user learn what each graphic means. Palm OS does not provide tool tip support (see Figure 2.11).

Figure 2.11  Graphic buttons

For more information on creating graphics for Palm OS, see Chapter 8, "Color and Graphics."

Custom Controls ^TOP^

Palm OS supports the creation of custom controls, called gadgets. You can create your own gadget if you have a need that the user interface guidelines don't address. Your gadget must support the general design principles outlined in Chapter 1, and your users must be able to intuit how to use it.

Some examples of gadgets include:

  • Launcher uses a gadget to display the current battery level.
  • Date Book uses a gadget for the main portions of its week view and month view forms (see Figure 2.12).
  • A medical application might use a gadget that displays an outline of the human body so that users can tap to record where they are injured.

Figure 2.12  Date Book gadget

Application Categories ^TOP^

Organize your application's database records into user-defined categories if that makes sense. Categories usually result in more efficient screen use. Users can switch between categories using a pop-up list or can display all records at once.

Categories are application-specific and are stored with the database. An application can have a total of 16 categories, including the Unfiled category. Users are allowed to create categories and are allowed to decide which records belong in which categories.

Your application can provide a set of predefined categories. Limit the number of categories you predefine so that your users are free to create categories that make sense to them. If you do provide predefined categories, allow your users to delete them so that they can add new ones. The Unfiled category must be one of your predefined categories. Do not allow users to delete the Unfiled category.

Provide a category pop-up list in the title bar of the base form to allow the user to change which category of records are displayed (see Figure 2.13).

Figure 2.13  Category pop-up list

Applications typically have a Details dialog that allows the user to change uncommonly accessed parts of a database record. The Details dialog is typically where you place controls to change the category. If your application has a form that edits a single record, you can also supply a selector trigger on that form that displays a pop-up list from which the user can select a record's new category. See "Selector Triggers" for more information.

If your application does not support categories but you still want to use the right side of a title bar for a pop-up list, that pop-up list must contain category-like information that filters the display. It should not perform some other operation. For example, a spreadsheet application might show a pop-up list in the title bar that allows the user to display a different worksheet if the spreadsheet has multiple worksheets.

General Application Behavior Guidelines ^TOP^

This section covers general guidelines for how applications should behave:

The remaining chapters in this book provide more specific guidelines for the behavior of individual controls.

Launching the Application ^TOP^

Your application must launch quickly. The typical user session with a Palm Powered handheld is one or two minutes long. Users do not want to add an extra several seconds to each session waiting for an application to launch.

During a normal launch, you should not display a splash screen. You might display a splash screen if this is the first time the user launched the application or if the application is running as a demo that will eventually expire and you want to show how much time is left.

You do not necessarily display the base form when users launch your application. Do so only if it makes sense. It's often better to return to the place the user exited last. For example, Memo Pad always returns you to the memo you were last reading.

Displaying the location where the user exited is desired because it creates a seamless interface. If you make your application behave like the user never exited, users can think of all Palm OS applications as running at the same time.

Exiting the Application ^TOP^

Applications do not provide an exit command. On the Palm Powered handheld, users do not think in terms of exiting one application and then launching another. The paradigm is such that they consider all applications to be running at once and they can move between them at will. Users move between applications by pressing one of the four hard keys on the handheld or by tapping the Applications icon.

Allow the user to exit any form, including modal dialogs or alert dialogs, gracefully at any time. If the user has been editing data, save the data before the user exits the form. If the user is in the middle of editing a database record when the form is exited, your application should allow the user to exit the form and perform the least destructive operation on the data.

The built-in applications define a minimum set of data that must be present for the record to be saved. In most cases, it is one character of data. In the Expense application, the expense type must be set.

For example, suppose you are editing a contact in Address Book, and you need to look something up in another application. You can tap the Applications icon and launch another application without losing your data. Address Book saves the changes you have made even though you have not tapped the Done button at the bottom of the screen. When you return to Address Book, you see the main form, and the record you last edited contains your changes (see Figure 2.14).

Figure 2.14  Address Book with partial record

In certain vertical market applications, it is both possible and acceptable to write your application so that it never exits. This is an acceptable practice only as long as the application is preloaded onto the handheld for each user and the handheld will never be used as a personal digital assistant.

Supporting Global Find ^TOP^

Support the global Find facility (see Figure 2.15) if your application stores textual data in a database. The Find facility should perform a prefix-only case-insensitive search on each word in a database record. A prefix-only search finds matches only if a word begins with the string the user enters. For example, suppose an application contains two records, one with the text "And Then There Were None" and the other one "How To Use a Lathe." If the user enters the word "the," the Find facility will find matches in the words "Then" and "There" in the first record, but not in the word "Lathe" in the second record.

In many applications, a user can mark a record as private. A private record is stored in the database but may not be displayed. If your application supports private records, make sure that the records are unavailable to the global Find facility when the user has them hidden or masked.

Figure 2.15  Find

Respecting User Preferences ^TOP^

Palm OS has system preferences for the display of:

  • Date formats
  • Time formats
  • Number formats
  • First day of week (Sunday or Monday)

Be sure your application uses the system preferences for display of this type of information.

Palm OS also provides standard panels that can be used to select a date, a starting and ending time, or just a single point in time. If your application works with dates and times, use these standard panels. Users are familiar with their usage from the Date Book and Preferences applications.

Palm OS preferences also allow users to remap the hard keys and icons in the Graffiti area so that they launch different applications. Respect the user's preference for which application to launch; however, you can help the user override the preference. For example, suppose you provide a replacement for the Date Book application and you would like the Date Book hard key to display your application. You can display an alert dialog upon startup that asks the user if they want to remap the Date Book hard key so that it launches your application. If they tap the OK button, your application can change the preference. If they tap Cancel, you should not ask the question again, but it is acceptable to provide a user preference that allows the user to remap the button at a later time.

Allowing System Messages ^TOP^

Allow the system to post these messages:

  • Alarms
  • Low-battery warnings
  • System messages during synchronization

The normal event loop used by virtually all Palm OS applications allows ample time for the system to post messages and handle necessary events. You only need to take special care if your application performs a lengthy computational task. For example, if your application has a large database with greater than 20,000 records and it must search through each of these database records, you might want to check for system events every so often during this loop.

Becoming Compatible Worldwide ^TOP^

If you're planning to localize your application, it's best to plan for localization starting from the beginning. Keep in mind the issues listed below:

  • Try to leave extra room for translation. Many languages simply take up more space than English does. German and French words, for example, are on average 25% longer than their English counterparts. Try to allow extra space for strings to display and larger modal forms than the English version requires.
  • Be aware that items such as colors and symbols also need to be localized. For example, red is a warning color in English, but that is not true in all cultures. Avoid colors and symbols that may be offensive in other cultures.
  • Dates and numbers are represented differently in other parts of the world. Always respect the user preferences that have been set for date, number, and time displays.
  • Abbreviations may be the best way to accommodate the particularly scarce screen real estate on the Palm Powered handheld.
  • Consider using string templates. For example, the Memo Pad application uses the template: Memo # of %. The application can replace # and % to change the text. Use as many parameters as possible to give localizers greater flexibility. Avoid building sentences by concatenating substrings together, as this often causes translation problems.
  • Remember that user interface elements such as lists, fields, and tips dialogs scroll if you need more space.
  • Write your code so that the application is easily localizable. For coding guidelines, see the chapter on localization in the Palm OS Programmer's Companion.