Sometimes data gathering applications are best designed with a wizard-type screen flow. This usually makes the User Interface simpler while still gathering data. Complex form-centric applications involving complex rules, can benefit if they are made workflow-driven.
In this model, the user is presented with a set of question screens which appear conditionally, based on the data filled in or already known. This is defined by condition rules and can be defined as a workflow with various branches - breaking down complex data gathering into easy to work with chunks, ending with the complete set of gathered data. For example, filling in government forms which can be complex and require only a subset of fields. In this case, the system handles the rules for which questions to ask, the user doesn't see forms but easy to understand screens, and the process is simplified.
User is presented with a sequence of specific, easy to understand screens instead of an overwhelming form with many fields.
Nuxeo's inherent flexibility allows rapid creation of such a system. We will demonstrate this with an example of a wizard-based screen flow based on Nuxeo workflows. We will look at options for designing the UI, its loose coupling using REST calls, as well as graphical definition of the workflow rules using our web-based Studio tool.
Let's first look at the logic and data side of defining a screen flow. First, we define the set of data we want to gather and create a Nuxeo document to represent this. A workflow acts on a document, which is really nothing but a set of data in Nuxeo. The benefit of using workflow to define the screen flow as opposed to the traditional application-based approach with links is that you de-couple application flow from the UI and take advantage of the Studio tools to define the logic and data. It is a Model-View-Controller paradigm implemented with already existing and easy to work with Nuxeo tools.
A workflow will consist of screens represented as Task Nodes in the workflow graph. Each node can define a form with input fields, which can be directly required as data and be used for evaluating transition logic. Next, each node also defines conditions for transitions to the next node. The conditions can use system data, the input values, or already existing values in the base document.
Nuxeo Studio - graphical design of workflow, driving the gathering of data. Each node is a Screen and each transition is a condition.
Next, we define Automation Chains and associate with transitions as needed. A Nuxeo Automation Chain is a sequence of operations which can be fired off before or after a workflow node, during transitions, scheduled in the background or based on user events. In our use case example, we run some operations to copy data from each screen input to the underlying document. This allows a screen flow to reuse data as well as be abandoned and continued at another time. All functionalities in Nuxeo are based on operations, so anything that deals with Content Management can be accomplished during Automation Chains. The other important fact is that Operations and Automation Chains defined in Studio can be fired off by REST calls. This is how we’re going to link the UI to the underlying screen flow definitions.
GetCurrentScreenID (Automation Chain called by REST) - Base document is retrieved, current task/screen is retrieved, and a JSON object with the ID is returned back.
At this point, we have defined everything about the screen flow except the front end UI. We have the data fields, nodes corresponding to each screen and the required input, transition rules and associated operations.
Let’s take a look at how we implemented this screen flow use case using a more intermediate approach. Nuxeo provides a WebEngine framework using Freemarker templates. This eliminates data binding overhead, and being a server side code, gives full access to the Nuxeo memory space and the object tree, while still being a ground up UI design framework.
Rather than a tutorial, here we've shown the proper approach to design a Screen Flow application. We've taken advantage of Nuxeo Studio to develop everything with minimal overhead and by utilizing REST calls we've coupled the UI only by Screen/Task ID, so that the designer is free to focus on the User Experience. By maximizing the utility built into Nuxeo and Studio, the only coding required is for the look and feel of the front end. This is just one more example of the flexibility and usability that Nuxeo provides to let you accomplish your development goals more quickly and dependably, and taking advantage of the Content Management capabilities within another Use Case.