An Assessment Of Bot Making Options
In this article, we will explore what exactly do we need to build a Chatbot from a slightly technical perspective.
Warning: There may be sprinkling of technical jargons in this article. As always, Google is always your best friend for further details and illustrated examples.
Introduction & Objective
Good software developers understand that there is never a tool / framework that is a “one-size fits all”. This is especially true when considering the use case and the projects that we build the solution for. There are some unique problems that require careful consideration of what to use, and how to use it. Otherwise, we might end up in a very difficult situation of not being “flexible enough” to scale or grow. If you are in a leader position, there are also other things to think of, such as available team skill sets, how easy to learn / run with the technology, and where to find resources or get help when things get tough.
We are now stepping into the age of Artificial Intelligence and Machine Learning. 5 out of 10 articles on the techno-sphere are specifically talking about bots. Or some variation of the word bot – “intelligent virtual assistants”, “automating ABC”, “smart XYZ” and how it is revolutionizing industries around the world.
So, what exactly is involved in building bots?
How is it different from the normal “code my business logic” way of software development?
Bot Building 101 (Technical Edition)
A bot is hosted on a channel (e.g. Facebook Messenger, Skype, Telegram, Slack). User types a request to the bot, the bot responds with the right information based on understanding of the request. Usually the channel forwards the request to a handler which will process what to do next. Up to this stage, it sounds like a regular Webhook or Web API connection.
How the bot presents the information back to the user is using bot components. Bot components are very much like the UI aspect of a conversation: text, images, audio, buttons. Note that each channel provides a different set of components and options through their platform APIs. From a web development perspective, it sounds just like a server request / response. However, it is the expectations of what bots are supposed to be able to do that catch many software developers off guard. (Hint: It is more than “just presenting information” back to the user)
In fact, the tricky part here is that often the user’s request is expressed in human language. The developer has to learn to deal with this apart from standard server formats (e.g JSON / any schema based request). And here is the other part of the bot equation: Artificial Intelligence (e.g “how it understands the request”, or Natural Language Processing – NLP). The “brain” of the bot does not just contain business logic, but also a (few) model(s) of “intelligence” of the bot. Basic terminologies used in NLP – Intents, Entities, Session & Context is necessary to get things going if you intend to use one.
(Off-Topic : If you intend to invest a lot more time on the topic of AI, I would suggest to read what is the difference between Artificial Intelligence, Machine Learning & Deep Learning first)
Soft Skills You Might Need
- Understanding how to communicate concisely with words.
- It would also help if you have a good command of English as most tools available today are English based.
- It would also help to understand a bit of communicative UX and user behaviors to craft your bot’s intelligence model.
- A clear understanding of the business context of what the bot is used for.
The Technical Bits
Some of my personal experience of building bots were using the following approaches:
- Chatbot Building Platforms (e.g ManyChat, Chatfuel)
- Facebook Chat API
- Microsoft Bot Builder SDK
- Synthetic Intelligence Markup Language with OSCOVA
Some might argue that ManyChat & Chatfuel are not exactly “cold steel programming tools” but I believe that as software developers, we should not discriminate on whether the tool is “hardcore matrix code” or “GUI based tools”. The more tools we try, the more we understand how the concept works. Once our mental model is in place, it will make more sense of what each tool offers in terms of functionality. From then on, you can easily determine the fit for your use case and niche of users. After all we are all in the business of building solutions to solve a problem.
Feel free to click on the links above to read my findings with each approach.
Below is a summary for your reading pleasure.
Chatbot Building Platforms (e.g ManyChat, Chatfuel)
- Great for simple use cases.
- Great documentation and pre-built bot templates.
- Uses JSON API for integration to external systems.
- No need to worry about hosting or deployment.
- Developers do not have absolute control over the data and performance of the server.
- If there is a need to do integration to systems that do not have a JSON API, the developer has to build the API themselves to connect.
- Usually targeted to specific messenger channels.
Facebook Messenger Platform API using standard REST calls
- Access to the latest features direct from Facebook. (Even when the feature is still in beta!)
- Documentation and code samples are available.
- Developer may need to put in place REST calls monitoring within their application just in case.
- Requesting the appropriate App Permissions requires a little more effort from the developer.
- Strict Policy Guidelines on branding and usage of their API.
- Not all features are supported worldwide (e.g. Payments).
Microsoft Bot Framework
- Supports multiple messaging platforms.
- Integrates with complementary services such as LUIS and Cognitive Framework easily (setup, hosting, monitoring centralized on MS Azure)
- NodeJS friendly
- Bot components are generic versions. To use channel specific bot components, the Developer needs to know the specific channel’s API payloads.
- Developer will still need to know how to generate access tokens from the channels to publish and deploy the bot.
- The framework is currently in PREVIEW, so we don’t actually know how much it will actually cost to host yet when it comes out in GA (General Availability).
Standalone Framework – Syn Bot OSCOVA
- Markup based Artificial Intelligence modelling tool.
- Support for offline devices since less dependency on Cloud APIs & Services.
- Paid License for premium support.
- Developer has to implement the bot UI / channel / third party integrations.
- Other online resources (apart from official website) might feature samples referring to SIML 1.0 instead of SIML 2.0 which OSCOVA uses.
So which should you choose for your first / next Bot project? The answer is: IT DEPENDS.
Another consideration is the fact that each channel has a specific user base that your bot might want to target. Hence, deciding on the final approach may not just be a pure “technical decision” after all…
To end this article,
“If you get stuck, draw with a different pen. Change your tools; it may free your thinking.”
– Paul Arden
“I’m not saying being a comedian is brain surgery, but it is definitely – it’s like being a carpenter. You learn how to make tables and chairs. You have to have the right tools, and you have to know how to put the thing together, right?”
– Denis Leary
Kindly leave your comments if you like to read more articles like these.