DevOps Archives - KenkoGeek

6 Mar 2019
By editor
Categories: AWS

Alexa Developer Rewards Program Extends to Developers Building Skills for India

We are excited to announce that starting today developers residing in India can start earning money through the Alexa Developer Rewards Program for highly engaging skills published to the India Alexa Skills Store.

Eligible skill categories include:

Education & Reference
Food & Drink
Games, Trivia & Accessories
Kids
Health & Fitness
Lifestyle
Music & Audio
Productivity

We evaluate customer engagement and determine skill rewards on a monthly basis. You can increase customer engagement and potentially earn more rewards by publishing more engaging skills to the India Alexa Skills Store, and by improving your existing skills. Read about these best practices on how to promote your Alexa skills and reach more customers.

There is no need to apply for the program. If your skill qualifies for rewards, you will receive an email from the Alexa team. The email will cover the next steps for your registration and payment account setup. Make sure your country/region is correctly set to India in the profile section of the Alexa Developer Portal.

To date, the Alexa Developer Rewards program has paid millions of dollars to developers in more than 20 countries. Visit the Alexa developer blog to read how the Alexa Developer Rewards program has helped developers like Gal Shenar, David Markey, and Oscar Merry earn money and build their voice businesses.

We’re excited to see what voice experiences Indian developers will build next.

6 Mar 2019
By editor
Categories: AWS

Innovations from the 2018 Alexa Prize

March 4 marked the kickoff of the third Alexa Prize Socialbot Grand Challenge, in which university teams build socialbots capable of conversing on a wide range of topics and make them available to millions of Alexa customers through the invitation “Alexa, let’s chat”. Student teams may begin applying to the competition now, and in the next six weeks, the Alexa Prize team will make a series of roadshow appearances at tech hubs in the U.S. and Europe to meet with students and answer questions about the program.

As the third Alexa Prize Socialbot Grand Challenge gears up, the Alexa science blog is reviewing some of the technical accomplishments from the second. An earlier post examined contributions by Amazon’s Alexa Prize team; this one examines innovations from the participating university teams.

The 2018 Alexa Prize featured eight student teams from four countries, each of which adopted distinctive approaches to some of the central technical questions in conversational AI. We survey those approaches in a paper we released late last year, and the teams themselves go into even greater detail in the papers they submitted to the latest Alexa Prize Proceedings. Here, we touch on just a few of the teams’ innovations.

Handling automatic speech recognition (ASR) errors

Conversations with socialbots can cover a wide range of topics and named entities, which makes automatic speech recognition (ASR) more difficult than it is during more task-oriented interactions with Alexa. Consequently, all the teams in the 2018 Alexa Prize competition built computational modules to handle ASR errors.

Several teams built systems that prompted customers for clarification if ASR confidence scores were too low, and several others retained alternative high-scoring ASR interpretations for later re-evaluation.

Gunrock, the team from the University of California, Davis, that won the 2018 challenge, built a system for correcting ASR errors that uses the double-metaphone algorithm, an algorithm that produces standardized representations of word pronunciations. When the ASR system assigned a word a low confidence score, Gunrock’s error correction module would apply the double-metaphone algorithm to the word and then search a database of metaphone-encoded pronunciations for a partial match. Those pronunciations are grouped according to conversation topic, which lets the module take advantage of contextual information.

So, for instance, the metaphone representation of the phrase “secure holiday” is SKRLT, which doesn’t occur in Gunrock’s database. But SKRLT is a substring of the metaphone representation APSKRLTS, which does occur in the database. So Gunrock’s system would correct SKRLT to APSKRLTS and return the corresponding English phrase: “obscure holidays”.

Knowledge graphs

Carrying on a conversation requires knowledge, and most teams chose to encode their socialbots’ knowledge in graphs. A graph is a mathematical object consisting of nodes, usually depicted as circles, and edges, usually depicted as line segments connecting nodes. In a knowledge graph, the nodes might represent objects, and the edges might represent relationships between them. Several teams populated their knowledge graphs with data from open sources such as DBPedia, Wikidata, Reddit, Twitter, and IMDB, and many of the teams built their graphs using the Neptune graph database service from Amazon Web Services.

^{An example of a knowledge graph built with Amazon Web Services’ Neptune service}

Alana, the team from Heriot-Watt University in Scotland and the third-place finisher in the 2018 challenge, used Neptune to build a knowledge graph that encodes all the information in the Wikidata knowledge base, plus some additional data from the DBpedia knowledge base. When the Alana socialbot identifies a named entity in a conversation, it begins a context-constrained exploration of the graph, assembling a subgraph of linked concepts.

If someone chatting with the Alana bot mentioned the movie E.T., for example, Alana’s linked-concept generator would follow the Wikidata link from E.T. to the entry for Drew Barrymore, who appeared in the film, but not to the entry for Sweden, which is the second country in which the movie was released. Then, once it has built up a database of linked concepts, the Alana socialbot selects one at random to serve as the basis for a conversational response.

Natural-language understanding (NLU) for open-domain dialogue

Amazon researchers provided the student teams with default modules for doing natural-language understanding (NLU), or extracting linguistic meaning from raw text, but most teams chose to supplement them or, in some cases, supplant them with systems tailored specifically to the demands of conversational AI. Student teams built their own modules to classify utterances according to intent, or the goal the speaker hopes to achieve, and dialogue act, such as asking for information or requesting clarification; to identify the topics of utterances; and to assess the sentiments expressed by particular choices of phrasing, among other things.

Most of the NLU literature focuses on relatively short, goal-directed utterances. But in conversations with socialbots, people will often speak in longer, more complex sentences. So Gunrock built an NLU module that splits longer sentences into smaller, semantically distinct units, which then pass to additional NLU modules.

To train the segmentation module, Gunrock used movie-dialogue data from the Cornell Movie-Quotes Corpus, which had been annotated with a special tag (“”) to indicate breaks between semantically distinct units. On a test set, the module was 95.25% accurate, and an informal review indicated that it was accurately segmenting customers’ remarks. For example, the raw ASR output “Alexa that is cool what do you think of the Avengers” was segmented into “Alexa that is cool what do you think of the Avengers ”.

Dialogue management

The outputs of the NLU modules, along with any other utterance data the teams deem useful, pass to the dialogue management module, which generates an array of possible responses and selects one to send to Alexa’s voice synthesizer.

