Siebel Sales Handheld Guide > Developing Siebel Handheld Applications >

Configuration Guidelines for the Siebel Handheld Client

This topic contains general guidelines to use when you configure the Handheld application. Use these guidelines when you design any new objects for the Siebel Handheld Client. This approach facilitates a logical separation of the Siebel Handheld Client user interface elements from the Siebel Web Client user interface elements.

Identify user activities

Consider the following when identifying user activities:

• To conserve memory (and thereby improve performance) and ease navigation, identify business processes that are required by users and develop applications that support these processes.
• If more than one type of user needs a Siebel Handheld application, it is preferable to divide the application into multiple responsibilities rather than give all possible users access to all available screens and views. Responsibilities are fully configurable by the application developer.
• Do not include additional functionality that is not required to reside on the device.

Limit the number of screens and views

Consider the following when introducing new screens and views:

• Keep the number of views in your application to 30 or fewer. Determine the critical business processes that the Siebel Handheld application will support and pick only the views that are necessary and are compliant with your business requirements.
• Limit the number of views within a screen to 12 or fewer to keep the Show drop-down list concise.
• Limit the number of screens to six or fewer to keep the Screen drop-down list concise.
• Keep screen names to about 15 characters or fewer, so that they fit in the Screen drop-down list. The number of characters is a general guide, because characters vary in width.
• Keep view names to about 30 characters or fewer so that they fit in the Show drop-down list. The number of characters is a general guide, because characters vary in width.

Limit the number of applets for each view

Organize data in multiple applets in a single view to leverage Tabbed Views. This allows the user to access critical data via a single click.

Limit the number of columns and fields for each applet to minimize scrolling

Consider the following when designing applets:

• Design applications that contain as few screen and view hierarchy levels as possible. In a Web-based application, you can have views with many applets, and the user toggles between the applets.
• Include the most important fields and columns that a user needs to see at a glance before scrolling. For example, if you have a form applet that is a parent, include only needed fields to avoid scrolling.
• If you are using a list applet, determine how wide it needs to be.
• Design each applet so that it only contains columns and fields that are required for end-user tasks.
• Consider moving required and editable fields into visible area of the applet where users can enter data and do not have to scroll. Because there is less screen space on a handheld device than on a laptop or desktop, the most important data must be immediately visible.
• The Date column can be formatted to show only the date instead of Date and Time where Time is not relevant. This saves the user from having to scroll.
• To minimize horizontal scrolling, limit the number of columns displayed in a list applet to no more than ten.
• There is no limit on the number of fields in form applets of single-applet views. However, to minimize scrolling, keep the number of fields to 20 or fewer.
• Use a form applet for the parent for each parent-child view.
• In a multi-applet view, limit the number of fields in form applets to five or fewer. Add additional fields only if the field width is short. For example a check box field.
• Reduce the number of fields if the fields are multi-line, for example, a Comments box that contains three lines of text.
• Do not include read-only check boxes in form applets. It is very difficult for users to discern that the check box is not editable.
• Do not add pick applets or set the Runtime property to true for Read-Only fields that have a picklist value associated to them. This will improve overall extraction time, synchronization time and dbfile.txt file size since the process will not be forced to extract all the picklist values for these fields.
• Keep query names to about 15 characters or fewer, so that they fit in the Queries drop-down list. For example, North American Organization is too long for a query name, so change it to a shorter name, such as N. American Org. The number of characters is a general guide because characters vary in width (for example, W is wider than i).
• For each screen, create a view called My *(asterisk) or All * as a single list applet view. For example, for the Activities screen, create a My Contacts view that has the Contacts list applet only.

Design Data Filters

Consider the following when designing data filters:

• Limit the size of the dbfile.txt file to less than three megabytes (MB). The RDBMS on the handheld device is approximately three times the size of dbfile.txt. If the data files are so large that they cannot be imported into the database with the available memory, users cannot successfully synchronize their data. For information about how to design data filters to limit the amount of data that is synchronized to the handheld device, see Data Filtering for Siebel Handheld Applications.
• When working with assessment creation functionality, you need to name your templates in such a way that they will filter only the needed templates that will be downloaded to the device. Without properly setting up filters, all templates will be downloaded to the device.