Add contexts, provide another layer of routing for intents about alexa-app HOT 14 OPEN

I've taken a slightly different approach to this problem.

With a very simple change that adds routes to the schema object and app.route as a top level app object (merely to keep the style consistent), I can route intents to different functions, based on a __STATE__ session variable.

This leaves intents responsible only for routing, and routes responsible for the output and user flow. A route can also be re-used in different intents.

app.route('mainMenu', function(request, response){
  response.session('__STATE__', 'mainMenu');
  response.say('Do you like rock music?');
});

app.route('artistType', function(request, response){
  response.session('__STATE__', 'artistType');
  response.say('Do you like The Clash?');
});

app.route('albumName', function(request, response){
  response.session('__STATE__', 'albumName');
  response.say('Do you like London Calling?');
});

app.launch(function(request, response) {
  app.route.mainMenu(request, response);
});

app.intent('YesIntent', {
  'routes': {
    'mainMenu': 'artistType',
    'artistType': 'albumName'
  },
  'utterances':[
    'yes',
  ]},
  function(request, response) {
    var state = request.session('__STATE__'); //e.g. 'artistType'
    var func = this.schema.routes[state];
    app.route[func](request, response); //e.g. call app.route.albumName
  }
);

Now, when YesIntent is invoked, it calls the correct route function based on where the user came from i.e. the last __STATE__.

To make it cleaner, setting the __STATE__ session and calling the correct route function could be handled automatically by alexa-app in the routes and intents -- the idea being to keep the default behaviour the same and fallback to the normal intent function call if no routes are defined.

It feels a little more straight-forward than nested contexts, and this demo functionality only required a couple of one line changes to alexa.app.

What do people think of this type of approach?

from alexa-app.

I like the idea of this and I am interested in seeing what you come up with.
What comes to my mind is that this more of a state machine, and you want to map the request to code that is written to handle a specific state.
So, the intent may be YesNoIntent, but under condition X, it is in state Y, so you write code to handle state Y. That way, multiple conditions or intents could be mapped to the same state. How you define the conditions might be configurable, or might be code-driven. It could be based on session data, or time of day, or if today is a holiday, etc.
This came up to me because I was thinking of writing a "princess story" app for my daughter to play with. For that, there would be many yes/no responses or other single words, but depending on where she is in the story, it would generate a different response. So I would need a way to track where she is, and what she said, and decide what state that puts me in. That can be done in code manually, like you point out, but an abstraction to make it easier would be great.
Instead of a fork, do you think this could be an add-on module? Or depending on what you come up with, merging it back into the core module might be fine.

from alexa-app.

Cool, I'll keep you updated. The context definitions could certainly be expanded to support more complex matching patterns. A string means a simple "context", but a method could manually define the parameters that qualify the state. That'd be an easy thing to expand later without breaking this initial simpler implementation.

I'm not sure how I would write it as an addon as I'm not familiar with how you've set up the module to accept addons.

Another pattern I am considering is based on the Mocha test patterns, which has a nice organization to it:

app.context('AreYouHappy', function() {
    app.intent("YesIntent", function(req, res) {
      // User answered "Yes" to "Are you happy?"
    }

    app.intent("NoIntent", function(req, res) {
      // User answered "No" to "Are you happy?"
    }

    app.intent(null, function(req, res) {
      // User used an intent that valid for this context. We could provide a prompt clarifying the options
    }
})

Pros and cons to each. This version groups the contexts together very clearly which I like. It could also support nested contexts which could make very complex conversational apps (perhaps like the one you outlined) even easier to organize...

from alexa-app.

I have been doing something similar by storing a "lastIntent" session variable and then checking it in my handler. It works well but I would also be interested to see how a built in context handler might impact code conciseness.

from alexa-app.

+1 for the hierarchical context callbacks. This maps well to how I conceptualize the problem. The intent handler only makes sense from within the context. Also this provides the bonus ability to initialize a local scope that is common to all intent handlers within a context:

app.context('AreYouHappy', function() {

    var contextInfo = getContextInfo();

    app.intent("YesIntent", function(req, res) {
      // User answered "Yes" to "Are you happy?"
    }

    ...
})

from alexa-app.

This is something I'm looking for too. Looks like some great ideas here.

from alexa-app.

I'm thinking of a structure like this. I think I can make it actually function. I've been racking my brain trying to come up with a code structure that could (a) represent a conversational structure in the code, and (b) execute correctly on each call, based on previously-established context. This is very difficult.

app.map(function() {
    say('do you want a pizza?');
    if (intent('yes')) {
        say('do you want extra cheese?');
        if (intent('yes')) {
            say('do you want pepperoni?');
            if (intent('yes')) {

            }
            else if (intent('no')) {

            }
        }
        else if (intent('no')) {

        }
    }
    else if (intent('no')) {

    }
    else if (intent()) {

    }

from alexa-app.

Here's a very rough POC of how code like this might function: https://jsfiddle.net/8b4zg4ft/
Any thoughts?

from alexa-app.

I find that structure very difficult to read. The branching on any app that requires more than a simple yes or no (good apps should allow the user to specify stuff out of order) would become out of control quickly.

I think the app.context method proposed a couple times earlier is a bit more flexible and organized.

from alexa-app.

I was trying to make the code kind of model the conversational structure of a skill. But if the skill requires more complicated branching like more of a FSM, then this definitely wouldn't work. I think that defining separate contexts and intent handling within them is fine, you just lose the logical nesting that makes code like my example easy to follow. Let me ponder it a little more. I think we can get a little better than the one-level flat context/intent mapping and create some kind of structure that better represents the flow. Maybe.

from alexa-app.

This feature is implemented in in alexia - similar framework for handling Alexa requests (for those who are interested)
See actions section in https://github.com/Accenture/alexia

from alexa-app.

Just adding my 0.02c but I wonder whether this can be implemented on top of alexa-app. It's fairly opinionated and is not how Amazon dictates authoring intents.

from alexa-app.

If anybody is keen on something like this, I think its worth pointing out this feature request in the forums that would actually make this feature useful.

Worth giving it a thumbs up if you have a chance

from alexa-app.

@h0lmie do you have a gist of how you accomplished this? i'm looking at trying todo the same thing.

from alexa-app.