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.

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.

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!

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)

Room awareness enhancement: add popular device types such as Fan, Air Conditioner, Set-top-box and let users change device type to their favorite. Now Alexa app allows changing device type between Light and Switch for some smart plug devices. But it would be great if for any device, users can define it as light, fan, air conditioner or set-top-box... and the room awareness feature will help simplify voice command. Users just can say: turn on the air conditioner, turn on the fan...
This device-type-changing feature will be very powerful when an infrared/RF universal remote control like Broadlink is connected to alexa. All traditional “dumb” devices can be voice controlled by alexa taking advantage of the room awareness feature.

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!

We would like to use this, but can't because the rules are too restrictive.If a user is asked about what they want info about, they should not be forced to say "tell me about Point Defiance Zoo". They should be able to say "Point Defiance Zoo" with no leading phrase. Instead of forcing us to use a leading or trailing phrase, please allow the use of just {query} (without 'search for...' or other text around it as in the example below:
{

    "name": "SearchIntent",

    "samples": [

      "search for {Query}",

      "find out {Query}",

      "search for {Query} near me"

    ],

    "slots": [

      {

        "name": "Query",

        "type": "AMAZON.SearchQuery"

      }

    ]

  }

The audio player interface allows playing from a streaming service - e.g. a radio station
This is a continuous stream that could run for many hours - but the skill is only given the opportunity to provide song information at the start.
It could respond to user requests - such as "What song is this?" (which is OK) but, primarily for devices with screens, it would be useful for the skill to be able to provide title/subtitle/graphics as the songs change within the continuous stream.

This could be done by having the Skill start the audio stream with a duration parameter which would result in a callback when it is about to be reached - similar to the PlaybackNearlyFinished request.
The Skill could then send new metadata (potentially with an offset to say display in X seconds) and with a new duration parameter.

An alternative approach that could work without any skill being developed at all ...
If the player automatically took the metadata from an ICY stream (as provided by Shoutcast / Icecast servers) then it would be a good alternative - especially if the skill to parse a regex that should be used to parse the ICY title - with a default that would handle "artist name - song title" which is what many internet radio stations use (and StreamURL for the image).
For example ...
Playing http://www.dandelionradio.com/DandelionRadio.pls.

Name : Dandelion Radio
Genre : Alternative
Website: http://www.dandelionradio.com
Public : yes
Bitrate: 128kbit/s
ICY Info: StreamTitle='Rocker: D. A. Stern - Isn't It Obvious?';StreamUrl='http://www.dandelionradio.com/images/drlogosq-black.jpg';