This Is How Cognigy Implemented Digression
Users Should Not Be Constrained To Fixed Dialog Paths
Introduction
Digression is a common and natural part of most conversations. The speaker, introduces a topic, subsequently the speaker can introduce a story that seems to be unrelated. And then return to the original topic.
Digression can also be explained in the following way… when an user is in the middle of a dialog, also referred to customer journey, Topic or user story.
And, it is designed to achieve a single goal, but the user decides to abruptly switch the topic to initiate a dialog flow that is designed to address a different goal.
Hence the user wants to jump midstream from one journey or story to another. This is usually not possible within a Chatbot, and once an user has committed to a journey or topic, they have to see it through. Normally the dialog does not support this ability for a user to change subjects.
Often an attempt to digress by the user ends in an “I am sorry” from the chatbot and breaks the current journey.
Hence the chatbot framework you are using, should allow for this, to pop out and back into a conversation.
For example, the user might be ordering a new phone, but switches topics to ask about tablets. Your dialog can answer the question about tablets, and then bring the user back to where they exited the customer journey for ordering a phone.
This approach gives your user a true unstructured conversation experience, being able to switch from one topic to another. This is analogous to a human conversation. Hence the user can change topics, following a dialog path or journey about the unrelated topic to its end, and then return to where they were before.
Again, this simulates a true, natural human to human conversation.
Why Do Chatbot Development Frameworks Not Scale Well?
One characteristic of Cognigy is that there are often multiple ways of implementing a conversational principle. Initially this might seem like overhead, but the principle comes into its own when it comes to scaling.
Many Conversational AI development frameworks do not scale well due to primarily two reasons…
The first being, the absence of design & development affordances. This is the case with no-code and low-code environments. There are instances where a particular design implementation cannot be implemented due to the absence of design/development canvas elements.
Obviously pro-code environments do not suffer from this ailment, but then there are other challenges.
When the no-code/low-code environment does not have the affordance for a certain implementation, existing features need to be clobbered together. And via improvisation the desired user experience is achieved. However, this is where the impediments surface with scaling and growing the conversational experience.
The second scenario is having a singe, one way of doing things, and this is the most common approach; having one way of doing things. Having one design/development affordance per perceived conversation challenge and scenario is fair. But having more that one possible affordance or option to approach a design challenges give developers/designers a chance to approach challenges with specific configurations of functionality.
For instances, if 10 design challenges are addressed with 3 options or approaches each, the number ways of solving grows exponentially. And this contributes to the scalability of the environment.
Taking all of this into consideration…Cognigy has three approaches…
Got To Flow Node
The Go To dialog node, or flow node in Cognigy language, allows the dialog to jump to another flow. This jump is obviously predicated on a certain condition which needs to be met.
Not only can the destination flow be defined, but also the destination node. The dialog can continue, or be set to wait for input on the destination flow.
The toggle exist to: “Absorb the Context of the target Flow into the current Context”. This really depend if you see the conversation digression actioned by the Go To as a new conversation or a digression.
In the example below, you can see on the left the context of the target flow is absorbed into the current context. On the right it is not the case.
An real-world requirement might be if you see the digression from one flow the the other as one conversation, and rather want to keep the context separate.
In VoiceXML and other environments there is a notion of a sub-dialog, where the dialog is sent to a sub-dialog and subsequently returned to the calling dialog.
This is handy to use the sub-dialogs as extensions, functions or components which can be called and then the dialog returns. This is not how Go To Flow Node is designed.
However, something similar can be done with the Execute Flow node.
Execute Flow
Here we have an Execute Flow where you run through a called Flow once and then start back of the original Flow.
This is analogous to sub-dialogs in VoiceXML, where a routine is called and control is returned to the calling flow.
Flows can act as functions, with specific aim of being re-used by other larger conversational flows. This reminds of how IBM Watson Assistant initially intended to use Action Skills within Dialogs Skills.
As seen above, The flow which is called is defined with the specific node where the conversation needs to drop into. Once the node is executed, control is returned to the calling node.
Attach Flow
Flows can simply be Attached to each other, in order to recognize the intents built in other locations.
The Branches flow is attached to Balances NLU. This means from the balances flow, the user can digress to branches. This is a good approach if your suspect or see users want to digress from one intent to another.
Above, a conversation where the user can digress from the Balances flow to the Branches flow. The user cannot digress back as the branches NLU does not have balances attached.
Conclusion
The easy approach is to structure the conversation very firmly from the chatbot’s perspective. And funnel the user in and out of the conversational interface, this might even present very favorably in reporting. But the user experience is appalling.
Overly structuring the conversation breaks the beauty of a conversational interface. Unstructured conversational interfaces is hard to craft but makes for an exceptional user experience.
One of the reasons is that user’s are so use to having to structure their input, that they want to enjoy and exercise the freedom of speech (spoken or text), which can lead to disappointment if the expectation of freedom is not met.
Digression is a big part of human conversation, along with disambiguation of course. Disambiguation negates to some extent the danger of fallback proliferation where the dialog is not really taken forward.
