Train Usage Guideline Bookmark this Guideline Printable Page


RCUI Document Version 5.0.1 for Oracle® Fusion Middleware 11g Release 1 Patch Set 1 (11.1.1.2.0)
Last Updated 04-Nov-2010

The Train component identifies the current step in a guided process, and provides links to navigate through the process.

Guideline Contents

Note: Images in this guideline are provided as a general reference, and may not be exact representations of FusionFX pages.

Related Guidelines

Guideline Section For Information About
Message Framework Confirmation Messages Optional confirmation at end of guided process.

Related ADF Elements

Refer to the ADF Faces Rich Client demos page to find demos and tag documentation for ADF elements related to this component:

ADF Element Notes
af:train Train component.

General Principles Bookmark this Heading Return to Top

Purpose:

The Train allows users to quickly see where they are in a guided process, and provides links to navigate through that process.

Description:

  • A guided process is the FusionFX equivalent of a wizard, providing the ability to divide a complex task into a series of steps, thus reducing the level of skill required to complete the task.
  • Each step in a guided process is represented as a train stop, with lines connecting one stop to another.

Usage:

  • As the user navigates through the process, the train should be refreshed together with the page contents to show the correct state of each train stop.
  • The train is contextual to the entire main content region of the page, and must not be used for a section of content within a page.
  • Each train is a unique entity with a predefined number of stops. The number of stops may not be increased or decreased dynamically, but stops may be skipped. Skipped steps are shown as disabled. See Train Stops below for more details.
  • The train does not support branching. When a process may present different routes depending on the user's choices, it is necessary to provide a pre-load page before the train is rendered. The user's input on the pre-load page determines the correct train to be displayed.
  • The train includes navigation links, but these are usually an alternate navigation method to the Train Button Bar.

Types of Trains Bookmark this Heading Return to Top

There are two types of train: Horizontal and Vertical.

  • Horizontal Trains: Typically displayed within the horizontal space of the Secondary Control Panel, directly above the page header (this is the recommended location). Suggested for shorter processes (3 - 7 steps) where all stops can be shown at the same time. When there are too many train stops to fit within the available horizontal space, an overflow list appears.
  • Vertical Trains: Typically displayed within the vertical space of the Secondary Control Panel and in dialogs (these are the recommended locations). In both cases they appear on the left side of the page or window (right side for bi-directional language applications). Suggested for longer processes (up to 10) steps so more stops can be shown at the same time. Vertical trains occupy space typically used for display of data, so are not recommended for processes with large amounts of detail in individual steps. When there are too many train stops to fit within the available vertical space, a vertical scroll bar appears.
  • See the Page Layout guideline for more information about the location of the train on the page. See the Secondary Windows guideline for more information on dialogs.

horizontal train

Horizontal Train

vertical train

Vertical Train

Types of Guided Processes Bookmark this Heading Return to Top

There are two types of guided processes:

  • Sequential: Consist of a number of logical, sequential steps with data dependencies between some or all steps.
  • Non-sequential: Consist of steps presented in a suggested order, but which do not have data dependencies between steps. A sequential process may become non-sequential when a user re-launches the process to make changes to an already completed object.
Note: Development teams specify process type at the train stop level, so a single guided process may consist of a mix of sequential and non-sequential steps. See Train Stops for details.

A horizontal train with sequential process

Horizontal Train with Sequential Process

A horizontal train with non-sequential process

Horizontal Train with Non-Sequential Process

Configurable Elements Bookmark this Heading Return to Top

Train elements calling out the parent train icon, the start and end overflow icons, train stop cells, the train line connecting the cells, required step indicators, and stop names labeling the cells.

Train Elements

Train Stops Bookmark this Heading Return to Top

Purpose: Show the user's current location in a guided process, and indicate whether it is possible to navigate to the next step in the process.

Description:

  • All stops are shown simultaneously, unless some are hidden in the Overflow List.
  • Sequential stops are enabled based on their position relative to the current stop. Only visited stops and the one immediately following the current stop are enabled.

A horizontal train showing all stop states

Train Showing All Stop States

