Feature Proposal: Conversational Components

[Kaan_Kilic]

Thanks for the feedback Mark!

Is upppercase (PHONE_NUMBER) the convention or could I as a developer create a component called PhoneNumberUSComponent?

There is no convention. You can name components as you like.

Would the pair work inside a state? Do you foresee a situation where the delegate can be in one state (or no state) and the completed handler in another state?

I think there has to be made some small tweaks for it to work in a state, which should be fairly easy to implement. As for one of them being inside a different state, I am not sure about the amount of work it would take. I also don’t really see a scenario in which it would be useful. The typical scenario I have in my head would be: Inside State A, delegate to a component. Receive the response inside the CompletedIntent inside the same state and route to what ever state you want from that point on. Do you have one in your mind?

Is the component name used by the class, in the useComponents statement, in the call to delegate, off of this.$components and elsewhere just convention? How is it enforced?

There is no naming convention. You have the possibility to specify the component’s name inside it’s name property (which might actually better fit into the config now that I think about it). If there was no name specified the framework will use the constructor’s name (in the example’s case PHONE_NUMBER). The component’s name will be used to reference the component from that point on, whether in delegate or with this.$components. It’s not currently implemented, but if you try to access it with a wrong name, you will simply receive an error.

In app’s config.js, can other component values be set and used throughout the component? For example, the count of fails before the component switches to sequence mode?

Yes, that’s possible.

Example:

module.exports = {
    components: {
        PHONE_NUMBER: {
            numberOfFails: 3
        }
    }
};

You can access the component’s config, outside and inside the component, using this.$components.componentName.config

Does the config for the component get merged into the config for the app? In this example, the IntentMaps?

The config inside the component is used as a default configuration provided by the dev. The changes you want to make to that default config will be made inside the app’s root config file, just like the example above.
The changes made in the root config are merged into the component’s default config.

The intentMap is handled a little different. The component’s intentMap is never merged into the app’s one. If a component is active, it’s intentMap will be used, else the app’s one.

Will the component configs honor stages? config.js, config.local.js, config.dev.js, config.test.js, config.prod.js?

Yes, since you make changes to the component’s config using the root config files, the staging feature you already use will work here as well.

Will the component model also follow the main Jovo model (not platform) with the ability to be named en.json and then have it properly merge out into en-US, en-GB, etc. based on the setting in project.js?

  alexaSkill: {
    nlu: {
      name: 'alexa',
      lang: {
        en: ['en-US', 'en-GB', 'en-IN', 'en-CA', 'en-AU'],
      },
    },

Not implemented yet, but should be possible.

How will differences in available built-in intents or slots be handled in a component that is to be used in multiple locations?

Difficult to answer, since it would be different for each component (e.g. amount of work to abstract it for every location).

Should every intent for a component be in a STATE? For example, the root of the PHONE_NUMBER component has Yes and No intents. Using this component in a skill that also has Yes and No intents would be problematic. Maybe the START handler is outside of a STATE but everything else is in one?

Yes, I agree. In the updated version everything is inside a state.

I currently have an implementation that has 2 different intents for numbers. One uses AMAZON.Number slot type and the other AMAZON.PhoneNumber. Because of Alexa’s lack of Intent Context, I have to include both intents in the state when asking for a phone number because sometimes one is chosen over the other. This same thing can happen with AMAZON.Time. All will need to be included that are also included in the main component because the language model is one.

I can see, how that could be a problem, but I’d say that’s a problem that can’t be addressed on framework/component side. Do you have an idea?

Any STATE in a component should have an Unhandled and FallbackIntent (maps to AMAZON.FallbackIntent). Often a StopCancelIntent (maps to AMAZON.StopIntent and AMAZON.CancelIntent) is also useful.

Yes, I agree. In the case of Stop and Cancel, the current idea is to send out a response (specifying the status as rejected) and routing to the onCompletedIntent at which point the dev can take over.

When I have handled phone number in the past, I have checked if it is valid and sent the user back to re-enter before asking to confirm: Ask, Validate, Confirm

I prefer Ask, Confirm, Validate, but I’m open for discussion.

I also handle the US situation when a user gives a 7-digit phone number instead of 10, it is assumed they forgot to say the area code. They are then prompted for the area code. This will be different in different countries.

Good idea. Might implement that in a further version.

I could see US_PHONE_NUMBER and INTL_PHONE_NUMBER components

If one went that route, it might make sense to split each component into multiple for each location, e.g. US_PHONE_NUMBER is its own component and DE_PHONE_NUMBER as well.

Is the component outside the main src tree because the idea is that component would be separate npm modules?

There’s no real reason, as far as I know.

Can we use removeState, followUpState, toStateIntent, and toStatelessIntent in a component?

Yes, should be possible.

Thanks again for the feedback! There should be an updated version of the phone number example out soon.

[marktucker]

If given permission, I can get the user’s mobile phone number using:

const mobileNumber = await this.$alexaSkill.$user.getMobileNumber();

This can then be used in the PHONE_NUMBER component to first validate (does it exist) and then use as a default value:

USER: Send me a text
ALEXA: Would you like to send the info to 555.867.5309?
USER: No
ALEXA: What phone number should I use?
USER: 555.555.5555
ALEXA: You want to send the text to 555.555.5554. Correct?
USER: No
ALEXA: What's the phone number?
...

There needs to be a way to pass the default phone number.

Option 1

// options param, completion handler
const options = {
  defaultPhoneNumber: '555.867.5309'
};

this.delegate('PHONE_NUMBER', 'CompletedIntent', options);

Option 2

// options param only
const options = {
  defaultPhoneNumber: '555.867.5309',
  completedHandler: 'CompletedIntent'
};

this.delegate('PHONE_NUMBER', options);

Option 3

// pass to $components
this.components$.PHONE_NUMBER.$params.defaultPhoneNumber = '555.867.5309';
this.delegate('PHONE_NUMBER', 'CompletedIntent');

Which option do you think is better?

[jan]

Option 2

// options param only
const options = {
  defaultPhoneNumber: '555.867.5309',
  completedHandler: 'CompletedIntent'
};

this.delegate('PHONE_NUMBER', options);

I like this one best! Maybe not every component will have a completedHandler, so making this part of the options makes sense to me

[renatoalencar]

You can use an Entity for this. You can build an entity with all the known values of possibilities you would use and create an intent the receives only that value.

But, I highly recommend you, that for no screen devices, to not prompt more than two options to the user. It can turn to be complicated to both the user and you.

[Marko_Arezina]

@renatoalencar I agree that overloading the user with options makes for a poor experience. However sometimes giving a list of choices is appropriate. For example listing products or article titles.

Allowing the user to select an item by name instead of ordinal value improves this experience. However, when you are pulling data from an API it may be hard to list all the possible entities since they can change frequently and have highly varied values. Alexa has support for Dynamic Entities which might do the trick, however I haven’t found something like that for Google Assistant.

[renatoalencar]

You can use the automated expansion option, if you want to try to generalize your entity.

[jan]

I’d love to see a Google Calendar Integrated Scheduling component

By the way, this is in the works Thanks for the great suggestion.

cc @Kaan_Kilic

[Andre]

I am struggling with the language model merge. I am using de-DE.js files (with the proposed component structure) but the jovo build command won’t merge my component model. I also tried switching to “*.json” files - no difference.

[jan]

The merge-feature is still in development (cc @rubenaeg). Right now, you have to merge by hand. Working on improving the whole process!