ACCESS | Fitting In

In the previous chapter, you learned what makes the Palm OS^® 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 or Graffiti 2 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 or Graffiti 2 Writing ^TOP^

Graffiti characters or, on newer models, Graffiti 2 characters are written in the input 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.

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 input area. The keyboard dialog appears (see Figure 2.2).

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 usually contains 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.

Icons in the Input Area ^TOP^

The four icons on either side of the input area (see Figure 2.4) usually 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. Others use a star icon in place of the Calculator icon and let the user choose the application that it opens.

External Keyboard ^TOP^

Many Palm Powered handheld models can accommodate 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 input 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.

Make sure that the large icon has an identifiable center so that the user knows where to tap. Your icons should blend well with the icons for the built-in applications in addition to presenting the marketing message your company wants to project. The icons for the built-in applications follow these guidelines:

• The large icon has a blue circle in the background. On low-resolution screens, the circle is solid and 22 pixels wide by 22 pixels high. On high-resolution screens, the blue circle has a one-pixel anti-aliased blue border with a two-pixel white circle inside and then a solid blue circle in the center. The icon is the same physical size as the low-resolution large icon.

• On top of the circle, the main element is skewed 30 degrees. For example, the Date Book application shows a calendar skewed 30 degrees in addition to a a clock at the normal angle.

• If the icon has a drop shadow, it should be shown as if there is a light coming from the top-left corner of the screen.

The small icon does not contain a circular background. The built-in applications typically take the skewed element from the large icon and show it at a normal angle.

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).

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).

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.

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
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 input area, with the icons in the input 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 input 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).

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.

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.

When creating your own custom font, remember to support both low-density and high-density screens. The high-density fonts are the same size as the low-density fonts, but they use the extra pixels to draw more smoothly and thus are easier to read. See the Palm OS Programmer's Companion for more information on creating fonts for multiple screen densities.

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:

• 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).

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.

• 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.

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).

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^

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).

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.

Respecting User Preferences ^TOP^

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 input 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^

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.

2 Fitting In