Using FreeFlow navigation

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 path exists, they system should support the user in navigating the application, keeping track of the path they have travelled and current status in the application as well. To help achive this we have know introduced the FreeFlow navigation.

By applying specific construcs of Flows, pages and containers the FreeFlow mechanisme 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 want 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 that have to be used to use this type of navigation and to use the validation engine differently
2. We created a new navigation menu which is a specific container implementation, that works in conjunction with the new flow types and the validation engine
3. The validation engine handles all validation rules as non-blocking when use FreeFlow. Validations on read-only fields or attributes will be executed by the validation engine.

The new flow typs and the new containertype can be found in the Blueriq Basic Modelling Library. The validation has been changed but only internally, so no specific installment of configuration has to done whether you want to use the FreeFlow or not.

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

How it used to be before FreeFlow

Before the availability of the FreeFree flow 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 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 or not possible.
• 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_Dashboar_FlowWidget and AQ_Dashboar_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)