Recently, a reader sent me a message in which he said:
A lot people mention you as one of the (main proponents) of the Dialogflow from scratch movement.
While it is a pretty succinct phrase, I don't think I am a proponent of Dialogflow from scratch.
I am a proponent of building better Dialogflow bots 🙂
I don't think it is just an aspirational phrase. To be very specific, I recommend people build their bots in such a way that the bot maker (the person who wants the bot to be built) balances three different aspects of the bot development process.
The missing third dimension when evaluating low code tools
In my view, Dialogflow is the best low code bot framework because it helps you keep your bot really "low code" without dumbing down the bot. Most people focus on only power and ease-of-use as the two dimensions when evaluating low code tools.
I think that misses an entire "sweet spot" of low code tools because you don't just throw away the bot after building version 1. There is a third dimension - the maintenance aspect - to whatever you are building using low code tools.
And when it comes to maintaining your bot, which would you rather prefer? To ask your developer to make every single little change in your bot, or that you are able to make a large set of changes by yourself and hand over only the minimum number of programming tasks to the developer?
So, there are actually three things to balance here:
- Dialog Management - how well the bot can be maintained without additional code being written
- Power - how powerful a bot you can build
- Ease of use - how little time you can spend building your bot
And to be clear, I only consider changes you make to your webhook as additional code. If you update training phrases, responses, input and output contexts etc, then you can do all that by yourself without relying on your developer and it falls under "dialog management".
I have made many recommendations in my previous articles:
- Use a context lifespan of 1
- Avoid slot filling
- Don't use entities until you actually need them
- Use wildcard entities sparingly and carefully
You will see that I am usually trying to balance these three aspects in those articles.
Isn't the "dialog management" metric subjective?
At this point, you might be wondering if the metric called "dialog management" is a bit subjective.
Before I answer that, here is what I can say based on my experience : no client of mine has come back and asked me to change the design of the bot I prototyped for them because it prevented them from building some additional feature.
In contrast, I have fixed the bots of many clients by asking them to remove required parameters and follow up intents from their bot (which they had added before our first call). Effectively, by using these features, they made it impossible to add some additional feature they wanted.
You will know that you have hit the sweet spot of Dialogflow development when this aspect (ease of updates and maintenance) is handled properly.
If you find a tool (to help improve your Dialogflow bot) which doesn't get in the way of balancing all these three aspects I will certainly recommend using that tool and not building everything from scratch. But this depends on both how the tool has been built, as well as the type of bot you are creating.
So you could say that the "dialog management" metric is a little subjective, but ignoring this metric will become quite expensive when you build version 2 of your chatbot.
- Dialogflow vs RASA NLU
- Dialogflow vs Lex vs LUIS vs Watson vs Chatfuel
- Machine Learning vs non-Machine Learning algorithm
- BotFlo update
- Learn Dialogflow basics for free (till May 31)
- 10+ practical projects to learn spaCy in depth
- An Epidemiology Glossary for Programmers
- All my mini-courses are free this week
- Reader Question: What if a specific system entity isn’t available in all languages in a multi-lingual bot?
- How much can Machine Learning ACTUALLY help with answering free-form questions?