Usage:

  • Trains should have at least three stops. Two-step processes can be handled solely with action/navigation buttons.
  • Trains have no size restrictions. Nevertheless, long processes can be cumbersome and confusing to users. If a linear process has more than 10 steps, re-evaluate the task flow and determine whether some steps can be combined effectively in a shorter process.
  • Stop names should be both concise and distinctive, providing a clear description of the stop content but without causing undue clutter in the train.
  • A guided process may include a review option in one of the following two ways:
    • Review Page as the Last Train Stop: Use this option when working with critical data, or at the end of long processes. The Review page may be a summary rather than a complete list of all settings.
    • Review Page Accessible from any Train Stop: Use this option when working with complex processes where users are required to make many decisions or enter significant amounts of data early in the process. In this option, each step has a Review button.
  • Consider omitting the review page in processes of six or less steps, if data is not critical, or if application users frequently work with the process and have a relatively high skill level.
  • Product teams can override the sequential behavior of individual train stops by setting up a condition for the sequential behavior. If the condition is not met, all stops after the current stop are enabled. Consequently a train may have some stops that are sequential and others that are non-sequential.
    • For example, stops A, B, and C do not have a sequential condition defined, whereas D, E, and F do. As a result the train proceeds as follows:
    • A-B-x-x-x-x
      A-B-C-x-x-x
      A-B-C-D-x-x (once user completes C)
      A-B-C-D-E-F
  • Stops may be skipped if product teams define the conditions required to do so. In that case skipped stops remain visible but are disabled. It is also recommended to provide Help text for the originating action or selection explains what causes a step to be skipped, in case users are uncertain why it has occurred. See the Help Framework guideline for more information.
  • Required, sequential steps should be placed at the beginning (first steps) of the train.
  • Stop names do not wrap, so should be kept relatively short.
  • Each stop should have tooltip text that specifies the state of the stop and the stop name, such as "Visited Step: Select Account".

a horizontal train with non-sequential stops

Train with Non-Sequential Stops

a horizontal train with skipped stops, in which, after step 1, stops are skipped until step 4.

Train with Skipped Stops

Process Name Bookmark this Heading Return to Top

Purpose: Identifies the current process.

Usage:

  • The process name does not appear in the train, but is incorporated into the page title and breadcrumbs.
  • The process name is alphanumeric without any limit on number of characters.
  • Product teams may manually truncate the process name.
  • The process name should be based on the syntax: "Action ObjectType [ObjectName]", where:
    • Action = the action being performed, such as Create.
    • ObjectType = the type of object being acted on, such as Invoice.
    • ObjectName = the unique name of the object. This should be omitted when creating a new object. For example, in a process named "Promote Employee John Smith", the object name is "John Smith".

Required Step Indicator Bookmark this Heading Return to Top

Purpose: Indicates that a page in the process contains one or more required fields.

Usage:

  • By default, the Required Step Indicator is turned off.
  • Development teams should selectively turn the Required Step Indicator on for any stops with required fields.

Alert Icons Bookmark this Heading Return to Top

Purpose: Indicates the status of a step.

Usage:

  • Two alert icons are provided for teams to use: Error and Warning.
    • Error icon: Required when one or more actions in a step fail due to data inaccuracies or system level problems.
    • Warning icon: Recommended when a step may require further attention.
  • Alert icons should only be used for visited steps.
  • Product teams may create their own icons to provide additional object-specific status information, such as the status of a server or other network service.
  • Clicking an Alert icon has the same result as clicking the train stop.
  • The tooltip text of the stop should include the Alert status if the Alert icon exists. For example: "Visited Step with Error: Select Account". If the stop name does not adequately describe the stop's content, development teams can specify a descriptive name for the stop, which is then appended to the tooltip text by the framework code.

Alert icons on train stops, one indicating an error and indicating a warning, respectively.

Alert Icons

Overflow List Bookmark this Heading Return to Top

Purpose: The overflow list contains train stops that cannot fit in the horizontal space allotted to the train.

Usage:

  • An overflow icon appears automatically at either or both ends of the train if all train stops cannot be displayed concurrently.
  • Users click the overflow icon to display the overflow list for that end of the train.
  • Although there is no limit to the number of train stops that may appear in the overflow list, it is recommended to limit train length to no more than 10 stops to make the process easier for users to complete.

The overflow icon on a train and the overflow list showing the names of the train stops not being displayed.

Overflow Icon and List

Parent Train Icons Bookmark this Heading Return to Top

Purpose: Indicate that a guided process was launched from another guided process.

Usage:

  • The parent train icon appears by default when a train is used in a subprocess.
  • The parent train icon appears on both sides of the subprocess train, and is not clickable.
  • The tooltip text for the Parent Train icon shows the name of the parent step used to launch the subprocess. If the subprocess is more than one level down from the main process, show the process path with this format: "Grandparent Stop name > Parent Stop name"
  • The parent step name is displayed as static text along with the parent train icon. This provide a stronger reminder that the user is in a subprocess. Product teams may choose to hide the parent step name, but this is not recommended unless the name is too long (more than 25 characters).
  • On completion of the subprocess, the user may return to the step in the parent process that launched the subprocess, or may continue directly to the next stop in the parent process. See Drill Down to Subprocesses for more information about these two options.

Train Button Bar Bookmark this Heading Return to Top

Purpose: Optional method to navigate through a guided process.

