Conversation to Code (Part 1)

In the previous article, “Thinking for Voice: Design conversations, not logic”, we talked about how the best first step in creating conversational interfaces is to build the conversation. Shocking, I know. But pretty quickly we’re going to want to turn that design into something more concrete. In this article, we take the next step and use a tool to convert phrases that a user might say into an “intent” that represents what they mean. Next time, we’ll discuss how to hook up some logic to this processing to return results, and future articles will discuss some other coding we can do to improve our voice agent.

As we designed our conversations, we started to identify patterns about what the user was saying and what they intended to do with each of these phrases. We grouped them by what we called an Intent for this reason.

The process of taking the phrases and turning them into Intents are referred to as Natural Language Understanding (NLU) or Natural Language Processing (NLP). If you’re a programmer who is familiar with regular expressions, you may be tempted to map one or more regexps to an Intent. If you do, you’ll quickly discover how painful this is to actually map phrases well and maintain them over time.

Instead, you should use one of the NLP systems that are currently available. Actions on Google can work with any of them, but it is well tuned to work with one called Dialogflow, which can provide NLP for a variety of other clients in addition to AoG. We will focus on using Dialogflow for our NLP, although many of the concepts we discuss should be applicable to other NLPs.

Getting started with Actions and Dialogflow

We won’t go into too many details about getting started with an Actions on Google project, or then using this to start a Dialogflow project. If you’re unfamiliar with the process, check out the documentation for Actions on Google and click on the “Getting Started” left navigation.

By default, however, Dialogflow provides two default Intents that we’ll delete:

• Default Fallback Intent
• Default Welcome Intent

You can delete these by going to the list of Intents, hovering over each Intent name, and clicking the garbage pail that appears to the right of each name.

Why delete them? They have some default settings that are best removed for our discussion (and for your Actions as you build them), so it is best to start with a clean slate and a better naming scheme.

With that out of the way, we can begin turning our conversations into Intents.

Building our Intent descriptions

We have our conversation. We’ve cleaned up our project. Time to build those Intents!

We can click on the + sign next to Intents in the left menu. This will bring up our Intent Editor, broken into sections. When you start out, it will provide some helpful text, followed by a blue link to “Add” whatever that section is about. You may need to expand some sections by clicking on the down-arrow on the right, and you can always collapse sections by clicking on the up-arrow in the same place.

First, you’ll need to set a name for the Intent. We’ve already used some when we were writing out the conversations, so we’ll go with those. We then need to set what will trigger that intent (either an event or some sample phrases) and how we will respond to the user (in our cases, we want a webhook to handle all the logic in code).

For our welcome intent, we need to set the event that triggers it. The most generic event is a “welcome” event, and as we start typing that in, we see it as the top option in a drop-down box. We don’t need to set any training phrases or collect any parameters since the Google Assistant will take care of that part for us. We don’t need to set any response in Dialogflow since our webhook will take care of that part, but we do need to enable Fulfillment and enable the webhook call for this Intent. Then make sure you click “Save”.

Our other intents will all have Training Phrases instead of Events. These phrases will come from the conversations we designed, plus others that we may come up with as we’re editing them. We’ll build our number Intent with a few phrases, entered one at a time, pressing return in between each, and make sure we’ve turned Fulfillment on before we save it.

Our letter Intent is much the same. You may wonder what happens if the user doesn’t say exactly what we’re training Dialogflow to listen to. Fortunately, Dialogflow uses an AI model that uses our phrases to train the model with what the user might say. It is usually pretty tolerant when it comes to fuzzy matches of phrases, but you should try to give it as many as possible to help it along.

As we enter our yes intent, think about the other phrases that the user can say to acknowledge something. Our scripts identified a few, but it makes sense to try out the response phrases and talk out loud, perhaps even with people who haven’t heard the prompts before, to see how they respond. You can certainly add more than the four we’ve determined here.

Don’t forget to click “Save” after each one. If you do forget, you’ll get a browser warning message asking if you want to discard the changes you made on the page.

As we enter the training for the no Intent, you may be wondering why we’re not setting the responses here, but instead relying on Fulfillment to take care of them. Although our responses are fairly simple, as we’ll see next time, handling even simple responses in the webhook means that we can have them do some fairly sophisticated logic. Doing it this way cleanly separates our request processing from how we handle the response. So why does Dialogflow offer the ability to send responses as part of the Intent configuration? Because there are some cases where it is easier to do so, and it can be faster. We prefer having everything handled the same way, through Fulfillment.

There is one more Intent that we need to build to handle some cases that didn’t come up as we designed our conversation. What if the user said something completely unexpected? If they declared “I like bananas”, for example. Or if they said nothing at all. How would we handle that? We’ve talked about these “not so happy” paths before, and we’ll cover the details of this in a later article, but for now, we’ll design a Fallback Intent, which will be called in the event none of the other defined Intents match what the user says.

To create a Fallback Intent, select the Intents menu in the left navigation. Then select the three-dot menu in the upper right.

You’ll then choose the “Create Fallback Intent” option.

Fallback Intents are very similar to regular Intents, although there are a few significant differences. You still need to give it a name, for example, but the training phrases are optional for a Fallback Intent. If you give any training phrases, they represent phrases that won’t match other Intents.

We’ve named our Fallback Intent input.unknown, to indicate that there is something odd about the user’s response. We don’t necessarily want to force any phrases to be ignored elsewhere, we just need this Intent to be handled similar to other Intents.

Ready for takeoff!

With all of our Intents built and saved, we’re all set, right?

Well… all set to work on the next step. Writing the logic to come up with these responses! Which we’ll cover next time.

It is worth taking a moment to review what we’ve done here. It doesn’t seem like a lot, but when designing conversational UIs, focusing and building the conversation is the most important step.

One good strategy is to test your conversation, even before you build the logic. We can try that out by turning off the webhook fulfillment in each of the steps above, adding some sample responses, and trying it out. We might find some phrases that we missed or think of some good ways to respond in some cases. Testing a UI, even a VUI, is a really important part of the process.

In our next article, we’ll look at how to build our fulfillment webhook so we can respond to our users. There are a lot of different approaches to this, but we’ll focus on the one that we outlined when we designed our conversation. There are several libraries available that help us with this task if we’re building with node.js, and we’ll look at them. We’ll also get a rough idea how to adapt this if we’re using another programming language.