This chapter describes the different types of forms available. Forms are analogous to windows in a desktop application. They are containers for control and data objects. There are two basic types of forms:
There are also several special cases of modal forms:
This chapter tells you how to choose which type of form to use and then describes behavior and appearance guidelines for each type of form. The form types are covered in order from most commonly used to least commonly used.
Choosing between Types of Forms
Most applications should use more modeless forms than modal forms. Modeless forms are full-screen forms that are the primary screens in your application. Modal forms are sub-forms used for a specific purpose.
Each application must have at least one modeless form, and most applications have more than one. For example the Address Book offers a main form that shows a list of contacts, an Address View form that shows the details for a single contact, and an Address Edit form that allows you to edit the contact information (see Figure 3.1).
Figure 3.1 Modeless forms in the Address Book

Modal forms (see Figure 3.2) are often shorter than the screen. They typically display only a few controls.

Use Modal Forms Sparingly
Reserve the use of modal forms for instances where a user must acknowledge a certain state before they can continue. Some acceptable uses of modal forms are:
- Setting options, such as application preferences
- Editing data that is changed rarely. For example, marking a record as private is an infrequent operation. The built-in applications place the control for this on a modal form.
- Editing commonly used parts of a database record if the rest of the record does not consist of discrete fields.
For example, a Date Book appointment consists mainly of text, the name of the appointment. Setting an alarm for that appointment is common, but the alarm appears in the Details modal form with the uncommon fields because there is no room for it elsewhere. If your data consists of discrete fields similar to Address Book, it's better to edit all commonly used parts of your records in a single modeless form.
Avoid Modal Forms for Lengthy Data Entry
Avoid the use of modal forms for lengthy data entry. Sometimes, applications that perform data validation display a series of modal forms, one stacked on top of the other. Avoid creating such a user interface. If, for example, you require a user to create a record by displaying three different modal forms, this requires a minimum of six taps: one tap to display each of the three forms, and one tap to dismiss each of the three forms. It is better to allow users to navigate between data entry forms at will, and it is better to have as few forms as possible.
If your application needs to perform data validation, it is tempting to use a modal form and not allow the user to leave the form until the record is complete and validated. Doing so is a poor design decision that may result in user frustration. The user may be distracted in the middle of entering the data. Suppose the user receives a phone call and needs to schedule an appointment with the caller. If you don't allow the user to leave your application without validating the data, he or she must cancel the data entry operation to schedule the appointment and re-enter all of the data later.
Instead, consider having your application behave in a similar manner as Memo Pad. Define a minimum set of data that must be present. If the user leaves the application in the middle of editing a record, save the record without validating it as long as that minimum data has been entered. When the user returns to your application, restore the edit form and restore the record that was previously being edited. Validate the data only when the user taps the Done button at the bottom of your form. If you have a corresponding desktop application, your conduit will have to check for and handle the case where a data record has not been validated. Your conduit can skip that database record and log the reason why it has not been synchronized.
Modeless Forms
A modeless form is the main GUI area of your application. Most forms are composed of a title bar at the top of the screen, an area for viewing or entering data, and one or more command buttons at the bottom that navigate to other forms (see Figure 3.3).
Figure 3.3 Modeless form parts