Alquist, the team from the Czech Technical University in Prague and the runner-up in the 2018 challenge, used a hybrid code network (HCN) for its dialogue manager. An HCN combines a neural network with handwritten code that reflects the developers’ understanding of the problem space. HCNs can dramatically reduce the amount of training data required to achieve a given level of performance, by sparing the network from having to learn how to perform tasks that are easily coded.

In Alquist’s case, the added code has two main functions: it filters out suggested responses that violate a set of handwritten rules about what types of responses should follow what types of utterances, and it inserts context-specific data into responses selected by the neural net. So, for instance, the neural network might output the response “That movie was directed by {say_director}”, where {say director} is an instruction to a complementary program that has separately processed data from the NLU modules.

Customer experience and personalization

All of the teams had to address the question of when to switch conversation topics and how to select new topics, but Iris, the team from Emory University, built a machine learning model that predicted appealing topics on the basis of conversational history — what topics a customer had previously accepted and rejected and what types of interactions he or she had previously engaged in. Iris trained their model on data from their socialbot’s past interactions with customers.

In tests, Iris compared their model to the simple heuristic of suggesting new topics in order of overall popularity and found that, on average, their model’s recommendations were 62% more likely to be accepted.

It was a pleasure to work with the student teams who competed in the 2018 Alexa Prize and a privilege to witness their innovative approaches to a fundamental problem in artificial-intelligence research. We can’t wait to see what the next group of teams will come up with!

Behnam Hedayatnia is an applied scientist in the Alexa AI group.

Papers:

Alexa science

Related:

6 Mar 2019
By editor
Categories: AWS

Conversation with Stoked Skills’ Gal Shenar: How to Monetize Your Alexa Skill While Helping Your Users

I recently had a chance to speak with Gal Shenar, founder of voice games studio Stoked Skills, about best practices for building voice-first games. This post is a recap of the second part of our conversation about his experience monetizing Alexa skills.

As briefly mentioned in the first post, Gal designed a clever way to monetize his Escape the Room and Escape the Airplane skills. By providing access to hint packs for a small fee through in-skill purchasing (ISP), he makes money while helping his players getting more deeply engaged with these skills.

A successful game is easy to start and hard to master. A contextual and on-demand hint framework is a way to mediate these two sides of a great gaming experience. Gal created just that. He wanted to recreate the experience of an in-person escape game, one in which a game master provides hints to players to solve puzzles when needed. He tested out a few approaches, listened to his users, and settled for offering hint packs for each room in his escape games. In today’s post, I share some of the things Gal and I talked about when it comes to monetizing Alexa skills, as well as insight into Gal’s unique approach. Let’s see how he did it.

A Skill’s Premium Experience is All About Value

The core concept Gal had in mind when designing the hint system for Escape the Room was that he wanted to provide the highest possible value for his paying users. He wanted players to experience the game for free and, in his words, “to feel taken care of.”

Creating a sense of urgency within a game’s storyline is a must for any immersive play experience. But Gal wanted to make sure that sense of urgency was not associated with a diminishing return on the investment for the player. Gal wanted “the hints to get progressively better” and to provide more value for the player as the game progressed.

Gal’s player-first approach paid off. He achieved his goal of providing value for players as demonstrated by conversion rates as high as 34% for his in-skill products. But he did not get there on day one. He experimented and adapted the in-skill product based on player feedback. He used tools in the Alexa Developer Console, including the beta testing feature to get player feedback before submitting for certification, the Intent History page to understand where players drop off, and the analytics dashboard to measure skill usage and earnings.

Your target should be offering the in-skill product at the right moment in the experience, ideally during a player’s moment of need and when they are willing to make a purchase to enhance their game play. Don’t bother them when they are busy. Help players, don’t sell to them. As Gal puts it, “done correctly, monetizing Alexa skills can be one of the most frictionless purchase experiences a customer can have.”

Easily Manage Payments with the Amazon Purchasing Flow

Customers can easily purchase premium experiences via voice using the payment methods associated with their Amazon account. And developers can easily leverage this simple voice purchasing flow. You basically only have to send a JSON response back to Alexa, describing what you are selling, and for how much. Amazon will handle the rest.

Here’s what Gal shared about his experience implementing ISP for Escape the Room.

As Gal showed us, Alexa will handle all the interactions with your players to process the transaction for your in-skill product. This flow will use the data that you have passed to the Alexa service in your JSON response to prompt players and describe what they are about to purchase. After the purchase flow is completed, you will receive a response status back from Alexa (ACCEPTED, DECLINED, ERROR or ALREADY_PURCHASED) and you will resume your skill flow. During the purchase interaction, Alexa might also provide promotional prices for Prime members, but you will always get 70% of the price you set, before any Amazon discounts.

As an Alexa skill developer, you have several options to choose from when adding ISP to your voice creations: subscriptions, consumables, and one-time purchases. Learn more from Gal on choosing the right ISP type here.

Unleash your creativity, entertain your customers, and start making money with Alexa skills.

Applications Accepted through 11:59 PM PT on Tuesday, May 14, 2019

Alexa Prize is different from other challenges in many ways, for example:

University students receive feedback on their interactions from a broad base of engaged users of a realworld AI technology. During the 2018 competition, Alexa customers held over 60,000 hours of conversations with Alexa Prize socialbots spanning millions of interactions. More information is available on our website.
Participating Alexa Prize teams are provided training, support, and access to the full suite of AWS services.

Here are some other things to note:

All 10 teams chosen for the Alexa Prize Socialbot Grand Challenge 3 will receive a sponsorship of $250K to build their conversational bots. Funding includes support for two fulltime students and one month of faculty time.
Teams retain ownership of their socialbots and associated IP, and are encouraged to publish their research. Amazon will have non-exclusive rights as described in the Alexa Prize Socialbot Grand Challenge 3 Official Rules.

If you still have questions, consider attending one of the events on our Roadshow. We’ll review the application process in depth and expand on resources available to competing teams. We’ll also be available for one-on-one meetings to address any specific questions you may have.

We look forward to receiving your applications. Please contact our team with questions or for additional information.

6 Mar 2019
By editor
Categories: AWS

Code Deep Dive: Implementing In-Skill Purchasing for Entitlements with Node.js

