VISUAL DESIGN OF A CONVERSATIONAL BOT

Abstract

A visual bot designer displays a user interface that has a visual authoring canvas and a property pane. It can also have a serialized file display pane. A user can provide authoring inputs on any of the user interfaces, and the visual bot designer computing system generates and displays updates on the other parts of the user interface.

Description

BACKGROUND

There are a wide variety of different types of computing systems. Some computing systems run applications configured to interact with user. Some applications are local to a user device, while others are hosted by a service on a remote server architecture (such as on the cloud).

Bots are software applications that perform tasks over a wide area network (such as the Internet. Bots are often deployed to implement interfaces that users interact with in a repetitive way. Conversational bots, or chat bots, for instance, often receive natural language queries from users, and respond to those natural language queries by taking actions or by responding to the user in natural language. Designing and authoring dynamic experiences can be difficult. When one designs and develops a bot, the process can be cumbersome, time consuming and error prone.

The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.

SUMMARY

A visual bot designer displays a user interface that has a visual authoring canvas and a property display portion. It can also have a serialized file display pane. A user can provide authoring inputs on any of the user interfaces, and the visual bot designer computing system generates and displays updates on the other parts of the user interface.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one example of a visual bot designer.

FIG. 2 is a block diagram showing one example of a chat bot or conversational bot.

FIG. 3 is a block diagram showing one example of components of a dialog flow.

FIG. 4 is a block diagram showing one example of designer user interfaces generated by the visual bot designer computing system.

FIG. 5 is a screen shot showing a particular example of one user interface.

FIGS. 6A and 6B (collectively referred to herein as FIG. 6) show a flow diagram illustrating one example of a design operation performed using the visual bot designer computing system illustrated in FIG. 1.

FIG. 6C shows one example of propagating a change on one interface to another interface.

FIG. 7A is a screen shot illustrating one mechanism for adding visual elements to the visual authoring canvas.

FIG. 7B is an example of a user interface that is similar to FIG. 7, but it shows a set of dialog management actuators.

FIGS. 8A-8G show examples of user interfaces that can be generated in the property pane of the user interfaces to generate and configure a trigger.

FIGS. 8H, 8I, and 8J show examples of a user interface in which a user can author events that triggers handle, in the bot being designed.

FIG. 8K is a flow diagram showing one example of how triggers are configured.

FIGS. 9A-9U show examples of property configuration interfaces for action nodes representing actions that can be added to a dialog flow.

FIG. 10 is a screen shot showing one example of a list of things that triggers can handle, in a bot.

FIG. 11 shows one example of a user interface to the visual bot designer computing system in which a looping action is selected in the visual authoring canvas and displayed in the property pane.

FIGS. 12A and 12B show one example of a JSON serialization of a visual representation on the visual authoring canvas, and displayed in a JSON file pane.

FIG. 13 shows one example of a language generation template that can be generated from the JSON serialization, and which can be processed by a computing system to perform bot operations.

FIG. 14 is a flow diagram illustrating one example of the operation of the visual bot designer computing system in receiving and processing authoring inputs on the visual authoring canvas.

FIGS. 15A and 15B (collectively referred to herein as FIG. 15) show one example of a flow diagram illustrating the operation of the visual bot designer computing system in performing undo/redo operations.

FIG. 16 is a block diagram of the architecture illustrated in FIG. 1, deployed in a cloud computing architecture.

FIG. 17 is a block diagram of one example of a computing environment that can be used in the architectures shown in the previous figures.

DETAILED DESCRIPTION

As discussed above, designing and authoring conversation bots, or chat bots, can be difficult, time consuming and error prone. Moreover, conversations, by nature, are dynamic. For a developer to design a system that anticipates and deals with unexpected responses, or interruptions, is difficult and complex. This type of system can be difficult to envision, communicate, and debug/improve. The present discussion thus proceeds with respect to a visual bot designer that has a visual authoring canvas that an author can interact with to design the logic flow for a bot. Code is automatically generated and can be displayed. This provides an intuitive, visual interface for bot design. Thus, people with varying degrees of coding expertise can author a bot. This technique for bot design increases efficiency in bot generation. It also facilitates re-use of bot components, which increases processing efficiency and can reduce storage requirements. Because the bot designer is highly intuitive, it also increases design accuracy.

FIG. 1 is a block diagram of one example of a computing system architecture 100. Architecture 100 shows visual bot designer computing system 102 that generates an interface 104 for interaction by an author (or user) 106. Visual bot designer computing system 102 also includes one or more processors or servers 108, data stores 110, application programming interfaces (APIs) 112 and it can include other items 114. In one example, system 102 also includes a language generation system 116, a natural language understanding system 118, and it can include other items 120, all of which are coupled to API 112. It will be noted that the language generation system 116, natural language understanding system 118 and other items 120 can be separate from visual bot designer computing system 102, and accessed by API 112 in a wide variety of ways (such as over a large area network, a local area network, near field communication network, a cellular communication network, or any of a wide variety of other networks or combinations of networks). In addition, author (or user) 106 can interact directly with user interfaces 104, or can otherwise interact with visual bot designer computing system 102, over a network, where visual bot designer computing system 102 is hosted in a remote server environment. These and other architectures are contemplated herein.

In the example illustrated in FIG. 1, designer user interfaces 104 illustratively include visual authoring canvas 122, property pane 124, serialized (e.g., JSON) file display pane 126, user interface control logic 127, and can include other items 128. Each of the designer user interfaces 104 illustratively includes functionality that allows author 106 to interact with the user interface in order to generate, delete and modify information thereon. For instance, visual authoring canvas 122 can have drag and drop functionality that allows author 106 to drag and drop elements onto, and remove visual elements from, the authoring canvas 122. Property pane 124 may have text boxes or other editable elements with which author 106 can interact to configure properties. Serialized file display pane 126 can display a serialized version of the elements on visual authoring canvas 122 and the corresponding properties on pane 124. The serialization pane 126 may be referred to herein as JSON file display pane 126, but this is by way of example only. Pane 126 can be editable or otherwise allow author 106 interactions. Interface control logic 147 detects interactions by author 106 with interfaces 104 and provides an indication of the interactions to API 112.

Data store 110 illustratively includes a set of bots 130-132 in various stages of design. It can also include other items 134. Each bot (e.g., bot 130) includes content 136 which is indicative of the linguistic elements that will be used by bot 130. It can also include flow/logic 138 which defines how bot 130 will run. Each bot 130 can also include undo/redo stacks 140 (or they can be stored elsewhere) so that author 106 can switch between different functional versions of bot 130 as it is being designed. Each bot 130 can include a wide variety of other items 142 as well.

Application programming interface 112 illustratively facilitates communication among various items in computing system 102 and it can implement bot design functionality 113 as well. Bot design functionality 113 is shown in API 112, as one example, but it (or parts of it) can reside elsewhere as well. Bot design functionality 113 can include a bot schema (or logic) 144. The inputs by author 106, through designer user interfaces 104, allow author 106 to generate a bot in accordance with bot schema 144. Bot design functionality 113 also illustratively includes code translator/generator 146, flat view generator 147, bot validation logic 148, bot storage logic 149, undo/redo logic 150, deployment logic 151, and it can include other items 152.

Code translator/generator 146 illustratively receives inputs on different portions of the designer user interfaces 104 and generates updates that are then displayed on the other portions of designer user interfaces 104. Some examples of this are described below. For instance, if author 106 adds a node (or other visual element) to visual authoring canvas 122, then logic 127 detects the element and provides an indication of the element to API 112. Code translator/generator 146 generates code, or translates that visual element, into a serialized representation that can be displayed on JSON file display pane 126. Similarly, if author 106 edits the JSON serialization on display pane 126, for example, to add an action to the bot, then code translator/generator 146 illustratively generates a visual element corresponding to the action and places it on visual authoring canvas 122, in a way that corresponds to the edited serialization displayed on JSON file display pane 126. The same is true for modifications made by author 106 in property pane 104. If author 106 modifies properties in property pane 124, then code translator/generator 146 generates information to update visual authoring canvas 122 and JSON file display pane 126, based upon the modifications to the properties. Similarly, if either the visual representations or the JSON file is modified, modifications are also propagated to property pane 124.

Undo/redo logic 150 illustratively detects user interaction with an undo/redo actuator (described in greater detail below) and allows the user to switch between different functional states of the bot application being designed. It thus controls the content of undo/redo stacks 140 in data store 110 to allow the user to switch back and forth in this way.

Bot validation logic 148 illustratively performs validations on the bot, as it is being designed by author 106. It can surface the result of those validations so the bot application can be corrected by the author 106 as necessary.

Also, as is described in greater detail below, when designing or authoring a bot, author 106 may provide an example of a textual input that is to be recognized in response to a prompt when it is input by a bot end user, later, at runtime. In another example, the author 106 may provide a textual example of responses that may be output by the bot when specified conditions are met. In such cases, language model building control logic 145 can provide the text to language generation system 116 and/or natural language understanding system 118. Language generation system 116 (alone or in combination with natural language understanding system 118) can be any form of language generation system (such as one based on artificial intelligence, or other models) and can generate additional example inputs and/or outputs, or a model therefor, based upon the textual examples provided by the author 106. In this way, the bot being designed will have much greater flexibility in recognizing and responding naturally to end users, without the author 106 needing to write out all possible expected dialog inputs or outputs.

Natural language understanding system 118 can be any of a wide variety of different types of natural language understanding systems. It can be a rules-based system or one based on models generated using artificial intelligence and/or machine learning. In one example, author 106 can simply select which type of natural language understanding system (or which particular system) is desired to process natural language in the bot being designed, and API 112 illustratively connects the bot functionality to that particular natural language understanding system 118. When the bot is deployed, it uses the selected natural language understanding system.

Flat view generator 147 generates a view of the linguistic elements (words, numbers, other alphanumeric characters or elements, etc.) used in the bot that is easily readable, in context, by author 106, and that can be easily searched, translated, etc. This is described in greater detail below. Bot storage logic 149 interacts with data store 110 to store the bot, and deployment logic 151 can be used to deploy the bot to a desired channel.

FIG. 2 is a simplified block diagram illustrating one example of a bot, in more detail. FIG. 2 shows an example of chat/conversational bot 130, after it has been designed. In the example, the bot 130 has one or more triggers 154. A trigger is configured to respond to a triggering event such as an input from an end user, an event in a running dialog, or other things, some of which are described below with respect to FIGS. 8A-8G and FIG. 10. When a triggering event, corresponding to a trigger, occurs, the trigger causes some operation to occur. For instance, the trigger can be configured to (upon the occurrence of its triggering event), launch a dialog flow, or cause the bot to perform other operations in response to the triggering event it is configured for. Triggers 154 can be configured to respond to intents 156, or any of a wide variety of other events 158. When the bot 130 is prompted by one of the triggers 154, it illustratively launches one or more dialog flows 160-162. One example of a dialog flow is described in greater detail below with respect to FIG. 3. The dialog flows are illustratively interruptible so that they may dynamically respond to changes in end user interactions (or other triggering conditions). That is, the bot 130 can launch a different dialog flow in response to detected changes. Bot 130 can have other items 164 as well.

FIG. 3 is a block diagram showing one example of dialog flow 154, in more detail. It can be seen in FIG. 3 that dialog flow 154 illustratively includes linguistic element content files 166 which include a textual representation of the inputs and outputs used in the dialog. Files 166 can include other alphanumeric content, or other symbols as well. Dialog flow 154 also illustratively includes flow/logic files 168 that define the flow or logic of the bot and how it uses the language content files 166.

The flow/logic files 168 can include triggers 170. They can include any of a wide variety of actions 172, and they can include other items 174. An action is a step of bot execution. Some examples of the actions 172 that can be included in the flow/logic files of a dialog flow 154 include a begin a dialog action 176, prompts 178, a send response action 180, a branching action 182, a looping action 184, edit/repeat/replace dialog actions 186, initialize/set/delete a property actions 188, an emit a trace event for debugging action 190, an end dialog action 192, an HTTP request action 194, and any of a wide variety of other actions 196. Many of the actions 172 are described in greater detail below.

Briefly, however, the begin a dialog action 176 illustratively begins a particular dialog in bot 130. A prompt action 178 prompts the user of the bot for an input. The send response action 180 sends a response, in response to a user input or otherwise. A branching action 182 defines conditions under which different branches are to be taken in the flow or logic of the bot. A looping action 184 controls the bot to loop over various actions or items based on looping criteria. The edit/repeat/replace dialog action 186 causes a dialog to be edited, repeated, or replaced with a different dialog. An initialize/set/delete a property action 188 causes a property of an action or other element to be initialized, set to a particular value, or deleted. An emit a trace event for debugging action 190 illustratively emits trace events that allow a developer to track where processing is occurring through the bot flow/logic 168.

An end dialog action 192 illustratively ends the dialog. An HTTP request action 194 allows the bot to make an HTTP request to an external service, or to another external computing system.

Each of the triggers 170 and actions 172 may have a set of properties that can be configured by author 106. Therefore, when a trigger or action is selected on visual authoring canvas 122, its corresponding property values are displayed in property pane 124, where they can be edited. Also, the JSON serialization of that trigger 170 or action 172, when it is selected on visual authoring canvas 122, is displayed on JSON file display pane 126.

FIG. 4 is a block diagram showing one example of a set of design user interfaces 104, in more detail. In the example shown in FIG. 4, design user interfaces 104 illustratively include menu pane 200, navigation pane 202, visual authoring canvas 122, selection-driven property pane 124 and JSON file display pane 126. Menu pane 200 can include a plurality of different menu selectors 204-206. Navigation pane 202 can include a plurality of dialog selectors 208-210. When author 106 actuates one of the selected dialog selectors 208-210, the author is navigated to the corresponding dialog, which is displayed on visual authoring canvas 122, property pane 124 and JSON file pane 126. The author 106 can then actuate any of a variety of different actuators 212-220 to take actions to perform design operations on the selected dialog. In the example shown in FIG. 4, those actuators include an add intent actuator 212, a delete intent actuator 214, a show intent actuator 216, a new trigger actuator 218, and it can include other actuators 220. Navigation pane 202 can also illustratively include a new dialog actuator 222. When author 106 actuates new dialog actuator 222, the author is provided with an interface that allows author 106 to begin designing a new dialog using visual authoring canvas 122, selection-driven property pane 124, and/or JSON file pane 126. Navigation pane 202 can include any of a wide variety of other actuators 226 as well.

In the example shown in FIG. 4, visual authoring canvas 122 displays visual elements corresponding to a bot 228. Bot 228 illustratively includes a trigger node 230 corresponding to a trigger that begins a dialog in bot 228. Bot 228 includes a plurality of different dialog nodes 230-232, which can be action nodes in different dialogs, different action nodes in the same dialog, etc. Nodes 230, 232 and 234 are illustratively linked to one another by links 236-238.

In one example, actuators in links 236 and 238 can be actuated in order to insert or add nodes between the two linked nodes. For instance, if the user wishes to add a dialog node between dialog nodes 232 and 234, the user can illustratively actuate link 238 and a menu is displayed which allows the user to add a node. In one example, the menu is defined by the bot schema 144 in API 112. Therefore, interface control logic 147 accesses the bot schema 144 to display different possible actions that the user can generate for insertion between nodes 232 and 234. Bot 228 can include a wide variety of other nodes and/or links 240, as well.

Selection-driven property pane 124 illustratively displays the properties of the node that is selected on the visual authoring canvas 122. These properties are indicated by block 242 in FIG. 4. The properties can include such things as the name of the node 244, the description 246 of an action performed at the node, and a wide variety of other properties 248 of the selected node. In one example, some or all of the properties 242 are editable by author 106. For example, they can be authored using a point and click device to select a property, and then by typing or otherwise editing the property.

JSON file pane 126 illustratively includes a display of the JSON file for the bot displayed on the visual authoring canvas 122. This is indicated by block 250 in the block diagram of FIG. 4. The JSON file is just one example; in other aspects, the displayed file may be another serialization or other representation of the bot being displayed on visual authoring canvas 122. In addition, in one example, when the user selects one of the nodes (or other visual elements) displayed on visual authoring canvas 122, then the selection-driven property pane 124 and the JSON file pane 126 are updated to show the information corresponding to that selected visual element. The reverse is also true. For example, where author 106 selects a portion of the JSON file displayed in pane 126, then the corresponding visual element is selected, highlighted or otherwise visually perceptible on visual authoring canvas 122, and the corresponding properties are displayed on property pane 124.

FIG. 4 also shows that, in one example, user interfaces 104 include a redo/undo actuator 252 (which can alternatively be separate actuators), and a start bot actuator 254. As is described in greater detail below, when author 106 actuates redo/undo actuator 252, the user can navigate between different functional states of the bot being designed. By functional it is meant that the bot will operate, although it may not operate as intended by author 106. Similarly, when author 106 actuates start bot actuator 254, the bot being designed is launched so that it the author 106 may interact with the bot as it will be deployed (such as to test the bot, etc.).

FIG. 5 is an illustration of a user interface display representing an example designer user interface 104. The example shown in FIG. 5 shows menu pane 200, navigation pane 202, visual authoring canvas 122, and selection-driven property pane 124. Some of the items shown in FIG. 5 are similar to those shown in FIG. 4, and they are similarly numbered.

In the example shown in FIG. 5, menu pane 200 includes menu selectors that allow different information corresponding to a bot to be displayed on interface 104. For example, design flow actuator 256 can be selected by author 106 to display information such as that shown in FIG. 5. Visual authoring canvas 122 shows visual elements corresponding to the design flow of the selected bot. Menu pane 200 can include a “test conversation” actuator 258 that can be actuated to test the conversation portion of the bot being designed. Menu pane 200 includes a “bot says” actuator 260 and a “user says” actuator 262. These actuators can be selected by the author to display, in pane 122, the dialog that is output by the bot, and the dialog that is expected from the user of the bot, respectively. An “evaluate performance” actuator 264 can be actuated to evaluate the performance of the bot against test data, and a settings actuator 266 can be actuated to display and modify settings.

Navigation pane 202 illustratively has a plurality of different actuators, some of which are discussed above with respect to FIG. 4.

Visual authoring canvas 122 shows visual elements corresponding to a bot that is being designed. The illustrated visual elements include a trigger node 268, a branching node 270, and a begin dialog node 272. Nodes 268 and 270 are connected by link 274, and nodes 270 and 272 are connected by branching link 276. FIG. 5 also shows that trigger node 268 represents a trigger that is activated by particular end user input that reflects an intent of the user (what the user wishes to do). An intent can be used as a triggering event to activate a trigger. An intent can be mapped to an utterance (spoken, typed or otherwise) input by a bot end user, in the natural language understanding system 118. For instance, the user may speak or type a phrase or utterance such as “display my to-do list”. The end user input is provided to natural language understanding system 118 (shown in FIG. 1) which will return a recognized intent. That intent is illustratively mapped to one or more different triggers, which may include trigger 268. When the bot is deployed, trigger 268 will cause a dialog in the corresponding node to run.

Branching node 270 represents a branch if/else action. This allows the author 106 to introduce a branch into the bot logic flow, such that the logic flow will follow one branch if a certain condition is met, and a different branch if the condition is not met.

Begin a dialog node 272 corresponds to an action which begins a dialog in the bot being designed. In the illustrated example, when the bot is deployed and processing reaches node 272, a dialog corresponding to an “add to-do” action will commence. This will illustratively navigate the bot end user through an experience which allows the bot end user to add an item to the user's to-do list.

It can be seen in FIG. 5 that the author 106 has selected the branching node 270. The properties for the branching node 270 are thus displayed in the selection-driven property pane 124. Thus, pane 124 includes a name 244 of the branching node, in this case “branch: if/else”. It also illustratively includes a description of the action performed at the node 246. In this case, the description reads: “action which conditionally decides which action to execute next”. It also includes additional properties 248. The additional properties 248 include a description of the condition as indicated by block 280. In one example, author 106 can type into a text box to define the condition. In another example, author 106 can select a condition from a drop-down menu, etc.

Properties 248 also define the actions that are to be taken if the condition 280 is true or false. Thus, pane 124 includes a “true branch” actuator 282 and a “false branch” actuator 284. If the condition is true, author 106 can select actuator 282 to define the actions that are to be performed. Author 106 can select actuator 284 to define the actions that are performed if the condition 280 is false. In one example, author 106 can select actuators 282 and 284 to add multiple actions into the true branch, and/or the false branch.

When the author 106 defines actions in the true branch or the false branch, visual elements corresponding to those actions are added into the corresponding branch in the link 276 on visual authoring canvas 122.

FIG. 5 also illustrates other manners of adding conditions and nodes to the bot. Each of the links 274, 276 and 277 has a corresponding “add” actuator that can be actuated to add actions (or nodes). Link 274 includes add actuator 286. When it is actuated by author 106, author 106 is provided with functionality (such as a drop-down menu or other functionality) to identify another action (or node) to be added to the design flow. Link 276 has add actuator 288 in the true branch, add actuator 290 in the false branch, and add actuator 292 after the branches. Therefore, if actuator 288 is selected by author 106, author 106 can add nodes in the true branch. This is another way to add functionality to the true branch, in addition or alternatively to selecting actuator 282 in the property pane 124. Similarly, when the author 106 selects add actuator 290, the author can add actions into the design flow in the false branch. When the author selects actuator 292, the author 106 can add actions into the design flow below the true and false branches.

Also, when the author selects add actuator 294 in link 277, the author can add actions (or nodes) to the design flow following node 272.

FIGS. 6A and 6B (collectively referred to herein as FIG. 6) show a flow diagram illustrating one example of the overall operation of a design experience using visual bot designer computing system 102. It is first assumed that author 106 provides an input invoking, or launching, visual bot designer computing system 102 in order to design, author, or modify a bot. Detecting the input invoking the visual bot designer is indicated by block 300 in the flow diagram of FIG. 6. Visual bot designer computing system 102 then detects author inputs indicating that author 106 wishes to begin performing bot design operations. This is indicated by block 302. For instance, author 106 can provide an input on menu pane 200 actuating design flow actuator 256 (shown in FIG. 5). Author 106 can also provide an input on navigation pane 202 selecting a particular bot to modify, or selecting an actuator to generate a new bot, etc. Detecting inputs on the menu and navigation panes is indicated by block 304 in the flow diagram of FIG. 6. The inputs can indicate that author 106 wishes to start design of a new bot/dialog 306. This can be done by the author selecting an actuator to begin design of a new bot or a new dialog. Alternatively, the inputs may indicate that author 106 wishes to load an existing bot or dialog for editing 308. The detected inputs can indicate a wide variety of other items as well, as indicated by block 310.

In response, visual bot designer computing system 102 accesses the schema 144 to obtain a representation of the interfaces to be generated and illustratively generates and exposes the designer user interfaces 104. This is indicated by block 312. As discussed above, the designer user interfaces 104 can include the menu and navigation panes 200, 202, the visual authoring canvas 122, selection-driven property pane 124, JSON representation pane 126, and a wide variety of other interface elements as well, as indicated by block 314.

Designer user interface 104 then detects an author input on a first part of the interface. This is indicated by block 316 in the flow diagram of FIG. 6. For instance, the author can provide an input on visual authoring canvas 122, on selection-driven property pane 124, on JSON file pane 126, or on another part of the user interface. The author can provide an input to generate or modify a trigger and/or intent, as indicated by block 318, to modify another dialog node, as indicated by block 320. The author 106 can provide an input configuring the bot to use a particular, external or remote, language processing system (such as language generation system 116 and/or natural language understanding system 118). This is the language processing system the bot will use during runtime. This authoring input is indicated by block 321. By way of example, author 106 may be configuring an action, represented by a node on canvas 122, that uses natural language understanding. Author 106 can thus select a system that is to be used during execution of that action. Author 106 can also provide another design input, as indicated by block 322.

When the user provides an input on one part of the designer user interface 104, that part of the user interface (or interface control logic 127) calls API 112 indicating the input. API 112 then uses schema 144 to determine how the updates should be reflected on the other designer user interfaces 104 and generates the update on the other portions of the designer user interface 104. Generating an update on the other parts of the interface based on the detected design input of the first part of the interface is indicated by block 324 in the flow diagram of FIG. 6 and is described in greater detail below with respect to FIG. 6C.

Briefly, by way of example, author 106 may edit the JSON string displayed on JSON file display pane 126. In response, API 112 uses code translator/generator 146 which accesses schema 144 to identify how that edited JSON string should be represented in the other interfaces 104. It uses the information in the schema 144 to generate updates to the visual authoring canvas 122 and property pane 124. This is indicated by block 326 in the flow diagram of FIG. 6. When author 106 makes a change to visual authoring canvas 122, then API 112 uses code translator/generator 146 to access schema 144 and update the property pane 124 and JSON file display pane 126 to reflect that update. This is indicated by block 328. When author 106 makes changes to the properties displayed in property pane 124, then API 112 uses code translator/generator 146 to access schema 144 and generate updates to the visual authoring canvas 122 and the JSON file display pane 126. This is indicated by block 330 in the flow diagram of FIG. 6. API 112 can detect changes to one part of design user interfaces 104 and update the other parts in other ways as well, and this is indicated by block 332 in the flow diagram of FIG. 6.

Designer user interfaces 104 and/or API 112 then perform any other processing steps based on the detected user design input. This is indicated by block 334 in the flow diagram of FIG. 6. For instance, when the author 106 inputs language that is expected by the bot, from an end user of the bot, or inputs language that is to be output by the bot, during use, then flat view generator 147 illustratively generates a “flat view” of the language content. In one example, this is a file that stores bot responses and expected user inputs, in context relative to one another so that they can be viewed. This can be used for search and replace of various terms, for localization (e.g., translation into different languages, or localization with respect to a single language), or for other reasons. Generating the flattened view of the language content is indicated by block 336 in the flow diagram of FIG. 6.

The author 106 may also select a particular language generation system 116 or natural language understanding system 118 that is to be used by the bot. In response, a reference to the particular recognizer or language generator is added to the bot logic so it can be accessed during runtime, once the bot is deployed. This is indicated by block 338 in the flow diagram of FIG. 6.

Also, where author 106 provides an expected input or an output to be generated by the bot, dynamic responses or inputs can be generated. For instance, the author may provide a relatively small number of examples of responses that are expected from a bot end user. In response, language/model building control logic 145 in API 112 can provide that information to language generation system 116 which will generate additional expected responses, or a model that can be used to identify expected responses, during use. Similarly, when the author provides an example bot response to the end user, then logic 145 in API 112 illustratively provides that information to language generation system 116 which generates additional examples of dialog that the bot can use. This may be useful so that the bot does not simply repeat the same phrase every time a particular point is reached in the logic flow of the bot. Instead, the bot may choose from a plurality of different outputs, so that the output doesn't become repetitive. This can be done, for instance, by introducing a looping action that loops over a set of different alternative linguistic expressions. Similarly, conditions can be inserted so that, in response to a particular condition (for example, a particular day such as a holiday) different responses can be used. Language generation system 116 can further utilize natural language understanding system 118 in generating the additional examples or models for the expected inputs or outputs that are generated by the bot. Processing dynamic responses by using different expressions to avoid redundancy or based on other conditions or criteria, is indicated by block 340 in the flow diagram of FIG. 6. The variations in responses can be stored and referred to in a language generation template which is described in greater detail below.

Language/model building control logic 148 can interact with language generation system 116 and/or natural language understanding system 118 in other ways as well. Where the author 106 has actuated one of the undo/redo actuators 252, then undo/redo logic 150 performs undo/redo processing to allow author 106 to switch between operational versions of the bot application. This is indicated by block 342 in the flow diagram of FIG. 6, and it is described in greater detail below with respect to FIGS. 15A and 15B.

As long as user 106 continues to provide design inputs to designer user interfaces 104, processing reverts to block 316. This is indicated by block 346 in the flow diagram of FIG. 6.

When author 106 wishes to end the visual bot design operations, the author will provide an input to that effect, such as clicking a close actuator. This is indicated by block 348. In that case, bot storage logic 149 illustratively stores the bot in data store 110 for further designing and/or deployment. This is indicated by block 350. When a deployment input is detected, as indicated by block 352, then bot deployment logic 151 identifies a channel where the bot is to be deployed. This is indicated by block 354. This can be provided, for instance, by author 106, or in other ways. Logic 151 then pushes the bot to the identified channel and functionally attaches it to that channel, as desired. This is indicated by block 356. For instance, the bot may be deployed in a social media channel 358, a web meeting channel 360, or any of a wide variety of other channels 362.

It will also be noted that, during the bot designer experience, bot validation logic 148 can perform validation operations, as author 106 stores changes, revisions, or other design inputs. Thus, bot validation logic 148 can identify invalid expressions, missing logic elements, or other validation issues, and surface them for author 106 during the design experience, when the author attempts to store or run the bot, or in other ways.

FIG. 6C shows one example of how changes to one of the interfaces 104 can be propagated to the other interfaces 104. Propagation is described as detecting an author change to the visual authoring canvas 122 and propagating the change to the other interfaces. However, the same type of propagation occurs regardless of where the author change is detected.

It is first assumed that author 106 makes a change to visual authoring canvas 122 by adding a node, of a given node type. This is indicated by block 301 and the node type is indicated by block 303 in FIG. 6C. Interface control logic 127 makes an API call to communicate this to code generator/translator 146. This is indicated by block 305.

Code generator/translator 146 then accesses bot schema 144 which can be an SDK, to obtain the schema definition for node that has been added by author 106. This is indicated by block 307. The schema definition can include properties 309 of the node and other items 311. A partial example of a schema definition is shown at block 313. The schema definition 313 is provided to code translator/generator 146, which serializes the definition and places the serialized definition in the dialog being edited, in data store 110. This is indicated by block 315 Code translator/generator 146 can output an acknowledgment indicating that the serialization has been successful as well. This is indicated by block 317.

Code translator/generator 146 then provides an update of the bot application state to the designer user interfaces 104, or to a client system that may be implementing the designer user interfaces 104. The interface control logic 127 then propagates the changes to panes 124 and 126, based on the updated bot application state received from the code translator/generator 146 in API 112.

FIG. 7A shows one example of how visual elements (e.g., nodes) can be added to visual authoring canvas 122 (and thus how triggers and actions can be added to the bot being designed). It can be seen in FIG. 7A that a trigger node 370 has been added to canvas 122. The trigger node has been configured to be activated when a conversation update is detected that is made to the conversation being executed by the bot. A “send a response” node 372 has also been added. A link 374 between nodes 370 and 372 includes an “add” actuator 376 that can be actuated by author 106 in order to add nodes or other visual elements to canvas 122 between nodes 372 and 374. It can also be seen in FIG. 7A that author 106 has selected add actuator 376. Interface control logic 127 detects this actuation and provides an indication of the actuation to bot schema (or logic) 144 in API 112. Logic 144 identifies what actions can be taken when actuator 376 is selected. It provides identified actions to interface control logic 127 which generates a drop-down menu 378 that has a plurality of actuators that can be selected to add items between nodes 370 and 372.

In the example shown in FIG. 7A, the actuators, when selected, allow author 106 to insert actions between nodes 370 and 372. Actuator 380 allows author 106 to insert a send response action 180 (shown in FIG. 3). Actuator 382 allows author 106 to insert functionality (an action) for asking a question. Actuator 384 allows author 106 to insert a branching action 182 or looping action 184. Actuator 386 allows author 106 to insert a dialog management action. Actuator 388 enables property management actions. Actuator 390 allows author 106 to insert functionality (or an action) to make an HTTP request 194 or perform other actions accessing external resources, and actuator 392 allows author 106 to insert emit a trace event functionality (or action) 190 or other debugging options.

FIG. 7A shows that author 106 has selected the “create a condition” actuator 384. In response, interface control logic 127 detects the actuation and provides an indication of the actuation to logic 144 in API 112. Logic 144 provides information to interface control logic 127 indicating the types of actions that can be taken, and interface control logic 127 displays panel 394 with a plurality of actions, including inserting branching or looping logic. Actuator 396 allows author 106 to insert a branch: if/else action. Actuator 398 allows author 106 to insert a branch switch (multiple options) action. Actuator 400 allows author 106 to insert a loop: for each item action, and actuator 402 allows author 106 to insert a loop: for each page (multiple items) action. If the author 106 selects one of actuators 396-402, then the corresponding display element is displayed between nodes 370 and 372 on canvas 122. At the same time, the property pane 124 and JSON file display pane 126 are updated as well, as discussed above. In one example, author 106 can collapse or hide different panes to see only the ones he or she wishes to see.

FIG. 7B is similar to FIG. 7A, except that the dialog management actuator 386 is actuated to show a plurality of different actuators 401 that author 106 can use to manipulate the flow of conversation. Those actuators can include starting a new dialog, ending the current dialog, canceling all dialogs, ending a dialog turn, repeating the current dialog, and replacing the current dialog. Some of these are described in more detail below.

FIGS. 8A-8G show user interface displays that can be displayed on property pane 124, and that allow author 106 to configure different types of triggers in the logic or dialog flow for the bot being designed.

In one example, when a trigger is inserted in the bot, it can handle various items. Author 106 can configure it by defining the particular item that the trigger will handle. FIG. 8A thus shows a user interface display 404 that can be displayed in property pane 124 when a trigger is to be added to the bot. Display 404 indicates that it is a “create a trigger” display and asks author 106 what this trigger is to handle. It then provides an actuator 406 that can be actuated by author 106 to select a particular item that the trigger is to handle. User interface display 404 also includes a cancel actuator 408 and a next actuator 410 that can be used to cancel the trigger creation or to navigate to a next step, respectively.

FIG. 8B is similar to FIG. 8A, except that it shows that the user has now selected actuator 406 such that a drop-down menu 412 is displayed. Drop-down menu 412 indicates a number of items that can be selected by author 106 to configure the trigger being created. The drop-down menu 412 indicates the different items, defined by schema 144, that a trigger can respond to. Items may include an intent (known or unknown), dialog events, activity types, and custom events, among other items.

An intent can be identified when a bot end user provides a natural language input. The natural language input may be provided to a natural language understanding system 118 which may map that natural language input to an intent, indicating what the user wishes to accomplish with the bot. An unknown intent is encountered when the natural language understanding system does not have a particular intent matched to the natural language input provided by the user. A dialog event may be raised by a dialog in the bot, or in a different bot. An event is can be any processing step that generates an output that can be deleted. An activity type indicates an action that is performed by the user or the bot, and a custom event is an event that may be customized by author 106. These are just examples of the types of items that a trigger can handle.

FIG. 10 is one example of a list of items that triggers can handle (or triggering events that can activate a trigger), as defined by schema 144. FIG. 10 shows that each item has a name, a description, a base dialog event that serves as the triggering event, and any conditions that are pre-built into logic 144. A pre-built condition is added when creating certain dialog components. One example is upon receiving a conversation update event. This event can be used, for instance, to welcome users once they join the conversation. However, the trigger needs to be configured in a certain way to achieve this. Since this is a common use case of the “HandleConversationUpdate” trigger, when the trigger is created, the necessary condition to evaluate when a user joins the conversation is also automatically created. An example condition can be:

Condition: toLower(turn.Activity.membersAdded[0].name) !=‘bot’

FIG. 10 also shows an example list of particular dialog events that a dialog event trigger may be configured to respond to, or handle.

FIG. 8C is similar to FIG. 8B, except that it shows that the user has selected the “intent” item from drop-down menu 412. Thus, it is displayed in actuator box 406. Once an intent has been selected, the author 106 is prompted to enter the name of the intent that is to be handled. This can be provided in text box 414.

FIG. 8D is similar to FIG. 8C, except that it can be seen that the user has instead selected the “dialog events” item from drop-down menu 412 as the item that the trigger is to handle. In response, the author 106 is prompted to select a dialog event. Thus, author 106 can select actuator 416 to be provided with another drop-down menu of the various dialog events that can be selected. They are determined by schema 144, and one example of a set of dialog events is shown in FIG. 10.

FIG. 8E is similar to FIG. 8D except that, instead of selecting a dialog event, author 106 has selected an activity type. In response, author 106 is provided with actuator 418 for specifying the particular activity that the trigger is to handle. Some examples of activity types are shown in FIG. 10.

FIG. 8F is similar to FIG. 8E, except that the author 106 has selected an unknown intent as the item that the trigger is to handle. FIG. 8G is similar to FIG. 8F, except that the user has selected a custom event as the item that the trigger is to handle.

FIGS. 8H-8J show user interfaces 104 that can be generated to allow author 106 to add intents to the bot. As mentioned above, an intent is an item that may be identified based on a natural language input provided by a bot end user. The natural language input may then be provided to natural language understanding system 118 which identifies an intent corresponding to (or that is mapped to) that natural language input. The intent may identify an action that the user wishes to perform, using the bot, such as booking a flight, making a reservation, sending an email, adding an item to the user's to-do list, or any other of a wide variety of actions that the bot can be used to accomplish. These are examples only and the intents can indicate other things as well. In one example, author 106 can author intents while also authoring triggers. In another example, triggers and intents can be authored separately and linked later. Other authoring sequences are also contemplated herein.

FIG. 8H shows one example of a user interface 104 that includes menu pane 200, navigation pane 202, visual authoring canvas 122, and property pane 124. It can be seen in navigation pane 202 that the user has selected an add intent actuator 212. In response, an add intent property display 420, shown in selection-driven property pane 124, prompts author 106 to configure the intent by inserting a set of target phrases in text box 422. The target phrases are examples of phrases that a bot end user may speak or type in order to invoke the intent. Interface 420 also includes actuator 424 (that may be a text box) that allows author 106 to define various constraints that may be placed on the intent.

As described above, in one example, author 106 may type a relatively small set of example trigger phrases in text box 422. Interface control logic 127 can then provide those examples to language/model building control logic 145. Logic 145 can provide those items to language generation system 116 and/or natural language understanding system 118 which automatically builds a model or generates additional phrases that are similar to those typed by author 106, which will be used by the bot to map to the intent being configured. For instance, if the bot end user utters one of the automatically generated phrases, those phrases will also trigger the intent being configured.

FIG. 8I is similar to FIG. 8H, except that in navigation pane 202 the author 106 has selected the “unknown intent” actuator 426. In response, the property pane 124 surfaces a user interface that allows author 106 to define constraints in describing the unknown intent. Thus, actuator 428 is surfaced for author 106.

FIG. 8J is similar to FIG. 8I, except that the user has actuated the conversation update activity actuator 430 in navigation pane 202. It will be noted that other activity actuators can be used as well and the conversation update activity actuator is one example. In that case, API 112 surfaces a constraints actuator 432 that can be used by author 106 to define or configure the conversation update activity that will correspond to the item being configured.

FIG. 8K is a flow diagram illustrating one example of how system 102 can be used to generate triggers that trigger a bot and/or run a dialog. Some of the examples discussed with respect to FIG. 8K were discussed in more detail above with respect to FIGS. 8A-8J.

Interface control logic 127 first detects an authoring input from author 106 indicative of author 106 identifying a trigger to be configured in the bot being designed. This is indicated by block 433 in FIG. 8K. The input can be received on any of the interfaces 104.

Interface control logic 127 then accesses the bot schema 144 and identifies which visual node is to be displayed on the visual authoring canvas 122 and displays that node. This is indicated by block 435 in FIG. 8K.

Interface control logic 127 then again accesses bot schema 144 to obtain trigger configuration data indicative of the configurable properties corresponding to the trigger node and the trigger being added to the bot being designed. Obtaining the trigger configuration data is indicated by block 437 in the flow diagram of FIG. 8K.

Logic 127 then controls property pane 124 to display a trigger configuration UI. The trigger configuration UI illustratively has one or more property input actuators that can be actuated by author 106 to input or configure a property of the trigger being added to the bot. This is indicated by block 439. The property input actuators can include a textual input mechanism 441 that can be used to input text. The text may be input by author 106 as a phrase that can activate the trigger. For instance, when the phrase is uttered by a bot end user, that phrase may be recognized as a triggering phrase that activates the trigger. The property input actuator may be an actuator that can be used to identify a dialog event that activates the trigger. This is indicated by block 443. The actuator may be one used to identify a dialog activity that activates the trigger. This is indicated by block 445. It can be a wide variety of other actuators that are actuated to identify a variety of other trigger activations as well. This is indicated by block 447.

Interface control logic 127 then detects author actuation of the property input actuator, identifying a property that activates the trigger. This is indicated by block 449 in FIG. 8K. Other property processing can be performed based on the identified property. For instance, when the property input is a textual input, then that textual input can be provided to language generation system 116 and/or natural language understanding system 118 to obtain additional, similar texts (variations) that may be similar in meaning to the text input by author 106 and that can also be used as trigger activating phrases. This is indicated by block 451. The additional texts can be received, or a model can be received that recognizes more textual inputs than the one that is input by author 106. This is indicated by block 453. As an example, the variations can be used and managed in language generation templates, as described in more detail above. Other property processing can be performed as well, and this is indicated by block 455.

Code translator/generator 146 then accesses bot schema 144 to obtain a code representation for mapping the trigger to the property that activates the trigger and configures the trigger so that it is activated by the configured property. This is indicated by block 457.

FIGS. 9A-9U show examples of property configuration interfaces that can be used by author 106 to configure actions corresponding to bot action nodes. Action nodes can be placed in the bot by author 106 by dragging and dropping them onto visual authoring canvas 122, by configuring them using property pane 124, or by defining them on JSON file pane 126. As discussed above, when any of these inputs is received, the action is also displayed on the other portions of the designer user interface 104. The user interface displays in FIGS. 9A-9U each show an example of an interface that can be displayed in property pane 124 to allow author 106 to configure a particular action 172 (shown in FIG. 3).

FIG. 9A shows a user interface display 434 that can be used to configure properties for a “send an activity” action, an output response that is sent to the bot end user. Author 106 can type variations of the message to be sent in text box 436. These message variations can be used by language generation system 116 and/or natural language understanding system 118 to build additional models or examples.

FIG. 9B shows a user interface display 438 that allows author 106 to define properties for an action that prompts the bot end user for a textual input. Author 106 can thus type an initial prompt in text box 440, define properties in text box 442, define an output format using actuator 444, add validation expressions that can be used to validate the input with actuator 446, and define how the bot should respond when an unrecognized value is received in response to the prompt. This latter item can be defined using text box 448. The author 106 can define a message that will be generated by the bot when an invalid response to the prompt is received. This can be done using text box 450. The author 106 can define a maximum turn count 452 to receive a valid response to the prompt (e.g., the maximum number of times the bot will prompt the user for an input). Author 106 can use text boxes 454 and 456 to define values that may be received in response to the prompt. Author 106 can use text box 458 to indicate how the bot is to respond by default. Actuator 460 allows author 106 to configure when the prompt will be used, and actuator 462 allows author 106 to define different types of end user interruptions that will be recognized, so that processing can be diverted to another dialog, to another portion of the same dialog, etc.

Similar user interfaces can be used to configure actions that prompt the end user for a number, for confirmation of a recognized input, or that allow the user to select from multiple choices. Similar user interfaces can also be generated to allows author 106 to configure an action that prompts the user for an attachment, a particular date, an authorization token or login information, among other things.

FIGS. 9C and 9D show user interface displays that can be generated to allow author 106 to configure branching actions in the bot logic flow. FIG. 9C shows a user interface display 464 that allows author 106 to define a “branch: if/else” action. This type of action conditionally decides which logic flow to follow when the bot is being executed. Text box 466 allows author 106 to input the condition to be evaluated in determining which logic branch to follow. Actuator 468 allows author 106 to define an action that is to be executed if the condition defined by actuator 466 is true, and actuator 470 allows author 106 to define which action is to be executed if the condition defined by actuator 466 is false.

FIG. 9D shows a user interface display 472 that can be generated to allow author 106 to define a “branch: switch” action. This type of action controls the bot to switch to a different logic flow, based on a condition to be evaluated. Author 106 can add branching logic for any number of conditions, in contrast to binary branching logic (if/else). Again, text box 474 allows author 106 to define the condition to be evaluated. The branch actuator 476 allows author 106 to define which branch to take if a particular bot execution case satisfies the condition identified by actuator 474. Actuator 478 allows the author 106 to define new bot execution cases that are to be evaluated, and that correspond to different branches in the dialog logic flow. Actuator 480 allows author 106 to define a default action to be taken if none of the cases defined by the other actuators satisfy the condition defined by actuator 474. One example might be to ask the bot end user what his/her favorite color is and then branching the conversation based on that answer. An example condition and set of cases might be:

Condition: user.favoriteColor

cases:

Red

Blue

Green

FIGS. 9E and 9F are user interfaces that allow author 106 to define looping actions that are to be taken. FIG. 9E shows a user interface display 482 that allows author 106 to configure actions that are to be taken, looping over each item in a collection of items. The bot may execute such a loop to provide dynamic responses, as described above. Text box 484 allows author 106 to define the list which is to be traversed (e.g. a list of alternative responses), and text boxes 486 and 488 allow author 106 to define property values and index values identifying the dialog that is to be used. Actuator 490 can be selected by author 106 to select any of a plurality of different actions that are to be taken, for each item in the collection defined by properties 484, 486, and 488.

FIG. 9F shows a user interface display 492 that allows author 106 to configure an action that is to be executed for each page of items in a collection. So, for example, if the bot is to return a list of to do items, then author 106 can define the number to show, per page, and the action to take for each page of items (such as sort by urgency, alphabetically, etc.). Again, text boxes 484 and 486 allow author 106 to define the list to be processed, and actuator 494 allows author 106 to define the number of items in the list, per page, for which an action is to be executed. Actuator 490, as described above with respect to FIG. 9E, allows author 106 to define the particular action to be executed, per page of items in the list.

FIGS. 9G-9I show examples of user interfaces that can be generated to allow author 106 to define an action in the bot logic flow to begin a dialog, to end a dialog, and to cancel all running dialogs, respectively. In FIG. 9G, user interface display 496 allows author 106 to use actuator 498 to identify a dialog to start. Actuator 500 can be used to pass an object into the dialog being started, and text box 502 can be used to define properties that are passed into dialog being started.

In FIG. 9H, user interface display 504 allows author 106 to use actuator 506 to identify a property that will be returned when the current dialog ends. As an example, when the dialog ends, it may output the name of the dialog indicating that it has ended. This can be done when configuring the bot with a command that ends the dialog. In FIG. 9I, user interface display 508 allows author 106 to configure the bot with a command to cancel all of the current dialogs by emitting an event which must be caught in order to prevent cancelation from propagating. For instance, if a command is issued to cancel all running dialogs, the command may function by canceling one dialog and continue on to the next dialog, and cancel it, unless the event is absorbed by the first canceled dialog. If the event is not one that will be absorbed, then the cancellation command will propagate through all running dialogs. Author 106 can use text 510 to identify the event. Author 106 can use actuator 512 to identify a value that is to be emitted (returned or output) along with the event being identified using actuator 510.

FIG. 9J shows a user interface 514 that can be used by author 106 to insert an action that ends a turn in the dialog logic flow, without ending the dialog itself. FIG. 9K shows a user interface display 516 that can be used by author 106 to insert an action which repeats the current dialog. For instance, if the bot end user is adding items to a to do list, the source dialog may be repeated so long as the bot end user continues to add items to the list. FIG. 9L shows a user interface display 518 that can be used by author 106 to insert an action in the bot logic flow that replaces the current dialog with a target dialog. For example, if the bot end user begins one dialog, but then switches or further defines his or her intent, a dialog switch can be made. One example of this is making travel plans. The bot may first run a dialog that allows the end user to specify date, and then switch dialogs to allow the user to make hotel reservations. This is just one example. Actuator 520 can be used to identify the target dialog, and actuator 522 can be used to configure information that is passed into the target dialog.

FIG. 9M shows a user interface display 524 that can be used by author 106 to modify an active dialog. Actuator 526 allows author 106 to choose a particular type of change that is to be performed. In the example shown in FIG. 9M, the change is to insert actions into an active dialog. Author 106 can then use actuator 528 to select which particular actions to execute or insert in the active dialog. Those actions can include any of the actions 172 described in FIG. 3, or other actions.

FIG. 9N is a user interface display 530 that can be used by author 106 to insert an action which causes the bot logic flow to make an HTTP request. Actuator 532 allows author 106 to select a method of making the request. For instance, one method is to retrieve information from a given server using the URL. Another only retrieves the header section. Another method can send data to the server. These are just a few examples. Text box 534 allows author 106 to identify a URL where the request is to be made. Text box 536 allows author 106 to define properties or other items in the body of the HTTP request. Text box 538 allows author 106 to define the other properties. Actuator 540 allows author 106 to identify additional headers to include in the HTTP request. Actuator 542 allows author 106 to define a type of response.

FIG. 9O shows an example of a user interface display 544 that allows author 106 to insert an action which emits (or returns or outputs) a custom event. Text box 546 allows author 106 to name the event, and actuator 548 allows author 106 to define a value that can be emitted (returned or output) along with the event.

FIG. 9P shows a user interface display 550 that allows author 106 to insert an action which writes to a log. For instance, in development, logging may be used to debug the bot. Author 106 can thus configure the bot to output arbitrary data to be logged for debugging. The log may be a terminal window in which the visual bot designer application is running User interface 550 allows author 106 to configure the action to create a trace activity and send that as well. Text box 552 allows author 106 to define the text and actuator 554 allows author 106 to indicate that a trace activity is to be sent.

FIG. 9Q shows a user interface display 556 that allows author 106 to insert an action that is used to emit a trace event for debugging purposes. Text box 558 allows author 106 to name the trace event. Text box 560 allows author 106 to define a value type of the trace event and text box 562 allows author 106 to define the value for the trace event.

FIGS. 9R, 9S and 9T show user interfaces 564, 566 and 568, that allow author 106 to insert an action that sets a property to the value, that defines and initializes a property to be either an object or an array, and that deletes a property and any value it holds, respectively. For instance, FIG. 9R shows that the property “user.taskList.todo” is set to “go grocery shopping.” FIG. 9S shows that the property “user.taskLists” is defined and initialized as an object. FIG. 9T shows that the property “dialog.item” is deleted.

FIG. 9U shows a user interface display 570 that allows author 106 to insert an action which allows modification of an array in memory. Actuator 572 allows author 106 to select the type of change to be made (e.g., remove). Text box 574 allows author 106 to identify the array property (e.g., user taskLists [dialog.listType]. Text box 576 allows author 106 to define the result property (e.g., turn.itemDeleted), and text box 578 allows author 106 to define the value of the item that is to be changed (e.g., dialog.item).

FIG. 11 is another example of a set of user interfaces 104 that enable configuration of a loop: for each page action. It can be seen that the node 201 for the looping action is displayed and selected on visual authoring canvas 122, and the configuration interface is displayed on selection-driven property pane 124.

FIGS. 12A and 12B (collectively referred to herein as FIG. 12) illustrate one example of a JSON string which represents a visual representation on visual authoring canvas 122. A JSON string, such as that shown in FIG. 12, can be processed to generate a language generation template, such as that shown in FIG. 13. A language generation template is a function which author 106 can use to define one or more variations of a text response. When template is called, it returns one of the variations of the text identified in the template, but also resolves other references to the template when made for purposes of composition (by author 106, for instance). When multiple responses are defined, one may be selected, for example, at random. Further, the template may be a conditional template in which expressions are defined to control the bot to select one of a number of different collections of variations, and select the particular variation from the selected collection. Templates can also be parametrized by author 106 so that different callers to the template can pass in different values for use in resolving the call to a particular variation. Thus, using templates, author 106 can add sophisticated response behavior to the bot but still consolidate and share common response logic. FIG. 13 shows multiple branching actions and activities, by way of example only.

FIG. 14 is a flow diagram illustrating one example of the operation of visual bot designer computing system 102 in receiving authoring inputs through the visual authoring canvas 122 on designer user interfaces 104. To begin, interface control logic 127 detects an author 106 input to modify an element on the visual authoring canvas 122. This is indicated by block 590 in the flow diagram of FIG. 14. The detected input can be a drag/drop input 592 by which author 106 drags a node onto the visual authoring canvas and drops it there. Alternatively or additionally, the detected input can be selection of an actuator that is used to add a node or action to the visual authoring canvas, as indicated by block 594. For example, the author 106 may select the “add” actuator on the visual authoring canvas. Alternatively or additionally, the detected input can be an indication to delete a node from the visual authoring canvas 122, as indicated by block 596. Or it can be a wide variety of other inputs. This is indicated by block 598. Logic 127 then accesses the bot schema (or logic) 144 to identify possible modifications that can be made, based upon the author 106 input. This is indicated by block 600.

Referring again to FIG. 7, assume that the user has selected the add actuator 376. Logic 127 then accesses schema 144 to identify what actions are available and display them in pane 378. Displaying the actuators to make the possible modifications is indicated by block 602 in the flow diagram of FIG. 14.

Interface control logic 127 then detects author 106 selection of a displayed actuator (such as one of the actuators in pane 278 or 394 in FIG. 7). This is indicated by block 604 in the flow diagram of FIG. 14. The actuation can be to insert or delete a trigger node 606, to insert or delete an action node 608. In another example, author 106 selects a node that is already displayed on the visual authoring canvas 122. This is indicated by block 609. The actuation can be any of a wide variety of other items 610.

Interface control logic 104 then interacts with visual authoring canvas 122 to modify the visual authoring canvas 122 based upon the detected actuation. This is indicated by block 612. Again, this can be to add or delete a node from the visual authoring canvas 122, as indicated by block 614. It can be to add or delete a link, as indicated by block 616, or it can be to make a wide variety of other modifications to the visual authoring canvas 122, as indicated by block 618. Logic 127 then calls API 112 to obtain information to update the property pane 124. This is indicated by block 613 in the flow diagram of FIG. 14. For instance, code translator/generator 146 can receive an indication of an identity of the visual elements that were selected or changed on visual authoring canvas 122, and access bot schema 144 to obtain the properties for the visual elements that are selected or changed, and display editable properties (or property actuators) for the items selected on the visual display canvas 122. Accessing the bot schema 144 based on the identity of the visual element is indicated by block 615. Displaying editable property actuators is indicated by block 617. The property pane 124 can be updated in other ways as well, based upon the modification to the visual authoring canvas 122. This is indicated by block 619. Logic 127 also calls API 112 to update the JSON file display pane 126. Again, it can call code translator/generator 146 which accesses bot schema 144 to obtain serialization information to generate a serialized representation of the visual elements that were changed on visual authoring canvas 122. Where a visual element was added, it can insert that serialization in the JSON file, on the JSON file display pane 126. Where a visual element was deleted, it can delete that representation from the JSON file display pane 126. Calling the API access bot schema 144 to update the JSON file pane 126 is indicated by block 620. Inserting or deleting a JSON string based on the update is indicated by block 622, and updating the JSON file pane in other ways is indicated by block 624. The updates can be propagated across interfaces 104 automatically. By automatically it is meant that the operations are performed without further human involvement except, perhaps to initiate or approve them.

FIGS. 15A and 15B (collectively referred to herein as FIG. 15) show a flow diagram illustrating one example of the operation of system 102 (and specifically undo/redo logic 150) in performing undo/redo operations based on detected author 106 actuation of the undo/redo actuator 252 on designer user interfaces 104. It is first assumed that author 106 is authoring a bot, and the bot application is in a particular state N. This is indicated by block 630 in the flow diagram of FIG. 15. Undo/redo logic 150 then places a representation of the bot application (in state N) on an undo stack 140 in memory 110. This is indicated by block 631 in the flow diagram of FIG. 15. Author 106 then makes a modification to the application to place the bot application in a new state N+1. This is indicated by block 632. The change that places the bot in a new state N+1 can be a modification (such as adding or deleting nodes on the visual authoring canvas 122). This is indicated by block 634. Alternatively or additionally, the change may comprise editing an expression and completing the expression so that the bot application is functional. This is indicated by block 636. It can be any of a wide variety of other changes that place the bot application in state N+1. This is indicated by block 638.

Before the bot application reaches another functional state, interface control logic 127 detects a user actuation of the undo actuator 252 on interfaces 104 and provides an indication to undo/redo logic 150. This is indicated by block 642 in the flow diagram of FIG. 15. Undo/redo logic 150 then places a representation of the bot application (in state N+1) on a redo stack 140 in memory 110. This is indicated by block 644. Undo/redo logic 150 then retrieves the representation of the bot application (in state N) from the undo stack. This is indicated by block 646. It provides that representation to interface control logic 127 so that state N of the bot application is now displayed on interfaces 104. Displaying state N of the bot application on the designer user interface 104 is indicated by block 648 in the flow diagram of FIG. 15. This can include generating the display on the visual authoring canvas 122, as indicated by block 650. It can include generating the serialized representation for the JSON display pane 126. This is indicated by block 652 in the flow diagram of FIG. 15. It can include automatically selecting a node and displaying its properties on the property pane 124, or generating a representation on the designer user interfaces 104 in other ways, and this is indicated by block 654.

It is then assumed that author 106 actuates the redo actuator 252, and this is detected by interface control logic 127 and provided to undo/redo logic 150. The author 106 need not do this, but FIG. 15 is provided to illustrate operation that occurs if author 106 does actuate the redo actuator 252. So, for purposes of the present description, it is assumed that author 106 does actuate the redo actuator 252. Detecting actuation of the redo actuator is indicated by block 656 in the flow diagram of FIG. 15. Because state N of the bot application is currently displayed on interfaces 104, undo/redo logic 150 places the bot application (in state N) back on the undo stack 140 in memory 110. This is indicated by block 658 in the flow diagram of FIG. 15. Undo/redo logic 150 then retrieves the representation of the bot application (in state N+1) from the redo stack. This is indicated by block 660. It provides that representation of the indication (the bot application in state N+1) back to interface control logic 127 on designer user interfaces 104, where it (the bot application in state N+1) is displayed on the designer user interfaces 104. This is indicated by block 662. Logic 127 thus generates the display on the visual authoring canvas 122. This is indicated by block 664. It generates the serialized output for the JSON display pane 126. This is indicated by block 666. It can update the property pane 124 and other items as well, and this is indicated by block 668.

It will be noted that the above discussion has described a variety of different systems, components and/or logic. It will be appreciated that such systems, components and/or logic can be comprised of hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components and/or logic. In addition, the systems, components and/or logic can be comprised of software that is loaded into a memory and is subsequently executed by a processor or server, or other computing component, as described below. The systems, components and/or logic can also be comprised of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are only some examples of different structures that can be used to form the systems, components and/or logic described above. Other structures can be used as well.

The present discussion has mentioned processors and servers. In one example, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

Also, a number of user interface displays have been discussed. They can take a wide variety of different forms and can have a wide variety of different user actuatable input mechanisms disposed thereon. For instance, the user actuatable input mechanisms can be text boxes, check boxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in a wide variety of different ways. For instance, they can be actuated using a point and click device (such as a track ball or mouse). They can be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, etc. They can also be actuated using a virtual keyboard or other virtual actuators. In addition, where the screen on which they are displayed is a touch sensitive screen, they can be actuated using touch gestures. Also, where the device that displays them has speech recognition components, they can be actuated using speech commands.

A number of data stores have also been discussed. It will be noted they can each be broken into multiple data stores. All can be local to the systems accessing them, all can be remote, or some can be local while others are remote. All of these configurations are contemplated herein.

Also, the figures show a number of blocks with functionality ascribed to each block. It will be noted that fewer blocks can be used so the functionality is performed by fewer components. Also, more blocks can be used with the functionality distributed among more components.

FIG. 16 is a block diagram of architecture 100, shown in FIG. 1, except that its elements are disposed in a cloud computing architecture 500. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various examples, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architecture 100 as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc.

In the example shown in FIG. 16, some items are similar to those shown in FIG. 1 and they are similarly numbered. FIG. 16 specifically shows that visual bot designer computing system 102 can be located in cloud 502 (which can be public, private, or a combination where portions are public while others are private). Therefore, author 106 uses a user device 704 to access those systems through cloud 702.

FIG. 16 also depicts another example of a cloud architecture. FIG. 16 shows that it is also contemplated that some elements of computing system 102 can be disposed in cloud 702 while others are not. By way of example, data store 110 can be disposed outside of cloud 702, and accessed through cloud 702. In another example, language generation system 116 and natural language understanding system 118 (or other items) can be outside of cloud 702. Regardless of where they are located, they can be accessed directly by device 704, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.

It will also be noted that architecture 100, or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc.

FIG. 17 is one example of a computing environment in which architecture 100, or parts of it, (for example) can be deployed. With reference to FIG. 17, an example system for implementing some embodiments includes a general-purpose computing device in the form of a computer 810. Components of computer 810 may include, but are not limited to, a processing unit 820 (which can comprise processors or servers from previous FIGS.), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to FIG. 1 can be deployed in corresponding portions of FIG. 17.

Computer 810 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media is different from, and does not include, a modulated data signal or carrier wave. It includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 810. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory 830 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 831 and random access memory (RAM) 832. A basic input/output system 833 (BIOS), containing the basic routines that help to transfer information between elements within computer 810, such as during start-up, is typically stored in ROM 831. RAM 832 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 820. By way of example, and not limitation, FIG. 17 illustrates operating system 834, application programs 835, other program modules 836, and program data 837.

The computer 810 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only, FIG. 17 illustrates a hard disk drive 841 that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive 855 that reads from or writes to a removable, nonvolatile optical disk 856 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 841 is typically connected to the system bus 821 through a non-removable memory interface such as interface 840, and optical disk drive 855 are typically connected to the system bus 821 by a removable memory interface, such as interface 850.

Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

The drives and their associated computer storage media discussed above and illustrated in FIG. 17, provide storage of computer readable instructions, data structures, program modules and other data for the computer 810. In FIG. 17, for example, hard disk drive 841 is illustrated as storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components can either be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that, at a minimum, they are different copies.

A user may enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, computers may also include other peripheral output devices such as speakers 897 and printer 896, which may be connected through an output peripheral interface 895.

The computer 810 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 810. The logical connections depicted in FIG. 7 include a local area network (LAN) 871 and a wide area network (WAN) 873, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 821 via the user input interface 860, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 810, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 17 illustrates remote application programs 885 as residing on remote computer 880. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of this is contemplated herein.

Example 1 is a computer implemented method of authoring a chatbot, comprising:

displaying a first display pane;

detecting authoring inputs relative to a set of visual nodes, connected by links as a flowchart, on the first display pane, the visual nodes in the flowchart being indicative of actions that the chatbot is configured to perform;

detecting a node selection authoring input, selecting a visual node of the set of visual nodes on the first display pane, the selected visual node corresponding to an action the chatbot is configured to perform; and

displaying a second display pane, along with the first display pane, with one or more property authoring actuators that are actuatable to configure properties of the action corresponding to the selected visual node.

Example 2 is the computer implemented method of any or all previous examples wherein displaying the second display pane with the one or more property authoring actuators comprises:

accessing a bot schema based on an identity of the selected visual node to identify the one or more property authoring actuators to display on the second display pane.

Example 3 is the computer implemented method of any or all previous examples and further comprising:

detecting actuation of at least one of the property authoring actuators on the second display pane, the detected actuation being indicative of a property configuration input configuring the action corresponding to the selected visual node, to obtain a configured action.

Example 4 is the computer implemented method of any or all previous examples and further comprising:

automatically generating a serialized representation of the configured action.

Example 5 is the computer implemented method of any or all previous examples wherein automatically generating the serialized representation comprises:

accessing the chatbot schema based on the configured action to obtain serialization information corresponding to the configured action; and

generating the serialized representation of the configured action based on the serialization information.

Example 6 is the computer implemented method of any or all previous examples and further comprising:

displaying the serialized representation on a third display pane, along with the first and second display panes.

Example 7 is the computer implemented method of any or all previous examples wherein detecting authoring inputs relative to the set of visual nodes comprises:

detecting actuation of an add actuator in a link of the flowchart;

accessing the chatbot schema to identify possible actions to add; and

displaying an action actuator corresponding to each of the identified possible actions, each of the action actuators being actuatable to select a corresponding one of the possible actions for addition to the flowchart.

Example 8 is the computer implemented method of any or all previous examples wherein detecting authoring inputs relative to the set of visual nodes further comprises:

detecting actuation of one of the action actuators to select a corresponding action; and

adding a visual node to the flowchart, the added visual node corresponding to the selected action.

Example 9 is the computer implemented method of any or all previous examples wherein detecting authoring inputs relative to the set of visual nodes further comprises:

automatically displaying one or more property authoring actuators that are actuatable to configure properties of the selected action on the second display pane corresponding to the added visual node, along with the first display pane; and

automatically generating a serialized representation of the selected action.

Example 10 is the computer implemented method of any or all previous examples wherein the flowchart represents a dialog that the chatbot is configured to execute, the dialog having linguistic elements comprising chatbot outputs and linguistic elements comprising expected user inputs, and further comprising:

generating an editable and searchable view of the chatbot outputs and expected user inputs in context relative to one another in the dialog.

Example 11 is the computer implemented method of any or all previous examples wherein the selected visual node corresponds to a branching action and wherein displaying the second display pane, along with the first display pane, with the one or more property authoring actuators that are actuatable to configure properties of the branching action comprises:

displaying, on the second display pane, one or more property actuators that are actuatable to set branch following criteria that configure the chatbot to follow a given branch of operation when the branch following criteria are met.

Example 12 is the computer implemented method of any or all previous examples wherein the selected visual node corresponds to a looping action and wherein displaying the second display pane, along with the first display pane, with the one or more property authoring actuators that are actuatable to configure properties of the looping action comprises:

displaying, on the second display pane, one or more property actuators that are actuatable to identify a collection of items and to configure the chatbot to use a different item, in the collection of items, in performing the looping action.

Example 13 is the computer implemented method of any or all previous examples wherein the collection of items comprises a list of alternate chatbot responses and wherein the looping action configures the chatbot, each time the chatbot reaches the looping action in the flowchart, to use a different one of the chatbot responses when generating a chatbot output.

Example 14 is the computer implemented method of any or all previous examples wherein the selected visual node corresponds to a user prompt action that prompts a chatbot end user for an input and wherein displaying the second display pane, along with the first display pane, with the one or more property authoring actuators that are actuatable to configure properties of the branching action comprises:

displaying, on the second display pane, one or more property actuators that are actuatable to identify the user prompt.

Example 15 is the computer implemented method of any or all previous examples and further comprising:

detecting an author input modifying the serialized representation on the third display pane to obtain a modified serialized representation;

accessing the chatbot schema based on the modified serialized representation to identify a new visual node and a location in the flowchart where the visual node is to be added;

and

automatically adding the identified new visual node to the identified location in the flowchart on the first display pane.

Example 16 is a computer system, comprising:

one or more processors; and

memory storing instructions which, when executed by the one or more processors, cause the one or more processors to perform steps of:

displaying a first display pane;

detecting authoring inputs relative to a set of visual nodes, connected by links, as a flowchart, on the first display pane, the visual nodes in the flowchart corresponding to actions that a chatbot is configured to perform;

detecting actuation of an add actuator in a link of the flowchart;

accessing a chatbot schema to identify possible actions to add;

displaying an action actuator corresponding to each of the identified possible actions, each of the action actuators being actuatable to select a corresponding one of the possible actions for addition to the flowchart;

detecting actuation of one of the action actuators to identify a selected action;

and

adding a visual node to the flowchart, in the link, the added visual node corresponding to the selected action.

Example 17 is the computer system of any or all previous examples wherein detecting authoring inputs relative to a set of visual nodes further comprises:

automatically displaying one or more property authoring actuators that are actuatable to configure properties of the selected action on a second display pane corresponding to the added visual node, along with the first display pane; and

automatically generating a serialized representation of the selected action.

Example 18 is the computer system of any or all previous examples wherein the instructions, when executed by the one or more processors, cause the one or more processors to perform steps further comprising:

displaying the serialized representation of the selected action on a third display pane, along with the first and second display panes;

detecting an author input modifying the serialized representation on the third display pane to obtain a modified serialized representation;

accessing the chatbot schema based on the modified serialized representation to identify a visual node and a place in the flowchart where the visual node is to be added; and

automatically adding the identified visual node to the identified place in the flowchart on the first display pane.

Example 19 is a computer system, comprising:

one or more processors; and

memory that stores instructions which, when executed by the one or more processors, cause the one or more processors to perform steps, comprising:

displaying a serialized representation of a dialog, that a chatbot is configured to execute, on a serialization display pane;

displaying a flowchart having nodes and links, indicative of the dialog, on a visual authoring pane, along with the serialization display pane;

detecting an author input modifying the serialized representation on the serialization display pane to obtain a modified serialized representation;

accessing a chatbot schema based on the modified serialized representation to identify a visual node and a place in the flowchart where the visual node is to be added, indicated by the modified serialization; and

automatically adding the identified visual node to the identified place in the flowchart on the visual authoring pane.

Example 20 is the computer system of any or all previous examples wherein detecting authoring inputs arranging a set of visual nodes further comprises:

automatically displaying a set of property authoring actuators, that are actuatable to configure properties of an action indicated by the identified visual node, on a property display pane, along with the visual authoring pane.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A computing system comprising: at least one processor; andmemory storing instructions executable by the at least one processor, wherein the instructions, when executed, cause the computing system to: display a first display pane;detect authoring inputs relative to a set of visual nodes, connected by links as a flowchart, on the first display pane, the visual nodes in the flowchart being indicative of actions that a chatbot is configured to perform;detect a node selection authoring input, selecting a visual node of the set of visual nodes on the first display pane, the selected visual node corresponding to an action the chatbot is configured to perform; anddisplay a second display pane, along with the first display pane, with one or more property authoring actuators that are actuatable to configure properties of the action corresponding to the selected visual node.

2. The computing system of claim 1 wherein the instructions, when executed, cause the computing system to: detect actuation of at least one of the property authoring actuators on the second display pane, the detected actuation being indicative of a property configuration input configuring the action corresponding to the selected visual node, to obtain a configured action.

3. The computing system of claim 2 wherein the instructions, when executed, cause the computing system to: automatically generate a serialized representation of the configured action.

4. The computing system of claim 3 wherein the instructions, when executed, cause the computing system to: access a chatbot schema based on the configured action to obtain serialization information corresponding to the configured action; andgenerate the serialized representation of the configured action based on the serialization information.

5. The computing system of claim 4 wherein the instructions, when executed, cause the computing system to: display the serialized representation on a third display pane, along with the first and second display panes.

6. The computing system of claim 1 wherein the instructions, when executed, cause the computing system to: detect actuation of an add actuator in a link of the flowchart;access a chatbot schema based on an identity of the selected visual node;identify possible actions to add based on the chatbot schema; anddisplay an action actuator corresponding to each of the identified possible actions, each of the action actuators being actuatable to select a corresponding one of the possible actions for addition to the flowchart.

7. The computing system of claim 6 wherein the instructions, when executed, cause the computing system to: detect actuation of one of the action actuators to select a corresponding action; andadd a visual node to the flowchart, the added visual node corresponding to the selected action.

8. The computing system of claim 7 wherein the instructions, when executed, cause the computing system to: automatically display one or more property authoring actuators that are actuatable to configure properties of the selected action on the second display pane corresponding to the added visual node, along with the first display pane; andautomatically generate a serialized representation of the selected action.

9. The computing system of claim 1 wherein the flowchart represents a dialog that the chatbot is configured to execute, the dialog having linguistic elements comprising chatbot outputs and linguistic elements comprising expected user inputs, and wherein the instructions, when executed, cause the computing system to: generate an editable and searchable view of the chatbot outputs and expected user inputs in context relative to one another in the dialog.

10. The computing system of claim 1 wherein the selected visual node corresponds to a branching action and wherein the instructions, when executed, cause the computing system to: display, on the second display pane, one or more property actuators that are actuatable to set branch following criteria that configure the chatbot to follow a given branch of operation when the branch following criteria are met.

11. The computing system of claim 1 wherein the selected visual node corresponds to a looping action and wherein the instructions, when executed, cause the computing system to: display, on the second display pane, one or more property actuators that are actuatable to identify a collection of items and to configure the chatbot to use a different item, in the collection of items, in performing the looping action.

12. The computing system of claim 11 wherein the collection of items comprises a list of alternate chatbot responses and wherein the looping action configures the chatbot, each time the chatbot reaches the looping action in the flowchart, to use a different one of the chatbot responses when generating a chatbot output.

13. The computing system of claim 9 wherein the selected visual node corresponds to a user prompt action that prompts a chatbot end user for an input and wherein the instructions, when executed, cause the computing system to: display, on the second display pane, one or more property actuators that are actuatable to identify the user prompt.

14. The computing system of claim 5 wherein the instructions, when executed, cause the computing system to: detect an author input modifying the serialized representation on the third display pane to obtain a modified serialized representation;access a chatbot schema based on the modified serialized representation;based on the chatbot schema, identify a new visual node and a location in the flowchart where the visual node is to be added; andautomatically add the identified new visual node to the identified location in the flowchart on the first display pane.

15. A method performed by a computing system, the method comprising: displaying a first display pane;detecting authoring inputs relative to a set of visual nodes, connected by links, as a flowchart, on the first display pane, the visual nodes in the flowchart corresponding to actions that a chatbot is configured to perform;detecting actuation of an add actuator in a link of the flowchart;accessing a chatbot schema to identify possible actions to add;displaying an action actuator corresponding to each of the identified possible actions, each of the action actuators being actuatable to select a corresponding one of the possible actions for addition to the flowchart;detecting actuation of one of the action actuators to identify a selected action; andadding a visual node to the flowchart, in the link, the added visual node corresponding to the selected action.

16. The method of claim 16 and further comprising: displaying a serialized representation of the selected action on a third display pane, along with the first and second display panes;detecting an author input modifying the serialized representation on the third display pane to obtain a modified serialized representation;accessing the chatbot schema based on the modified serialized representation to identify a visual node and a place in the flowchart where the visual node is to be added; andautomatically adding the identified visual node to the identified place in the flowchart on the first display pane.

17. A computing system comprising: at least one processor; andmemory storing instructions executable by the at least one processor, wherein the instructions, when executed, cause the computing system to: generate a representation of a user interface having a first display pane and a second display pane;detect authoring inputs relative to a set of visual nodes, connected by links as a flowchart, on the first display pane, the visual nodes in the flowchart being indicative of actions that a chatbot is configured to perform;detect a node selection authoring input, selecting a visual node of the set of visual nodes on the first display pane, the selected visual node corresponding to an action the chatbot is configured to perform; andgenerate, on the second display pane, one or more property authoring actuators that are actuatable to configure properties of the action corresponding to the selected visual node.

18. The computing system of claim 17, wherein the instructions, when executed, cause the computing system to: detect actuation of at least one of the property authoring actuators on the second display pane, the detected actuation being indicative of a property configuration input configuring the action corresponding to the selected visual node, to obtain a configured action.

19. The computing system of claim 17, wherein the instructions, when executed, cause the computing system to: detect actuation of an add actuator in a link of the flowchart;access a chatbot schema based on an identity of the selected visual node;identify possible actions to add based on the chatbot schema; anddisplay an action actuator corresponding to each of the identified possible actions, each of the action actuators being actuatable to select a corresponding one of the possible actions for addition to the flowchart.

20. The computing system of claim 17 wherein the flowchart represents a dialog that the chatbot is configured to execute, the dialog having linguistic elements comprising chatbot outputs and linguistic elements comprising expected user inputs, and wherein the instructions, when executed, cause the computing system to: generate an editable and searchable view of the chatbot outputs and expected user inputs in context relative to one another in the dialog.