A train button bar in a page.

Train Button Bar

Usage:

  • The Train Button Bar is optional. When used it should be displayed in the toolbar region of the page header on each page of the guided process.
  • The Train Button Bar is pre-configured to display Back and Next buttons; product teams can add other buttons to provide additional actions for objects on the page.
  • The recommended button sequence is as follows:
    • First Step: Back (disabled), Next, Finish or Submit button (disabled), Cancel
    • Subsequent Steps: Back, Next, Finish or Submit button (disabled), Cancel
    • Final Step: Back, Next (disabled), Finish or Submit button, Cancel
  • Product teams should disable the Next button when users are not permitted to navigate forward, and should disable the Back button when users are not permitted to navigate backward.
  • If product teams provide additional buttons to perform custom actions, those buttons should be placed before the Back button or after the Next button. For example, a Save and Exit button can be placed between the Next and Finish buttons.
  • The tooltip for the Back button is "Back", and the tooltip for the Next button is "Next". Product teams should provide equivalent tooltips for other buttons.
  • When all mandatory steps have been completed, a Finish or Submit button may appear before the final step, unless the guided process finishes with a Review step. For more information on button labels, see Labels Specific to Guided Processes in the Buttons guideline. For more information on Review steps, see Train Stops earlier in this guideline.
  • Development teams may also include page locator text or a page locator choice list between the action/navigation buttons, as described in the following subsection.
Note: The Train Button Bar is also used in two-step processes, which do not make use of the Train component. In two-step processes, the first step should include a Next button, an optional Review button, and a Cancel button, and the second step has the same button choices as the final step described above.

Page Locators Bookmark this Heading Return to Top

Purpose: Page locators identify the current step by number in the sequence, and may also enable navigation to other steps.

Description:

  • Page locators are not specific FusionFX components, but consist of either labels or choice lists.
  • Page locators are optional. When used, page locators should appear on each page containing the train.
  • Page locator text is read-only, such as "Step 2 of 5".
  • A page locator choice list is populated with both step numbers and names for all enabled steps, such as "Step 2 of 5: Employee Address", and allows users to jump more than one step at a time.
    • In non-sequential processes, page locator choice lists display all steps in the process.
    • In sequential processes, page locator choice lists display all previous steps, the current step, and the next step, but do not show later steps unless the user has jumped back to a prior step.
      • For example, if the current page is step 4 of 10, then the choice list includes steps 1 through 5, but does not include steps 6 through 10. However, if the user jumps back to step 2, the choice list may continue to display steps 1 through 5, since they have been visited.

A train button bar with page locator label

Train Button Bar with Page Locator Label

A train button bar with page locator choice list

Train Button Bar with Page Locator Choice List

Usage:

  • Page locators of both types are recommended only when adequate horizontal space is available.
  • Development teams should use a page locator choice list rather than a page locator label when:
    • The process is completely non-sequential, or
    • Allowing users to jump more than one step in a sequential process does not cause excessive data dependencies and error handling.
  • Step names in page locator choice lists should be shortened (not truncated) to avoid wide choice lists. For directions, see Shortening Titles and Headers in the Language in UI guideline.
  • If a train contains skipped steps, the skipped steps should appear disabled in the page locator choice list. For more information on skipped steps, see Train Stops earlier in this guideline.
  • When the user jumps back more than one step and makes a change, data dependencies may invalidate choices already made in subsequent steps. See Data Dependencies in Sequential Processes below for details.
  • In a subprocess, the page locator choice list contains only the subprocess steps, not those of the main process. See Drill Down to Subprocesses for details.

Data Dependencies in Sequential Processes Bookmark this Heading Return to Top

When the user jumps back more than one step and makes a change, data dependencies may invalidate choices already made in subsequent steps. If processes have such data dependencies, developers must either handle the dependency with a combination of messaging and Help text (see the Message Framework and Help Framework guidelines), or must allow jumps of only one step at a time.

For example, the user advances to step 5, jumps back to step 2, and changes data that affects dependent data in step 3. As a result the user cannot jump forward to steps 4 or 5, but is forced to go to step 3.

To handle the dependency:

  • Whenever the user jumps backwards, consider displaying a Warning message saying that, "If you make changes in this step, you may need to redo your work in the following steps:" It is also recommended to associate Help text with each component that can cause a data dependency. The text can read, "Changes made here affect data in following steps."
  • If the user then advances to the next step, remove all forward navigation options beyond the step that has become invalidated by the data dependency.
  • If the user makes changes and tries to return to any subsequent page other than the next page, display a Warning message with options to go back or continue forward. See the table below for details on navigation options with dependencies in different locations.

Warning Messages for Data Dependencies Bookmark this Heading Return to Top

