Building coaches

You can build a coach as the user interface that process participants or case owners use to interact with a service.

In the first stage of designing a coach, your goal might be to build a mock-up. The mock-up contains static elements to visualize what data the coach needs at run time and where the coach displays the data in its layout. After you complete the first stage to design the look of the coach, you then feed real business data to the coach controls. This step requires you to create bindings between the coach controls and the data structures (variables) that represent the business data in your IBM® Business Process Manager processes or cases. Your process participants or case owners can then interact with the business data, which helps them make the appropriate decisions.

Building a coach is often an iterative process in which you loop back to refine the coach as you build it. Although you can do some of the steps in any order, in general you take the following steps:
  1. Create one or more mock-ups for the coach. Use the mock-ups to identify elements in the coach that are common with other coaches. Identify the following information:
    • The elements in the coach that are reusable.
    • The best layout for the user interface elements in the coach.

    You can then use this information to decide which parts of the coach you can implement as reusable coach views. For example, after you create the mock-up, you see that your coach contains two sets of identical address fields. Instead of creating the two sets of address field in the coach, you create one address field coach view. You can then use it for both sets of address fields.

  2. If there are toolkits that contain artifacts that your coach can use, add a dependency to these toolkits. These artifacts include business objects, coach views, and files. The dependency is to a particular snapshot of the toolkit. If you are revising an existing coach, you can upgrade the dependency to a different snapshot of the toolkit. The upgrade is optional. If you do not do the upgrade, the coach continues to use the existing dependency.
    Important: The coaches 8.5 toolkit uses Dojo 1.8.6 with AMD (Asynchronous Module Definition). If you upgrade the coaches toolkit to version 8.5.0, review the coaches in the process application to assess the impact of the upgrade in Dojo version.
  3. If the coach views that your coach will use do not exist, create them. For information, see Developing reusable coach views.
  4. In the human service diagram, add the coach to the diagram and then double-click it to edit it.
  5. Drag coach views or variables onto the layout of the coach. These coach views can be the coach views that you created earlier or the stock controls. The variables are business objects and their parameters that are defined for the human service . For the variables, the Designer puts the coach view that is associated with the business object or parameter type onto the layout. For example, if you drop a variable that is of the String type, the Designer puts a text stock control that is bound to the variable. If the variable type does not have an associated coach view, the Designer puts a placeholder message on the layout instead. You can then use the placeholder to manually specify the binding between the variable and a coach view.
    For examples of dragging a coach view and variables onto a coach, see Example: creating a tabbed coach.
    Tip: For elements in the coach that you do not plan to reuse, you can drop the appropriate palette component onto the coach. For example, for text instructions for the user, you can drop an HTML element and add the text as HTML code. You can also drag fields within a variable directly onto the coach.
  6. To lay out the coach views in the coach, use sections. For example, if you want two coach views beside each other, drop them into a horizontal section. You can embed sections within other sections.
  7. To edit the coach view instances, select them and then change their properties. For example, for text fields and buttons, change the label to something useful for users. Many coach views contain configuration options that you can set for each instance. You can also override the styling of the coach view instances by adding CSS classes and attributes as HTML properties. These CSS classes are defined elsewhere such as in the coach view definition as inline CSS or in a CSS file uploaded as an included script.
  8. If the coach views support having different types of visibility, define their visibility. For information, see Setting the visibility of coach views.
    Important: You can set the visibility of the controls in the Coaches toolkit. Custom coach views might not provide you with this functionality. If a custom coach view does not support setting visibility, contact the developer of the coach view to add support for this functionality.
  9. Wire the coach into the service flow by connecting boundary events that the coach views fire to the appropriate elements in the service flow.
  10. If needed, validate the data in the coach. For information about validating coaches in client-sided human services, see Validating client-side coaches using client-side validation and Validating client-side coaches using server-side validation. For information about validating coaches in heritage human services, see Validating coaches in heritage human services.
  11. In the Designer or the Inspector, click Run Service.
  12. Review the coach and update the coach or the coach views that it contains until the coach looks and behaves as you intend.
Parent topic: Creating user interfaces for business processes
Related tasks:
Enabling tracing for Coaches
Related information:
Stock controls
Controls in the Content Management toolkit
Boundary events
Building heritage coaches