Editor’s Note: In this new code deep dive series, we will provide an end-to-end walkthrough of how to implement in-skill purchasing (ISP) in your Alexa skill. We will be using the Premium Hello World Skill (available on GitHub), which is a sample skill that demonstrates how to use ISP features by offering a “Premium Greeting Pack” that greets the customer in a variety of languages like French, Spanish, Hindi, and more. We will explain each line of code as we walk through several scenarios that monetized skills should be able to handle. With each installment of this series, we’ll introduce you to a new ISP product, starting with entitlements (or one-time purchases) in this post. We will explore subscriptions and consumables in future posts. If you’d like, you can follow along by referencing the steps in the GitHub guide to set up the Premium Hello World skill on your developer account.

Today we will look at a few ISP-related scenarios and walk through how we are handling each step in our skill code. We’ll focus on four scenarios to give you an understanding of how the whole experience works.

Scenarios 1 and 2 illustrate how to clearly distinguish premium content from free content in your skill, and “upsell” an in-skill product to a customer.

Scenario 3 shows how to provide customers with an easy way to know what they have already purchased by supporting the “what did I buy” utterance, and how to allow customers to learn about your premium content on-demand by supporting a “what can I buy” utterance.

Finally, Scenario 4 brings it all together to illustrate the experience for a customer who has bought the premium product, and can access the premium content seamlessly.

Also, be sure to read the certification guidelines and marketing guidelines to ensure that you’ve covered all of the requirements.

Let’s get started.

Scenario 1: Customer has not purchased the in-skill product. Our skill should upsell the value of the Premium Greeting Pack.

In this scenario, we let the customer experience the standard greeting twice and then we offer them (upsell) a premium experience. In this happy path illustrated below, we see them make the purchase and receive the experience (product) they have unlocked. As you read through the storyboard, notice the example dialog in yellow/blue (user/Alexa) and the basic logic on the right.

The customer launches the skill (A) and does not currently have the premium pack. Our skill will respond back with the standard greeting in this first turn, and ask them if they would like to hear another greeting.

Next, the customer responds with a “Yes” to the prompt “Would you like another greeting?” (B). Our skill now informs them that they can purchase the “Premium Greeting Pack”, which will give them access to greetings in other languages. We do this by prompting them with an “Upsell” offer, by sending a Connections.SendRequest directive to Alexa, with a name: 'Upsell' property. We do this inside our helper function getResponseBasedOnAccessType(), and then call it from the AnotherGreetingHandler through the callback function checkForProductAccess().

//Inside getResponseBasedOnAccessType() helper function
//Customer has not bought the Premium Product. Upsell should be made.

  if (isUpsellNeeded) {
    const upsellMessage = `You don't currently own the Premium Greeting pack. ${
      premiumProduct[0].summary
    }. ${getRandomLearnMorePrompt()}`;
    const sessionAttributes = handlerInput.attributesManager.getSessionAttributes();
    return handlerInput.responseBuilder
      .addDirective({
        type: "Connections.SendRequest",
        name: "Upsell",
        payload: {
          InSkillProduct: {
            productId: premiumProduct[0].productId
          },
          upsellMessage
        },
        token: JSON.stringify(sessionAttributes)
      })
      .getResponse();
  }

This generates the following JSON back that our skill sends back to Alexa:

{
    "body": {
        "version": "1.0",
        "response": {
            "directives": [
                {
                    "type": "Connections.SendRequest",
                    "name": "Upsell",
                    "payload": {
                        "InSkillProduct": {
                            "productId": "amzn1.adg.product.a3c807a6-ca7b-4862-adfa-eb92e268831c"
                        },
                        "upsellMessage": "You don't currently own the Premium Greeting pack. The Premium Greeting Pack greets you with a secret greeting. Want to learn about it?"
                    },
                    "token": "{}"
                }
            ],
            "type": "_DEFAULT_RESPONSE"
        },
        "sessionAttributes": {},
        "userAgent": "ask-node/2.3.0 Node/v8.10.0"
    }
}

//Inside AnotherGreetingWithUpsellHandler()
// IF THE USER SAYS YES, THEY WANT ANOTHER GREETING, AND UPSELL SHOULD BE MADE

const AnotherGreetingWithUpsellHandler = {
  canHandle(handlerInput) {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name === "AMAZON.YesIntent" &&
      handlerInput.attributesManager.getSessionAttributes().shouldUpsell ===
        true
    );
  },
  handle(handlerInput) {
    //Get the locale for the request
    const locale = handlerInput.requestEnvelope.request.locale;

    //Instantiate a new MonetizationServiceClient object to invoke the inSkillPurchaseAPI
    const monetizationClient = handlerInput.serviceClientFactory.getMonetizationServiceClient();

    //Check if upsell should be done. You can set your own upsell timing logic inside the shouldUpsell() function.
    const isUpsellNeeded = true;

    //Get list of products the customer has bought, and then respond accordingly
    return monetizationClient.getInSkillProducts(locale).then(function(result) {
      //Pass the handlerInput, list of products customer has access to (result), and the flag for upsell to the helper function checkForProductAccess to determine the response.
      let response = checkForProductAccess(
        handlerInput,
        result,
        isUpsellNeeded
      );
      //Modify the Upsell message so we hear a standard greeting before it
      const originalUpsellMessage =
        response.directives[0].payload.upsellMessage;
      const newUpsellMessage = `Here's your standard greeting: ${getStandardGreeting()}  ${originalUpsellMessage}`;
      // Setting a Session Attribute to keep track of the number of times the customer has said heard a standard greeting.
      // We will use this to determine if an upsell is required.
      const attributeNameToIncrement = `numberOfStandardGreetingsOfferedInThisSession`;
      incrementCountInSession(handlerInput, attributeNameToIncrement);
      response.directives[0].payload.upsellMessage = newUpsellMessage;
      return response;
    });
  }
};

//Inside checkForProductAccess() helper function

function checkForProductAccess(handlerInput, result, isUpsellNeeded) {
  const premiumProduct = result.inSkillProducts.filter(
    record => record.referenceName === `Premium_Greeting`
  );
  const response = getResponseBasedOnAccessType(
    handlerInput,
    premiumProduct,
    isUpsellNeeded
  );
  return response;
}

Handling the Purchase Experience Flow

At this point, Alexa’s Purchase Experience Flow takes over (C), and responds back to the customer with more details about the product (as provided by you when you created the product), along with the pricing information (again, as provided by you when you created the product). Amazon may even include a Prime discount for the customer.

