//End Google Tag Manager
Steve works at a design agency focused on chatbot development. He’s proficient in node.js and excited to be working at the forefront of a new software channel.
His colleague Marina originally worked on crafting content for websites, but now works alongside him in delivering chatbots for brands.
When he first started building chatbots he used “no code” tools like Chatfuel and Motion.ai. These were great tools for creating scripted bots, particularly for marketing, but he quickly found them limited for his use cases.
The emphasis of these tools was allowing the person off the street to be able to create a bot in a matter of minutes. They succeeded at this task and anyone could easily capture the novelty and marketing value of chatbots. They had limitations however when the use case became more complex. It was difficult or impossible to customize the bot or integrate it with existing systems.
There were also obvious limitations to development using visual tools. He wasn’t arguing that there should be a usability / learnability trade off. He believed that is was important for systems to be easy to learn for everyone at the outset. Not everyone would be prepared to put in the time and effort to improve. However, the system should allow multiple ways of interacting so that experts can constantly improve their productivity on the platform.
The learning curve to get a program running in a current programming language was reasonably small but admittedly a bit steeper than the learning curve to get a chatbot up and running via a visual tool.
The beginner could, however, improve their productivity exponentially by increasing their knowledge of the features of the language and the various tools available. No one seriously considered replacing text editors with visual tools for coding (although there were many visual tools that supported coding including visual cues directly on the code itself).
Steve acknowledged that it was possible to build the chatbot in a pure programming environment such as Microsoft Bot Framework, but that wasn’t the solution he was looking for. While he would have more control and flexibility using these types of tools, he would end up having to code many common features of the bot himself.
This type of framework was developed with developing intelligent bots in mind using smart NLP and AI engines such as LUIS. For his use cases, using this type of platform was almost the opposite of the problem he faced with the no code platforms. These platforms made it much harder than necessary to code the types of bots he was developing.
Programmers use text editors supported by visual tools and Steve believed that similar solutions would eventually be available in the chatbot framework space. What was available right now would improve immeasurably in future.
He had another reason for believing this. Programmers frequently refactor code using find / replace, copy / paste and other tools, but this is not possible to the same extent in a visual system.
In addition, some features may be difficult to represent visually. If a chatbot feature on Messenger for example was complex, it might be difficult or impossible to find a nice user interface to represent the feature graphically. This is arguably already happening with chat extensions.
In his view, chat extensions were indicative of a trend that was moving away from the purely conversational UI towards bots becoming more graphical apps. Facebook Messenger and other platforms would aim to become a universal mobile app in the same way (with a few tweaks) that Wechat was already in Asia
When he discussed this with Marina, she agreed. In fact she felt she had a similar problem on the content side.
While she had very quickly managed to get up and running on no code platforms, the limitations were obvious for the bots they were trying to build. The first time she was tasked with building a more complex bot she had changed the process. Instead of developing the bot on a no code platform, she created various specifications and prototypes for the chatbot which she then gave to Steve to implement.
This was a very inefficient process chiefly because she could not make changes to the content herself but had to ask Steve to make the changes for her. Over time Steve had developed some tools that allowed her to be able to maintain parts of the content herself via a google spreadsheet, but it was not an ideal solution.
More importantly, she also felt that as an expert doing this every day she needed better tools to increase her productivity.
The content was words and simple text structures applied to controls such as graphical widgets, buttons, quick replies and cards. She could write out conversations in a text editor in a matter of minutes, but those same simple conversations took her a few hours to put together on these visual coding platforms.
Marina concluded that even the content side was missing important tools that could make them a lot more productive than they were now for professional chatbot makers.
This story has a happy ending. Botpress.io was built with the Steves and Marinas of this world in mind i.e. for professionals who need professional grade tools for creating bots.
While Botpress.io is really easy to learn, it’s not focused on allowing the person off the street to develop chatbots. It’s focused on allowing professional chatbot makers to do their jobs better.
Professional chatbot makers are often assumed to be people working on natural language and similar AI solutions, however we have a broader definition. The data scientists would definitely fall under the definition of professional chatbot makers, but our definition includes all the various members of the team involved in creating professional bots. This includes those developers and content makers that either create bots for a living or at least have achieved a very high level of understanding and proficiency with regards to the bot creation process.
Generally these professional chatbot makers will be chatbot developers and content makers working at start-ups, dev houses, digital agencies or as in-house professionals for a corporate.
These professionals expect a set of tools that allows them to focus on the business logic and content that is unique to the customer experience they are developing, rather than spending time on coding common features or dealing with the rigid, locked in processes specified by visual tools.
Botpress is not the right choice for someone who wants to create a chatbot in the easiest possible way and is prepared to accept the limitations of less flexibility and not much room for improving productivity.
In many ways the task of building a website is a good analogy for building a chatbot. A professional agency would not use Wix.com to build the website because of the limitations but they would use Wordpress rather than building the site from scratch in HTML or CSS. The no code platforms are similar to Wix,com and building a chatbot from scratch using the bot framework might be likened to building a website from scratch using html or css. Botpress is similar to using Wordpress.
In our opinion the chatbot industry is still in the process of working out what combination of NLP, guided conversations, and graphical widgets make a great bot. How chatbots evolve will depend on the evolution of the underlying technologies as well as the features offered by the chat platforms.
The tools available to professional chatbot makers need to give them fast and easy access to all the various technologies that can be used to create bots. It is important, but often overlooked fact, that to create a great user experience for a bot it is critical to use all the features of the messaging platform that is being used. For example, chat extensions are now an important feature on messenger and need to be used to create a great user experience.
Ignoring these type of features in order to make the bot easily deployable across various chat platforms in a generic way means reducing the user experience to the lowest common denominator. An sms bot must be approached in a totally different way to a Messenger bot to make the most of the features (or lack of features) available in the communication channel.
Professional bot development tools need to take these sorts of considerations and a lot more into account. The quality of a professional bot developer is expected to far exceed that of an amateur developer using a no code platform in terms of functionality and overall experience. In addition, the professional chatbot is expected to have superior security features and customized analytics (and the related capability to do A/B testing of content).
Professional chatbot makers will come to expect that frameworks allow them to develop their expertise over time, not just in terms of increasing the features that they are able to create, but also in terms of the productivity they can achieve using the underlying development tools.
Disclaimer: We encourage our blog authors to give their personal opinions. The opinions expressed in this blog are therefore those of the authors. They do not necessarily reflect the opinions or views of Botpress as a company.