|
Siebel Business Process Framework: Task UI Guide > Guidelines and Techniques for Developing a Task UI > Guidelines for Developing a Task UI >
Guidelines for Designing a Task View
The following categories describe the more common task views:
- User decision or user choice. A view where the end user chooses from a set of options that determine how the task UI proceeds.
- Single object data entry. A form view that contains a built in new record.
- Multiple object data entry. A list view that contains a New button.
- Task review. A view that displays data that is entered thus far in the task instance, with options for modification.
- Summary view. A view that is generally used at the conclusion of the task UI.
General Guidelines for Designing a Task View
Table 20 describes general guidelines you can use when you design a task view.
Table 20. General Guidelines for Designing a Task View
|
|
Avoid redundancy. |
For example, avoid having multiple buttons that perform the same function. Having more than one button that performs the same function increases uncertainty and unnecessarily increases the complexity of the view. |
Focus the content of the task UI. |
When designing a task view, present only data that is specific to the particular task, thereby maintaining simplicity of the instructions and the presentation of the UI. |
Focus feedback that is provided by the task UI. |
The current task pane provides feedback to the end user about the progress that the user is making within a task instance. Keep this feedback succinct and make sure it clearly relates to successful completion of the job task that the user is currently performing. |
Use an applet message. |
When combining dynamic data, such as with a business component and a transient business component, with static text, you can use an applet message. |
Use a radio button or picklist to assist the user in making a decision. |
Use a radio button or picklist to constrain the response that the user can enter, and to maintain a tight task UI. |
Override default method disabling, when necessary. |
In most cases, a default method must be disabled. The common exceptions are the New button on a list applet for nonloop operation, and the Query button that constrains data. |
Avoid using a button that navigates the user to a different view. |
A button or a script must not navigate the user to a different view. If this situation occurs, then the task UI pauses. A service that calls a server component must not assume it is working on task data that is uncommitted. |
Avoid modifying the look and feel of a template. |
Usually, you do not need to modify a template. Use IsInTask, target Task UI Service (SWE), to determine whether a section of a template must be executed in task mode only. |
Avoid using a search specification on an applet. |
Instead of using a search specification on an applet, consider using Use Task View Step Search Specs, if possible. This way, you can avoid confusion when an applet is reused across task views. |
Use a consistent approach to page design. |
When designing a page, start with the page type, such as Overview, Work, Review, or Summary. Proceed with the page title, then with completing the task UI. |
Guidelines for Using the Form Applet and List Applet
The following guidelines can be applied when using a form applet or a list applet:
A list view is often used in the standard UI when a new record must be created. The list view is displayed, then the end user clicks New in order to create a new record. This configuration is unnecessary in a task UI, at least when only a single record is created. Instead, the new record can be created by using a Siebel operation step. Then a View step displays a view that contains a form applet. The form applet displays the new record that contains empty fields for the end user to finish. In your task UI , use a list view when a list of items must be displayed or generated. However, you might find you do not use the list view as often in a task UI as you do in the standard UI. Guidelines for Reusing Views and Applets
To enforce the simpler layout requirements of a task UI, it is recommended that you define a new applet and view, or modify a predefined view and applet. Where possible, use the CSSSWEFrame template for new applets in order to avoid performance implications from whatever specialized code that might exist. Guidelines for Designing Buttons and Menus
The following guidelines can be applied when you design buttons and menus:
- Do not launch a task UI that generates a new record from outside the task pane. Also, you might need to disable a button that launches a task in the case where a record is not yet present.
A button or menu requires at least one data record from the business component that is referenced by the task UI. For a task to be instantiated, the business component must be referenced. If the business component includes no records, then the business component cannot be referenced and the task cannot be instantiated, causing an error.
- Make sure the task UI is deployed before you add a button or menu to start the task. A task must be activated before it can be started from a button or menu item. Otherwise, the end user receives a run-time error.
- Do not build menus and buttons that perform the same function. For example, avoid including both the top and bottom task playbar applets on the same view. Instead, include either the top or the bottom task playbar applet.
Guidelines for Using a Script when Starting a Task UI
The following guidelines can be applied when using a script to start a task UI:
There is limited support for starting a task UI from a script. Guidelines for Using the Default Focus
Your page can include a default focus so the end user can use the keyboard to navigate. When laying out a page, make sure the most likely act the end user takes is prompted by judicious placement of the cursor, which is to say, the default focus. Note the following examples:
- On an overview page, the most typical next act that the user performs is to click Next. Therefore, place the default focus on the Next button.
- On a content page, the most typical next act that the user performs is to edit the first editable field. Therefore, define the cursor to appear in the first editable field.
Guidelines for Designing the Structure and Content of a Page
This topic describes guidelines for designing the structure and content of a page. Guidelines for Designing the Structure of a Page
The following guidelines can be applied when designing the structure of a page that appears within a task UI:
- Define a title for the task UI that describes the goal of the task to be accomplished. For example: Create a New Account.
- Define a page title that is concise. Each page title can be an explicit statement of the purpose of the page.
- Define a useful page explanation. Briefly elaborate on the purpose of the page.
Guidelines for Designing the Content of a Page
Make sure a page includes content that is suited for the purpose of the page. Table 21 describes types of content that can appear on a page and their appropriate usage.
Table 21. Types of Content That Can Appear on a Page and Their Appropriate Usage
|
|
Overview Page |
Displayed at the start of a task UI. Provides an overview of the goal of the task UI that can help the end user determine whether to proceed with the task. For example, the overview page in a driver license renewal task can indicate that completing the task requires the social security number and the driver license number of the end user. |
Step Page |
Displayed throughout a task UI. Contains only data that is relevant or meaningful to the current task UI step. |
Review Page |
Displayed before a commit step. Allows the end user to review data before it is committed. Allows the end user to review, edit, and navigate back in the task UI to make adjustments, which is different from a summary page, which is post commit. |
Summary Page |
Displayed at the end of a task UI. Provides a log and confirmation of work that the end user performed. This page cannot contain editable data fields because it is a confirmation of information already committed to the database. |
Guidelines for UI Design Styles to Avoid
The following guidelines can be used when determining what UI design styles you must avoid:
- Avoid using a drilldown.
For example, consider the Contact screen in the standard UI, which displays a list of contacts. Clicking the Account Name field that appears in the list view of the Contact screen navigates the end user to the Account screen that displays the chosen account. This functionality is known as a drilldown.
A drilldown is not permitted in a task UI because using the drilldown requires that the task be paused so that the standard UI view that is targeted by the drilldown can be reached.
- Avoid using a button on an applet.
- Avoid a design style that uses a vertical or a horizontal scroll bar. The scroll bar disorients the end user.
- Avoid including too many applets in a view. Keep the design of each view as simple as possible.
- Avoid redundancy. Avoid including multiple buttons or applets that accomplish the same function.
|