“The Premium Greeting Pack greets you with a secret greeting. Prime members save $0.19. Without Prime, your price is $0.99 plus tax. Would you like to buy it?”

If the customer accepts the upsell offer (D) (by responding with a “Yes” to the prompt – “Would you like to buy it”?), Alexa responds back with a Connections.Response directive, which among other things, includes the payload.purchaseResult property, which indicates the result of the purchase transaction – ACCEPTED, DECLINED, ALREADY_PURCHASED, or ERROR.

If Customer Accepts the Upsell offer, our skill receives a purchaseResult of ACCEPTED. Like, so –

{
        "type": "Connections.Response",
        "requestId": "amzn1.echo-api.request.ace59d6a-2a7c-414c-b3d0-4a4b021d6fa4",
        "timestamp": "2019-02-20T23:58:07Z",
        "locale": "en-US",
        "status": {
            "code": "200",
            "message": "OK"
        },
        "name": "Upsell",
        "payload": {
            "purchaseResult": "ACCEPTED",
            "productId": "amzn1.adg.product.a3c807a6-ca7b-4862-adfa-eb92e268831c"
        },
        "token": "{}"
}

If Customer declines the Upsell offer, our skill receives a purchaseResult of DECLINED. Like, so –

{
        "type": "Connections.Response",
        "requestId": "amzn1.echo-api.request.674935ee-d248-4cdf-908b-fa04a9743d03",
        "timestamp": "2019-02-21T01:03:28Z",
        "locale": "en-US",
        "status": {
            "code": "200",
            "message": "OK"
        },
        "name": "Upsell",
        "payload": {
            "purchaseResult": "DECLINED",
            "productId": "amzn1.adg.product.a3c807a6-ca7b-4862-adfa-eb92e268831c",
            "message": "Skill Upsell was declined."
        },
        "token": "{}"
    }

It’s important to note that Amazon provides the purchase experience flow and also keeps track of which products are available and which have already been purchased. Your skill makes calls to the Monetization Service to determine if purchases have been made, and to pass purchase requests to Amazon.

Resuming the skill after Alexa’s Purchase Experience Flow is complete

As you can see in the JSON above, Alexa sends a Connections.Response directive back to our skill with a purchaseResult of “ACCEPTED” after the purchase is completed. We handle our response in the ConnectionsResponseHandler, as shown below.

//Inside ConnectionsResponseHandler.canHandle()    

 return (
      handlerInput.requestEnvelope.request.type === "Connections.Response" &&
      (handlerInput.requestEnvelope.request.name === "Buy" ||
        handlerInput.requestEnvelope.request.name === "Upsell")
    );

//Inside ConnectionsResponseHandler.handle()
//Check if the `purchaseResult` was ACCEPTED or DECLINED


switch (handlerInput.requestEnvelope.request.payload.purchaseResult) {
          case "ACCEPTED":
            theGreeting = getPremiumGreeting();
            speakOutput = `You have unlocked the Premium Greeting Pack. Here's your Premium greeting: ${
              theGreeting["greeting"]
            } ! That's hello in ${
              theGreeting["language"]
            }. ${getRandomYesNoQuestion()}`;
            const attributeNameToSave = `entitledProducts`;
            saveToSession(handlerInput, attributeNameToSave, premiumProduct);
            repromptOutput = getRandomYesNoQuestion();
            // resetting the count of standard greetings to avoid hitting upsell logic
            const secondAttributeNameToSave = `numberOfStandardGreetingsOfferedInThisSession`;
            const numberOfStandardGreetingsOfferedInThisSession = 1;
            saveToSession(
              handlerInput,
              secondAttributeNameToSave,
              numberOfStandardGreetingsOfferedInThisSession
            );
            break;

//Inside getPremiumGreeting() helper function

function getPremiumGreeting() {
  //TODO: Add more greetings
  const premium_greetings = [
    { language: "hindi", greeting: "Namaste" },
    { language: "french", greeting: "Bonjour" },
    { language: "spanish", greeting: "Hola" },
    { language: "japanese", greeting: "Konichiwa" },
    { language: "italian", greeting: "Ciao" }
  ];
  return premium_greetings[
    Math.floor(Math.random() * premium_greetings.length)
  ];
}

This generates the following speech output for the customer:

You have unlocked the Premium Greeting Pack. Here’s your Premium greeting: Bonjour ! That’s hello in french. Can I give you another greeting?

Scenario 2: Customer has not bought the product and asks for a premium greeting.

In this scenario, the customer does not currently have the “Premium Greeting Pack” and asks specifically for a premium greeting. In this case, our skill should make an upsell, and then hand off the control to Alexa to walk the customer through the Purchase Experience Flow, just as in the last scenario.

The utterances for getting a premium greeting will match the PremiumGreetingIntent, and trigger our PremiumGreetingHandler (B) as shown below.

As we did in the AnotherGreetingHandler in the last scenario, we will instantiate the Alexa Monetization Service Client, and call our checkForProductAccess function, which will then check if the customer has access to the product already. If not, it will launch the Purchase Experience Flow, just like in the last scenario (C & D above)

const PremiumGreetingHandler = {
  canHandle(handlerInput) {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      (handlerInput.requestEnvelope.request.intent.name ===
        "PremiumGreetingIntent" ||
        handlerInput.requestEnvelope.request.intent.name === "BuyIntent")
    );
  },
  handle(handlerInput) {
    const locale = handlerInput.requestEnvelope.request.locale;
    const monetizationClient = handlerInput.serviceClientFactory.getMonetizationServiceClient();
    const isUpsellNeeded = true;
    return monetizationClient.getInSkillProducts(locale).then(function(result) {
      return checkForProductAccess(handlerInput, result, isUpsellNeeded);
    });
  }
};

Scenario 3: Customer has not bought the product and asks “What have I bought?”

In this scenario, the customer wants to know what premium products (if any) they have bought.

Since the customer has not bought any products yet, we encourage them to ask about the products available to buy by saying – “what can I buy” (B).

The Utterance “what have I bought” is handled by the PurchaseHistoryHandler as shown below –

// User says: Alexa, ask Greetings helper what have I bought

