Description

Normal flow navigation is meant to guide the user through a form or an application along a predefined route. However, when no such predefined route exists, they system should support the user in navigating the application, by keeping track of the path they have travelled and current status of the application as well. To help achive this we have now introduced the FreeFlow navigation.

By applying specific constructs of flows, pages and containers the FreeFlow mechanism can be applied using the building blocks we all already know. An adaptation in the validation engine of the Blueriq Runtime helps the user to navigate freely, while being attented to validation messages on pages, that can be solved along the way whenever the user wants to or is able to. After which the whole flow can be completed.

Three parts of Blueriq are used to implement the FreeFlow navigation:

  1. There are two specific flowtypes required to use this type of navigation and change to behaviour of the validation engine while in these type flows.
  2. A container type to use as the navigation menu,
  3. An event named 'previous' to support flowing back to the last visited menu item

To not interrupt the user's flow, when using the free flow mechanism, the validation engine handles all validation rules as non-blocking. An additional change in the validation engine when using free flow is the validation of read-only fields. The use case for such a validation is for read-only attributes that represent a conclusion based on multiple inputs. For instance a user can make deposits from multiple accounts, but the sum of the deposits must be 10.000 euros or more to proceed. In that case a validation on the read-only field 'sum of the deposits' could be used.

The required flow and containertypes can be found in the Blueriq Basic Modelling Library. The 'previous' event can be defined in the model to support the automatic flow back. The changed behaviour in the validation engine is triggered when the application enters the flow of type FreeFlow, it's behaviour changes back to 'normal' navigation when that flow is finished. 

The basic construct in which FreeFlow should be modelled is as depicted in the figure below.

Because of the 'previous' event, which will route the user back to the last visited page, the return route is not modelled when using free flow navigation. Instead the return button on the page gets a Validate and Continue event named Previous. In free flow we can use the validate and continue event type while navigating the menu items since the validations will not hinder the user's flow but will only assist in keeping track of the pages the user has visited, but that contains invalid or incomplete information.

Each free flow menu item will correspond to a flow of type SinglePageFlow. This suggests that the single page flow can only contain a single page, which is not entirely true. We do expect the single page flow to have one 'landing' page for the menu item. From that landing page users can navigate to other pages in the single page flow, but they can not navigate to other menu items while doing that. So in the model the menu should be disabled. A typical use case for this type of navigation is when the menu landing page contains an instance list and new instances will be added on a separate page. In this case the menu can temporarily be disabled when the user fills out the information in the instance and returns to the menu landing page to continue the free flow.

How it used to be before FreeFlow

Before the availability of the FreeFlow in Blueriq you were also quite able to create such a navigation model. This however had a lot of drawbacks. To accomplish it a lot of boilerplate modelling had to be done, that didn't account to the actual business goal of the application. And because of all this boiler plate modelling, maintaining and testing your model grew in effort significally. 
With boiler plate modelling we mean that:

  • the navigation container had to be custom made, including a front-end theme with extensive conditionality
  • the navigation 'options' had to be modeled, usually decision tables were abused for this (abused because it mixes business logic with interaction logic)
  • validation rules were commonly duplicated, for handling the blocking and non-blocking situations that the attributes had to be able to deal with
  • the flow model was overly complicated because all the options had to be explicitly modeled, also troubling the readability of the model and thus troubling maintainability
  • the navigation model had to be put into the domain, in order to model the decision tables and use it in the flows. Again mixing business knowledge with interaction knowledge

Having summed these items, it is understandable that when new requirements for this application arise it makes it that much more error prone and labor intensive in implementation ánd testing.

When to use Free Flow navigation in Blueriq

Good use cases for the Free Flow navigation concept are:

  • when the user might not be experienced in the topic at hand in the form and wants or needs to be able to fill in all information known to him as it arises
  • when there are a fixed number of high level topics that can be addressed by the user in any order. The navigation menu only allows for one levels of topics, sublevels are not supported.
  • when validations should not limit the user in getting the known information into the form

When to use traditional navigation in Blueriq

  • when linear navigation is fitting for your form and user experience
  • in DCM applications with dashboarding it is questionable if FreeFlow navigation should be applied. A good UX design has to be made in order to combine the two.
  • in other combined solutions where the Blueriq flow might be part of a bigger design of different software component. Also here applies: a good UX design had to be made in order to combine the two.

Blueriq components that can not be used in combination with FreeFlow

  • external flows, because the external flow creates its own session it doesn't have the same validation context ánd cannot provide the same user experience as this session dóes apply blocking validation 
  • widgets using the AQ_Dashboard_FlowWidget and AQ_Dashboard_ProjectWidget. The same reasons as per the external flows apply.
  • applying a repeat condition to a SinglePageFlow. This flowtype is not meant to be repeatable (in order to create a undefined number of menu items in the AQ_NavigationMenu container)

Didn't find the answer you were looking for? Try the advanced search!