handle intents with states

[janevin]

Hi Guys,
I have a design question about using the sdk.
Let’s say we have 2 states: MakePaymentState (with MakePaymentIntent, IntentA, IntentB, HelpIntent and UnhandledIntent) and AccountInfoState (with AccountBalanceIntent, IntentC, HelpIntent, and UnhandledIntent).
If I am in the MakePaymentState and I say something like “what’s my account balance”, it maps to the UnhandledIntent.
But if I am in the AccountInfoState and I say something like “what’s my account balance”, it maps to the AccountBalanceIntent correctly.
And I don't want to add my AccountBalanceIntent to the MakePaymentStateHandler, because it's not related to making a payment. And I shouldn't stop user to say anything at this point.
Do I use state management correctly? If yes, how can I trigger an intent in another state automatically (or with an easier way)? Should all intents within all states be available to be mapped to at any time?

[tianrenz]

Hi @janevin

If the skill design allows the possibility that user might invoke "AccountBalanceIntent" in either state, then it's good practice to include "AccountBalanceIntent" handler in both states.

You can easily forward intent using the following code:

// In MakePaymentState
"AccountBalanceIntent" : function() {
    this.handler.state = "AccountInfoState"; // Switch state
    this.emitWithState("AccountBalanceIntent"); // Invoke the "AccountBalanceIntent" in "AccountInfoState"
}

The user interaction design is very important. In any state, the provided state handlers should take into account all possible invocations from user, and provide necessary routing logic with this.emit() or this.emitWithState().

Regards

[janevin]

It works. Thanks @Amazon-tianrenz .
If there are more than 50 intents which are "similar" to AccountBalanceIntent, then I need repeat the above code 50 times in the makePaymentState. And it applies to all other states too.
For a small project, it works great. But for a complex chatbot(over 100 intents), is there any better way to handle this?

[tianrenz]

Hi @janevin,

The concept of Stateis to provide a conversational context so that your skill "knows" what the customer response is referring to. For example, user can answer yes/no to different questions and they will all map to the same Amazon.YesIntent/Amazon.NoIntent. Skill then needs a way to tell what question that customer is answering to.

Often times if you found skill reusing lots of similar intents in multiple state, it might be a good idea to reconsider the skill design and have a different set of states to manage user flow. Maybe putting all reused intents in same state handler and invoke them by changing the state? (exp: put AccountBalanceIntent in a "CheckBalanceState" handler?)

Nonetheless, your question brings a interesting concept: it might be useful to have a "baseState" handler that can be accessed from different states or, for the lack of better words, an "intent inheritance" concept. We are actively seeking for new and better design ideas for our SDK. I've created a backlog item to evaluate the potential benefit of this feature internally.

Thanks for you interest in Alexa Node.js SDK. Hope you have a great skill dev experience!

[talkingnews]

it might be useful to have a "baseState" handler that can be accessed from different states or, for the lack of better words, an "intent inheritance" concept.

I completely agree - @Amazon-tianrenz 's idea seems like such a good one, I've created a Uservoice item you can vote on! https://alexa.uservoice.com/forums/906892-alexa-skills-developer-voice-and-vote/suggestions/32306572-intent-inheritance-with-a-basestate-handler

[tianrenz]

Hi all,

Thanks for your support for the SDK. We've released ASK SDK v2 for Node.js yesterday, which aims to address many of the issues here. We encourage you to check out our wiki here.

[fluxquantum]

Hi, tianrenz thank you for spending time to response to this thread, is there documentation that explains how to use state handlers with the newest version of the ask-sdk?

[tianrenz]

Hi @fluxquantum ,

In the v2 SDK, you can use any attributes as one of the matching condition in your canHandle logic. This allows to you define even more complex skill state.

I would recommend to check out this sample here which uses gameState to manage state handlers.

Regards

[fluxquantum]

Thank you for the prompt reply. Based on the usage of:
const attributesManager = handlerInput.attributesManager;
const sessionAttributes = attributesManager.getSessionAttributes();

Is the Alexa.CreateStateHandler no longer compatible / deprecated with v2?

[yadavsulekha]

Hi @janevin,

The concept of Stateis to provide a conversational context so that your skill "knows" what the customer response is referring to. For example, user can answer yes/no to different questions and they will all map to the same Amazon.YesIntent/Amazon.NoIntent. Skill then needs a way to tell what question that customer is answering to.

Often times if you found skill reusing lots of similar intents in multiple state, it might be a good idea to reconsider the skill design and have a different set of states to manage user flow. Maybe putting all reused intents in same state handler and invoke them by changing the state? (exp: put AccountBalanceIntent in a "CheckBalanceState" handler?)

Nonetheless, your question brings a interesting concept: it might be useful to have a "baseState" handler that can be accessed from different states or, for the lack of better words, an "intent inheritance" concept. We are actively seeking for new and better design ideas for our SDK. I've created a backlog item to evaluate the potential benefit of this feature internally.

Thanks for you interest in Alexa Node.js SDK. Hope you have a great skill dev experience!

Hello @tianrenz - How to know which question's answer is 'YES/NO' when you have Multiple intents where work forward on the basis of Yes and No.