const PurchaseHistoryHandler = {
  canHandle(handlerInput) {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name ===
        "PurchaseHistoryIntent"
    );
  },
  handle(handlerInput) {
    const locale = handlerInput.requestEnvelope.request.locale;
    const monetizationClient = handlerInput.serviceClientFactory.getMonetizationServiceClient();
    return monetizationClient.getInSkillProducts(locale).then(function(result) {
      const entitledProducts = getAllEntitledProducts(result.inSkillProducts);
      if (entitledProducts && entitledProducts.length > 0) {
        const speakOutput = `You have bought the following items: ${getSpeakableListOfProducts(
          entitledProducts
        )}. ${getRandomYesNoQuestion()}`;
        const repromptOutput = `You asked me for a what you've bought, here's a list ${getSpeakableListOfProducts(
          entitledProducts
        )}`;
        return handlerInput.responseBuilder
          .speak(speakOutput)
          .reprompt(repromptOutput)
          .getResponse();
      }
      const speakOutput = `You haven't purchased anything yet. Would you like a standard greeting or premium greeting`;
      const repromptOutput = `You asked me for a what you've bought, but you haven't purchased anything yet. You can say - what can I buy, or say yes to get another greeting. ${getRandomYesNoQuestion()}`;
      return handlerInput.responseBuilder
        .speak(speakOutput)
        .reprompt(repromptOutput)
        .getResponse();
    });
  }
};

Next, as advised by our skill, the customer asks “what can I buy”. This fires off the WhatCanIbuyIntent (C), and the skill responds with the list of products available to purchase. Our skill only has one premium product available to purchase – Premium Greeting Pack.

Here’s the handler – WhatCanIBuyHandler that generates that response.

//Inside WhatCanIBuyHandler// 
User says: Alexa, ask Greetings helper what can I buy

const WhatCanIBuyHandler = {
  canHandle(handlerInput) {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name === "WhatCanIBuyIntent"
    );
  },
  handle(handlerInput) {
    // Inform the user about what products are available for purchase
    const locale = handlerInput.requestEnvelope.request.locale;
    const monetizationClient = handlerInput.serviceClientFactory.getMonetizationServiceClient();
    return monetizationClient
      .getInSkillProducts(locale)
      .then(function fetchPurchasableProducts(result) {
        const purchasableProducts = result.inSkillProducts.filter(
          record =>
            record.entitled === "NOT_ENTITLED" &&
            record.purchasable === "PURCHASABLE"
        );
        if (purchasableProducts.length > 0) {
          const speakOutput = `Products available for purchase at this time are ${getSpeakableListOfProducts(
            purchasableProducts
          )}. To learn more about a product, say 'Tell me more about' followed by the product name. If you are ready to buy, say, 'Buy' followed by the product name. So what can I help you with?`;
          const repromptOutput = `I didn't catch that. What can I help you with?`;
          return handlerInput.responseBuilder
            .speak(speakOutput)
            .reprompt(repromptOutput)
            .getResponse();
        }
        const speakOutput = `There are no products to offer to you right now. Sorry about that. Would you like a greeting instead?`;
        const repromptOutput = `I didn't catch that. What can I help you with?`;
        return handlerInput.responseBuilder
          .speak(speakOutput)
          .reprompt(repromptOutput)
          .getResponse();
      });
  }
};

Moving ahead with out dialog, the customer now says “Tell me more about Premium Greeting”. This triggers the “PremiumGreetingIntent” (D).

At this point, Alexa’s Purchase Experience Flow takes over (E & F), and the dialog is similar to Scenario 2: Customer has not bought the product, and asks for a premium greeting , where the skill guides them through the purchase experience.

Scenario 4: Customer has purchased the in-skill product.

This is a pretty straight forward scenario. The customer has already purchased the Premium Greeting Pack, so our skill should respond back with a premium greeting, and ask them if they would like to hear another greeting, and respond back accordingly.

Here’s your Premium greeting: Konichiwa ! That’s hello in japanese. Would you like another greeting?

We handle the response for this in the AnotherGreetingHandler as shown below:

//Inside AnotherGreetingHandler//
//Utterance: Yes (in response to "do you want another greeting?")
// IF THE USER SAYS YES, THEY WANT ANOTHER GREETING.

const AnotherGreetingHandler = {
  canHandle(handlerInput) {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name === "AMAZON.YesIntent"
    );
  },
  handle(handlerInput) {
    //Get the locale for the request
    const locale = handlerInput.requestEnvelope.request.locale;

    //Instantiate a new MonetizationServiceClient object to invoke the inSkillPurchaseAPI
    const monetizationClient = handlerInput.serviceClientFactory.getMonetizationServiceClient();

    //Check if upsell should be done. You can set your own upsell timing logic inside the shouldUpsell() function.
    const isUpsellNeeded = false;

    //Get list of products the customer has bought, and then respond accordingly
    return monetizationClient.getInSkillProducts(locale).then(function(result) {
      //Pass the handlerInput, list of products customer has access to (result), and the flag for upsell to the helper function checkForProductAccess to determine the response.
      let response = checkForProductAccess(
        handlerInput,
        result,
        isUpsellNeeded
      );
      return response;
    });
  }
};

We hope you find this new series helpful as you embark on the journey to use ISP to sell premium content in US skills to enrich your Alexa skill experience and further delight your customers. You can reach out to me on Twitter @amit and my co-author for this series @memodoring. We can’t wait to see what you build!

Understanding Intent Chaining

Intent chaining allows your skill code to start dialog management from any intent, including the LaunchRequest. You can chain into any of your custom intents as long as your interaction model has a dialog model. How do you know if you have a dialog model? If you have at least one intent with a required slot, or you’ve enabled auto delegation, your skill has a dialog model. While you can chain from any intent, there are some intents that you cannot chain to. For example, you can’t chain to the LaunchRequest or any of the built-in intents, such as, Amazon.HelpIntent.

In the past, your skill code could only return a dialog directive once dialog management was triggered through a user utterance. Intent chaining has me super excited because our skills can now activate dialog management programmatically!

Let’s consider an interaction that uses dialog management without intent chaining. The conversation takes place between a coffee shop skill that our customers will use to order tea or coffee. We won’t go through the entire conversation start to finish. We’ll focus on just the transition from the LaunchRequest to the intent that we want to chain into, OrderIntent. The LaunchRequest greets the customer and the OrderIntent uses dialog management to take their order. As you read think about how this conversation could be simplified.

CUSTOMER Alexa, open coffee shop.

ALEXA Welcome to the coffee shop. Say start my order to get started.

CUSTOMER Start my order.

ALEXA Which would you like coffee or tea?

CUSTOMER coffee