Table 3.1 Modeless form details
System Supplied Behavior
Palm OS® supplies the following behavior for every modal form.
Always Full Screen
The currently displayed form takes up the entire screen and remains on the screen at the same location until the user chooses a new form. It's not possible for the user to resize, move, or collapse a form.
Keep in mind that screen sizes of future Palm Powered handhelds may vary. The Sony Clie already has a different screen resolution (320 X 320 pixels) than other Palm Powered handhelds although its screen is still the same size as other handhelds. The HandEra 330 has introduced the ability to rotate the display and the ability to collapse the Graffiti® area. If the user collapses the Graffiti area, there is more space available to the application.
Only Topmost Form Is Active
Only one form has the input focus at a time. This form is called the active form. If one form is drawn on top of the other (as is the case with modal forms), the topmost form is active until it is closed. Then the previous form becomes active.
Form Navigation
To navigate to another form, the user does one of the following:
- Taps one of the controls in the current form.
- Taps an icon in the Graffiti area that displays another application.
- Presses a hard key that navigates to another application.
Look and Feel
Follow these guidelines for the behavior and appearance of a modeless form.
Limit Form to a Screenful of Information
Try to ensure that a form contains only one screenful of information. However, if it does not make sense to break the information into multiple forms, a form can be scrollable. For example, the Launcher form is scrollable so that it can show all of the installed applications. The Address Edit form is scrollable so that you can edit all fields in a contact entry on a single form.
Use Title Bar to Orient the User
The title bar shows the title of the form flush left with the screen. If the form displays a database that uses categories, information about the category is flush right with the screen. Forms that display multiple records show a category pop-up list that can be used to filter the display. Forms that allow editing a single record display a selector trigger that allows you to change the category for that record. (See Chapter 5, "Presenting Options," for more information about selector triggers.) The Palm OS draws a 2-pixel line on the border between the title bar and the data area. Figure 3.4 shows example title bars.

The purpose of the title bar is to orient the user. From a quick glance at the handheld, the user should be able to recognize the current application and current form within that application. Applications often look alike, so most should display a title bar that gives the name of the application followed by the name of the form. The Address Book follows this guideline, as shown in Figure 3.4.
The title bar can also provide extra information. The Mail application shows how many messages there are in the current mailbox. (See Figure 3.5.) The Address Book shows an icon that indicates when the user's business card is being displayed or edited.
Figure 3.5 Extra information on title bar

Title Bar Controls Are Primarily Informational
You can place controls in the title bar. The Date Book application shows a control that allows the user to select a day of the week. It is best if controls in the title bar are primarily informational in nature, that is, if they are the type of control that the user seldom changes. Keep in mind that users interact mainly with the Graffiti area of the handheld, which is below the bottom of the form. If your controls are in the title bar, users must move their hands as far away from the Graffiti area as possible. It is better to place the more commonly accessed controls near the bottom of the screen.
If your application does not support categories but your title bar has a pop-up list on the right side of the screen, that pop-up list must display category-like information that filters the display. Do not use this space for a pop-up list that has a purpose other than filtering the display.
Games Should Have Title Bars
On Palm Powered™ handhelds, even games have title bars (see Figure 3.6). The title bar makes an excellent location to show the game status: the score, current level, and so on.
Figure 3.6 A title bar for a game

Breaking the Rules
This section points out a few of the applications that break modeless form guidelines and tells you if doing so was appropriate.
Nonstandard Title Bars
If the form's data area is so distinctive that it cannot be mistaken for another application, you may use the title bar to display something other than the application and form name. However, the information in the title bar still should orient the user.
For example, the Date Book main form (see Figure 3.7) uses its title bar to show the current date, the day of the week, and controls that allow users to navigate to a different date. It can do so because the main form is clearly an appointment calendar for a certain date. The user would gain little if the Date Book showed a title that said "Date Book Day View" and had the current date and the day selection controls below the title bar.
Figure 3.7 Other orienting information in title bar

In rare circumstances, the title bar may be skipped altogether, but only if the form cannot possibly be mistaken for some other application and the user could not be confused about its purpose. The Calculator application does not display a title bar (see Figure 3.8). This provides more room for the numeric display area and the buttons, allowing for buttons large enough to be tapped with fingers instead of the stylus.
Figure 3.8 Modeless form with no title bar

Note, however, that if users see a title bar, they expect to see some form of a title, whether it is the current date or time or the title of the form. Resist the temptation to include the title bar but omit the title in favor of adding other controls to your application (see Figure 3.9).
Figure 3.9 Bad example of title bar

The Note view (see Figure 3.10) used in Address Book, Date Book, and To Do is another example of a modeless form that breaks the title bar rules. In this case, you should never follow its example. The Note view shows a dark background for the entire length of the title bar and centers its title rather than left-justifying it. This makes the Note view look like a modal form without a border.
Figure 3.10 Bad example of title bar

