PROBLEM: Forcing a user to remember a skill name is counter-intuitive, bad experience and leads to low adoption rates.

Examples :
Alexa, tell Agent NEO to find my Home Value
Alexa, tell Harmony to turn on my TV
Alexa, ask AllRecipes for a Pasta Recipe

Proposed Solution:
Alexa, find my home's value (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, turn on my TV (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, find a Pasta Recipe (Alexa knows that the skill AllRecipes that the user has enabled, can handle this intent)

All Alexa has to do to achieve this is, scan through the intent handlers of the skills the user has installed. Then simply pass the command to the correct skill. This is so much smoother than having to tell Alexa to tell a skill name to do something.

Google home introduced this feature a few months ago and it works so seamlessly.

The current flash briefing content (per provider) is a 'one size fits all approach'. Everyone gets the same NPR briefing, for example.

There are many use-cases where user-specific information could be very powerful in the flash briefing, often in concert with interactive skills. Some examples:

• A sport team skill that (in the flash briefing) reminds you of your game time this weekend (or of changes), without you ever having to touch a calendar




• A retailer skill that (in a flash briefing) advises of significant deals, relevant to your buying history or explicit 'watch list'.

I think this would take flash briefing content 'to the next level'.
Please consider!

Using timer trigger for this will help. Currently, you can only achieve this by defining a specific time.

This is especially useful for devices that would normally be set to the default position of "on" and I don't want to forget that I temporarily turned it off.

Alternatively, you could give us the ability "if off, turn on in 'x' minutes".

Also useful because default position in most switches is 'off' after power outage. Right now, I'm running a 'turn on' once per hour in case of power failure.

I'd really like to get it down to 10 minutes but that's simply too much manual config with no easy copy/paste.

Problem:

When an audio streaming skill is actively streaming/playing, users of the skill have to re-open the skill in order to issue additional commands. This creates a very awkward user experience, for example:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, ask AnyPod to play the oldest episode"

<oldest episode starts playing>

"Alexa, ask AnyPod to fast forward 3 minutes"

<episode fast forwards>

"Alexa, ask AnyPod to <etc>"

--

Solution 1:

Ideally this interaction would go like this:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"AnyPod, play the oldest episode"

Having "AnyPod" (the skill's invocation name) substitute in as an alternate wake word would be great. But of course you'll never do that in a million years, until in a few years from now when you actually do. So how about this as a compromise in the meantime:

Solution 2:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, play the oldest episode"

This will require some clever engineering to determine whether the user is said something that maps to a valid intent within the active audio streaming skill's invocation model - and if not, handle the request the same way they are currently handled. That seems reasonably doable.

It does create potential problems where an audio streaming skill may have an intent that conflicts with the invocation name of another skill -ie, the user may wish to open another skill but find that the audio streaming skill "hijacked" their request because the invocation name for the other skill triggered an intent in the audio streaming skill. But, that problem is solvable a few different ways - put greater restrictions on the intents that can be accessed in this scenario, for example:
a "catch all" intent with nothing but a custom slot could not be allowed

any intent with words matching the invocation name of existing skills would not be allowed (they would be allowed during normal skill usage, but not in this more restricted context)

I would like my skill to be able to listen for specific responses, i.e. make Alexa bias towards utterances of one or multiple intents that I specify in the skill's response, for the next user input.

For example, let's say my skill has a CityIntent which has utterances:

• I live in {city}


• It is {city}


• {city}

And my skill has another MovieIntent which has utterances:

• I like {movieType}


• I prefer {movieType}


• {movieType}

And at certain times my skill may also expect {yes/no} answer from user.

Since {city} and {movieType} have different value, Alexa usually does a good job of figuring out which intent should be mapped.

However, sometime the single word utterances are incorrectly mapped to wrong intents, and there's very little or hacky way for my skill can cope with such cases.

Therefore I want my skill to have the ability to specify what the NEXT intention user is likely to make, at any point during conversation. Then Alexa can bias the listening towards the likely utterances and map to the correct intents.

I have looked into DialogModel, however it doesn't seem to be applicable because it doesn't allow switching intent, i.e. my code cannot be handling MovieIntent and then request Alexa to ElicitSlot for CityIntent.

Thanks!