Common Layout Configuration
This section explains how to define the parts of the layout that is common to all the pages of your journey.
1. JSON Schema Support & Setup
Before starting, please ensure that you have set up the JSON schema for your configuration files. Refer to the relevant guide for your journey type: classic journey, split journey, or multi-tenant journey.
2. Header
2.1. Header Actions
You can specify Building Blocks that will be used as header actions in your generated application by adding them to the frame.header.actions property of your journey configuration. These Building Blocks can be configured very similarly to the ones under pages.
Any Building Blocks being displayed as a header action should not influence the height of the header, meaning that to display them properly, their height should be equal or less than the header height.
You can use ACL rules for these Building Blocks. All Header Action Building Blocks will be placed under the ACL resource header-actions. If the Building Block in the below example provided an ACL resource called button, this ACL resource could be hidden using the ACL resource path header-actions/contact-us/button.
{
"frame": {
"header": {
"actions": [
{
"package": "@allianz/building-blocks-fnol",
"module": "FnolContactUsModule",
"selector": "bb-fnol-contact-us",
"id": "contact-us",
"resources": {
"buttonType": "small",
"retailContactUsData": {
"call": "tel:123456789"
}
}
}
]
}
}
}2.2. Header Logo
Per default, a click on the page logo inside the header will trigger a reload of the current journey. You can change this behavior by defining a HEADER_LOGO_LINK_URL inside your environment variables.
3. Navigation
3.1. Sections
The frame configuration allows you to specify the navigation section for the journey. You can group multiple pages into single sections.
Here is an example configuration to group pages B and C into one section and to have page A and page D on separate sections with custom names.
{
"frame": {
"navigation": {
"sections": [
{
"id": "my-first-section",
"label": "My First Section",
"pages": ["my-page-a"]
},
{
"id": "my-second-section",
"label": "My Second Section",
"pages": ["my-page-b", "my-page-c"]
},
{
"id": "my-last-section",
"label": "My Last Section",
"pages": ["my-page-d"]
}
]
}
}
}By assigning the pages, the navigation can highlight the current section based on the currently shown page. It can also mark a section as completed, when all pages of a section have been visited by the user.
In the following example, the user visited the my-page-a, is currently either on my-page-b or my-page-c and has not yet visited my-page-d. This leads to the My First Section marked as complete, the My Second Section being highlighted as the currently active one and the My Last Section being marked as not yet visited.
If you navigate to a page that is not part of any defined section the navigation will not be able to show any section as the current one.
💡 There is a limit of 7 sections by design. If this limit is exceeded the app generation will fail with an error.
💡 You can hide the navigation bar for the whole journey by setting the
sectionsfield to an empty array.
{
"frame": {
"navigation": {
"sections": []
}
}
}However, if the sections is not provided at all, TALY will automatically generate the navigation sections based on the pages listed in the journey configuration.
Conditional Navigation Sections
In certain use-cases you want to be able to remove specific Navigation Sections from the Progress Indicator dynamically. You can do that using conditional Navigation Sections. Each section accepts a visibleIf property to provide a JSONPath expression or a PFE_EXPRESSION condition that references one or more values from the application's state. The section will then only be shown if that value is truthy.
Example:
{
"frame": {
"navigation": {
"sections": [
{
"id": "my-first-section",
"label": "My First Section",
"pages": ["my-page-a"]
},
{
"id": "my-second-section-with-jsonpath-expression",
"label": "Final Section",
"pages": ["my-page-b", "my-page-c"],
"visibleIf": "$['show-my-second-section']"
},
{
"id": "my-third-section-with-pfe-expression-condition",
"label": "Final Section",
"pages": ["my-page-d"],
"visibleIf": "!({$['my-bb'].person.firstName} == {$['something'].items[0].id})"
}
]
}
}
}With these conditional sections it's possible to reflect complex flows, where the user can skip entire sections depending on the application's state.
⚠️ The Navigation Section configuration does not affect the page flow, so you need to make sure that your PFE configuration matches this Navigation Section configuration.
In the above example, this means that ifmy-second-section-with-jsonpath-expressionis hidden, then the user must not be able to navigate tomy-page-bormy-page-c. At that time, these pages can not be associated with a section, so if the user ends up in one of these pages the Navigation area won't be able to highlight any section.
💡 Journeys may still not have more than 7 sections. However, conditional sections are excluded from the automatic check that happens during the journey generation. You need to manually ensure that there are no more than 7 sections shown at the same time.
3.2. Next Button
By default, the "next button" on the page is always enabled. The page will automatically scroll to the first invalid form control, when the user triggers the button.
If you want the "next button" to be disabled until the page is completed and valid, you can use the nextButtonDisabledWhenPageInvalid flag.
{
"frame": {
"navigation": {
"nextButtonDisabledWhenPageInvalid": true
}
}
}4. Content
In an Expert journey, the content alignment is configurable. By default, everything in the journey is left-aligned. However, it's possible to restrict the content (still left-aligned) to the center of the page. To achieve this, add the following configuration to your pages JSON configuration:
{
"frame": {
"content": {
"centered": true
}
}
}Take a look at the Frame Content documentation for more details.
5. Footer
It's possible to provide your own copyright text, a collection of links, and a subline in the footer of your journey.
{
"frame": {
"footer": {
"copyrightHolder": "Allianz",
"links": [
{
"external": true,
"label": "Terms of Use",
"path": "https://www.allianz.com/en/terms-of-use.html"
}
],
"subline": "Allianz Australia Insurance Limited ABN 15 000 1111 222. AFS Licence No. 234567"
}
}
}For more details take a look at the underlying interface: https://taly.frameworks.allianz.io/interfaces/FooterConfiguration.html
You can use the ACL tag taly-frame-footer in an ACL rule to show or hide the footer based on runtime conditions. However, if you want to permanently hide the footer in your generated journey, we recommend using the chromeless flag in the frame configuration of your journey instead of using ACL (more info here).
6. Additional Frame Features
6.1. Spinner
The spinner appears and blocks the entire screen if an action (network request or navigation) takes more than 1 second.
To activate the spinner in your application set frame.spinner to true in the frame configuration, like so:
{
"frame": {
"...": "...",
"spinner": true
}
}The spinner component shows a configurable label to provide a short description of the currently active service activator to keep users informed about what the system is doing.
💡 By default, TALY offers the generic localizable message:
Loading.... Please ensure to replace this default, if necessary, to provide a great user experience.
This label can be configured by providing a displayMessage property in the service activator config. The value of displayMessage can be set in two ways: You can use an object with the keys headline (mandatory) and subline (optional). Alternatively, you can directly pass a string to displayMessage, which sets the headline of the spinner implicitly. If you want the label to be translatable, you can add the @localize. prefix in front of the desired message.
Each spinner label will be displayed for at least 1 second and then switched to the new incoming message. Once all service activators and actions are done, the spinner component will be hidden immediately as illustrated below:
Timeline of busy app: |----|----|----|- (|---- = 1 second)
Active Service Activator: A B C D
Resulting spinner label: A B C -6.2. Chromeless
We have a flag to generate an application without header and footer.
To hide header and footer in your application set frame.chromeless to true in your journey's frame configuration, like so:
{
"frame": {
"...": "...",
"chromeless": true
}
}6.3. Work In Progress Banner
You can show a "Work In Progress" status banner on all pages of your journey by enabling the workInProgressIndicator option in the root of your pages JSON file (application JSON file for split journeys):
{
"workInProgressIndicator": true
}By default this option is set to false. If it is set to true, it shows an english text WORK IN PROGRESS on the top of the application:
When extracting your journey translation file, there will be an entry corresponding to the @@wip-banner-text i18n key where you can add your translation.
💡 Once the flag is set, the message is shown for the whole journey and cannot be configured for each page separately.
6.4. Offer Code
To show an Offer Code below the Action button(s) you need to tell TALY where to look for your offer code:
{
"frame": {
"offerCode": {
"stateKey": "$.path.to.offerCode"
}
}
}As soon as there is a value at the specified location in the PFE state, the offer code will be visible on all pages. You can hide it with ACL by targeting <your-page-id>/offer-code, if necessary.
💡 Please note that this feature is only available in Retail journeys.
7. Data Model
For further details please see the corresponding data model.