Were you able to identify how we could simplify this conversation? How about instead of having the user say, “start my order” to have your skill start the order conversation, why don’t we just start taking their order? In that case our conversation would look something like:

CUSTOMER Alexa, open coffee shop.

ALEXA Welcome to the coffee shop. Which would you like tea or coffee?

CUSTOMER coffee

That’s so much simpler, isn’t it? We can immediately start taking their order. Before I show you how to chain intents, let’s take some time to fully understand the benefits of chaining intents.

It’s entirely possible without intent chaining to update our LaunchRequest to say, “Welcome to the coffee shop. Which would you like tea or coffee?” However, when the customer responds, dialog management isn’t active. The customer needs to say something to trigger the OrderIntent. Upon doing so, dialog management springs into action tracking the conversation for us. One major advantage to using dialog management is improved accuracy. The Alexa service is able to more accurately anticipate what your customer will say next and the intent that should handle it. In this case, our customer is most likely going to respond with their choice of either “tea” or “coffee,” which needs to be handled by our OrderIntent.

You can even use intent chaining to chain from one intent with dialog management to another. You can, for example, create a set of intents designed to collect sets of information and chain between them based on what you have and have not collected. Furthermore, you can even chain from a custom intent that uses auto delegation. Now that we understand the benefits of intent chaining, let’s take a look at how it’s done.

Chaining Intents with Dialog.Delegate

Our example coffee shop skill has an OrderIntent that we want to chain into when the customer says, “Alexa, open coffee shop” from our LaunchRequest. To do that all we have to do is return a dialog delegate and the name of the intent we want to chain to from our LaunchRequest. First, we’ll take a look at how we’d do that with the addDelegateDirective function.

.addDelegateDirective({
    name: 'OrderIntent',
    confirmationStatus: 'NONE',
    slots: {}
 })

That’s pretty easy! Here we used addDelegateDirective to add the Dialog.Delegate directive to our response, and we set the name property to OrderIntent which is the intent we want to chain to. The confirmationStatus indicates whether the intent has been CONFIRMED or DENIED. While NONE indicates that our customer hasn’t been asked to confirm. The slots object allows us to programmatically set slot values. This comes in handy when restoring the collected slots when returning from a context switch. For more on that, take a look at Build for Context Switching: Don’t Forget Important Information When Switching Between Intents.

If you’re feeling adventurous, you can use the addDirective() function instead. You’ll have to manually set the directive type to Dialog.Delegate, define updatedIntent and set name to OrderIntent:

.addDirective({
    type: 'Dialog.Delegate',
    updatedIntent: {
      name: 'OrderIntent',
      confirmationStatus: 'NONE',
      slots: {}
    }
  })

The choice is yours, but I’d recommend addDelegateDirective because it reduces the amount of code you have to write. Now that you understand how to build the directive, let’s take a look at how we build the whole response with the responseBuilder.

return handlerInput.responseBuilder
    .addDelegateDirective({
        name: 'OrderIntent',
        confirmationStatus: 'NONE',
        slots: {}
    })
    .speak("Welcome to the coffee shop.")
    .getResponse();

The addDelegateDirective function belongs to the responseBuilder, which we are using to build the response that our skill sends back to Alexa. The speak function defines what Alexa will say. Take a look at the text we’ve passed to it.

    .speak("Welcome to the coffee shop.")

Something seems to be missing? It does not include the question, “Which would you like tea or coffee?” Why did we leave it out? When we defined our OrderIntent, we marked the coffee slot required. Doing so requires us to define prompts in our dialog model, which Alexa will use to ask our customer to fill the slot! Returning the Dialog.Delegate from our LaunchRequest triggers Alexa to immediately start prompting for our required slots using our dialog model.

Chaining Intents with Dialog.ElicitSlot

Dialog.Delegate isn’t the only dialog directive at our disposal. The elicit slot directive allows us to specify what the Alexa voice service will prompt for next. We can also use it to programmatically convert optional slots into required slots.

Intent chaining supports the elicit slot directive. So, we’re able to chain into a specific intent while eliciting a specific slot. Let’s take a look at how we’d do that using the addElicitSlotDirective function.

.addElicitSlotDirective('drink',
{
    name: 'OrderIntent',
    confirmationStatus: 'NONE',
    slots: {}
})

The first parameter we pass to addElicitSlotDirective is the name of the slot that we want to elicit. In this case, we’re going to elicit the drink slot. Just like addDelegateDirective we set name to the intent that we are going to chain to (OrderIntent) and the confirmationStatus to NONE. Let’s take a look at how we’d do the same with the addDirective function.

.addDirective({
    type: 'Dialog.ElicitSlot',
    slotToElicit: 'drink',
    updatedIntent: {
        name: 'OrderIntent',
        confirmationStatus: 'NONE'
    }
})

In this case we are manually defining the directive. We have to set the type to Dialog.ElicitSlot and slotToElicit to drink and then define and wrap the name and confirmationStatus in updatedIntent. It’s great to have the flexibility to build the request manually, but just like Dialog.Delegate, I recommend using the helper function. Let’s take a look at the whole responseBuilder. Keep an eye out to what we are passing to the speak function in this case.

return handlerInput.responseBuilder
    .addElicitSlotDirective('drink', {
        name: 'OrderIntent',
        confirmationStatus: 'NONE',
        slots: {}
    })
    .speak("Welcome to the coffee shop. Which would you like tea or coffee?")

    .reprompt("Which would you like tea or coffee?")
    .getResponse();

Did you notice when our skill chains with the Dialog.ElicitSlot directive, we include the question, “Which would you like tea or coffee?” Unlike Dialog.Delegate, Alexa won’t use our prompt defined in the dialog model to automatically ask the question. When we use Dialog.ElicitSlot to specify what slot to have Alexa prompt for next, it’s our responsibility to also define the prompt. If we don’t provide the question, Alexa will say, “Welcome to the coffee shop” and leave the microphone temporarily open for our customer to respond without asking a question. After a few seconds of awkward silence, your skill will speak the text that you passed to reprompt. If your reprompt also lacks a question, the awkwardness will repeat. The session will then close after a few seconds. This will confuse your customer, so be sure to include the question when you use Dialog.ElicitSlot to chain intents. On the other hand, if you’re using Dialog.Delegate to chain intents, and you include the question, Alexa will repeat the question, once with your initial response and again with prompt defined in your dialog model.

