Get best of the week

As we did the next designer of chat bots. Part 1



Hi Habromir! The last year the team and I spent creating our startup Botlify Chatbot Constructor for Business, and I would like to share with the audience a short history of the project and the technical decisions made. In this post, I will try to concentrate as much as possible on technical details and to go deeper into the product and business less, despite the fact that in this project my role is much less connected with development and technology. This material is based on my personal experience, I am not a startup coach and do not pretend to be a good programmer, manager, architect or entrepreneur. We are a relatively young startup with few users, so there will be nothing about the workloads and problems of large projects. Under the cut, I’ll tell you how my project began, what kind of development rake we stepped on and what conclusions we made.

My name is Andrey, for some time I worked as a developer, mainly in PHP, then team lead, and then as technical director in several small startups, where I fell in love with NodeJS. But it so happened that lately I am more likely an entrepreneur. This is not the first startup that I founded, and even less the first startup in which I participated. I happened to work in several successful projects and a lot of failures. I founded even more failed projects myself. Each time, the causes of failure are completely different, as well as the stages at which I failed, but somehow I used this experience in this project.

Goals


Before starting the story about the project, I would like to talk about what goals we pursued from the very beginning, starting this adventure. In fact, our designer began as a pet project for learning the basics of product management, customer development, acquiring new management skills and experience in startups. I heard and tried many times to apply the LEAN Startup approaches and each time it turned out completely differently. Of course, we dreamed of building a business on this and making good money, but we did not entertain ourselves with the illusions that this was a simple and short way. And even more so, we did not try to make some kind of WOW! -Innovation. My co-founder and I had constant full time work and we understood that we won’t be able to devote much time.The main motivator was precisely the opportunity to master completely new areas of the IT industry and apply new knowledge in practice, and at the same time earn money.


As a programmer, I really liked to draw class diagrams, sequences, flowcharts. For me, the visualization process itself was a stage in understanding problems and solutions, and it allowed me to get a big picture of what was happening. While working on the next project, I again faced with the need to insert a widget with online chat on the site and see what ready-made solutions are in this area. So, among what I was looking for, I came across platforms that allowed not only creating widgets with online chat for the site, but also embedding chat bots in them. I talked to one of these bots and he left me a good impression. And then I started trying to come up with different chatbot scripts that could be useful in my projects. Fantasy just poured on the table: an appointment with the nail salon,help to make a choice in the online store, indicate the right place in the documentation, accept the request to the support service. What I just did not think of.

Then I climbed to look at various designers and almost all offered me to fill out forms, and then fill out forms, and then fill out forms again. In general, create bots by filling out forms. As a result, it was extremely inconvenient for me, I constantly lost the context of what was happening, I had to go back to the previous steps to restore the context, and there was no question of convenient thinking through logic and designing scripts. Well, I think, I'll try first to “design” my bots in an external tool, and then I will transfer it to the desired platform.

And here I came across the first problem: How to describe the dialogue with the bot in such a way that it is clear what and why the bot responds and at the same time have the whole sequence of actions in front of itself?At first, I tried using xmind and other tools to create a mind map. It turned out something like this.

Mind map chatbot example

Later it became clear that chat bots as a whole fit pretty well in the concept of describing states and transitions between them, it turns out to be quite convenient to navigate in the conversation branches even where there are a lot of them.

Only a few competitors were found providing a visual bot designer. For some, it was more intuitive, for someone less, but in general, such constructors seemed to me much more user-friendly. It became interesting for us to try to do something similar, we wanted to create a tool with which you can create a chat bot without programming skills, simply describing it in the form of a diagram. Of course, some technical skills are still required, but it is not much more difficult to create a mind map.

Bots are a rather complicated and big topic, and our resources are very limited. Therefore, it was vital for us to simplify our decision as much as possible so that it would ever see the market. “ The sooner the better ” - I will not tire of repeating this mantra in the context of startups.

AI & ML


The question about artificial intelligence in chat bots is still open for me. But now we proceed from the fact that we are an early start-up, we do not have competencies in AI and ML within the team and we have already agreed that we just want to draw diagrams and not prepare datasets, train neural networks and that’s all. At the moment, we do not use artificial intelligence and machine learning in our bots . Perhaps someday, in the future, when there will be money for it.

It is important to understand that the same bots in their essence can be made very differently. Roughly speaking, there may be a bot that writes: “ What are you doing? ” And expects an arbitrary response from the user in the spirit: “ Learn about borsch ”, “ I want to order borsch ”, “What time is it now?". Having received the answer, the bot tries to recognize it, determine the intention and choose the right branch for the development of the dialogue. Needless to say, given typos, a variety of forms and expressions, this can be expensive.

