Chatbots: Testing Contexts

Watson Conversation Tool in action

Some weeks ago I blogged about a tool I wrote for the IBM Watson Conversation Service (WCS). It allows you to manage your conversation workspaces from the command line and to test dialogs. Yesterday, I added a new feature to it that helps me (and you) to examine and modify the dialog context. Here is how you can test contexts with my watson conversation tool.

Best practices for lively chatbots

TJBot as lively chatbot

More and more chatbots are being developed and there are good reasons for it. Not all chatbot projects succeed. Often, missing user acceptance is stated. The dialog system might not have hit the nerve, might not have fitted into the target environment. Would you talk with a friend who does not remember your name is repeating the same five phrases over and over again? I would not. So what can be done to make chatbots more lively, more human-like? Here are some best practices and ideas on how to implement them.

Introduction

I started my series on chatbots with lessons and tips from a chatbot hackathon. In that blog I focused on general aspects of building dialogs and designing a conversation system. The language needs to fit the audience. It is something we will look at again today. In a recent blog post I shared tips and tricks for building chatbots. It is possible to carry context throughout a conversation and embed conditions and advanced expressions into the dialog flow and single reponses. We will use that to implement some of the best practices found below. Building lively chatbots could also mean to give the bot a face. The open source project TJBot (pictured) is an example for that. The TJBot can listen, speak and see, give additional feedback and interact through its arm and its light. We won’t cover those aspects, e.g., hardware design or user interfaces, in this blog entry.

IBM Marketing and DB2, Db2 and dashDB

IBM Cloud with Bluemix: DB2, Db2, dashDB

This week I am going to acknowledge that I have been with IBM for 16 years. Looking back, everything might seem brighter and better than it was. However, I remember working in great teams, interesting and challenging projects, many successes and some failures to learn from, and the constant changes. During the time with IBM I got used to those many changes to product names, the constant rebranding. When I first heard about a change to DB2 that was announced last week, I scratched my head and moved on. The product itself does not change, it's a name.

Here are some of the changes, see the Db2 website for details:

• DB2 for Linux, UNIX, and Windows (DB2 LUW) is now names just "Db2".
• DB2 for z/OS is "Db2 for z/OS".
• dashDB TX (dashDB for Transactions) is referred to as "Db2 on Cloud". It reflects that it basically was and is a fully managed Db2 (LUW) database system.
• The former "IBM DB2 on Cloud", the cloud-hosted version of DB2 LUW, is now named "Db2 Hosted" to correctly imply what it is.

To keep you mentally flexible and to stimulate your brain cells, the uppercase B in "DB2" is now lowercase. "Db2" is what you will see more and more on the outside. But the product itself, as stated above, will remain "DB2". Therefore, you don't have to rewrite your test procedures. And if you have to prepare slides, e.g. for one of the upcoming IDUG conferences, there is one benefit with the new naming: Autocorrect is correct now...

A great Summer and a sane week!