Siebel Service Handheld Guide > Application Development >

Configuration Guidelines for Siebel Handheld

There are a few general guidelines you should bear in mind when configuring for the Siebel 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
  • To conserve memory (and thereby improve performance) and ease navigation, identify business processes that are required by end users and develop applications that support these processes.
  • If more than one type of user needs a Siebel Handheld Client 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
  • Keep the number of views in your application to 30 or fewer. Determine critical business processes that the handheld will support and only pick 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 View drop-down list concise.
  • Limit the number of screens to 6 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 View drop-down list. The number of characters is a general guide because characters vary in width.
• Limit the number of applets for each view

  Design each view so that it has one or, at most, two applets. Limiting the number of applets enhances performance, and enriches the user experience.

  NOTE:  Some views contain three applets. Use the toggle button to navigate between the two child applets.

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

  Consider the following when designing your applets:

  • Design applications that contain as few screen and view hierarchy levels as possible. In a Web-based application, you may have views with many applets, and the user toggles between the applets. However, for handheld applications, create more views with fewer applets to allow users to quickly find information with a minimal amount of toggling.
  • 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 would not have to scroll. Because there is less screen space on a handheld device than on a laptop or desktop, the most important data should 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 you should 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 single-applet More Info view. Create this applet as a form applet. For example, for the Contacts screen, create a More Info view that has the Contacts form applet only.
  • For each screen, create a view called My * 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
  • 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. See Data Filtering for information on how to design data filters to limit the amount of data that is synchronized to the handheld.
  • 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.