On the other hand, we can use closed questions when it comes to it's about choosing, for example, a bot can write: " What are you willing to do? "and offer options:" Learn about borsch "," Order borsch "," Find out the time". On the one hand, the user loses his freedom of action, but on the other hand, we not only simplify the calculations significantly, but also can more easily manage the dialogue context by turning it in the right direction. We prefer to use open questions in the context of collecting user text data: enter email , phone, write your question to support, etc.

Chat bot vs man


Another argument against letting the user communicate with the bot in free form was the belief that the chat bot should not “play” in a person. In my opinion, when communicating with a bot, a person should clearly understand what communicates with the bot, know what opportunities it has and how to use them. And if a person understands that he is communicating with a bot - what's the point in free text communication? It is much better when the chatbot becomes a person’s assistant, and not a substitute for it and is not shy about it, and the person clearly understands that he communicates with the chatbot and what its functions are. In this case, communication turns out to be noticeably more effective.

Process


I am a fan of udalenki. Don’t feed me bread - let me put together a remote team and start working with it. I am comfortable working remotely myself, I know how to organize work and find people who can work independently and efficiently as well. I understand perfectly well that this is not suitable for everyone, I completely agree with this, but I think that in the bright future there will be more and more udalenki. It's just that economics is nothing personal. Since this is my project and I ordered music for it - here, too, is a remote one, this leaves a certain imprint.

At the very beginning of work on any project, I consider it very important to try to formalize my ideas as much as possible. While the idea has not found its form on paper, in the form of text, notes, drawings, no idea exists at all. At the same time, all processes within the team should be as simple, natural and fast as possible, communication effective. You should not use large, heavy tools to manage your team, like Jira or Redmine, if your whole team is you and your friend. But also not to use anything will not work out, otherwise everything very quickly gets out of control and chaos will arise, curbing which is much more difficult than simply not allowing it. Even in the head of one person such a mess can be formed according to the project, it’s not for me to tell you what to say about the team, even if only 2-3 people.

We, like real startupers, used Trello to organize tasks and store important links for the project, and ideas were also thrown there. For business documentation, Google Docs , while the technical one, is quite well created in markdown and put into the corresponding repository. Communication throughout the day - Telegram , and for daily stand-ups Google Hangouts . Daily stand-ups are one of the cornerstones of the existence of remote teams . If this is not there, there is no team, someone necessarily begins to feel lonely, tired, misunderstanding and discontent are accumulating, not only control over the situation but also relations in the team is lost.

From the point of view of the development process, America did not have to be discovered either. We determine the length of the sprint, plan the sprint based on the goals of the startup. We take puzzles and start sausage. A new challenge is a new branch in your favorite version control system. Are you done? We issue a Pull request, wait until someone comes down to the review. Did the review go? CI worked fine? Well then, you can hold everything in the develop branch, wait for the green light from the develop assembly and update the test server. The code we store on GitHub . Until the first paying customer, these were publicly open repositories. As a person who has tried to promote several open source solutions in the past, I sincerely resent every time a startup starts shaking for the safety of its code before it starts to make any money.If you try to copy - this is a clear business success . It costs nothing to close the repository later. And business, you know, is buried, as a rule, far from in the code. I have access to the code of many, including very successful products, but is it worth saying that having them I will not even closely repeat their success? To build Docker containers and run autotests, we decided to try GitHub Actions , fortunately, they gave preliminary access. In general, the impressions remained quite pleasant, the assembly speed is satisfactory. The only thing that was unpleasant was updates with loss of compatibility with previous versions. A couple of times they quite seriously changed the scheme of description of actions and had to reconfigure everything. But we knew what we were doing when we agreed to try the product in statusBeta .

From the very first days, literally, from developing a landing page for demand testing, we tried to release releases at least once a week and test at least one hypothesis. At first, the hypotheses were more global, we tried to find various problems, target audience, and develop a proposal. But the further the product developed, the less global they became and the essence itself was less likely to change. The project started from scratch, with the usual landing page, then on the knee we created a demo client of the chat bot, which still hangs on our main page. This demo could reproduce a strictly programmed dialogue and served us as a demonstration of what could be done on our constructor - the result of his work, and not the constructor itself. The trick was that we assumed that the business would not come to us for the bot designer,but for some result, the advantage that he will give. We wanted to pour our customers a cup of coffee made by our coffee machine, instead of showing the coffee machine itself. It is easy to guess thatmaking a cup of coffee is much faster and cheaper than collecting a coffee machine . Guided by this principle, we decided to make a client demo first, especially since with a number of ready-made tools it took us no more than two evenings, including the development of dialogue scenarios.