Conclusion

As you can see, intent chaining allows you to streamline the conversation that your customer will have with your skill. As a bonus, you get increased accuracy since you’re setting the context that allows Alexa to anticipate what the customer is going to say next and which intent should handle it.

I hope this has inspired you to think about how you can put intent chaining to use in your skills. If you do, I’d love to hear about it! Please reach out to me on Twitter @SleepyDeveloper to let me know!

Resources

6 Mar 2019
By editor
Categories: AWS

Hear It from a Skill Builder: Going from Voice-Only to Voice-First with Multimodal Alexa Skills

Editor’s Note: Using the new Alexa Presentation Language (APL), you can deliver richer, more engaging voice-first interactions to your customers across tens of millions of Alexa-enabled devices with screens. Today we welcome a community expert—Adva Levin, Alexa Champion, founder of Pretzel Labs, and winner of the Alexa Skills Challenge: Kids—to offer some best practices for building multimodal skills. She shares how she redesigned her Kids Court skill into a multimodal experience.

APL lets developers and designers create flexible designs for multimodal devices that include voice and display. Since voice-first multimodal devices are so new, for many people multimodal design can be a first-time experience both as a user and as a designer. The Alexa team has been putting together best practices for designing multimodal skills, and you can get inspired by some APL skills here.

As a designer approaching a relatively new medium, it’s also interesting to look at other mediums for inspiration. My favorite example is of a waiter taking an order at a restaurant. If you observe that situation closely, you can see how the diners’ attention naturally shifts from looking at the menu to listening to what the waiter says, briefly glancing at the menu, and vice versa. Things get even more interesting when the waiter starts talking about specials that are off the menu!

This attention shift happens naturally in a person-to-person conversation. When you design the visual and voice components of your Alexa skill, mirror this interaction. It’s up to you as a skill builder to guide the customer through a good user experience that navigates the conversation so your skill can help them achieve their goals.

When redesigning Kids Court as a multimodal skill, I wanted the visuals to draw the users into the humorous world of a skill where Alexa is the judge in their fights. However, it was also important to keep the users (who are mostly kids and their parents) focused on the conversation and not get them too distracted by visuals. I went with a calm, illustrated graphic language that shows what happens at the court, and a combination of animated and real characters to show that the court deals with situations from real life. I used speech bubbles to help the users concentrate on what they are supposed to say to carry the conversation forward.

Here are some best practices I picked up while designing a voice-first, visual experience for Kids Court.

1. Picking the Right Balance

What is the right balance between audio and visuals for your skill? Here are some examples and considerations:

Using subtitles, or SpeakItem Command: Think of this like a TV show that has captions. This concept keeps the experience consistent between voice-only devices and multimodal ones. It is best used for wordy skills, or skills where it’s critical that the user understands every single word Alexa is saying. For example, try to ask Alexa to look something up on Wikipedia.

Enhancing the conversation with visuals: Professional conference speakers rarely use heavily worded slides, but the images are there to enhance, support, and help focus the audience on what the speakers are saying. This example works best for most skills. I recommend watching a few TED talks to see how the speakers strike a balance between speaking and showing their slides. For example, in Kids Court, the written text is a shortened version of what Alexa says. The speech bubble helps users understand what to say at key interactions, and the graphic layer around it contributes to a more lively overall experience.

Using voice-supported visuals: An example for this is a TV show that has beautiful imagery that is accompanied by a voice over, like a nature show with voice-over narration. This can be tricky, as you still need to provide a good experience for voice-only users, but it’s a good source of inspiration for use cases that rely heavily on visuals. For example: The Magical Zoo skill draws users in by using beautiful illustrations and sound effects. There is no text on the screen, and Alexa gives verbal cues hinting which animal to transform next.

2. Designing for Different Devices

Using APL, you can design and build voice-first, visual experience that are optimized for different device types, delivering a quality customer experience. As you design your experience, consider the functionality of the device. Is the screen used for display only, or should the user be able to use touch buttons in addition to using voice commands? As you think about adapting your concept to different device sizes, consider the environment and the customer’s context.

For example, the communal experience in the living room on a Fire TV is completely different than a quick glance at your Echo Spot in the bedroom. Adapting to different screen sizes doesn’t only mean creating different sizes of images, but may also require different concepts for different devices. What elements and information is it key for you to show on the smaller devices? Here are some more tips for designing voice-first experiences for different Alexa-enabled devices.

3. Storyboarding

Create a detailed storyboard, breaking down your skill into interaction points. Write down what Alexa says in each point, and mark the key interaction points where visuals can support and enrich the experience.

Sync the images with the audio by using the pager component. At every beat, think where you want your users’ attention – listening or looking – and design your speech, sounds, and images accordingly. For specific parts of the skill where you have longer pieces of audio and want a carefully tailored experience, you can use videos.

If you’re using text in your visuals it can be helpful to shorten the visual text, but be careful not to confuse your user with different calls to action.

4. Creating Your Graphics

Now that you have a sketch of the exact screens you need, you can start designing your visuals. Keep your skill’s style in mind, including persona, voice, and tone of your skill. Your visual language should be in line with the personality, speech, and sound design to create a harmonious experience.

You can explore graphic design tools, like Photoshop and Pixelmator, or online tools like Canva, Pixlr or Crello for backgrounds. Another option is to work with a graphic designer who can help you bring your vision to life.

Skill-Building Foundation

Both types of SkillBuilders derive from a common base type, which means they have some things in common. You can add Request Handlers, Request Interceptors, Response Interceptors and Error Handlers to all SkillBuilders. (If you’re not familiar with these features, you can learn more in this blog.) Additionally, you can further customize the User Agent reported as part of your skill’s response or set the SkillId used for request validation if you don’t want to use the AWS Lambda trigger validation (for example, when you’re using the SDK but not using Lambda).

Here’s where things start to diverge. The SDK provides tools and utilities that make skill building easier. This frees you up from having to create code to manage persistent attributes, or to implement retries when calling a throttled API. While these tasks may be common, the SDK does not require you to use a specific persistence layer (or database); you can choose from the available persistence adapters or even create your own, yet still fully leverage the SDK. Similarly, you might want to use your own API client rather than use the one provided with the SDK. This flexibility is why there are different SkillBuilders.

SkillBuilder Tradeoffs

