This chapter describes user interface elements that display data. They often comprise the bulk of a user interface. These elements are:
The first section tells you how to choose which of the elements listed above is best for your application. The rest of the chapter describes behavior and appearance guidelines for each element.
Choosing Which Element to Use
To display data, you can use fields, tables, or lists. Fields are good for allowing free-form entry of text and for displaying large documents. Tables and lists display columnar lists of data.
Text fields can display long documents or a single line of text. The Memo Pad Edit form shown in Figure 6.1 is a good example of using a field to display and edit a document.
Figure 6.1 Multi-line text field

The Address Book Edit form uses single-line fields for each part of a contact' s information (see Figure 6.2).
Figure 6.2 Single line text fields

Use a table to display a list of items if those items represent the primary data of your application. Tables can show either a single column of text or multiple columns containing text and other user interface elements (see Figure 6.3).

A list user interface element is a box that generally displays a textual single-column list (see Figure 6.4) although it can be modified to display multiple columns or graphics. The user cannot directly edit the items presented in the list.

Use a list for information that is secondary in nature and that is primarily static. Some examples of places where a list element is appropriate are:
- The Edit Categories dialog uses a list to display categories because they are a secondary form of information.
- An application that shows the time of day in various cities could show the possible cities in a list element because the primary data of the application are the times of day.
- A document reader application could show the titles of available documents in a list element because the primary data are the contents of the documents themselves, not the list of titles.
For more information on choosing between a table and a list, see "Choosing Lists Over Tables".
Fields
Fields (see Figure 6.5) can display one or more lines of text. Fields can be either editable or non-editable.
Figure 6.5 Multi-line text field

or font height + 2 (single line) Make multi-line fields as tall as possible. Use a multiple of the line height (font height + 2). |
|
Usually requires label to tell user what to write in the field |
System Supplied Behavior
Palm OS® provides the following support for fields:
- Insertion point positioning. When the user taps in an editable text field, Palm OS displays a blinking cursor at that location.
- Text selection. The user can drag the stylus to select a range of text. On Palm OS 3.5 and later, the user can also double-tap a word to select that word or triple-tap to select the entire line.
If the field is scrollable, the user can drag the stylus past the edge of the field, and the system scrolls the field in direction indicated.
- Display of text using a single font. You cannot, for example, display three words of text and have the second word be bold.
- Word wrapping for multi-line text fields.
- Maximum character limit. You can set a maximum number of characters for an editable text field. If the user enters more than the maximum number of characters, the field stops accepting input.
NOTE: The maximum characters attribute is actually the maximum number of bytes that the user can enter. In some encodings, characters are larger than one byte. Consider this when setting your field's maximum characters.
Palm OS does not support overstrike input mode (that is, overwriting text to the right of the cursor), horizontal scrolling, or numeric formatting for text fields.
Look and Feel
Follow these guidelines for the behavior and appearance of fields.
Editable Fields Have Dotted Underline, Are Left Justified
Fields that are editable should use a dotted underline to indicate that the field can be edited. Do not use a solid underline.
Virtually all editable fields should left-justify the text contained in them. Constructor for Palm OS allows right-justified fields, but you should only use right justification for numeric fields or for non-editable text fields that you use as labels.
You can place an editable field anywhere on a form except in the title bar area.
Edit Menu Required
Any form containing an editable text field must contain an Edit menu. See the section "Edit Menu Required for Text Fields" for more information.
Graffiti Shift Indicator Required
Any form containing an editable text field must contain a Graffiti Shift Indicator. Most modeless forms have the Graffiti Shift Indicator positioned as shown in Figure 6.6.
Figure 6.6 Graffiti Shift Indicator placement (modeless form)

This placement leaves space for the scroll buttons if the form uses them. Even modeless forms that use a scroll bar instead of scroll buttons place the Graffiti Shift Indicator at this location. If you have so many controls at the bottom of the form that the Graffiti Shift Indicator cannot be placed 17 pixels in from the right, leave 4 pixels of white space between the Graffiti Shift Indicator and the control to its left.
On modal forms, place the Graffiti Shift Indicator as shown in Figure 6.7. It's rare for modal forms to have both a Graffiti Shift Indicator and scroll buttons, but if yours does, place the Graffiti Shift Indicator 4 pixels to the left of the scroll buttons.
Figure 6.7 Graffiti Shift Indicator placement (modal form)