When we saw the interest from the visitors of the landing and the additional conversions generated by our demo, we decided that we would go further. I remember that our first release of the constructor was a registration form with a login form, after which the user was taken to a page with an apology and a promise to inform when something else worked. I did the login and registration forms a good hundred times in my life and I could not even think that here we would immediately find a lot of problems.About 60% of the first users simply could not complete the registration process . For whom the button does not work, for whom email does not come, for whom something else is. At first, I perceived the idea of ​​releasing only a couple of forms quite skeptically, but a first glance at Yandex.Metrica made it clear that it was rather the right decision. The realization that users behave differently than you would like, and sometimes the way you even thought you couldn’t, had a big impact on everything we did next. As a hobby, I spent several times a week on a couple of hours in a web browser just watching how users use our craft.

So, little by little, we added functionality to our brainchild and came to a product that still has value not only for us, but also for our users, some of which even pay us money. In the long run, we did not understand what we want to come to, what our product will look like. The only thing that we understood then was that we do not understand anything and are in a state of uncertainty.

Result


This experiment brought me and my team to an angelic investment from the friends, family, fools category, built by MVP, first sales, great experience, lots of joys and disappointments. We are not yet a true business, but we strive to become one. And when I say this, I mean that we are still in search of a sustainable business model and product-market fit. Again we plan to look for the right product concept, our customer, our market.

The initial goals were achieved by no means all, but the project grew from a home hobby and turned into a full-time job, and responsibility appeared to investors, users, and employees. Of course, the project has a lot of problems, both conceptual and technical, but there is nothing unsolvable and we plan to continue working.

Before embarking on the more technical part of my opus, it’s probably worth briefly telling about what the product allows you to do.

  • Manage chatbots in your account
  • Visual chatbot editor
  • Control access to chat bots (editing access, public access)
  • Ability to publish chat bots on the web (widget, embedded, fullscreen)
  • Chatbot settings (design, names, metrics, widget position, etc.)
  • Support for integrating chatbots with external services through GET and POST requests
  • Analysis of bot dialogs
  • Account management
  • Subscription Model, Subscription Management


Architecture


Now, knowing the background, goals, idea, and principles that guided us in the development, I can begin to give a general description of how this all works. Since our initial choice was to create chatbots for sites and fullscreen chatbots , like app.botlify.io/bot/5de53dbf9b9bae002b319600 it was clear that most of the work would be on the frontend side. As a result, the front of work on the client was formed into a meaningful list of tasks and Wishlist:

  1. Create / find a client library, a kind of “engine” for chat bots in a browser that understands the received json instructions and maintains a dialogue with the user.
  2. Create an application for editing bot nodes, which will save a list of nodes and links between them in some json-object (on the basis of which the client library will conduct dialogs).
  3. , , , - . , , , . , , , ..
  4. , , . id , :

    <script defer src="https://app.botlify.io/botlify.min.js"
    onload="Botlify({ bot: '5de53dbf9b9bae002b319600', type: 'widget'})"
</script>
  5. , , ( )

The whole logic of dialogs from creating chat bots (nodes and connections) to working directly with them in the web client is handled by frontend. The role of the backend is more about managing access, subscriptions, newsletters, notifications, and storing data transmitted from many web clients.

Frontend


For the front, we use Reactjs . We pack everything in Docker (we build and shove it into the nginx container), the code on Github in private repositories, for CI we use Github Actions . We launch containers on ordinary VPS servers with simple bash scripts. To simplify the development of the UI took Blueprint .

  • Web — javascript , - . json -, . -(, , , , , .).
  • Web — javascript . id , , Web- .
  • — , . json, -. , «» , — -.
  • User Account - a web application for managing your account, subscription and bots.
  • Administrative panel is a web application for administrators. Management of users, bots, subscriptions, dashboards with analytics.


The diagram below shows the components of the frontend and how they interact with each other. Webclient and bot editor are used only in the context of other applications, while if editor is used only in our applications, then the web client can also be used by our clients as a web module. When building the project, packages with Webclient and Editor are added to the Dashboard and Admin applications. In addition, the web module is built using webpack for delivery to users.



