Guidelines and Techniques for Developing a Task UI

This chapter describes guidelines and techniques for developing a task UI. It includes the following topics:

Guidelines for Developing a Task UI

This topic describes guidelines for developing a task UI. It includes the following topics:

Guidelines for Organizing the Task Flow

Use the following guidelines when you organize the task flow:

Envision a simple task UI. Envision the display of information as a series of linked pages or steps when you design a task UI. Although in many situations you can configure a task step in a single page, it is not required. If the step is complex, then you can separate it into multiple pages. Simplicity is an important design principle for a task UI.
Simplify task complexity. Make sure the task UI is self contained and is a single point-to-point flow. During the design phase, consider the number of steps and decisions. If necessary, separate one task into multiple tasks.
Chunk the task UI. Separate the task UI into a number of logical chunks. A task UI must guide the user through a task that is easy to follow and review. A task that is too long might disorient the user. A rule of thumb is to create chunks that include between five and seven items.
Use the Chapter feature. You can configure task UI to use the Chapter feature to assist the user in understanding the overall job task and to monitor completion of the job task. The chapter feature provides the user with an outline of the task UI. This feature helps the user understand the work that the user already performed and how much work the user must still perform at a point in the overall task. The individual steps in a chapter can vary depending on choices that the user makes.
Organize the task UI around logical commit points of the task transaction. For more information, see About Task Transaction.

Guidelines for Designing Task Functionality

Use the following guidelines when you design the functionality of the task UI:

Design for the user profile. Consider the experience and the job role of the user. Consider questions such as job turnover, and computer aptitude.
Design for how frequently the user performs the task UI. How frequently the user performs the task can affect how the task UI is designed. A task that the user performs infrequently might require more guidance because the user is not provided an opportunity to internalize expertise.
Enforce forward navigation. You can enforce forward navigation but allow for review and editing of work that the user performs in the task UI. Design your task UI so that the task guides the user forward through the task in a way that allows the user to edit and review portions of the task that the user has finished. Navigation that requires the user to click Previous is acceptable, but the user must not be required to repeatedly click Previous through a long list of views.
Allow the user to enter record data across multiple views. Allowing the user to enter record data across multiple views can help to organize the fields that the user must use to create a complete record that is very complex.
Allow the user to define a query. Use a separate view for each of the following:
- Use one view for the query.
- Use another view for the query results.
Use the form view and list view correctly. Do the following:
- If each record includes a large number of required fields, then loop through a form view.
- If each record includes a small number of required fields, then use a list view.
This technique helps to minimize horizontal and vertical scrolling of the list view.

Use the same task view in multiple view steps in a task UI.
Choose a display style for the step of the current task pane. Make sure Siebel CRM uses the correct style according to the complexity of the task UI. Depending on the complexity and length of a task UI, you can configure Siebel CRM to do one of the following:
- Display all steps simultaneously.
- Display only a subset of steps simultaneously.
Avoid using a link in a task UI. Remain in the task UI. Avoid a script or run-time event that pauses the task and then leaves the task.
Include a review page. A review page allows the user to review and modify data before Siebel CRM saves this data. You can place a review page at the end of a task UI. For a long task, you can place a review page at multiple locations throughout the task.
Configure Siebel CRM to perform an operation that occurs outside of the Siebel database only if the user clicks Submit. The task controller does not roll back modifications that Siebel CRM makes outside of the Siebel database, such as with saving an attachment. It is recommended that you configure Siebel CRM to perform this type of operation only after the user clicks Submit. If the user steps back through the task UI or cancels the task, then you avoid having Siebel CRM create an orphan file.

Guidelines for Using a Script to Start a Task UI

If you use a script to start a task UI, then use the following guidelines:

Make sure an active UI context exists before the user starts a task UI.
Do not start a task UI from the middle of a run-time event, such as the WriteRecord event.
Do not create a task UI from a script and then immediately pause the task to the inbox. The Workflow Task step can perform this logic, but you cannot use it through a script. If you define a task UI to start from a script, then Siebel CRM starts it immediately when the script runs and then displays the first view in the Siebel client.
Make sure a business component record is available to the task UI. A script must only call a task when the business component includes at least one record.

