It is rare that business doesn’t want to provide a 24×7 personalized services. But they rarely do. Why? It is easy to personalize content in graphical user interface (GUI), but it is generally impossible to personalize arbitrary services as user interaction design and implementation can get out of hand quickly. Hiring live agents is not option, as it is not scalable to operate. Chatbot has the potential to be the solution, but it is too expensive to build today.
There are many reasons why it is expensive to build usable conversational user interface (CUI) to your services. Today let’s focus on a major one of these: the lack of component based framework. I will talk about what is the component driven development and why it is a good idea to adopt this methodology. And then we will cover the main considerations for building a component based framework specific to conversational user experiences. It should shed some light on why such framework is more involved thus hard to come by. At same time, it should also be clear that nothing is really insurmountable, chatbot will be built in far greater number than any other types of application when we overcome this and other blocking issues.
Component driven development
Component-Driven Development (CDD) is a development methodology that advocate build things based on prefabricated components. This methodology is popular because it exploit the following observation: it is generally much more involved in building something than using it. You can light a match, but can you produce a box of matches? Way harder. Using off-the-shelf component is a key way to reduce cost in building things. It is no surprise that CDD is widely adopted in real world, we can see its application everywhere, in construction, in computer manufacturing, and of course in software development.
But what is a component? Per Cambridge dictionary, A component is a part that combines with other parts to form something bigger. In software development, there are three aspects about component:
- Self contained. The component should provide the claimed functionality without external help. For example, any date picker will encapsulate the details like leap years, variance in months of the year and interaction between day of week and day of month, etc. The caller of the component does not need to know anything about it.
- Reusability. The same component can be wired into different context for different larger purpose. Like, the same date picker can be used in any context where we need to get a date from user, and it is typically possible to wire the result of this component to outer context declaratively.
- Configurability. Ideally, builder can customize its behavior via configuration (think low bandwidth control so caller does not have to say much). It is very easy to setup the initial state of date picker to for better user experience, and sometime, it is also easy to configure the look and feel via well defined control.
1. How Conversational AI can Automate Customer Service
2. Automated vs Live Chats: What will the Future of Customer Service Look Like?
3. Chatbots As Medical Assistants In COVID-19 Pandemic
4. Chatbot Vs. Intelligent Virtual Assistant — What’s the difference & Why Care?
In user facing front end development, CDD is even more prevalent. Almost all modern frontend framework at their core are component based, Reactjs, SwiftUI, Vue, you name it. But why this is the case?
Benefit of the component based approach
There are many possible angles that component based approach can be advantageous.
- Since the same component can be used multiple times in the different context, the average cost of get same functionality via component is lower, some time much lower comparing to build it from scratch (can be close to zero).
- Simply update the component to new version can fix the issues of component without much of builder’s involvement, some time before builder even realized there is a problem.
- Using component can greatly reduce the time to market. As component can be prefabricated or developed in parallel.
- Using component allow builder try different things quickly. As builder can focus on what they want instead of how to build it.
Conversational user interaction (CUI) component
For conversational user interface, the component based approach can be more appealing. As half of the user interaction is dictated by end users, it is very likely that we will converge to smaller set of CUI components thus introduce huge cost savings in building conversational user experiences. But what are the basic considerations of highly reusable conversational user interaction component?
The center of the any CUI component is what information, or set of slots, can be collected from user through conversation so that chatbot can use such information to invoke services user wants. Obviously schema for the same vertical can be fairly stable, which makes conversational user interaction a profitable target for componentization.
Given the set of slots that chatbot need to collect through conversation, one can define the interaction logic, imperatively or declaratively, which dictates how these slot will be filled. This is the part of the CUI component that need to be encapsulated. One of the key requirements on the conversational interaction logic is order insensitivity. Assume user knows what they want, the collected information should not change regardless in what order user choose to provide the information. In another word, CUI component should behave deterministically with respect to the order of user input. While the state machine is enough to model the graphical user interaction (GUI), one typically needs to use statechart (Harel statechart) to efficiently model the conversational user interaction even at the single frame level, because we can not control what user might do.
It should be easy to port the same interaction logic into different languages. To this end, there should be simple configuration on these CUI components that one can customize its dialog understanding and text generation behavior. Ideally, such configuration should requires no background in the natural language understanding or machine learning so that everyone can contribute to language aspects without going though steep learning curve.
For graphical user interface component, the runtime can be fairly simple because the wiring of components are static after being determined at configuration time. Since we can not control what user might say or do, the runtime for CUI component need to be a lot more involved. For example, to support user seamlessly switching between different topics, chatbot runtime need to dynamically figure out the pronoun antecedent from context, automatically switch between different topics accordingly, so that chatbot and user are always on the same page.
Integration with service
For task oriented conversation, the goal is always connecting user with desired services. So it should be possible for the CUI component to pair up with different service providers for maximal reuse. Furthermore, when CUI component used together with the compatible backend component, builder can simply deliver services directly by populate the table hosted in the backend components, without need to understanding how component works at CUI level.
The advent of high level component based frameworks greatly reduced the cost of building the GUI application, and there is little question that these frameworks contribute to the ubiquitous availability for web and mobile apps. However, the conversational user experience are still mainly built from scratch. It is excruciating slow and expensive and only the team with extreme deep pocket can do it well. Lacking of well designed component based CUI framework has plagued the chatbot development for so long as there are many aspects need to be taken care of. But the wait is over: check framely.io to see how you can build chatbot in a component approach today.