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

7    Scrolling

Palm OS® User Interface Guidelines

Palm OS® 68K SDK

Palm OS® provides two controls that can scroll other controls:

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 between Scroll Bars and Scroll Buttons ^TOP^

To scroll form content, such as tables, lists, fields, or bitmaps, you have your choice of scroll bars or scroll buttons. Scroll bars appear on the right side of the screen (see Figure 7.1).

Figure 7.1  Scroll bars

Scroll buttons are arrows that appear at the bottom of the form (see Figure 7.2).

Figure 7.2  Scroll buttons

When choosing between scroll bars and scroll buttons, consider the following:

  • Will users want to scroll a line at a time?

    Scroll bars support scrolling both a line at a time and a page at a time. Scroll buttons scroll a page (one screenful of information) at a time.

    For most multi-line editable text fields, most users want both modes of scrolling available, so multi-line text fields should always use a scroll bar. For other user interface elements, either scroll bars or scroll buttons will do if scrolling a page at a time is sufficient.

  • Do you need an indicator of location?

    Scroll bars provide a good indicator of the location of the data within the database (that is, whether the user is viewing the beginning, end, or middle of the data). Although scroll buttons show when the user is at the beginning or end of the data, they give no indication of how far until the beginning or end when the display is somewhere in the middle.

    Because scroll bars are the better indicator of location, you should use scroll bars as long as you can sacrifice seven horizontal pixels of your data. If there already is a fairly clear indicator of location and you can't sacrifice the space, use scroll buttons. For example, the Address Book list view is sorted alphabetically, so users typically know where they are within their own data. Address Book uses scroll buttons so that it can display more of the contact's phone number or email address (see Figure 7.3).

Figure 7.3  Showing location

  • Will your target audience be able to navigate using a scroll bar?

    Scroll bars are tiny targets for the pen, making them difficult to use in certain situations. Your target audience may have difficulty using scroll bars if they use your application while in a car, on a train, or if they are older. Because scroll bars are on the right side of the screen, left-handed users often can't see how far they've scrolled. They become annoyed with applications that rely entirely on scroll bars.

    If a significant percentage of your target audience is mobile or older, you may decide that they are better supported by scroll buttons. However, users are often satisfied as long as they can use the scrolling hard keys on the handheld. If you want to use scroll bars, just be sure to support the scrolling hard keys as well.

  • Do you display any right-justified data?

    If you display any controls on the right edge of the screen, you probably are better off using scroll buttons. Otherwise, a user who aims for the scroll bar and misses might mistakenly tap your control.

    For example, the rightmost column of the Address Book list view is a control. The user can tap this column to enter a note about the current contact. If the Address Book were to have a scroll bar immediately to the right of this column, the user might mistakenly tap the note column when aiming for the scroll bar.

Scroll Bars ^TOP^

A scroll bar scrolls the display of another user interface item (see Figure 7.4). Scroll bars can be attached to multi-line text fields, tables, lists, or forms.

Figure 7.4  Scroll bar

Table 7.1 Scroll bar details 

Dimension

Value

Width

7

Height

Height of element that the scroll bar scrolls

Top

Align with top of element to be scrolled

Left

153

Border

None

System Supplied Behavior ^TOP^

A scroll bar has four values that determine its behavior:

  • The minimum value, which is typically 0.
  • The maximum value, which is often not set until run time. This value is the number of lines it should take to scroll to the end of the element, which is computed with the formula:

number of lines of textpage size + overlap

where number of lines of text is the total number of lines or rows needed to display the entire object, page size is the number of lines or rows that can be displayed on the screen at one time, and overlap is the number of lines or rows from the bottom of one page to be visible at the top of the next page.

  • The initial value, which is usually the same as the minimum.
  • The page jump value, or the amount by which the value is increased or decreased when the user scrolls. This should be at least one less than the number of lines that can be displayed at one time to provide context. That is, if the field can display ten lines of text, the page jump value should be nine.

Palm OS ensures that the scroll bar does not appear until there is more than a screenful of information to be presented. It also ensures the behavior described in Table 7.2.

