Siebel Business Process Framework: Task UI Guide > Best Practices for Working with Tasks > Best Practices for User Experience of Tasks >

Best Practices for Designing a Task View

When designing a new task view, present only data specific to the particular task, maintaining simplicity of instruction as well as UI presentation. The Current Task pane provides feedback to the user about their progress within a task. Keep this feedback succinct and make sure it clearly relates to successful performance of the task at hand. When designing a page, start with its type (Overview, Work, Review, Summary), then with its title, and then proceed to fulfill the task in accordance with these two principles.

The following are common issues and concerns when approaching Task UI.

• Avoid the following common ad-hoc UI design styles:
  • Drilldowns.

    For example, consider the Contact screen in the ad-hoc UI. The view displays a list of contacts. One item in each contact is the Account the contact is associated with. The Account Name is what is displayed; clicking on Account Name moves the end user to the Account screen displaying the selected account. This is drilldown functionality.

    Drilldowns are not permitted in Task UI. This is because using the drilldown requires pausing the task so that the ad-hoc UI view targeted by the drilldown can be reached.

  • Buttons on applets.
  • List applets that require horizontal scroll bars.
  • Too many applets in a view. Keep the design of each view as simple as possible.
• Choosing between Form and List applets.
  • List applets. Should be used for list and summary views.
  • Form applets. Should be used when the user needs to manipulate the displayed record.

    Form applets are generally preferred in Task UI because they focus the end user's attention on a single record and the work that needs to be done with it.

    List views are often used in the ad-hoc UI whenever a new record needs to be created. In the ad-hoc UI, the list view is displayed, and the end user presses the New button to create a new record. This is unnecessary in Task UI, at least when only a single record is being created. Instead, the new record can be created using a Siebel Operation step. Then use a View step to display a view having a form applet. The form applet shows the new record, which has empty fields for the end user to fill in.

    In your implementation of Task UI, list views are appropriate whenever lists of items need to be shown or created. However, you will likely find that you do not use list views as often in Task UI as you do in the ad-hoc UI.

• Using applet messages.

  When you are combining dynamic data, such as business components (including transient business components) with static text.

• Using radio buttons and picklists for user decisions.

  Use radio buttons and picklists to constrain user responses and maintain a tight task flow.

• Overriding default method disabling.

  In most cases, default methods should be disabled. The common exceptions are: New buttons on list applets for nonloop operation, as well as Query buttons which constrain data.

• Using buttons to invoke methods and services.

  Buttons and scripts should not navigate the user to a different view. If this is done, the task pauses. Services that call server components should not assume they are working on uncommitted task data.

• Modifying the look and feel using templates.

  Usually, you do not need to modify templates. Use the IsInTask method, target Task UI Service (SWE), to determine whether a section of template should be executed in task mode only.

• Avoiding Applet search specs.

  Review the applet search specs and move to Task View Step Search Specs if possible. This way, you can avoid confusion when reusing applets across task views

Structuring Pages

Consider the following points when designing pages within a task.

• Create goal-oriented task titles. Your task titles should emphasize the goal of the task to be accomplished. For example: Create a New Company.
• Create concise page titles. Each page title should be an explicit statement of its purpose.
• Create useful page explanations. Briefly elaborate on the purpose of the page.

Creating Page Content

A page should not include content that is not suited for the purpose of the page. Page content types fall into the following four general categories:

• Overview page. A page at the start of the task that is used to provide an overview of the task's goal, which can help the user determine whether to proceed with the task or not. For example, an overview page of a driver license renewal task may indicate that completing that task requires the user's social security number and driver license number.
• Step page. Should contain only data that is relevant or meaningful to the current task step.
• Review page. Allows the end user to review any data before it is committed. This is different from a summary page, which is post-commit. The review page allows the user to review, edit, and navigate back in the task flow to make adjustments. Review pages can appear anywhere in a task where an end user is required to commit data.
• Summary page. Provides a log and confirmation of that which the end user has accomplished. This page should not contain any editable data fields, as it is a confirmation page of information already committed to the database.

Reusing Views and Applets

It is recommended that you create new applets and views to enforce the simpler layout requirements of Task UI. Use the CSSSWEFrame template for new applets where possible, to avoid performance implications from any specialized code that may exist.

Working with Buttons and Menus

Consider the following points when implementing buttons and menus:

• Buttons and menus should not require a context business component or record.
• Make sure that tasks are deployed before adding buttons or menus to invoke them. Only activated tasks should be invoked from buttons or menu items. Otherwise users receive run-time errors.

Using Script to Invoke a Task

Invoking tasks from scripts has limited support. In general, there must be an active UI context before invoking a task. Note the following restrictions:

• You cannot invoke tasks from the middle of events (for example, WriteRecord).
• Tasks started from script are launched immediately and the end user is immediately shown the first view. The restriction is that tasks cannot be created from script and then be immediately paused to the Inbox. The Workflow Task step does this, but it cannot be done from script.
• Tasks that require a context record: scripts should only call tasks that do not require, or optionally require, a context.

Using Default Focus

When laying out any page, make sure the most likely first action is suggested by smart placement of the cursor, which is to say, the default focus. For example, on an overview page, the most logical next action is to press the Next button, so place the default focus on the Next button. On a content page, it is most likely the first editable field, so configure the cursor to appear there first. All of your pages should have default focus so the user can use the keyboard to navigate.

Common Types of Views Used in Tasks

Task views fall into the common type categories that follow:

• User decision or user selection. The end user chooses from a set of options that determine how the task flow proceeds.
• Single-object data entry. A form view with built-in new record.
• Multiple-object data entry. A list view with New button.
• Task review. This view displays data entered so far in the task, with options for modification.
• Summary view. This view is generally used at the conclusion of the task.