Configure product tour scenarios¶
You can configure the product tour scenarios to adapt it to your project needs, covering different onboarding scenarios.
Product tour scenarios are configured with YAML configuration files. Configuration is SiteAccess-aware, allowing you to create separate onboarding experiences for different back offices in multisite setups.
For more advanced customization cases that require PHP code, see Customize product tour.
Use the default provided configuration, available in config/packages/ibexa_integrated_help_tours.yaml, as a starting point that you can adjust to your needs.
Configuration structure¶
Configure product tour scenarios under the ibexa.system.<siteaccess>.product_tour key.
Each scenario has a unique identifier and contains steps, which in turn contain blocks.
Basic configuration structure of a scenario:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | |
The product tour scenarios are meant to be translatable.
It's recommended to use translation keys instead of literal values in the YAML configuration, and provide the translations separately.
Use the ibexa_integrated_help translation domain.
For all the examples below, you can provide the translations by creating a translations/ibexa_integrated_help.en.yaml file with the following content:
1 2 3 4 5 6 7 8 9 | |
To insert a line break into a translation, HTML encode the <br> entities to <br/>.
Scenario configuration¶
Each scenario must specify its type and can optionally restrict access by user groups.
Scenario display order¶
The order of scenarios in the configuration file determines the order in which they are evaluated and, if the right conditions are met, displayed.
For general scenario, the scenario appears at the earliest opportunity (on any page after logging in), with an exception of the user settings area.
For targeted scenarios, the scenario begins if the target element is found in the DOM when the page is loaded. Targeted scenarios don't trigger in the user settings area as well.
To control where a targeted tour appears, ensure that the first step targets an element unique to that specific page. You can target elements that appear after a user action (for example, modals like content browser), but the first step's target must be present in the DOM when the page is loaded.
Once a scenario ends, the system evaluates the next scenario from the configuration and, if applicable, displays it.
Scenario type¶
Set the scenario type to either general or targetable to control how the scenario is displayed.
1 2 3 | |
Scenario title¶
Use the optional scenario_title_translation_key field to provide a human-readable label for a scenario.
This label is displayed in the user settings page where users can reset their product tour progress.
1 2 3 4 | |
If the translation key is not set, the raw scenario identifier is used as the label.
Translations must be provided in the ibexa_integrated_help translation domain (for example, in translations/ibexa_integrated_help.en.yaml).
User group restrictions¶
Restrict scenario visibility by excluding specific user groups by using their content remote IDs:
1 2 3 | |
When creating new back office user groups, you should decide whether the existing product tour scenarios should be available for the new user group. If not, add the new group to the exclusion list.
Warning
If a scenario contains information meant only for specific group of users, always use the user_groups_excluded setting to exclude other groups.
Don't rely only on UI access restrictions to control the access to scenarios, as a malicious internal user could trigger and preview them outside of the intended place.
Step configuration¶
Steps define individual instructions within a scenario. The configuration differs based on scenario type:
General scenario steps¶
General scenario steps display centered modals and support the background_image setting, allowing you to set a shared background image for each step.
For the background, you can use an absolute URL or place your image in the public directory and provide the path relative to it.
To resolve the path relative to the site root, prefix it with /.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Targeted tour steps¶
Targeted tour steps highlight specific UI elements by using CSS selectors.
You can select a specific element by using the target setting.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
If a step's target element doesn't exist on the page, the step isn't displayed and the scenario is stopped. Ensure your configuration matches the actual DOM structure to avoid broken scenarios. Use unique selectors to avoid triggering your scenarios on other pages.
Interaction modes¶
Select how the scenario step interacts with the target element by using the interaction_mode setting.
Targeted steps support three interaction modes:
TODO: 2 pane screenshot here, showing the UI for each of types.
Note
Clickable and draggable modes are designed for single actions only (buttons, links). You can't select an entire form. If the interaction with the highlighted element results in redirection to a new page or opening a modal window where the previous target element can't be found, the "Previous" navigation button won't be displayed.
Standard mode:
The default value. A tooltip attached to specific element on the page is displayed. Users continue the scenario with Previous/Next buttons:
1 2 3 4 5 6 7 8 | |
Clickable mode:
A tooltip attached to specific element on the page is displayed. Users continue the scenario by clicking the highlighted element.
1 2 3 4 5 6 7 8 | |
Draggable mode:
A tooltip attached to specific element on the page is displayed. Users continue the scenario by dragging the highlighted element.
1 2 3 4 5 6 7 8 | |
You can use this mode only with HTML elements that have the draggable attribute set to true.
Block types¶
Blocks are content elements that make up each step, available both for general and targetable scenarios.
Seven block types are available for building step content, and a scenario step must contain at least one.
If multiple blocks are defined for a step, they are displayed one after the other.
TODO: Step screenshot with all 7 blocks available?
Title block¶
Display bold, prominent titles:
1 2 3 | |
Text block¶
Display regular text content:
1 2 3 | |
Link block¶
Add external or internal links:
1 2 3 4 | |
List block¶
Create bulleted lists with title:
1 2 3 4 5 6 7 | |
The title_translation_key property is optional.
Media blocks¶
To provide data to the media block, provide absolute URLs or place your image or video files in the public directory and provide the path relative to it.
To resolve the path relative to the site root, prefix it with /.
Image block¶
Embed images inside the step.
You can provide alternative text by using the alt_translation_key property.
Assuming a public/img/diagram.jpg image exists, set the configuration value to /img/diagram.jpg.
1 2 3 4 | |
Video block¶
Embed video content by using the video HTML element:
1 2 3 4 | |
Custom Twig template block¶
For advanced content, use custom Twig templates that allows you to fully control the styling of the block:
1 2 3 | |
Create the dedicated template, for example in templates/custom_template.html.twig.
1 2 3 | |
and provide the required translations in translations/app.en.yaml:
1 | |
Configuration examples¶
Example 1: General welcome tour¶
The following example showcases all the built-in block types for a general scenario consisting of a single step.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | |
Example 2: Targeted feature tour with interactive steps¶
The following example showcases the three interaction modes of a targetable scenario building an onboarding scenario for the customizable dashboard:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | |
To learn how to customize your scenarios even further with PHP code, see Customize product tour.