Table 6.2 Graffiti Shift Indicator details
If you place a Graffiti Shift Indicator on your form, Palm OS correctly displays all of the Graffiti shift states (punctuation, symbol, uppercase shift, and uppercase lock). For Japanese systems, the Graffiti Shift Indicator also indicates whether the front end processor is on or off and whether it converts to Hiragana or Katakana characters.
Enable Auto-Shifting for Most Text Fields
Turn on the auto-shift attribute for all editable text fields unless the field should not accept any uppercase letters. The auto-shift attribute is a convenience for your users that automatically capitalizes the first word in the field and the first word after a sentence. Do not enable auto-shifting if the field contains information that is not routinely capitalized, such as an email address.
Note that the auto-shifting rules are language-specific, since capitalization differs depending on the region. These rules depend on the Palm OS version, the market into which the device is being sold, and so on.
Set the Focus When the Form Is Displayed
When a form containing a text field is displayed, set the focus in the text field so that it shows the blinking cursor. Users can then start writing immediately without having to tap the text field first. If the form has more than one text field, set the focus in the first field. For example, the Address Book Edit form places the focus in the Last Name field (see Figure 6.8).

Decide if Single-Line Fields Should Grow
Wherever possible, you should make the text field wide enough to display its maximum number of characters. If it's not possible, consider growing the field as needed. For example, the User Name field in the Network Preferences panel grows if the user enters a very long name (see Figure 6.9). All other controls on the form are adjusted downward.
Figure 6.9 Field that resizes as text grows

If you absolutely cannot allow the user to enter more than a single line of information, turn on the single line attribute. If this attribute is not set, the user can accidentally enter a carriage return in the field and keep writing. If the field does not resize with the carriage return, the user may not know that they've entered extra information in the field.
Add a Scroll Bar to Multi-Line Text Fields
If you have a multi-line text field that accepts a large number of characters, add a scroll bar to support scrolling the text field. See Chapter 7, "Scrolling," for guidelines on scrolling.
Limit the Amount of Required Data Entry
When designing your form, remember that most users only have the Graffiti power writing software and onscreen keyboard available to enter data. For this reason, you should try to limit the amount of data you require users to enter in a text field. Wherever possible, consider helping the user by providing pop-up lists instead of text fields, by auto-completing text the user enters in the field, and so on.
Support Graffiti Navigation and Tabbing between Fields
Support the Graffiti navigation characters on forms containing several text fields that the user might fill out in succession. Although most users do not take the time to learn the Graffiti navigation characters, power users know them and appreciate interfaces that allow them. See Table 6.3 for a list of the Graffiti navigation characters.
Table 6.3 Graffiti navigation keystrokes
![]() |
|
![]() |
|
![]() |
|
![]() |
Also consider that users may fill out your form using an external or built-in keyboard. These users expect that pressing the tab key will move the cursor to the next field and that pressing the shift and tab keys will move to the previous field. Support this functionality where possible.
Validate After Text Is Entered
If your application needs to perform data validation on text entered into a field, provide a Done command button and validate all text fields when the user taps the button. It's tempting to perform validation as soon as the text is entered; however, doing so is a poor design decision for Palm OS.
Suppose the user receives a phone call in the middle of entering data and needs to schedule an appointment with the caller. If the user has made a mistake entering data in the current field and you do not allow the user to exit your form until the mistake is corrected, the user could become extremely frustrated. It's better to preserve the data as the user has entered it and allow the user to exit immediately. When your application is relaunched, display the data entry form with the partially entered data. Validate only when the Done button is tapped.
Breaking the Rules
Text fields normally do not belong in the command button area, but you can place a field in this area if it allows the user to navigate the view. The Address Book application's main form uses such a text field (see Figure 6.10).
Figure 6.10 Text field in command button area

Lists
A list (see Figure 6.11) provides a box with a list of choices to the user. The list is scrollable if the choices don't all fit in the box.
In Palm OS, a list element associated with a pop-up trigger is called a pop-up list. This section describes lists that don't pop up. See "Pop-Up Lists" for guidelines for pop-up lists.

System Supplied Behavior
Palm OS supplies the following behavior for every list.
Pen Interaction
Tapping a list item unhighlights the current selection and highlights the item under the pen. Dragging the pen through the list highlights the item under the pen. Dragging the pen above or below the list causes the list to scroll if it contains more choices than are visible. If the pen is otherwise dragged outside the list, the selection is unchanged.
Scrollable Lists
If there are more choices than can be displayed, the system draws small arrows (scroll indicators) in the right margin next to the first and last visible choice. When the pen comes down and up on a scroll indicator, the list is scrolled. When the user scrolls down, the last visible item becomes the first visible item if there are enough items to fill the list. If not, the list is scrolled so that the last item of the list appears at the bottom of the list. The reverse is true for scrolling up. The scrolling hard keys on the handheld perform the same behavior. Scrolling doesn't change the current selection.
Look and Feel
Follow these guidelines for the behavior and appearance of lists.
Always Show Current Selection
The list should always show the current selection when the form containing it is first opened. Suppose the user opens a form containing a list with twenty items, scrolls the list to the bottom, selects item fifteen, and dismisses the form. The next time the user opens the form, the list should still be scrolled to the bottom and item fifteen should be selected.
Present Items in a Logical Order
Position list items so that the most useful items are near the top. For example, if you are presenting a list of times of day, start the list with the most active part of the day, such as 8:00 AM. Do not start with midnight.
Use a Scroll Bar for Large Lists
Although lists come with their own scroll indicators and handle scrolling automatically, you can suppress the display of these indicators programmatically and attach a scroll bar to the list instead (see Figure 6.12). You should consider doing so if the list is the main element on your form and it contains a large number of items. The scroll bar is preferred for large lists because the scroll bar provides an indicator of location. See Chapter 7, "Scrolling," for more information.
Figure 6.12 List with scroll bar