Only limited support exists for starting a task UI from a script.

Guidelines for Designing User Interface Elements

This topic describes guidelines that you can use to design user interface elements.

Guidelines for Designing a Task View

Use the following guidelines when you design a task view:

Avoid redundancy. For example, avoid using multiple buttons that perform the same function. Displaying 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. Configure task UI to display only data that is specific to the current step. This technique helps to simplify the UI.
Focus feedback that the task UI provides. The current task pane provides feedback to the user about the progress that the user makes in a task instance. Make sure this feedback is succinct and relates only to the job task that the user is currently performing.
Use an applet message. If you configure task UI to combine dynamic data, such as with a business component and a transient business component, then you can use an applet message. For more information, see Overview of Transient Data.
Use a radio button or picklist. You can configure task UI to use a radio button or picklist to help the user make a decision.
Override default method disabling. In most situations, you must disable a default method. The following are common exceptions:
- A New button on a list applet for nonloop operation.
- A 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 that it works on task data that Siebel CRM has not saved.
Avoid modifying the look and feel of a template. You typical do not need to modify a template. You can use the IsInTask, target Task UI Service (SWE) to determine whether Siebel CRM must run a section of a template only in task mode.
Avoid using a search specification on an applet. Instead of using a search specification on an applet, use a search specification on a task view step. This technique helps to avoid confusion if you reuse an applet across task views.
Use a consistent approach to page design. For example, when designing a page, do the following:
- Begin with the page type. For example, Overview, Work, Review, or Summary.
- Proceed with the page title.
- Finish completing the task design.

For more information, see About the Task View.

Guidelines for Using a Form Applet and a List Applet

Use a list applet to do the following:

Display a list of items.
Allow the user to create a list of items.

You might find you do not use a list view in a task UI as often as you use a list view in the standard UI. Apply the following guidelines:

Use a list applet for a list or summary view.
If the user must modify data in a record, then use a form applet. The form applet focuses user attention on a single record.
Use a Siebel operation step to allow the user to create a new record. Use a view step that includes a form applet that displays a new record that includes empty fields that the user finishes. Siebel CRM typically uses a list view that allows the user to click New to create a new record in the standard UI. This configuration is not necessary in a task UI, particularly if the user only creates a single record.

Guidelines for Reusing Views and Applets

To enforce the simpler layout requirements of a task UI, it is recommended that you create a new applet and view or modify a predefined view and applet. You can use the CSSSWEFrame template to avoid performance problems that might occur with specialized code when you create a new applet.

Guidelines for Designing Buttons and Menus

If you design buttons and menus, then use the following guidelines:

Do not configure Siebel CRM to open a task UI that creates a new record from outside the task pane. If Siebel CRM does not yet display a record, then you might need to disable a button that opens a task. A button or menu requires at least one record from the business component that the task UI references. Siebel CRM must reference this business component when it creates a task instance. If the business component includes no records, then Siebel CRM cannot reference it and cannot create a task instance, and an error occurs.
Make sure you deploy the task UI before you add a button or menu to start the task. You must activate the task before the user can use a button or menu item to start it. If you do not activate it, then Siebel CRM displays a run-time error in the Siebel client.
Do not create menus and buttons that perform the same function. For example, avoid including the header (top) and footer (bottom) task playbar applets on the same view. Instead, include only the header task playbar applet or only the footer task playbar applet.

Guidelines for Using the Default Focus

Include a default focus that prompts the user to perform an action. For example:

Place the default focus on the Next button. On an overview page, the user typically clicks Next.
Define the cursor to display in the first editable field. On a content page, the user typically edits 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

Use the following guidelines to design the structure of a page that displays in a task UI:

Include a title for the task UI that describes the goal of the task. For example: Create a New Account.
Include a page title that is concise. Each page title can be an explicit statement of the purpose of the page.
Include a page explanation. Briefly elaborate on the purpose of the page.

Guidelines for Designing the Content of a Page

The following table describes types of content that Siebel CRM can display on a page and their recommended usage. Make sure the page only includes content that supports the purpose of the page.

Table Types of Content That Siebel CRM Can Display on a Page

Page Content Type	Recommended 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 user to determine to proceed with the task. For example, the overview page in a driver license renewal task can indicate that completing the task requires a social security number and a driver license number.
Step Page	Displayed throughout a task UI. Includes only data that is relevant or meaningful to the current task UI step.
Review Page	Displayed before a commit step. Allows the user to review data before Siebel CRM saves it. Allows the user to review, edit, and navigate in the task UI to make adjustments.
Summary Page	Displayed at the end of a task UI. Provides a log and confirmation of work that the user performed. This page cannot include editable data fields because it is a confirmation of information that Siebel CRM already saved to the Siebel database.

Guidelines for User Interface Styles to Avoid

Avoid using the following items:

Avoid using a drilldown. For example, consider the Contact screen in the standard UI that displays a list of contacts. If the user clicks the Account Name field in the list view of the Contact screen, then Siebel CRM navigates the user to the Account screen that displays the chosen account. This functionality is known as a drilldown.

Siebel CRM does not allow a drilldown in a task UI. Using a drilldown requires Siebel CRM to pause the task so that it can navigate the user to the standard UI view that the drilldown references.
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 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 perform the same function.

Guidelines for a Multilingual Task UI

You can use values that are independent of any given language to design a task UI that Siebel CRM can run in multiple languages. You must pay close attention to the following items:

Display names that use symbolic strings. Do not use overrides.
Use LIC (language independent code) instead of a display value.
Values for the Task Property.
Field values for a business component and transient business component. For more information, see Overview of Transient Data.
Siebel operation steps.
Conditions.
LOVs.
Multilingual LOVs (MLOVs). If a LOV type is Multilingual, then Siebel CRM uses language independent code to store the data that the LOV binds.
Marked for translation.

About Literal Values in a Multilingual Environment

A literal value depends on a language, so a task UI cannot reference a literal value in a dynamic picklist and function correctly in a multilingual environment. A task that references a literal value is language dependent and you must not configure Siebel CRM to run it in a multilingual environment. A literal value in a dynamic picklist can include content that the user creates. These values reference content rather than metadata or an LOV, so they are variable and the task cannot reliably interpret them. For more information, see Siebel Global Deployment Guide.

Guidelines for Using a Business Service

A business service allows you to run a predefined or custom action in a task UI. Code that Siebel CRM calls synchronously or asynchronously cannot view data that Siebel CRM has not saved from temporary storage to base tables. To avoid this problem, you can add a commit step before you start a server task for a server component.

Using Script with a Business Service

You can use Siebel VB or Siebel eScript to create your own custom business service that Siebel CRM calls from a task UI. A server script in a business service operates on the temporary instances of a business component and updates the S_TU_LOG table. It does not update the base tables.

Caution: A task UI cannot call a business service that includes browser script. If a task UI calls a business service that includes browser script, and if that task runs on the Siebel Server, then the business service fails.

Techniques to Improve the Usability of a Task UI

This topic describes techniques you can use to improve the usability of a task UI. It includes the following topics:

Split View Technique

A business component record can include a large number of fields. Dependencies might exist between fields in this record that require the user to enter information in the fields in a specific order. A view that displays all business component fields simultaneously is difficult to use. A task UI can guide the user through completing these fields.

You can use a form applet that references the same business component to split data entry for a single record into multiple views. Navigating backward and forward between these views displays different fields of the same record while preserving the field values that the user enters.

It is recommended to keep fields that depend on one another in the same view. This technique avoids a problem if modifying a field value in one view causes Siebel CRM to modify a field value in another view. For example, through a pick map or the On Field Update user property.

Example of the Split View Technique

Assume a task UI includes account data that includes two hundred single value fields and eighty multivalue fields in the Account business component. This task UI uses the following views to display these account fields:

The first view displays identification data, such as Name, Location, DUNS, and CSN.
The second view displays classification data, such as Account Type, Industry, Territory.
The third view displays communication data, such as Primary Address, Phone Number, Fax Number, and URL.