The Note feature was designed early in the development of the Palm OS and its built-in applications. It uses the name of the appointment, contact, or task as its title. At the time, it was thought that left-justifying the title made the form look strange. In retrospect, there were several better ways to solve this problem without breaking the guidelines. It would be better to make the Note view a modal form to underscore that this form simply changes one field in a database's record, or to use a modeless form whose title began with the word "Note."
Modal Forms
A modal form, or dialog, is a sub-form that is used for a specific purpose. Modal forms are displayed on top of the current form. Modal forms have a different title bar style than modeless forms, and they have a border (see Figure 3.11).
Modal forms should be far less common in your application than modeless forms. Their main use is for setting options, such as application preferences.

System Supplied Behavior
The Palm OS ensures that the topmost modal form is the only form that receives pen down events or keystrokes. The user cannot, for example, click the main form's title bar to dismiss a modal form. Also, the global Find facility is not available while a modal form is displayed.
Look and Feel
Follow these guidelines for the behavior and appearance of a modal form.
The User Can Exit at Any Time
You must allow the user to exit the application by tapping an icon in the Graffiti area or pressing a hard key even while a modal form is displayed. When you create the modal form, you specify a default button. If the user exits the application without tapping a button on the modal form, the application behaves as if this button were tapped. The default button should be the one that results in the least destructive action. Typically, this is the Cancel button, but in some cases the OK button is least destructive.
Make Modal Forms as Short as Possible
Although modal forms are always the width of the screen, they are not always the height of the screen. It's best to make the modal form shorter than the screen so that the main form, appearing below the modal form, provides context. Try to make the modal form as short as possible. Allow at least 3 pixels of space between the main form's title bar and the top of the modal form. If the modal form obscures any portion of the main form's title bar, make the modal form the full size of the screen. (See Figure 3.12.)
Figure 3.12 Full screen modal form

Always align the modal form with the bottom of the screen. Modal forms align with the bottom of the screen for two reasons. First, it allows the main form's title to be visible, providing more context for the user. Second, it places the modal form's controls closer to the Graffiti area.
Buttons on Modal Form
Most modal forms have an OK button in the bottom left and a Cancel button immediately to its right. They may have other buttons aligned with these buttons as necessary (see Figure 3.11).
If the modal form performs more than one action, use a Done button to dismiss the form rather than OK and Cancel. For example, you might beam more than one application from the Launcher's Beam form (see Figure 3.13). In this case, a Cancel button does not make sense because you can't cancel a beam after it has finished. The OK button is renamed Done in this case because users tap the button to indicate that they are done beaming applications.
Figure 3.13 Modal form with Done button

Edit Menu Required if Form Has a Text Field
If the modal form has an editable text field, you must associate a menu bar with it, which should contain the Edit menu at minimum. This allows support for the copy and paste shortcut keys. The menu always displays from the top of the screen (see Figure 3.14).
Figure 3.14 Menu on modal form

A Graffiti Shift Indicator is required as well as an Edit menu for forms with editable text fields. See "Fields" for more information.
Breaking the Rules
This section points out a few of the applications that break modal form guidelines and tells you if doing so was appropriate.
Modal Forms Without OK Button
Your modal form may exclude the OK button if it helps minimize the number of required taps. Most modal forms have more than one control or have a text field. The OK button is required to let the application know when the user is done entering information. However, consider the Go To Date form in Date Book (see Figure 3.15). This form is dismissed as soon as the user has tapped one of the dates. Because choosing a date is the only purpose of the form, the OK button has been removed.
Figure 3.15 Modal form with no OK button

