Skip to main content

Why use Narratory over Dialogflow ES alone

· 9 min read
Ludvig Linse

A common question we get is what advantages Narratory has over using Dialogflow alone. We think that Kajsa, one of our first users, sums it up quite well in her quote:

"With the help of Narratory, I can focus on the design and the underlying logic instead of getting lost in contexts and wasting time navigating clumsy interfaces. In all, I am probably 2-4x faster with Narratory compared to using Dialogflow alone"

Below, we try to systematically go through each of the painpoints that Dialogflow bot creation has today, and how Narratory could be both more efficient and fun to use.

A note on Dialogflow#

Starting off, Dialogflow is a great product that has done a great job democratizing social AI, making chatbot building accessible for non-expert coders and non-coders (through it's graphical interface) alike:

  • It is one of the most flexible NLU engines on the market, and the only one with fully dynamic context-dependent language model that allows you to have different active intents in different dialog states (Dialogflow calls this concept "contexts")
  • It also has plug and play integrations to most types of clients (i.e. interfaces where users can interact with your bot - like Slack, Messenger, Telephone gateways etc). And even if they don't have an official client, there is an ecosystem of partners supplying excellent clients - for example kommunicate and botcopy for rich web integrations.
  • It supports expressiveness in many ways: available in more than 20 languages, comes with built-in text-to-speech & speech-to-text and has a flexible rich content system.

Challenges using Dialogflow and how Narratory overcomes them#

With the above strenghts in mind, here we list a few challenges using Dialogflow.

1. Dialog authoring: "Where is my Dialog?"#

When first mapping out a new chatbot, one intuitive way is to write a script between a human and a bot:

Some people like to start with an overview flowchart, but most build a script anyway before starting to actually build their bot.

Bot: Welcome DianaUser: I have problems with my orderBot: Okay, what is your order number?User: I don't have itBot: You can find it on your order confirmation email

When you set off to build this in Dialogflow, you typically define all inputs (the user prompts above) in the GUI. The output can then be either:

  1. Statically on each intent in the Dialogflow web GUI
  2. Dynamically in a fulfillment function - i.e. a web endpoint that the bot will call once this Intent is classified.

When you are used to the Dialogflow methodology, this probably feels intuitive. However, your dialog is now spread in potentially three different places which makes some things harder:

  • You have to manually match each intent and it's corresponding dynamic answer in a fulfillment function by the intent name. In addition to being tedious to update/change, this is prone to human errors.
  • When you need to make a change, it's not alwayas clear where the change needs to happen. And trust us, changes will need to happen - it is very much in the DNA of chatbot making that most of the work happens after you have exposed it to users.

How Narratory helps#

  • With Narratory, your dialog lives in ONE place. This allows you to focus on the dialog authoring and the jump from a script (as written above) to working chatbot is much smaller.
  • Your intents and entities are directly connected to the output and your code editor help you avoid human errors. Any change you need to make to the dialog can then be done in one place.
Dialog in once place

2. Context management: "What was the context now again?"#

Managing context is probably the hardest and most important skill to build a good Dialogflow agent. Instead of having all intents active at once you can sharpen the AI depending on where in the dialog you are.

Several challenges exist when doing this in Dialogflow:

  1. You have to match strings for input and output contexts between the Dialogflow GUI and your fulfillment functions. There is a big risk for human error here, and tedious to update/change.
  2. You also have to come up with a descriptive names for each context which has to be communicated to the team building the bot.
  3. You have to decide the lifetime of a context - i.e. how many dialog turns it should be active for.

To sum it up, managing context in Dialogflow is hard work.

How Narratory helps#

Narratory automatically handles context for you based on the intuitive bot and user turns and conditionals that you define in your dialog script. We also recommend our slot-filling video tutorial to show a more advanced example of this.

3. Variables and Conditionals: "I want to say this only if this entity was previously extracted..."#

Most dialogs require branching (or "conditionals") based on various things - entities extracted from what users said, what platform the user is on (facebook, phone etc), if the user spoke or wrote the input, what time it is, a variable set previously in the dialog or depending on the result of a query to an API.

Doing this in Dialogflow is a programming exercise and likely happens in your fulfillment functions. Here you can save variables to any persistant data store of your choise and apply any logic you want manipulating the answers you give to users. This is very flexible but requires a lot of work for something that is very common in most dialogs.

How Narratory helps#

In Narratory, every extracted entity is a variable accessible through-out the whole interaction (unless it gets overwritten). This also goes for variables that you manually set directly in the dialog OR using a webhook response using set: { foo: "bar" }. There are also plenty of useful system-set variables like platform, turnCount and user_returning available for use.

You can then in your dialog use conditionals on BotTurns allowing you to do complex branching, or conditionals on bot output if you simply want to give a different reply given some criteria.

vars and conds

For a good example of how conditionals allow intuitive solutions to advanced concepts like slot-filling, see the flight booker video tutorial.

4. Infrastructure: "But, I wanna build a bot - not set up servers..."#

For each bot you likely has to create fulfillment logic - either by setting up a server or a few cloud-functions that provides dynamic answers to users. This typically requires a developer skilled in system administration or devops and has to be done for every single agent where static answers is not enough, or as soon as you want to integrate business systems. This might seem a trivial task, but these endpoints have to be high-performing which either forces you to deal with cold starts on cloud functions or set up your own servers.

How Narratory helps#

Narratory automatically creates a fulfillment function that provides the answers based on your dialog script.

5. Updating: "What change did I make now again?"#

With your agent growing, it will become important to keep track of changes over time. With your dialog spread in a GUI and in fulfillment functions - this is hard. To highlight this need, there is even a dedicated library to export Dialogflow agents using a command line tool. This, however, does not help you version-control your fulfillment functions - which has to be done separately.

How Narratory helps#

Since Agents built using Narratory live in text files, they are 100% compatible with your normal version-control software (likely Git). For example, see the Narratory example apps on Github

6. Testing: "Gah, do I have to answer this again?"#

When testing a Dialogflow agent, you have three options:

  1. You start testing from the beginning of the dialog. This will obviously feel tedious if you want to test something towards the end of the dialog.
  2. Add a context to the Dialogflow testing prompt. Here you have to look up the right context and you might not have the right state variables set.
  3. Use flat hierarchy of intents - i.e. not using contexts. This will make your NLU model less sharp which is bad for most usecases.

How Narratory helps#

With Narratory, you can start your interaction from anywhere in the dialog and easily record and then replay scripts, automating testing. See testing docs.

testing terminal

7. Google Assistant: "Woah, I have to use this transactions API?"#

Since Dialogflow is the main creation tool to build Google Assistant actions, this is a common usecase. Google Assistant comes with certain built-in features like user authentication and transactions. These features are not plug and play in Dialogflow however, so developers have to spend time to build these complex flows for each solution they build.

How Narratory helps#

Narratory comes with built-in support for Google assistant Authentication and Transactions, allowing you to authenticate users and create transactions with just one line in your dialog script.

Summing it up#

To sum up, Narratory can provide a creator experience that allows you to work faster and more efficiently. This allows you to stay creative and focus on what makes YOUR chat-bot special - by building a great dialog instead of focusing on technical heavy-lifting.

Wanna give Narratory a go? Head over to Setup, it shouldn't take more than 5-10 minutes to get up and running.

Do you have any questions or feedback? Please get in touch at info@narratory.io