This is part of a series of “Bot Making Tools Assessment” findings from the ‘How To Build A Bot With The Right Kind Of Tools‘ article.
Checkout the rest of the series by following these links:
- Chatbot Building Platforms
- Facebook Chat API
- Microsoft Bot Builder SDK (this article)
- Synthetic Intelligence Markup Language with OSCOVA
Before continuing with this section about the Microsoft Bot Builder SDK, it would be useful to do a quick recap of the difference between a library and a framework .
Basically, Microsoft provides a set of libraries, tools and a portal to help the developer develop the bot. They also have a pretty good set of design guidelines, technical documentation and sample projects . So, for developers who prefer “cold steel programming tools” and need this kind of granularity, this is a good option, especially when they are already familiar with the Microsoft development platform and tools. And guess what, since Microsoft being all Open Source friendly nowadays, NodeJS is also a very much supported preferred development language too.
An added bonus to developing on this framework is the ability to add Artificial Intelligence features by using the LUIS (part of Microsoft’s Cognitive Services). Plus, if the developer choose to host the bot on Microsoft Azure, everything (including the AI services) are setup in 1 place with central monitoring of API consumption and resource usage. It also the developer has less worry on service provisioning / API key tracking & hosting performance all round.
Bear in mind that Microsoft’s Cognitive Services actually consists of other nifty tools (Image Recognition, Text Analysis… just to name a few) that the developer can further explore to enhance their bot. Click here to read more about Cognitive Services and what it has to offer.
Note that the developer will need some knowledge of:
- Cloud Hosting services to deploy the bot, and setting up Artificial Intelligence services such as LUIS and/or other Cognitive Services.
- Using the portal to register & publish the bot – the developer must have a basic knowledge on getting the necessary keys and tokens from each of the channels to deploy the bot to. There are guided instructions on the portal so it is not difficult to follow through.
A few caveats:
- Since it supports multiple channels, the developer should not expect the bot UI to be the same across different channels “pixel by pixel”. The framework comes with a bot emulator that can help allows the developer to test “generic” versions of bot components, and that’s it. It will not render the UI exactly how an end user would see it in the channel. Check out the differences using the Channel Inspector .
- This is similar to the problem for mobile developers when developing native applications on iOS and Android (e.g. the application bar is in different places – top or bottom). Whilst it is still not too bad for mobile developers to “just standardize across the board with standard custom UI design”, for bot developers (unfortunately) this is not possible. There is no “styling” layer as bot interactions are very tightly coupled with their host channels.
- Another problem is also the fact that not every channel has the same set of bot components, although it is still possible to workaround this using the ChannelData property . The developer would need to know the format of the payload of that channel’s component, which means digging through the relevant documentations from the channel’s documentations.
Suggested Use Cases:
- e-Commerce (e.g. complex data flow and calculations)
- Bots that have complex logic or flows that require session context / database backend
- If you want to utilize LUIS or Cognitive Services from Microsoft, integration work is easier on C# .NET Platform.