Modal Forms that Don't Exit
It's possible for a user to miss a modal form entirely. Suppose the user becomes distracted immediately before the form is displayed, the handheld powers off, and then, to turn it back on again, the user presses one of the hard keys. The hard key dismisses the modal form by simulating a default button tap.
In most cases, the default button should protect the user from any unintended consequences of not seeing the modal form. For example, if the form was a Delete confirmation dialog, the default button would be the Cancel button, so not seeing the modal form is not destructive.
If a default button is not enough protection for the user, you can create the modal form such that it is not dismissed until one of its buttons is explicitly tapped. Usually, this is only the case when the form presents vital information to the user. The low battery alert dialog, for example, must be explicitly dismissed because its intent is to inform the user of impending data loss. The Date Book alarm dialog and the Attention Manager dialog (see Figure 3.16) also must be explicitly dismissed because they present information that the user has requested to see at a specific time. If the user were to miss this information, it would be more annoying than having a dialog that must be explicitly dismissed.
Figure 3.16 Attention Manager dialog

Alert Dialogs
An alert dialog is a special case of a modal form. Alert dialogs are used in specific instances and have more rigid rules about appearance. Alert dialogs have no other controls on them besides the command buttons used to dismiss the alert (see Figure 3.17). They display an alert icon and a message.

Table 3.3 Alert dialog details
Types of Alerts
Use an alert dialog to display an error condition, to prompt the user for a response, to inform the user of an event, or to warn the user of an upcoming event (such as low battery level).
Table 3.4 describes the four possible types of alerts, when to use them, the icon to display on each, and an example message.
Look and Feel
Follow these guidelines for the behavior and appearance of an alert dialog.
The User Still Can Exit at Any Time
The rules for an alert dialog's behavior are the same as those described in "Modal Forms." Specifically, you must allow the user to press a hard key or tap an icon in the Graffiti area to exit the application while an alert is displayed. If so, your application behaves as if the default button on the alert were tapped. You specify which button is the default when you create the alert.
Title Describes Operation That Caused Alert
The title of the alert dialog should describe the operation that the user was trying to perform. For example, alert dialogs about the beaming operation have "Beam" in the title bar. An alert dialog about deleting an address from the Address Book is titled "Delete Address."
Message Is a Complete Jargon-Free Sentence
The message you display should be a complete sentence. It should describe the problem in plain language and, where possible, describe how to correct the problem. It should not contain computer jargon. "Disk full" is an example of a poor alert message. Palm Powered handhelds do not have disks, and users may not know what a disk is. A better message would be "The storage area is full."
Buttons Directly Answer Question
If the dialog simply displays a message, it should have a single button named "OK". If the dialog asks a question about how to proceed, avoid using generic buttons such as "Yes" and "No" or "OK" and "Cancel" wherever possible. When users are provided a message such as "Save data?" with buttons "Yes," "No," and "Cancel," they are often confused about which button to choose. Instead, it is better to make the affirmative answer to the question more explicit. Repeat the verb of the message (see Figure 3.18). If the message is "Delete this record?" the buttons should be "Delete" and "Cancel," making it clear that choosing "Delete" deletes the data. Resort to "Yes" or "No" only if the alternative is cumbersome. The confirmation alert "Make this address your business card?" uses "Yes" and "No" buttons for this reason.
Figure 3.18 Alert dialog buttons

Use Attention Manager for Reminders
If your application must remind the user of a particular event similar to the way the Date Book reminds users of appointments, use the Attention Manager dialog (see Figure 3.19) on Palm OS 4.0 and later releases rather than displaying an alert dialog. To use the Attention Manager, you don't create an alert dialog resource. You write code that tells the Attention Manager what text to write in its dialog. The Attention Manager displays all current and past due reminders in a single dialog.
Figure 3.19 Attention Manager dialog

