All New IBM Watson Assistant Instances Now Default To The Enhanced Experience
And Why This Might Not Be Ideal
Introduction
Before reading this article, allow me to add two caveats…
Firstly, I do not know what the Watson Assistant feature list or roadmap looks like. There might be features around the bend which demystifies or nullifies some of the comments below.
Secondly, I might be missing something glaringly obvious…
From 9 February 2022 all new instances of IBM Watson Assistant (WA) points to the new interface. This new interface or experience is Actions based and not independent NLU/Dialog Skill based.
Seemingly, for new instances the previous interface is inaccessible. However, for existing implementations in the previous interface, no work will be lost when toggling or switching between the two environments.
For existing implementations, you can switch back to the classic/previous experience at any time by clicking Switch to classic experience from the account menu.
As seen above, In the IBM Cloud Catalog, if Watson Assistant is selected, the about section focusses on Actions.
The New Watson Assistant Experience
WA created a whole new interface focusing on:
- A managed and guided end-to-end experience taking users from the initial design phase to production launch.
- Simplified Low-Code Approach
- Deprecating traditional NLU in general. And Intents in specific.
- Deprecating the dialog skill approach…for now at least.
- Solely going with the Actions approach to dialog development. Actions is analogous to Microsoft Power Virtual Agents
- Entities becomes more slot filling and variables exercise
- Focus is on Web Chat deployment
As seen above, in the new Watson Assistant Navigation pane, Actions are first and foremost in the Build sequence of events.
Actions are at the core of the conversational agent. Actions encapsulates NLU with an input-to-meaning approach and the entities concept are implemented as slots.
The chatbot experience is focused on web chat and the new interface go to great lengths in how the web chat experience will look.
As seen above, the test pane can be hosted in a grey-scaled mock website.
As seen above, users can enter their website URL for a more realistic, production-like implementation feel. This function is ideal in a sales environment where a realistic and compelling demo is required.
As seen above, the final demo view, with the website view. And a fully interactive chat window on the right.
The Good
- IBM is simplifying the process of getting a bot to production
- Integration to cloud call center solutions are simplified for live agent transfers
- Integration to conversational mediums are also made easy, to mediums like SMS/text, WhatsApp, Facebook Messenger, phone integration etc.
- Actions have been improved with elements like digression, variable management, response types, response settings and more
- Conversational topics can be addressed in a modular fashion
- Conversational steps can be dynamically ordered by drag and drop
- Variable management is easy and conversational from a design perspective
- Conversation state conditions can be set
- Design and development are combined
- Integration with current solutions and development tools like Twilio
- Formatting of dialog presentation & design affordances
The Not So Good
- Finetuning of the conversational experience is absent. Complex implementations will outgrow the Watson Assistant Actions environment
- Highly configurable mediation layers will be required on the medium-end of the solution and also the services integration
- If used in isolation scaling impediments will be encountered
- It remains a State Machine Approach to dialog management
- Linear Design interface
Watson Assistant Dialog Skills is unique in its approach to dialog development and in many respects a complete solution. It will be a shame if this functionality will be deprecated. Should this happen, it will surely disrupt the planning and roadmaps of most established customers and users.
More Observations
Firstly…Watson Assistant Actions will surely impress with the speed with which one can develop a prototype chatbot or voicebot conversation, with various medium and live agent integration.
However, as the conversation and functionality grows, finetuning will be required for the conversation.
Mediation layers are custom code which facilitates the communication between the chatbot framework and the integration points. This assists with custom logs, lower level of control, and customized resilience and more. Added are elements like fail-over, error handling etc.
Out of the box integration will not suffice and a mediation layer or intelligent connector will be necessitated for transfer to live agents and medium integration.
Secondly…As I have written below, Actions implemented in a way it was not intended will lead to impediments in scaling and leveraging user input in terms of intents and entities.
The initial implementation scenario for Actions, was to act as an extension to Dialogs. To create quick and re-useable extensions to dialogs. These extensions can be for customer satisfaction surveys…capturing specific data etc.
Thirdly…If a Dialogs approach (as seen in classic Watson Assistant) is not incorporated in the new Watson Assistant experience in future, scaling will always be problematic and Watson Assistant will not be favored for large implementations.
Fourthly…It seems like IBM is aligning with an Web 3.0 approach where the chatbot is very much integrated with the web, or an organizations website. And content is presented and organized according to the user’s input. With the chatbot acting as a conversational user interface in order to render the web content and media.
This is surely one implementation for a conversational agent, but there are many others. Taking a narrow approach, as it seems IBM is doing now, will have detrimental consequences in the future.
Fifthly…to democratize the access to chatbots, terms and concepts need to be simplified, and the user interface simplified. The real challenge is to do this, whilst not sacrificing functionality. This functionality will be desperately needed as the conversational agent grows in complexity.
So, how do companies maintain functionality whilst simplifying the development and management interface…there are a few examples in the market place. But it does not feel as if IBM is accomplishing it here.
A Few Key Features Of Actions
- You can think of an action as an encapsulation of an intent. An action is defined by a set of user input examples. No intents are defined, an Actions skill is an intent-less implement. A type of end-to-end approach. Deprecating the use of intents.
- An action is a single conversation to fulfill an intent and capture the entities. An conversational extension of the subject.
- A single action is not intended to stretch across multiple intents or be a horizontally focused conversation.
- Think of an action as a narrow vertical and very specific conversation.
- Actions must not be seen as a replacement for dialog skills.
- Actions can be used as a standalone implementation for very simple applications. Such simple implementations may include: customer satisfaction surveys, customer or user registration etc. and short and specific conversations.
Most importantly, actions can be used as a plugin or supporting element to dialog skills.
Of course, your assistant can run 100% on Actions, but this is highly unlikely or at least advisable. You will always have a collection of skills in your assistant.
The best implementation scenario is where the backbone of your assistant is constituted by one or more dialog skills, and Actions are used to enhance certain functionality within the dialog. And a search skill can be added for discovery.
Don’t Use Actions Like This
It does not seem sensible to build a complete digital assistant / chatbot with actions. Or at least not as a standalone conversational interface. There is this allure of rapid initial progress and having something to show. However, there are a few problems you are bound to encounter…
A conversation built making use of Actions with conditional checks and re-prompts where the condition fails.
Conversations within an Actions skill are segmented or grouped according to intents. Should there be intent conflicts or overlaps, inconsistencies can be introduced to the chatbot.
Entity management is not as strong within Actions as it is with Dialog skills.
Compound intents, or multiple intents per user utterance can be problematic.
In Closing
Dialog Skills are displayed assistant settings as a future, coming soon feature. The length of this moratorium on Dialog Skills is not known and the shape or form of future dialog skills are also not known.
As mentioned before, simplification is important, but over simplification can lead to the diminishing of functionality, which in turn impedes scaling of the chatbot.
Ensuring the customization of chatbot responses based on the medium will always be relevant, but for complex enterprise-scale implementations, a coded mediation layer will be required. The services needs to be independent of each other so so that even if one service is replaced or changed, the other services can seamlessly interact with new services.
