Simple Decision Trees in Bloomreach Experience

​ Bart Musters

​ 2017-10-16

 

Google Maps helps over 1,000,000,000 users navigate to the right destination. But, aren’t decision trees/wizards the real hero of the internet?

In August 2017, Danish insurance company, Topdanmark asked Bloomreach to migrate their whole website to Bloomreach Experience and use its out-of-the-box capabilities.

The website migration included their decision trees - sometimes also referred to as wizards.

A decision tree is a step-by-step guide to help navigate a user through a specific process. After every click, you get a new set of options and end up with the information you were looking for.

In the case of Topdanmark, the final step could both offer rich text and/or Enterprise forms.

So the team and I set out to create a decision tree component with the following requirements:

Requirements

• A headline can be defined for the first level

• Each item (button) can either lead to an output (end result) or to the next level with a title and new item

• It is possible to add multiple levels (and up to 6 items per level)

• The number of levels should be dynamic, depending on the chosen path (so one path can have 2 levels and another one can have 5)

• The last item determines the output, that can either be a form or rich content

Important implementation details

• Topdanmark provided the frontend (HTML, CSS, Javascript)

• The decision tree can be added as a component. This component extends from an Enterprise Forms component, to enable form submissions. In the component configuration, the root node of the tree has to be selected.

• All steps of the tree are rendered directly on the page. Using Javascript the next steps are made visible. The final step, with the rich text content and the form, will be loaded asynchronously. This is done using the doBeforeServeResource method that expects a UUID as a parameter in the URL.

• The depth of the tree is limited to 7, to avoid mistakes such as adding a link from a step to itself or its parent. Then an infinite loop can be created that will cause an OOM error and crash Tomcat.

• There are 2 document types: one for each decision step and one for the final step called "decision tree content blocks". In the content blocks document type, only content blocks can be selected (such as rich text or a form). The "decision tree" document type contains a title, child header, link pickers to children (also decision tree documents) and a link picker to a content block document. In the "decision tree" document type, either children should be added or a link to a content block document, not both

Pros

• A very intuitive solution which is easy to understand for editors

• It enables excellent performance so users don’t have to wait until the page or next step is loaded

• It’s flexible and easy to extend

• And it’s implemented without any customizations to the CMS

Limitations

• Javascript has to be enabled in the browser

• Since the form is loaded asynchronously it first needs to be initialized to enable Javascript features such as validation or the datepicker. This does not work OOTB with the Javascript from the Eforms demo. This part is also not yet completely fixed in the Topdanmark project.

• After form submission, the whole page is reloaded. The state of the decision tree has to be remembered if there is a problem submitting the form.

 

If you are interested in how to make a decision tree for your own project, check out the blog post by my colleague Jouke, with a detailed step-by-step description and code snippets.