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 high level view of the architecture and sequence
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.
There is a range of UI options for Nuxeo based applications. The easiest and most integrated, is using Studio to define UI layouts. You can apply CSS, and various styling options without having to code any additional HTML or application logic. You’re customizing what Nuxeo already provides and you work directly on the Nuxeo system. If your application requires more control over the front end or is specialized in particular tasks, it would be better to define your front end from the ground up. By using REST calls and our Javascript API, which wraps packaging HTTP calls, you can run all the Automation Chains from an independent application. This gives you full control over the UI while still taking advantage of all that Nuxeo has to offer. You can add any other application functionality that is not necessarily acting on Nuxeo content.
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.
In our example solution, each screen in the flow is defined with a different DIV with an ID matching the ID of the workflow task. From the Task Node definition in Studio we also see the field values required and code those into the screen DIVs. We also have 2 REST calls for processing the screen. When a screen is submitted, the Javascript on the UI using our JS Client makes a call to a Automation Chain we defined to complete the Task (Screen). It takes the field values as input parameters. The chain then copies the values to the underlying document, and calls a Complete Task on the Screen Node. The transition conditions are evaluated and the workflow moves to the next node, which becomes the next current screen. Our UI reloads and with another REST call, gets the ID of the current Task (Screen) to display. In our example we simply show the DIV with that ID and hide all others. We are now on the next screen in the Screen Flow and the process continues until the screen flow ends.
Here is a sample DIV section from the UI as well as the Javascript code snippet using the Nuxeo API:
<!-- Personal_details -->
<div id="Task4739" class="noDisplay node">
<p>
My name is <input type="text" class="infoField" name="ad:firstName" value="${Document['ad:firstName']}" placeHolder="first name" required />
<input type="text" class="infoField" name="ad:lastName" value="${Document['ad:lastName']}" placeHolder="last name" required />
, my address is <input type="text" class="infoField" style="width: 700px; font-size:smaller;" name="ad:address" value="${Document['ad:address']}" placeHolder="address" required />
</p>
</div>
nxClient.operation("REST_getCurrentTaskId")
.context({"applicantDataDocId": gMainDocId})
.execute(function(inErr, inData) {
if(inErr) {
displayRestError("Get the current task", inErr);
} else {
gCurrentTaskId = JSON.parse(inData).taskId;
gAllDivs[gCurrentTaskId].removeClass("noDisplay");
// Now use the TaskId to display the appropriate DIV in whichever way you want
...
}
});
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.