Breaking the Rules
This section points out a few applications that break the list guidelines and tells you if doing so was appropriate.
Choosing Lists Over Tables
Lists and tables are not interchangeable. A list always displays a box around its contents. This box conveys that the information inside of it is secondary to some other type of data in the application.
Many application developers shy away from using tables because of the degree of programming difficulty involved. Instead, they use a list element because lists are easier to work with programmatically (see Figure 6.13).
Figure 6.13 Improper use of a list

The form shown in Figure 6.13 is an early design of the main form of the Books application described in Chapter 1, "Palm OS Application Design." This application's primary purpose to catalog the books that a person owns. The book titles displayed in the form are thus the main data of the application and should be displayed in a table.
There are ways to programmatically suppress the drawing of the box around the list. As long as your application suppresses the list's border and scroll buttons so that it looks and feels exactly like a table element would, then you may use a list element instead. Note that you can use lists to simulate multi-column tables as well as single-column tables.
Tall Lists
If you use as much of the data area of a form as possible to display a list, the list can show eleven items maximum. This can be problematic if you have a list with twelve items. You hate to make your users scroll just to reach the last item in the list.
The Set Time dialog shown in Figure 6.14 has this problem. The minutes list has exactly twelve items. To show all twelve items, the list has encroached on the command button area of the form. The list containing the hours was resized to match. To make room for these lists, two command buttons were moved from this area to the left side of the form.
Figure 6.14 List in command button area

Another possible approach to this problem would have been to have each of the two lists show only eight items because it's likely that a user is scheduling appointments during an eight-hour work day. This would have made room for all four buttons at the bottom of the form.
The designers of this form weighed the two possible approaches and decided that it is easier for the user if he or she can see all possible choices for the minutes field at once. This usability factor outweighed any other considerations on control placement guidelines.
You'll probably not run into a similar situation when designing your interface. If you do, avoid mimicking this interface without clearly considering the trade offs involved. Grow the list into the command button area only if you believe the possible user benefits of doing so clearly outweigh any other design considerations.
Tables
Tables (see Figure 6.15) are a convenient way to display a set of data and organize that data into one or more columns.

System Supplied Behavior
Tables are highly configurable objects. The system supplied behavior depends heavily on the type of table you create. Palm OS supports the use of certain user interface elements in the table, namely editable text fields, check boxes, and pop-up lists. Palm OS ensures that these elements work exactly as they do when they appear outside of a table.
If the table displays non-editable text, Palm OS ensures that the text is highlighted when the pen is down in the bounds of the table item and unhighlighted when the pen is released. Note that only a single item is selected. Palm OS does not support the selection of an entire table row.
Look and Feel
Tables do not have borders or column headings because the short-term clarity is not worth the long-term loss of space. From a user interface standpoint, there are two types of tables: tables that allow direct editing and tables that don't.
The To Do List main form (see Figure 6.16) is an example of a table that allows direct editing. To create a new item in the list, you tap the New command button. From there, you can directly enter the text of the task, assign its priority and due date, and check the box when the task is done.
Figure 6.16 Table with direct editing

The Address Book list view (see Figure 6.17) is an example of a table that doesn't allow direct editing. In such a table, you must decide what happens when the user taps an item. In most cases, the application should display a form that edits the data in that item.
Figure 6.17 Table without direct editing

As stated previously, Palm OS only allows selection of a single table item at a time. Your application must be designed so that each item selection has a different and unique purpose.
Consider the table in the Address Book list view. This table has two columns, but they might not be the columns you think they are. The first column displays both the contact name and phone number or email address. The second column is a very narrow column that displays the note icon if a contact has a note attached to it. Tapping an item in the first column displays more information about the selected contact. Tapping an item in the second column (even if the item is blank) displays the Note form, in which users can enter a free-form note about the contact.
If you have a similar display, you'll probably be tempted to show the contact name in one column, the phone number in a second column, and the note icon in a third column. Such an interface is appropriate only if tapping the phone number performs a different function than tapping the contact name. If tapping either the name or the phone number takes the user to the same form, both the name and the number should highlight at the same time.