Optional View Technique

If a task UI must display data that the user can review, and if this data is optional, then you can make the view optional.

Using the Optional View Technique

This topic describes how to use the optional view technique.

To use the optional view technique

Open the Task Editor for the task UI you must modify.
For more information, Opening the Task Editor.

Add a Siebel operation step using values from the following table:

Property	Value
Operation	Query

Optional. In the Multi Value Property Window, click the Output Arguments tab, and then add an output argument using values from the following table.

Property	Value
Type	Output Argument
Output Argument	NumAffRows For more information, see Arguments of a Task Step.

Property

Value

Type

Output Argument

NumAffRows

For more information, see Arguments of a Task Step.

For more information, see Creating an Output Argument on a Task Step.

Add a Decision step:

Place this decision step immediately after the Siebel operation step you added previously.

Add a branch using values from the following table.

Property	Value
Type	Condition

In the conditional branch, test that the value of the NumAffRows task property is a literal value that equals 0.

Add another branch using values from the following table.

Property	Value
Type	Default

Add a view step immediately downstream of the decision step.
This view step displays the optional data.
To bypass the optional view, use the condition branch.

Example of the Optional View Technique

An activity field can include instructions. If no instructions exist, then the task UI can skip the view that displays them.

Mixed View Technique

If an applet references a single business component, and if the boundary of the business component is not intuitive or obvious to the user, then you can create a task UI that displays a logical set of data in a view. You can configure Siebel CRM to combine data from multiple business components into a single task view step. A task can include more than one applet, so the user does not need to worry about boundaries between business components.

Example of the Mixed View Technique

A view displays a list of items in an order and asks if the user must add a new item. Siebel CRM uses a single applet to display the list of ordered items according to the Order Item business component. A second applet includes the following items:

A question that Siebel CRM displays as an applet message.
The answer to the question, stored as a field in a transient business component and displayed as a radio button. For more information, see Overview of Transient Data.

Mixed Applet Technique

If a task UI must display data from several business components in a single applet, then you can create a task UI that uses a transient business component to hold data for the mixed applet. The task UI can save the data to a nontransient business component. The task UI saves this data immediately following the view that includes the mixed applet. For more information, see Overview of Transient Data.

Example of the Mixed Applet Technique

The predefined CMEREF - Activation Order task UI is an example of the mixed applet technique. It asks for the following information in a single applet:

Account name
Customer first name
Customer last name

At a later point in this task UI, it uses this data to query an existing account and contact. If it does not find a record, then it does one the following:

Creates a new account or a new contact
Creates a new account and a new contact

Business Component Method Technique

The standard UI requires the user to click a button or to choose a menu item to call a section of business logic. This business logic typically calls a business component method and is not readily available as a business service method. The problem with this kind of user experience is that the user must possess knowledge about the following items:

The user must click a button to run the logic
The user must understand the result of clicking the button
The user must understand the sequence to use to click multiple buttons

To avoid this complexity, task UI provides the following capabilities:

Display unambiguous choices in the Siebel client
Describe the result of clicking a button
Provide backward navigation
Enforce the sequence to use to click multiple buttons

You can provide the user with multiple choices in a task UI, one choice at a time:

The user makes a choice, and then clicks Next on the task playbar applet.
The task UI calls the business logic and in the correct order.
If an exception occurs, then the task UI displays an error dialog.
If an exception does not occur, then the task UI can display the next view.

Using the Business Component Method Technique

This topic describes how to use the business component method technique.

To use the business component method technique

If an adapter business service does not exist, then create one using values from the following table.

Property	Value
Class	CSSBCAdapterSvc

Make sure the value of the Business Component user property specifies the business component whose method or methods it is adapting.
Define a method with the same name as the business component method that Siebel CRM must call from the task UI.
Call the business component method from a business service step in the task UI.
This business service step must reside downstream of a task view step so that the Next step flows to the business service step and calls the business component method.

If you enable backward navigation to the selector view, and if this view displays an option that logically negates the underlying business logic that Siebel CRM performs, then you might need to adjust the flow of your business process so that it is compatible with backward navigation and the business logic.