Warning message dialogs may provide different message text and action/navigation buttons depending on the location of the data dependency in relation to the current page. The Warning message must explain the results of each choice. The following table shows the permutations:

Location of Dependency Action/Navigation Buttons in Message Dialog Result of Choice Notes
Next step "Go Back to Step {X}" User reviews changes in Step {X}; all prior navigation options remain available Step {X} is the step where change influenced a dependency in a later step.
"Continue at Step {X+1}" User confirms changes in Step {X}, and continues to Next step; forward navigation is then limited to Step {X+2} User can only advance one step at a time, so any additional dependencies in later steps are handled.
Single step subsequent to Next step "Go Back to Step {X}" User reviews changes in Step {X}; all prior navigation options remain available  
"Go to Step {X+n}" User confirms changes in Step {X}, and continues to subsequent step with dependency; forward navigation is then limited to Step {X+n+1}
Multiple steps subsequent to Next step "Go Back to Step {X}" User reviews changes in Step {X}; all prior navigation options remain available  
"Continue at Step {X+1}" User confirms changes in Step {X}, and continues to Next step; forward navigation is then limited to Step {X+2}
"Go to Step {X+n}" User confirms changes in Step {X}, and continues to subsequent step with dependency; forward navigation is then limited to Step {X+n+1}

Drill Down to Subprocesses Bookmark this Heading Return to Top

Purpose: Subprocesses allow users to perform a task that is not a directly related to the parent process.

Example: When creating a purchase order in a guided process, it may also be necessary to create a new vendor or shipper in a subprocess.

Description:

  • A subprocess is essentially an expansion of the main process, rather than a branch within the main process. When the user is done with the subprocess, the user should be returned to the main process.
  • FusionFX supports two types of subprocesses:
    • Subprocess as Train Stop: Completing the subprocess completes all input for the parent train stop. On completion of the subprocess the user continues directly to the next stop in the parent process. For example, the parent process could be an online training course, with each chapter of the course as a subprocess.
    • Subprocess Launched within Page: Provides additional input for the parent train stop. On completion of the subprocess the user returns to the parent train stop. For example, when modifying a user account profile, the user may launch a subprocess to edit bank or credit card information.

Usage:

  • All subprocess page titles should use the format: "childProcessName: stopName". The parent process name may be displayed in the page's breadcrumbs.
  • Nested processes are typically multi-step subprocesses with a subprocess train.
  • Optional subprocesses may consist of any of the following:
    • Single step or two-step subprocess displayed in a modal dialog.
    • Two-step subprocess displayed in the main page, with the parent train shown, but all stops disabled except the current stop.
    • Multi-step subprocess displayed in the main page with a subprocess train, and parent train icons and text.
    • A composite page with Subtabs, or with navigation links in a vertical Local Context Region.
  • Users complete or cancel a subprocess with action/navigation buttons.
    • When the subprocess is displayed in the main page, it should include a "Continue" button to complete the subprocess (instead of using the same button that completes the parent process), and a Cancel button to return to the main process and abandon any subprocess changes.
    • When the subprocess is displayed in a dialog, the dialog should include standard OK and Cancel buttons.

Confirmation Message Bookmark this Heading Return to Top

Purpose: A confirmation message shows that changes made in a guided process have been committed to the database or submitted to workflow for approval.

Usage:

  • Confirmation messages are displayed in dialogs.
  • It is important to analyze the frequency of use of the application, and the users' experience level to determine whether a confirmation message is necessary. Consider providing confirmation messages when:
    • Users will be unsure that changes have been saved, especially for longer tasks.
    • Changes made to data may have serious consequences.
    • It is necessary to provide a summary of the transaction for user records.
  • In general, consider providing transaction details in the confirmation message when:
    • The process generates a confirmation number.
    • Users may need to print or save a record of the transaction.
  • Confirmation dialogs contain an OK button to dismiss the dialog, and may contain a Printable Page button.
  • See Confirmation Messages in the Messaging guideline for more information.

Re-Entering a Completed Process Bookmark this Heading Return to Top

When a user creates an object using a train process, and then re-launches the process to modify the object, there are two methods to facilitate user changes without stepping through the entire process:

  • Display the train with all stops enabled (as a non-sequential process), so the user can choose the stop needing changes. After the user changes data in a step, later steps in the sequence may remain enabled, or become disabled because of data dependencies between steps. Use this option when all train stops can be displayed at the same time.
  • Display a checklist page instead of a train, so the user can choose the step needing changes from the checklist. Use this option when multiple users may have privileges to modify the object, with different users editing different steps in the checklist concurrently.

A checklist page with all steps enabled, shown after re-launching a completed process, in order for the user to modify it.

Checklist Page with All Steps Enabled (Indicating a Process has Been Relaunched after Completion)