Table 7.2 Default behavior of scroll bars 

When...

Then...

User drags scroll car

Scroll car moves in the direction indicated

User taps scroll arrow

Scroll car moves up or down an amount that indicates a single line

User taps in gray area immediately above or below scroll car

Scroll car moves up or down by an amount that indicates a page

User drags in a text field beyond the edge of the text field

Scroll car moves up or down along with the text

The system does not scroll the user interface element to which the scroll bar is attached. Your application's code must do that.

Look and Feel ^TOP^

Follow these guidelines for implementing a scroll bar.

Vertical Scroll Bars Only

Palm OS only provides support for scrolling vertically. Horizontal scrolling is not supported.

Support Immediate Mode Scrolling

There are two scrolling modes possible: immediate mode and non- immediate mode. In immediate mode scrolling, the scrolling happens as the user drags the pen. This is preferred because it allows the user to see how far the field is moving. Non-immediate-mode scrolling waits until the user lifts the pen before scrolling the display.

Support the Scrolling Hard Keys

You should always allow the scrolling hard keys on the handheld itself to scroll any user interface element. They should have the same effect as tapping the gray area above and below the scroll car. That is, they should scroll up and down a page at a time.

Breaking the Rules ^TOP^

Because Palm OS does not support horizontal scrolling, you should avoid creating a user interface that requires it. In most cases, users do not expect to have to scroll a display horizontally. Web browsers, however, often must support horizontal scrolling to support Web pages with large graphics or large tables.

Scroll Buttons ^TOP^

The scroll buttons are two arrows that appear at the bottom of the screen (see Figure 7.5). If the user taps the arrow with the pen, the form scrolls in the direction indicated. If the user holds the pen down on an arrow, the form repeatedly scrolls in the direction indicated.

Figure 7.5  Scroll buttons

Table 7.3 Scroll button details 

Dimension

Value

Width

13 pixels

Height

8 pixels per button

Top

144 for up button

152 for down button

Left

147

Font

Symbol 7

Contents

0x01 for up button

0x02 for down button

Border

None

System Supplied Behavior ^TOP^

Palm OS ensures the following:

  • The button highlights while it is being pressed.
  • The scroll buttons don't appear until there's more than a screenful of information to display.
  • The up arrow is grayed out when the first screenful is displayed.
  • The down arrow is grayed out when the last screenful is displayed.

The system does not know what user interface element is to be scrolled; therefore, your code must inform the system when there is more than a screenful of information to display, when the top of the data is displayed, and when the bottom of the data is displayed. If your application informs the system of these conditions appropriately, you'll see the behavior described above.

Also note that your application's code is responsible for actually scrolling the display.

Look and Feel ^TOP^

Follow these guidelines when implementing scroll buttons.

Always Show a Screenful of Information

Screen space is so limited that you should always show users as much of their data as you possibly can. For this reason, you should always adjust the scrolling so that a full screenful of information is displayed.

Suppose your form has a table containing ten rows and there are fourteen items to be displayed. If the user taps the down button to scroll down ten items, the next screen only has four items to be displayed (see Figure 7.6). Instead of displaying just those four items, scroll backward enough to display the previous six items as well.

Figure 7.6  Form at end of data

Support the Scrolling Hard Keys

Users expect to be able to use the scrolling hard keys in all applications that support scrolling. The up hard key should perform the same function as the up scroll button, and the down hard key should perform the same function as the down scroll button.

Breaking the Rules ^TOP^

Never rely solely on the scrolling hard keys to scroll your interface. Always include either the scroll buttons or a scroll bar to indicate that scrolling is possible.

Some applications omit both the scroll buttons and the scroll bar in favor of another indication that there is more information to display. Often, this takes the form of a label or graphic that specifies the percentage of data that has already been displayed (see Figure 7.7). A percentage is not a clear enough sign that you can scroll to see more information. For this reason, you must always have some form of scrolling user interface element in your display.

Figure 7.7  Scrolling with no buttons