Example of the Business Component Method Technique

The predefined Field Activity Invoicing task UI displays an option to automatically create an Invoice. The user clicks AutoInvoice in the Invoice applet to create this invoice in the standard UI. The predefined task calls an adapter business service method after the selector view. This task UI eliminates the requirement to use the AutoInvoice button in the Invoice applet.

Refine Query Technique

It is recommended that you define a query for a task UI, typically as a search specification in a task view step. However, sometimes it is not possible to know at design time the exact search specification that the user requires at run time, and Siebel CRM might display a large number of records when the search specification for the task UI runs. You can configure a task UI that uses query-by-example to allow the user to refine this query.

Siebel CRM uses the following logic in the refine query technique:

The task view step includes a broad search specification.
The task controller sets this search specification as an anonymous search specification on the business component, using the & (ampersand) prefix to substitute task properties that the search specification references.
The task view includes a Refine Query button that calls the Refine Query method on the business component. This method uses the search specification set in Step 1 but allows the user to refine the search criteria.
The user refines the search specification, clicks Execute Query in the task view, and then Siebel CRM displays the task UI only in query mode.
Siebel CRM uses the refined search specification set in Step 3 to run the query.
If Siebel CRM does not display the fields that the search specification in Step 1 references, then the user cannot remove this query even if the user is required to remove it.

Example of the Refine Query Technique

The predefined Create Order task UI includes a task view step that allows the user to choose a number of products. To search products, the user can use the customer zip code, but this query can return hundreds of products. The Create Order task UI allows the user to use the name to refine the query. For example:

[Name] LIKE '*300 minutes*'

This task UI does not display the zip code, so the user can only narrow the original search specification and cannot broaden it. The predefined Create Order task UI resides in the Siebel Communications application.

Commit Interim Data Technique

A task UI might require a long time to finish but the business requirement dictates that data that the task updated be visible to other users as soon as possible.

Using the Commit Interim Data Technique

This topic describes how to use the commit interim data technique.

To use the commit interim data technique

Open the Task Editor for the task UI you must modify.
For more information, Opening the Task Editor.
Add a view step that reviews data that the user enters in the task.
At the point in the task UI where data that the user entered must become visible to other users, set the Forward Button Type property to Submit.
For more information, see Validation with Forward Navigation in the Task Playbar.
Add a commit step immediately downstream of the view step you added previously.

Example of the Commit Interim Data Technique

In the predefined Field Activity Main Task task UI, if the user updates the Status field, then Siebel CRM saves it to the Siebel database so that other users can view it, regardless of whether or not the task instance finishes. The following logic is involved in this example:

A Siebel operation step updates the activity status.
A task view step includes a Submit button. This task view step is immediately downstream of the Siebel operation step described in Step 1.
A commit step saves data to the Siebel database. This commit step is immediately downstream of the step described in Step 2.

This behavior makes sure the user understands that Siebel CRM saves the modifications, and allows the user to step back through the task UI and choose a different status before committing modifications that are visible to other users.

Other Usability Techniques

The following table describes other usability techniques you can use.

Table Types of Content That Siebel CRM Can Display on a Page

Page Content Type	Recommended Usage
Use the Defer Write Record property.	For more information, see Using the Defer Write Record Property of a Siebel Operation Step Instead of a Transient Business Component.
Place all required fields on a single view.	Placing all required fields on a single view helps the user to finish the transaction. If necessary, you can use a transient business component to store interim data. For more information, see Overview of Transient Data.
Avoid using too many pop-up elements.	Too many pop-up elements can be distracting.
Use a list view as a picklist.	You can use a list view as a picklist to allow the user to pick records.
Use the selector.	The Selector forces the user to choose between several options that are available.
Use the hierarchical selector.	The Hierarchical Selector forces the user to make several mutually dependent decisions. Make sure you avoid cascading a series of selector views with only relevant options.
Push data to the Customer Dashboard.	If a task UI captures customer information that is useful in the customer dashboard, then configure Siebel CRM to push this data to the Customer Dashboard.