Recently, we did a rework of the user’s profile completion flow in our Drivy web and mobile applications. We went from a basic single screen form to a multi-steps one. The idea was to simplify the flow and ask only for the information needed depending on the user’s answers. As we had to deal with multiple possible paths, we decided to work on a little decision tree algorithm.
Let’s say that our decision tree is made up of multiple steps
and for every steps there’s one or several possible answers that we will call outcomes
.
If we know the path
, which is made up of outcomes, we will be able to find the next step.
The idea is to have a collection where the first element is a step class name and the second one is an object composed of the possible step’s outcomes. For each step’s outcome, we define a collection where the first element is a step class name and the second one is an object…and so on.
Let’s imagine that we need to ask if the user wants to rent a car or if they own a car and want to add it on the platform.
The step class would gather its possible outcomes and everything else related to it. For instance, in almost all of our steps we had to deal with a form so this is where we defined it. We could define a #can_skip?
method that could check if the step has already been filled, or could be skippable somehow. Doing this way, it becomes really convenient to define specific rules on steps.
Once we have our decision tree declared with all of its steps, we need to build a small recursive method that will find the next step according to the path
(cf figure 4).
And here you are, you can now iterate through the DECISION_TREE
, giving a path or not, to find the according next step.