In earlier releases, each application that reminded the user displayed a separate alert dialog for each reminder. Most users have run into the situation where they have had their handheld turned off all day, turn it on, and are presented with a series of alert dialogs about appointments that have passed. The Attention Manager displays a single dialog so that the user can dismiss all past reminders at once. It also has the ability to perform non-visual reminders such as playing sounds or vibrating the handheld.
The Attention Manager is only designed for attempts to get attention that can be effectively suspended. It is not suitable for the following:
- Anything requiring an immediate response, such as the "put away" dialog that is used during beaming or a request to connect to another user
- Error messages
- To Do List items or incoming email messages
Breaking the Rules
If you want any other control on the alert dialog, you must create a modal form rather than an alert dialog. Use the alert icons on the modal form to make it look more like an alert dialog. Figure 3.20 shows an example of a modal form that behaves as an alert dialog. In this way, the dialog can include a check box that allows the user to archive the deleted record.
Figure 3.20 Modal dialog disguised as alert

If your application runs only on Palm OS 3.5 and later, you can create an alert dialog that has a text field on it. You can use this, for example, to have a user enter a password to confirm the operation.
Progress Dialogs
Despite your best efforts, you may find that some lengthy operations cannot be avoided. For example, if you need to connect to a network or use the serial or infrared ports, there is no way to make a connection happen more quickly. In these cases, use a progress dialog (see Figure 3.21) to indicate that an action is taking place.

Table 3.5 Progress dialog details
The progress dialog has a bitmap and a message that are updated periodically to indicate that the operation is progressing. For example, when you beam a business card to another Palm Powered handheld, the Beam progress dialog shown in Figure 3.21 toggles between two beaming bitmaps and updates the message in the following order: "Initializing," "Starting," "Searching," "Connected," and "Sending."
Progress dialogs dismiss themselves when the operation completes, so they do not include an OK or Done button. They do have a Cancel button so that the user can cancel the operation.
The purpose of using a progress dialog is to placate the impatient or unknowing user who may believe that the handheld has crashed. The progress dialog informs the user of what the system or application is doing. If your task does not have multiple steps and if it takes more than one second but less than three seconds to complete, you may instead use a simple Please Wait form centered in the screen. The Launcher uses such a form while it gathers database information when you choose the Info menu item (see Figure 3.22). However, as with progress dialogs, the Please Wait form is to be avoided if at all possible. Use it rarely if at all.

NOTE: Do not display the Please Wait form for more than a few seconds. If you do, the user will still believe that the handheld has frozen.
About Dialogs
Use the about dialog (see Figure 3.23) to display the version number and copyright notice for your application. All applications should have an about dialog. The about dialog must be accessible from the Options menu on the main form. Its title is "About application" where application is the name of your application. It has an OK button centered on the form and no Cancel button.

Table 3.6 About dialog details
The about dialog should contain the following types of information:
- Copyright notice
- Version number
- Terms of usage: Can your program be copied? Is it freeware, shareware, or commercial software?
- Registration information, such as the user's license number if they have paid or the amount of time remaining on the demo if they have not paid
- A phone number or web site where they can go for support
Tips Dialogs
Tips dialogs (see Figure 3.24) are displayed by modal forms when the user taps the "i" button in the corner of the modal form.

The tips dialog provides further assistance to a user who is wondering how to use a particular modal form. It is a good idea to associate a tips dialog with most, if not all, modal forms in your application other than progress or about dialogs.
The tips dialog should briefly describe each field on the form, the purpose of each field, and any special symbols on the form. Some tips dialogs also tell the user about shortcuts that are otherwise hidden. For example, in Address Book a user can attach a note to a contact by tapping to the right of the contact's information in the list view. The user learns this if he or she reads the tips in the Address Book Details dialog.
There is little or no formatting to the string that you supply for the tips dialog. You cannot, for example, change fonts or add a graphic to the tips. You also cannot change the dialog's title.
TIP: It's common to show a bulleted list in the tips dialog. To type a bullet in Constructor for Palm OS, set the string so that it shows all characters as hexadecimal, type "95", and then deselect the "View as Hex" option.
Tips dialogs should only contain necessary and useful information. Because of the compact nature of the text presented in the dialog, this dialog is not a good venue for providing users with conceptual background material they might need to know to use your application effectively. Such information is best presented in an external user manual, not on the handheld itself. Tips dialogs also are not a place for extra information, such as programmer credits that you might see in an about dialog.