Right now the process of adding a new language to an existing skill in the developer console is tedious, especially when the data for those languages is exactly identical.

For example, right now, the process for manually copying things on the Publishing Information tab (Launch tab on the new console) alone involves tabbing back and forth 12 different times between the two languages to copy the text from the six different fields. For an English language skill being released worldwide, that process has to be done 4 times (and that's only going to grow).

Making things worse, in the new console, each time you tab you also get forced into a "save" dialog even if you didn't change anything (as described here: https://alexa.uservoice.com/forums/906892-alexa-skills-developer-voice-and-vote/suggestions/33345916--unsaved-data-flow-doesn-t-work-properly) which further multiplies the number of manual clicks you have to make just to have a new language with identical configuration.

A "copy to (select locale)" option would be much preferrable.

Acknowledging that there are minor differences in the available intents between locales (US first name intent not available in India, etc), it would be reasonable to still do the copy but just notify the developer that their intent model needs fixing.

Currently, there is no way to accurately do automated testing of how user audio resolves (in terms of intents and slots) for a given skill.

At present, this testing is more-or-less done manually. There are several use cases where automation would be vitally important. Given:

-When testing a large skill, it is extremely cumbersome to manually test a wide array of sample utterances for every change we make to the voice model. This discourages iterative design.
-The overall Alexa voice model is constantly shifting. This is a good thing, but often this results in changes to how our skills launch utterances, one-shots, etc are resolved, and right now we have no way to do this testing on a regular, automated cadence.
-Testing a skill across a variety of voice types (varying gender, age, accent) is not something that we see done today, because the effort to manage something like that is considerable.

And, on a point unrelated to test automation, it would also be beneficial if we could have our users who are struggling with misfiring intents send us an audio clip of their voice and let us send that to this endpoint to see what's happening. Trying to reproduce a user's accent/pitch/prosody as a developer is (often comical, but) not particularly helpful.

All of these cases could be resolved by:
1. An endpoint within the SMAPI or some other similar REST service; which,
2. Accepts as a POST request an audio file in a specified format;
3. Along with whatever request metadata might be relevant; as well as
4. A parameter in the path or body that specifies the id of the skill under test; and
4. Returns a JSON object with the exact Alexa request that would've been made to the specified skill

Ideally this API could also have a mechanism for dealing with things like sessions and dialog management (and how the intent resolution may change in that state), but the 90% case could be easily covered by a simple "isNewSession" flag that lets us emulate both one-shots and open session requests.

It's worth noting that we've actually tried (with some success) to solve this problem on our own - to middling success - via AVS. The functionality just does not exist for this to be addressed by third parties, unfortunately. A description of our feeble attempt can be found here: http://www.3po-labs.com/blog/a-proof-of-concept-and-its-roadmap

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)

Currently all skills must run through Amazon’s Natural Language Understanding and provide a language model to Alexa. While this is helpful for getting started, many more advanced features for Language Processing and response building benefit heavily from having the user’s speech accessible to perform more complex operations like sentiment analysis, conversation reconstruction or custom natural language processing through models on other services. This allows developers to deliver a richer experience to users through the additional processing it makes possible.
For my use case in specifically it would be acceptable to have an option in the console to disable the language model and only receive the speech transcript in requests, and I think there are other developers who would benefit from this as well. Currently to get access to an approximation of the raw speech requires a basically empty language model, which works but suffers in performance.

Why have you hidden the Skill ID away onto the dashboard. When I'm updating to a new Lambda version and pasting in the endpoints, I then need to skill to set at lambda, which means I need to go to the dashboard page. Please make it available like it was on the old console.

Also, please please please, lets have some simple debugging logs and testing of execution for the Lambda.

Just a little test button next to the endpoint where it fires off something (discovery?) (SmartHome Skill) just to make sure it can execute the Lambda, between the permissions issues and region issues it's way to easy to get something wrong and it not work for an unknown reason.

Like wise, some error logs please (real time, not 36 hours delayed!). Esp for development skills. I've had skills not work because I set the wrong lambda version's skill (application) ID, and because of wrong region and working skills fail because the refresh token errors on my server, I was left with no clue bit to try all sorts of things to guess what was going wrong. It's mighty painful.

Testing: The test page is way confusing, and given I'm using a smart home skill it should be possible to just have a few buttons (send discovery, send turn on, turn off, etc), I can't even figure out where to begin with the test page as it is at present.

Better feedback in the Alexa development website as well please (alexa.amazon.co.uk), information on the devices discovered etc.

Thanks,

Steve.