Settings and activity
16 results found
-
1 vote
Craig Walls
shared this idea
·
-
4 votesCraig Walls
supported this idea
·
-
101 votes
Thank you very much for your patience. Your comments and votes are greatly appreciated. While we cannot promise each feature request will be implemented our team reviews each request and sends them to the appropriate product teams.
An error occurred while saving the comment Craig Walls
supported this idea
·
-
1 voteCraig Walls
shared this idea
·
-
1 voteCraig Walls
shared this idea
·
-
1 voteCraig Walls
shared this idea
·
-
6 votesCraig Walls
supported this idea
·
-
436 votesCraig Walls
supported this idea
·
An error occurred while saving the comment Craig Walls
commented
Some skill interactions last longer than a simple utterance or even a dialog. For example, let's say that a skill has been created to act as an interactive guide to a National Park. The user may want to interact with that session for several hours while they explore the National Park, asking for information about the areas of the park they are at.
For extended sessions with a skill, it should be possible (given user permission or a specific invocation phrase) to keep a session open without the skill leaving the microphone open and without the user speaking the invocation name on every interaction. It should stay open until the user explicitly closes the skill or some extended timeout period (say, 24 hours).
E.g., if they are in Yellowstone, they may ask for information about Old Faithful, and then as they walk further down the trail ask for information about Grand Geyser, and then a little later ask about Morning Glory Pool. After leaving the Upper Geyser Basin, they may arrive at Mammoth Hot Springs an hour later and ask about some of the features there. In this case, they could start their experience by saying "Alexa, open Yellowstone Guide for an extended session" and then until they explicitly say "quit" (or some other utterance triggering the stop intent) they can ask questions without saying "Alexa" every time.
-
8 votesCraig Walls
supported this idea
·
-
1 voteCraig Walls
shared this idea
·
-
2 votesCraig Walls
shared this idea
·
-
3 votesCraig Walls
supported this idea
·
-
5 votesCraig Walls
supported this idea
·
-
70 votesReceived · 10 comments · Alexa Skills - Developer Voice And Vote » Built-in Intent / Slots · Admin →Craig Walls
supported this idea
·
-
29 votesCraig Walls
supported this idea
·
An error occurred while saving the comment Craig Walls
commented
I'd like to up-vote this request. I do understand the reasons why changing the name is discouraged for live skills. But it would be helpful for some cases. Let's say, for example, that you have published a skill with a certain invocation name and discover later that name is problematic...perhaps it is commonly misheard by Alexa (my situation) or potentially conflicts with another live skill. You come up with a new, better, and less problematic invocation name. But the only option currently is to abandon the previously deployed skill and redeploy with a new invocation name. It would be helpful if you could change it to remedy the issue. Maybe limit it to one name change per live skill so devs don't abuse this option and maybe force it through certification again.
-
59 votesCraig Walls
supported this idea
·
I can think of several use cases for proactive events that aren't covered by the current limited set of schemas. I can see value in having specific schemas that may uniformly notify users of certain situations (weather, for example), so the current set is good. But a generic schema that can be used for anything that the current set doesn't cover would be extremely useful, enable developers to create skills that are more useful to their users, and ultimately create more value to customers and to the Alexa platform.
Also, as a side request, I'd like to see proactive events be able to target a specific device. Unless I'm mistaken, proactive events currently target either a single user or broadcast to a set of users, but not to a specific device. That's fine for many use cases, but I can think of some where it would be best to target a specific user's device with such a notification. (Specifically, I'm thinking of users using mobile devices such as their phone or TalkSocket who want to receive a notification when some event takes place and they are away from home, but do not necessarily need it sent to all of their devices at home.) Reminders and timers can (and must) target individual devices this way, including mobile devices (I know, I've tested it). It'd be nice to see this for proactive events, as well.