The Standard SkillBuilder object comes preconfigured to use the “default API client” and the Amazon DynamoDB persistence adapter and is included in the full SDK. (Note: Using the Amazon DynamoDB persistence adapter does not automatically grant your skill access to DynamoDB – access is controlled through an AWS IAM policy.) In general, using the Standard SkillBuilder is the simplest way to get started. To use Standard, include the full SDK (ask-sdk), which also includes the core SDK. The core SDK (ask-sdk-core) only includes the Custom SkillBuilder to avoid requiring unneeded dependencies.

The most common reasons to use the Custom SkillBuilder instead are that you need to use a different persistence adapter, or you don’t want to include extra dependencies in your code package. Let’s look at both of these scenarios.

Setting the Persistence Layer

The most common case for needing a different persistence adapter is for those skills which are Alexa-hosted skills. This offering currently includes Amazon S3 as the persistence layer, so when creating your skill, you will be required to use the Custom SkillBuilder if you are persisting any attributes. To use the S3 persistence adapter in Node.js, add this line of code to your SkillBuilder setup:

.withPersistenceAdapter(new s3Adapter.S3PersistenceAdapter({bucketName:process.env.S3_PERSISTENCE_BUCKET})

Note: In the above example, it’s assumed you’re using Alexa-hosted and your S3 bucket name is available as an environment variable. To use a different bucket, change the bucketName value passed to the constructor.

In addition, you’ll need to import the S3 persistence adapter since it isn’t included by default. Add this to your code:

const s3Adapter = require('ask-sdk-s3-persistence-adapter');

Include this code as a dependency by adding this to your package.json:

"ask-sdk-s3-persistence-adapter": "^2.0.0"

It’s important to remember that since you’ve taken advantage of persistence layer flexibility, you must also add an API client since one wasn’t included by default. If you miss this step, you may see errors like the below when you attempt to use one of the Alexa APIs:

Cannot read property 'getMonetizationServiceClient' of undefined

Adding the default API client can be done by adding this line of code to your SkillBuilder setup:

.withApiClient(new Alexa.DefaultApiClient())

If you are only getting API client related errors, a cleaner fix is to change your SkillBuilder type to Standard; however, that’s only recommended if you can also use the DynamoDB persistence adapter.

Avoid Extra Dependencies

The second common reason to use the Custom object over the Standard object is to avoid extra dependencies. If you use only the Custom SkillBuilder, you only need to include the core SDK (ask-sdk-core). This does not include the DynamoDB persistence adapter, which in turn means the AWS SDK is not included since it is not required. A smaller deployment package is helpful if you are bundling your dependencies and want to edit your code directly in the Lambda console, or if you want quicker deployments. With the introduction of features like Layers, you should be freed from some of these restrictions and able to focus on choosing the right SkillBuilder for your use case.

Not a One-Way Door

If you started with one SkillBuilder type and decide you want to switch, you’re in luck. To move to the Standard SkillBuilder, first ensure you are including the full SDK (ask-sdk), then change “SkillBuilder.Custom()” to “SkillBuilder.Standard()” and remove any persistence or api client setup calls.

Note: If you have customized your persistence adapter configuration, you will need to bring that along in your conversion. If you have done that, it’s likely better to stick with the Custom SkillBuilder rather than risk break something.

To move to a Custom SkillBuilder that is configured the same as the Standard one, change “SkillBuilder.Standard()” to “SkillBuilder.Custom()”. Then add these lines of code to your SkillBuilder setup:

.withPersistenceAdapter(new DynamoDbPersistenceAdapter({

    tableName: 'MySkillTableName',

    createTable: true

})

.withApiClient(new Alexa.DefaultApiClient())

The last step is to adjust your dependencies (if you want to). The full SDK (ask-sdk) includes all the required dependencies, but you can decompose them into the core SDK (ask-sdk-core) and the DynamoDB persistence adapter (ask-sdk-dynamodb-persistence-adapter).

More Resources

I hope this information helps you in understanding the difference between Standard and Custom SkillBuilders so you can confidently choose the one that is best for your skill. We look forward to seeing what you build. Tweet me @franklinlobb and I’d be happy to check it out! Check out the following resources to dive deeper:

Skill Builder Examples
Skill Builder entry in ASK SDK for Node.js documentation
Skill Builder entry in ASK SDK for Python documentation
Skill Builder entry in ASK SDK for Java documentation

2 Mar 2019
By editor
Categories: HowTo

How to add Puppet Agents to Foreman

This is the second part of the Foreman tutorial. In the first guide, we’ve already shown you the installation and configuration of Foreman on Ubuntu Server 18.04 LTS and now I will show you how to add Puppet Agents to Foremen.

28 Feb 2019
By editor
Categories: HowTo

How to Install Cachet Status Page System on CentOS 7

Cachet is a beautiful and powerful open source status page system written in PHP that allows you to better communicate downtime and system failures to your customers, teams, and shareholders. In this tutorial, we will install the Cachet status page system using PHP, Nginx, MySQL, and Composer on the CentOS 7 system.

28 Feb 2019
By editor
Categories: HowTo

How to Install Monica Personal Relationship Manager on Ubuntu 18.04 LTS

Monica is a free, open source web-based Personal Relationship Management software written in the Laravel framework. It is used to keep track of all the important details about your friends and family.

A Skill’s Premium Experience is All About Value

Easily Manage Payments with the Amazon Purchasing Flow

Related Content

Applications Accepted through 11:59 PM PT on Tuesday, May 14, 2019

Scenario 1: Customer has not purchased the in-skill product. Our skill should upsell the value of the Premium Greeting Pack.

Handling the Purchase Experience Flow

Resuming the skill after Alexa’s Purchase Experience Flow is complete

Scenario 2: Customer has not bought the product and asks for a premium greeting.

Scenario 3: Customer has not bought the product and asks “What have I bought?”

Scenario 4: Customer has purchased the in-skill product.

Related Content

Automatic speech recognition

Contextual topic and dialogue act models

Sensitive-content detection

Conversation evaluator

CoBot

Understanding Intent Chaining

Chaining Intents with Dialog.Delegate

Chaining Intents with Dialog.ElicitSlot

Conclusion

Resources

1. Picking the Right Balance

2. Designing for Different Devices

3. Storyboarding

4. Creating Your Graphics

Related Content

Skill-Building Foundation

SkillBuilder Tradeoffs

Setting the Persistence Layer

Avoid Extra Dependencies

Not a One-Way Door

More Resources