MVP 1. Web Client


As a startup, we always strive to achieve maximum results using a minimum of resources. It seems to me that a fairly logical step for the first MVP was the creation of a web client from the point of view that it represented the “product face”, showed the result of the work of the designer, and not the process of creating the bot — a cup of coffee, not a coffee machine. In order to minimize the development time of the solution, we decided to look for libraries suitable to our requests and, suddenly, found! lucasbassetti.com.br/react-simple-chatbot is a react component that covered almost all of our needs!

This component suggested describing the chatbot logic in the form of an array of steps, reading the values ​​entered by users, customizing the appearance, validating the data, and looked flexible enough to start with. The simplest steps description looks something like this:

<ChatBot
      steps={[
        {
          id: '1',
          message: 'What is your name?',
          trigger: '2',
        },
        {
          id: '2',
          user: true,
          trigger: '3',
        },
        {
          id: '3',
          message: 'Hi {previousValue}, nice to meet you!',
          end: true,
        },
      ]}
    />

We started by trying in this way to compose a chatbot presenting our project, whose mind map was on the screen at the beginning of the article. Of course, manually describing such json turned out to be rather inconvenient, and I had to write a lot of custom functions, but in general this process gave an understanding of how the component works, how to achieve the desired result with it.

Further, my colleague customized the appearance, made several display options, and we concocted an example with a barbershop and Van Gogh exhibition. You might even notice that we didn’t even think about image optimization. Yes, it was and was not necessary. In the process of work, we have formed an approximate vision of how the client will work and we began to look for solutions for the designer himself, in order to take advantage of the benefits of visual editing as soon as possible.

MVP 2. Constructor


Based on what we saw when working with the client, we made a general conclusion that the bot can have several types of actions: send something, wait for user actions, send a request to an external service. For a minimally viable bot editor, we decided to limit ourselves to blocks:

  • Start - a technical unit that starts a new session
  • End - block ending the session
  • Message - upon reaching the block, the bot sends the message specified in the body of the block
  • — . ,

It was assumed that the blocks would be interconnected by arrows, or lines. All blocks except the “Start” block have one input port (socket). Many lines can connect to the input port, connecting the unit with others. All blocks except the End block have from one to several output ports. Output ports determine to which block control is transferred after the logic of the current block is completed.

