Terminology

Glossary of terms you may encounter while working with Slang

VAX — The concept behind Slang. Expands to Voice Augmented eXperience. The notion of adding Voice on top of an existing eXperience (usually touch based app) to make the end user usage of the app significantly better.

Slang Buddy — Your app's voice component & includes the configurations required to set up the voice feature in your app. The buddy configuration is a collection of the various intents, entities, utterances, prompts & voice messages that correspond to the different activities or tasks that the end user can perform in the app. For example, the Slang Buddy of a travel app would consist of one or more intents, entities, utterances, prompts & voice messages for the different travel related tasks that the end user can perform within the app using the voice feature. This includes tasks such as search for flights, book flight, search for hotels, book hotels and so on.

Intent — Think of them as commands that you want to support through voice. This can be tasks such as booking a flight, ordering a t-shirt, searching for a restaurant, and so on.

Utterance — Indicates the various ways an end user may utter a particular command.

Entity — Pieces of data that are additional parameters to the intent. If marked as required, entities are the specific pieces of information without which a task or intent cannot be completed. For example, you cannot book a ticket if you do not know the travel date.

Entity Type — Entities are instances of Entity Types. This allows for efficient reuse of the value lists and machine learning across various entities that may have the same type. For example, in a flight booking app, destination_city and source_city mean different things to the app, but their value list can be shared.

Standard Entity Type — To make it easier Slang has available a set of standard entity types with extensive value lists that can be used out of the box. Examples include std.duration, std.geo.city, std.geo.state.

User-Defined Entity Type — In cases where the app's entities cannot be represented as a Standard Entity Type, User-Defined Entity Types can be created and customized to match the requirement. For example, a fashion app may need to create a User-Defined Type to represent the brands of clothes available for sale.

Prompts - A Prompt is a three-part message that consists of (a) A question (b) An affirmative response and (c) A negative response. When a Prompt is correctly configured, the Slang framework will automatically ask the question at the appropriate stage of the voice interaction life cycle, and respond with either the affirmative or negative response based on whether the app completed the action successfully or not.

Statements - A Statement is a Prompt without the question part. It is a two-part message that consists of (a) An affirmative response (b) A negative response. When a Statement is correctly configured, the Slang framework will automatically speak the affirmative or negative response based on whether the app completed the action successfully or not.

App Prompt - The different voice messages that you would like Slang to speak when the user is interacting with your app using the voice feature. This can be a welcome message to greet the user as soon as they initiate the voice interaction in the app or clarification prompt that Slang is expected to speak out when the app is unable to hear or understand the user.

Intent Prompt - The different voice responses that you would like Slang to speak out to the user specific to an intent. This can be a confirmation message to spoken when a user the app has fulfilled the intent.

Intent Help - The different help messages that you would like displayed to the user when assistance is required specific to an intent. This includes the help title & sample utterances to help the user.

Entity Prompt - The different voice prompts that you would like Slang to speak out to the when a the specific entity is missing in the user utterance.

Slang Trigger — The customizable button that automatically appears on all of the screens in the app after Slang has been initialized. This is the entry point for voice interactions in the app for the end users of the app.

Slang Surface — The view/surface that appears on top of the current screen, when the user clicks on the Slang Trigger or when Slang wants to interact with the end user. This is the visual representation of app's "voice layer".

Buddy ID — For every Slang Buddy, the system generates a unique identifier referred to as the Buddy ID. Slang uses Buddy IDs to identify your app. The intents, utterances, entities, and entity types you create to define your commands or interactions, are associated with this ID. All you have to do is, use the same value when integrating Slang into your code base.

Save — Changes (create or update) that you make to intents, utterances, entities, and entity types are all relevant to a particular app. In order to make these changes available to the Slang back-end for creating or updating the app specific training model, they must be saved to the server. On clicking the Save button, the changes are saved to the server in the form of a JSON schema.

Publish — On clicking the Publish button (either to Staging or Production environments), a most recent snapshot of the saved changes gets created and is used to create or update the app specific training model. This is then used by Slang during voice interactions with the end users.

Environment — The schema that was configured using the console can be saved either to the "Staging" or "Production" environment. Similarly the Client app that uses this schema can either refer to the "Staging" environment or "Production" environment.

Staging — This is the environment to which the changes to the console should be published to when things are still being developed. The changes will only be visible to client app that explicitly targets the "staging" environment.

Production — This is the environment to which changes to the console should be published to when everything is tested and ready for the app's end users to consume. The changes will be visible to ALL clients app that explicitly target the "production" environment and so it is important to make sure that it's backward compatible.