[MUSIC PLAYING] DAN IMRIE-SITUNAYAKE:
Hey, everyone. I'm Dan Imrie-Situnayake. This is the third
of three videos that teach you the fundamentals
of Dialogflow, an awesome tool for building
conversational experiences. In this video, we're going
to talk about dialogue. The first two videos
introduced how we can use intents and
entities to capture what your users want to do
and the specific things they mention. But there's more to conversation
than making a single statement and getting a single reply. Conversation is a process
where two speakers negotiate meaning and understanding
through their back and forth. That back and forth over time
is what we call dialogue. For anything more than the
most simple experiences, you'll be building dialogue. So let's explore how
dialogue works in Dialogflow. There are two types of
dialogues we need to consider. We have linear dialogues
and non-linear dialogues. Linear dialogues are
used in the process of collecting all
the information necessary to complete
a required action, like booking an appointment
or placing an order. Nonlinear dialogue
is something closer to a real conversation with
branches, twists, and turns based on changes in context. Let's take a closer
look at linear dialogue. Imagine we're asking an agent
to book an appointment to repair a bike. Before the agent can help us
it needs to know a few things-- the type of service required,
the date, and the time. It might be that
the user provides all of this information
in one statement. I'd like to make an appointment
to repair a puncture tomorrow 4:00 PM. In this case, we now know the
type of service they need, the date, and the time so we
can satisfy their request. But what if the user only gave
us some of the information? I'd like to book an appointment
at 2:00 PM on Friday. We have the date and
the time, but we still need the type of service. Fortunately,
Dialogflow can help. When you add entities
to an intent, it's possible to mark
them as required. This means that if the
user doesn't say something in their first statement,
Dialogflow will automatically prompt for the
necessary information, and you can customize the
prompt so it sounds natural. We call this feature
slot filling. Let's say we mark service type,
date, and time as required. Since service type
is currently missing, Dialogflow will
now prompt for it. SPEAKER: What type of
service does your bike need? DAN IMRIE-SITUNAYAKE:
It has a puncture. SPEAKER: Thanks, you're
scheduled for a puncture repair this Friday at 2:00 PM. DAN IMRIE-SITUNAYAKE:
Slot filling can be incredibly powerful. You can support thousands of
possible conversation paths just by checking a few boxes. The user can even
go back and change things they've already set. Here's the same interaction
happening in a different way. I want an appointment. SPEAKER: What type of
service does your bike need? DAN IMRIE-SITUNAYAKE:
It has a puncture. SPEAKER: What date
are you available? DAN IMRIE-SITUNAYAKE:
How about this Saturday? SPEAKER: What time
would you prefer? DAN IMRIE-SITUNAYAKE: Actually,
could read 2:00 PM on Friday? SPEAKER: Thanks. You're scheduled for a puncture
repair this Friday at 2:00 PM. DAN IMRIE-SITUNAYAKE:
Linear dialogue can be pretty impressive. But it only works when
we have a specific set of facts we wish to collect. Non-linear dialogue
is something closer to a real-life conversation. When the user says
something, it's interpreted in the context
of what was said before. To illustrate, let's
see an example. I'd like to make an
appointment to repair a puncture at 4:00 tomorrow. SPEAKER: So I'm booking
you for a puncture repair tomorrow at 4:00 PM. Is that right? DAN IMRIE-SITUNAYAKE: Yes. SPEAKER: Should I
send you a reminder? DAN IMRIE-SITUNAYAKE:
Yes, please. SPEAKER: Will do. You on Friday. DAN IMRIE-SITUNAYAKE:
The conversation we saw includes two
yes/no questions. When the user answers
the first question, our agent knows the user
is confirming that booking. As a result, it asks
about sending a reminder. When the user answers
the second question, our agent knows they are
confirming the reminder, not the booking. To understand which
question is being answered and where in the
conversation we are, Dialogflow uses a
concept called contexts. For each intent, you can define
multiple input and output contexts. In this case, our
book repair intent has the output context
confirm repair. When a specific
intent is matched, it's output contexts
are attached to the current
conversation state. In this case, the
conversation's contexts now include confirm repair. Each intent may also
have input contexts. If an intent specifies the
input context confirm repair, it will only be matched
if the confirm repair context is currently
attached to the conversation. In our example, we have four
intents that match a yes or no from the user. But two of them are yes or
no to confirming the repair, while the other's a yes or
no to sending a reminder. We can use context to ensure
only the appropriate intent is matched. We add the input
context confirm repair to our repair.yes
and no intents. To the yes intent, we also
add the output context confirm reminder. Then we add the input
context confirm reminder to our reminder.yes
and no intents. Because of how we set both
intents input contexts, the repair.yes or
no intents will only match after the book repair
intent and the reminder.yes or no intents will only
match after the repair.yes. In addition to
acting as a filter, contexts apply a bias
to intent matching. So faced with two
options, Dialogflow will be more likely
to match a given user statement to an intent that
has a matching input context. Contexts expire automatically
after 20 minutes. And you can also specify
how many subsequent turns of conversation they'll last. You can also use an
intent output context to update or remove any contexts
that are currently applied. Contexts are extremely powerful. They can even be
used to store data, like the values of
parameters, and make it available to
subsequent intents. To learn more, visit
the docs via the link in the description. Another useful tool in our
quest to build conversations is the follow-up intent. It provides a shortcut for
a common usage of contacts. For a given intent, you
can add follow-up intents that will only be triggered
after the initial intent has been matched. You can use these to match
things like yes or no in answer to a specific question
posed by an intent, like in our earlier example. By making them specific
to a single intent, you avoid accidentally
matching any yes or no answers given elsewhere in
the conversation. Follow-up intents
make use of contexts, So you can use
them as a shortcut for this powerful feature. Another useful feature
is the fallback intent. Fullback intents are triggered
if a user's input is not matched to any of the
available intents. You can use them to
help guide the user in the right direction. Every agent comes with a
default fallback intent, and you can create
follow-up fallback intents that use contexts to
ensure that they will only be matched after a specific
intent has been triggered. So far, we've talked
about using Dialogflow's built-in capabilities to control
the flow of a conversation. However, there
are always moments where you want your own
logic to take control. You could be using
parameter values to make something
happen on your backend, like booking an
appointments in a calendar. Or you could be making use
of information about the user to build a custom
response to their query. To control Dialogflow's
conversations programmatically, you'll need to use fulfillment. It's easy with some
basic programming skills. First, you create
a web server that exposes a single HTTP endpoint. We call this a
WebHook, and it's where your custom logic will live. While you can use any
environment you prefer, we provide a
built-in editor that lets you write JavaScript
code and deploy it into Cloud Functions for
Firebase with a single click. Next, you just
enable fulfillment for any intents that need it. You can give each
intent an action name that helps your fulfillment
know which one was triggered. Now when one of these
intents is matched, Dialogflow will
send a JSON request to your WebHook that
contains what the user said, the values of any entities
that were extracted, and the action name, so you
know which intent was matched. If you are using one of
our one-click integrations, you'll also receive some
data from that platform about the user. When you call our
API directly, you can provide custom
information of your own. In your WebHook, you
can use this information to do stuff, like
access your data store, trigger business
logic, and call APIs. You can also
generate a response. Whatever response you generate
will be sent to the user by Dialogflow. You can also use the
WebHook to set and remove context and parameter
values, allowing you to control the flow of
conversation through your code. Between all of
these tools, we have a ton of ways to
guide and control the flow of a conversation. There's a lot here
to think about, but the best way to learn
is to jump right in. Check the links
in the description below for more information
and have fun building. [MUSIC PLAYING]
