Auto news on Youtube Oct 31 2017

After defining intents and entities, as a chatbot creator, you would typically focus

on designing the dialogue.

Creating a dialogue defines how your bot will respond to what the user is asking.

Dialogues in Watson conversation are defined visually through a user interface that is

structured around the concept of nodes.

Each node has a name, a condition, and one or more responses.

There are a few more bells and whistles available, but at its core we're talking about name condition

and responses.

The dialogue starts executing from the first node at the top.

If the condition is met, it will reply to a user with a response specified in that node

and stop the execution until the user has entered some new input.

If the condition is not met, it will skip the response and proceed to consider the next

node below.

If this second node's condition is met by the user's input, the nodes response will

be sent to the user.

If the condition is not met, we continue to the next node, and so on.

Essentially, the execution from top to bottom continues while the node conditions fail to

meet what the user inputs has entered.

For the condition you can use intents, entities, a specific entity value, and a few reserved

conditions like welcome, Anything_else, true and false.

You can also combine intents and entities with AND and OR logical combinations?

Typically you'd want to greet the user as they arrive.

So the first node might use a special word, "Welcome" as the condition.

Ensuring that that particular node is executed the first time that the user starts interacting

with the chatbot.

The response, we configured in that particular node, will be our initial prompt that greets

the user, inviting them to chat with our chatbot.

If the user input doesn't match any of the node's conditions, by default no response

will be provided to the user; and this isn't great from a user experience standpoint because

nobody likes to be ignored.

So it's a good idea to have also a node at the very bottom of the dialog that is always

executed if the user input failed to satisfy the conditions of any of the other nodes above.

The failover condition for this node is called Anything_else.

When will this note be executed?

In practice, when our bot has failed to understand the user.

So in this node we should have an appropriate response that invites the user to rephrase

or maybe suggest some queries that we know our bot can handle.

If we only included a single response in this node the bot could get annoying rather quickly.

Imagine seeing I don't understand over and over again.

Hopefully our user won't trigger the Anything_else node too often.

But it would be good to have multiple responses with some variation to them, even if they

all express the same concept.

It's a small detail that can affect the user experience and now intelligent our chatbot

appears to be.

These responses are executed sequentially by default, so the first time the user asks

for something that our chatbot doesn't understand, our Anything_else node will be hit, and it

will show the first response to the user.

When this happens again because the user enters something else that we don't understand, the

second response will be shown instead, and so on.

It's also possible to set the order as random, by clicking the "Set to random" link under

the responses block.

These two nodes handle such common scenarios that they appear by default when you create

a new dialogue.

That's quite handy since all you have to do is then customize them with what you want

in the prompt and what kind of I don't understand responses you want to include and send to

the user.

It's also possible to create children nodes.

These are considered for execution only when the parent node's condition is met first.

Normally the flow of execution for a particular user input is stopped once the condition is

met by one node.

We send back a response, wait for more input, and then restart the cycle evaluating this

new input against the conditions in our nodes top to bottom.

However if the matching node has children nodes, the execution continues with its children,

not with the main nodes.

If a parent node has multiple children, they are considered top to bottom.

It turns out, this is quite useful in practice.

In fact, it's common to have a parent node ask for further clarification to the user

in its response, and then handle the specific information provided by the user in its children

nodes.

For example the parent node might be triggered by the user asking, "I'd like flower suggestions

for a special occasion."

It doesn't provide information about which specific occasion, so the response from the

node might be, "which occasion?"

When the user replies with say, "Birthday," the child node that matches the

birthday condition will be executed and its response, displayed to the user.

For this to work, we'll need multiple children nodes, each having as its condition an Occasion

value like anniversary, funeral, etc., each having an appropriate response.

Alternatively, we can take advantage of the fact that responses themselves can have conditions

attached.

A node can have multiple responses that are only processed if their own condition is met.

So, instead of having multiple children nodes, one for each occasion, we could have a single

node that provides different responses, depending on which Occasion value is provided in response

to our request for clarification.

Children nodes can have children nodes of their own, giving us the ability to create

a quite complex dialogue flow.

Furthermore we have the ability to jump from one node to another.

Something that can complicate our dialogue flow, but, which will be necessary at times,

in order to accomplish what the chatbot needs to do.

Don't worry if this is a bit overwhelming?

We covered a lot of ground to give you a theoretical foundation.

When we create our chatbot in the next module, it will become much more familiar with how

we use parent, children nodes, conditions, and responses in order to define a convincing

conversation flow for our chatbot.