IBM Watson Assistant Actions Now With Improved Management

With The First Foray Into Watson Assistant Actions Finetuning…To Some Extent

Cobus Greyling

--

Introduction

On 19 August 2021 a new feature was released for IBM Watson Assistant Action skills. The preview and test pane in Actions now includes tow tabs; debug and variable views. This brings the testing process close and in-step with the application created.

IBM Watson Assistant Actions can be seen as a low-code approach to build chatbots which are constituted by an array of intents.

Within the preview pane, a Debug mode and Variable values tab have been added. Discussed in detail later…

And each intent has a very linear and simplistic dialog.

However, since inception quite a few features have been added to to Actions.

The latest being debug mode and variable values. Which I discuss in detail later in this article…

Other enhancements added were digression, sub-dialogs, currency and percentage response types etc.

It is evident that an ever increasing array of functionality is being added to Actions. In a sense it is detracting from the minimalistic feel which was a hallmark with the inception of Actions; with the environment becoming increasingly complex.

And all the while, the user needs to be cognizant that there is a threshold of functionality and complexity, and if crossed…Actions will cease to be optimal for the implementation… and Dialog Skills will need to be used.

The sequence of events (steps) are set on the left. Variables are set and default values can be setup. Simple or complex conditions can be set for each step. The exit of a step can range between a few options.

There is also the possibility that Action Skills are a first foray into Intent deprecation and encapsulating a conversation within an intent group. And subsequently linking these steps up.

With digression, each Action within a Skill can act as a sub-dialog. Very much analogous to the sub-dialog idea within VoiceXML.

What Are Action Skills Intended To Be?

At the inception of IBM Watson Assistant Actions, it was evident that the ideal use-cases for Actions include:

  1. Very simple and linear chatbot interactions like a customer survey, or user feedback.
  2. To act as an extension to Dialog Skills. Plugging functionality in and out of Dialog Skills. This adds a level of flexibility.
  3. You can think of an action as an encapsulation of an intent. Or the fulfillment of an intent.
  4. An action is a single conversation to fulfill an intent and capture the entities.
  5. A single action is not intended to stretch across multiple intents or be a horizontally focused conversation.
  6. Think of an action as a narrow vertical and very specific conversation.

Advantages of Actions include:

  • Conversational topics can be addressed in a modular fashion.
  • Conversational steps can be dynamically ordered by drag and drop.
  • Collaboration
  • Variable management is easy and conversational from a design perspective.
  • Conditions can set.
  • Complexity is masked and simplicity is surfaced.
  • Design and Development are combined.
  • Integration with current solutions and developed products
  • Formatting of conversational presentation.

Disadvantages of Actions include:

  • If used in isolation scaling impediments will be encountered.
  • Still State Machine Approach to dialog management.
  • Linear Design interface.

Variable Values & Debug Mode

In general, one vulnerability with chatbot development frameworks is the turn-around time to go from development to testing. Changes are made to the chatbot application, and a lengthy process needs to be followed to save, deploy, restart the testing environment, and start a test conversation.

And obviously this is an iterative process.

This is especially debilitating when troubleshooting and much time is lost during this process.

Another challenge, in general, with testing chatbots is that the test environment and development environments are really separated and not integrated. And the maker is having a hard time linking the two together and establishing a correlation.

This feature is helpful when re-using features within an action, but not wanting to re-prompt the user on each step. Steps can be skipped if the information is available.

This is all solved in Watson Assistant Actions with the debug and variable view within the preview test pane.

Click on the Debug mode icon to view the detail.

As the conversation continues, values are populated on the fly and changes can be made to the values. This helps in steering the conversation mid-stream without restart the conversation to enter alternative value.

Below you will see some detail on that…

Variable values can viewed as the application is tested.

From this preview while debug is active, the NLU scores can be gleaned. The step sequence can be viewed; when clicking on the Go to icon, the relevant step in the action is displayed. This serves as a quick link between the test environment and development environment.

From this preview while debug is active, the NLU scores can be gleaned. The step sequence can be viewed; when clicking on the Go to icon, the relevant step in the action is displayed. This serves as a quick link between the test environment and development environment.

You will see two types of variables in the test pane:

  • Action Variables
  • Session Variables

Action Variables are named after the step in which the data that is stored in the variable is collected from user input.

A session variable is a variable that you can set and use across all actions. A session variable exists for the duration of a single session. A session is what we call an instance of a conversation between the assistant and a customer.

The Session and Action variables are populated in real-time during the conversation. A session variable is a variable that you can set and use across all actions. A session variable exists for the duration of a single session. A session is what we call an instance of a conversation between the assistant and a customer.

Conclusion

The easy approach to chatbot development is to structure the conversation very firmly from the chatbot’s perspective. And funnel the user in and out of the conversational interface, this might even present very favorably in reporting. But the user experience is appalling in most cases.

Overly structuring the conversation breaks the beauty of a conversational interface. Unstructured conversational interfaces is hard to craft but makes for an exceptional user experience.

One of the reasons is that user’s are so accustomed to having to structure their input, that they want to enjoy and exercise the freedom of speech (spoken or text), which can lead to disappointment if the expectation of freedom is not met.

I guess the focus of Action Skills is to rapidly roll out conversational experiences, enabling non-technical makes. But, added to this, Actions might be IBM’s vehicle to take cutting-edge innovations to market. Hence the augmentation of functionality.

--

--