After a short inspection of the available solutions, we settled on Rete.js (https://rete.js.org). I got acquainted with the documentation, examples and found in them everything that we needed to start. They even had an example just with a chat bot, which was the last trigger

Rete . . , — , JSON


Node in Rete.js

All nodes can contain a name, inputs, outputs and controls. Inputs and outputs should be located to the left and right of the node, respectively (for custom nodes there may be exceptions). They are represented by a socket and may have names. For the inputs, we allowed an unlimited number of connections (you can get to the node in many ways), for the output we limited ourselves to only one connection, however, unlike the input sockets, some blocks have many output sockets.

Rete.js is built in such a way that its functionality is expanded by creating custom nodes, controls, components, which allowed us to quickly get exactly the picture we wanted to see, for which I thank the creators of Rete ! Of course, one of the most important is a ready-made editor!

As written indocumentation :
An editor is an area with nodes and connections between their sockets. The following options are available:

  • Interaction with the workspace (moving, scaling) and node management (moving, adding, deleting)
  • Display of connections, nodes, their inputs / outputs and controls
  • Handling Editor Events
  • Import / export schema in JSON format
  • Extending functionality with plugins
  • Customization of the workspace, nodes and connections


Having conjured a little with Rete and having studied in more detail examples, we managed to build something that allowed us to create and delete blocks “start”, “end”, “message”, “keyboard input”. At the output, we received json with a description of the nodes, sockets, and lines connecting them.

One of the first versions of the editor

Already something, but this is not enough, because our web client does not understand this json. He needs some kind of his own, with the description of steps. It was decided to embed a converter from one json format to another in the client.

Json transformer


The utility receives NodesMap, compiled by the editor, as input, and returns a StepsMap that the client understands. The code of the entire transformer takes a little more than 100 lines, depending on the type of the node and the data, a suitable step, triggers functions, and a set of instructions (actions) to be performed in this step are created in it. There are instructions that save the variable in the chatbot state, there are those that substitute the variable in the text, or send a request to our server.

Having tied the components together, we began to test the resulting tools. Even without the backend, it was very exciting. We made up dialogs in the editor and inserted json into the client through dev tools, and as a result we got a bot that says how we need it! He also knows how to save variables and use them, damn it! Great sensations of the first victories ... The mosaic of the device of our application has already practically formed in my head, we got something working on the principles that we want to use in the future. We got a certain skeleton around which it remained to build up “meat”. And most importantly - it became clear how to do this:

  1. Change the editor, add the desired type of node
  2. We teach json transformer to transform a new node into a new step
  3. We teach the client to work with a new step

On the other hand, it was necessary to begin to engage in the user’s personal account so that it was possible to create bots, save them, manage and we decided to concentrate on this in order to quickly show users not a concept, but a product.

User account


The above libraries performed certain functions related to the creation of chatbot logic (editor), its interpretation or its reproduction (client). The issues of data storage, the ability to load created bots, managing them and setting properties not related to logic remained open and the application should have solved them for users. Armed with blueprintJS, we sketched a prototype of a personal account in which it was possible to register and create several bots. When you click on the bot to create a person had to fall into the editor with a new bot, and when you click on the bot card in the editor with this bot. We decided to entrust the functions of loading and saving the bot via the API of our backend to this layer in order to leave the bot editor independent of the backend.



The application of the user’s account is able to download the editor package and transfers ready data for display to it. This application also manages forms for setting bot properties (name, api keys, avatar, publication settings), and allows you to view statistics. In order to allow users to immediately see the result of the editor, we added a web client to the user’s office, to which we give the json bot scheme, he interprets it in steps and plays it on the “preview” tab. By and large, this is a very classic admin panel with a couple of interesting components (bot editor and web client), I think many did. But it was at this stage that it became noticeably inconvenient to develop our application.

Initially, it seemed to us a good idea to contain the product components in different repositories and we did not see any particular problem in this. However, it quickly became clear that keeping many repositories up to date is problematic, not to mention the need to dance with a tambourine when developing, because they are to some extent interdependent. And given that we had only one full-time developer, this approach was a huge awl in the ass. And any deployment turned into a branch of hell on earth because of the difference in the assembly and publication of libraries, applications, backward compatibility problems. Hence the banal, but not the most useless conclusion: premature allocation of modules can do more harm than helpI have already been convinced of this many times on the backend, and here I came again, but at the front. Yes, and I didn’t miss a chance on the backend: =)

One of my colleagues gathered his will into a fist and combined everything into a mono-repository managed with lerna . Now our only front-end repository is divided into packages: admin, client, common, dashboard, editor, web-module. They may have a different assembly inside, but lerna allows them to link together and update dependencies between packages. After that, the development and deployment of the frontend became much faster and easier, everything is immediately at hand, but still divided.

After creating the cabinet, we spent some time on new blocks in the editor and their processing by the client:

  • — . ( ),
  • — -
  • Email — email

I don’t have much to tell about the admin panel and web module, everything is very standard there. Let me just note that the admin panel should not be done ahead of time either . We have it, but no one uses it, because personally it is not difficult for me to see everything that interests me immediately in the database. There is no humanities that would need our admin panel in the team, and keeping it up to date is essentially a little less expensive than maintaining a user’s account. Over time, a simple dashboard was added there, displaying payments, new registrations and visits of the application, but this information is hardly worth the development of a whole admin. panels with tables, forms and separate authentication

Results?


We were able to build prototypes and landing pages very quickly. Yes, it was not at all what many imagine under the guise of MVP. But just a couple of evenings after the idea arose, we could begin to show it to people and test it. Different landing pages, advertisements, texts in the bot - we could test and search. I highly recommend that anyone involved in startup development think about how to get things done as quickly as possible. We made the first product to extract value in about three months, and then a more gradual process of regular improvement began. Of course, now we have more blocks inside the constructor, we added validation, data types, GET and POST requests, a lot of any design and display settings, but you could start without all this, which we did.

Over time, the system began to become more complex and evolve, and I was not able to even closely describe everything that is actually happening. Start small, things get complicated over time, when necessary. Any extra component can result in a very high cost because it is not only necessary to create and integrate, but also to support, test, document, deploy, monitor, introduce other team members to it. Probably you should not bother with queues on RabbitMQ, if before that there were no queues in your application. Most likely, solutions based on technologies that already exist will be enough for a start. Any new component is an additional cost for integration, operation, testing, support, documentation, deployment, etc., etc.

I hope my experience will be useful to at least someone. For a long time I tried to figure out which hub to determine this, but I did not understand. Let me know if it’s worth writing the second part in which I wanted to talk a little about the backend, external services and development plans

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles