The current [i]"open "[/i] / [i]"exit"[/i] workflow is cumbersome and annoying when you forget to exit an app and ask for a built-in intent (such as asking for the weather). As this would be the largest impediment to application user experience, what is the plan here for the future? Will there be a way to specify an intent as "global" so that the user can run it without needing to open a session with the app?
For example, I just built a "How long is my commute to work?" intent. Let's say my morning routine is to check the traffic time and weather - that's currently a ~40 second workflow (
https://www.youtube.com/watch?v=NXQCYBXZhCQ). For apps to take off I see global intents as a "must have".
Hey Tim I agree that the UX paradigm of Open/Exit is cumbersome and it belongs to Desktop applications of the last decade :) Having said that, you can send a session close message after the first your first Intent. ie ￼User: "Alexa Open Artisan and tell me what's my commute like this morning" Echo: “Your commute looks...” --> send close session tag. Done Not ideal but it works... I hope the final solution is that once a user install an App the "Launch Name" cold be the the in the action/intent. Likes this: App name: Artisan. Launch Name: "commute" User: "Alex, what is my commute like this morning" Echo: “Your commute looks...” --> send close session tag or not... As long as the user has Artisan app install all "commute" questions will be routed to Artisan's service. I'm might be missing something with this logic, like app developers creating very generic "Launch Names" that will generate requests that don't belong to the service... for example: "Alexa, define commute"...but again in this case the Launch Name is define.. Toughts?
That's certainly a creative workaround! Totally feasible but would be a little frustrating as a developer to need to create a new app for each unique intent you wish to support. I could see either method having a permission system of sorts, so when installing the application from within the companion app it would prompt: "This app reconfigures the [i]commute[/i] and [i]distance[/i] trigger words. Do you wish to allow this?" Message was edited by: Tim Arnold
Thank you'll very much for the feedback, As Noel mention we do currently support one-shot invocation for applications, example: "Alexa, Open <[b]launch name[/b]> and <[b]sample utterance[/b]>” which will work for any intent with the applications intent schema. Tim i also wanted to mention that this is a built in feature and no need to specify a new app for each new intent. Example, "Alexa, open [b]artisan[/b] and [b]what is my commute this morning[/b]” should work for your application, as well as any other sample utterance that you have in your intent schema. The UX paradigm, is still a work in progress. We will incorporate your feedback to drive future efforts. Thanks again!!
I agree with Tim, the biggest thing holding me back from doing any serious development is having to say "Alexa open app and do something". Almost all of the functionality I want to build is a single user interaction and the functionality that does require back and forth from the user still fells odd to have to start it with "open". I'd much rather have a keyword that starts a session instead of having to open an app, similar to the flash briefing when a user says "Alexa, what's new" and then they can say "Alexa next" because they are in the context of the flash briefing.
I echo Tim's sentiments - definitely want a way to make more "natural" sounding commands. One tactical change which would be awesome is to support the following phraseology: "Alexa, tell to ” This makes for a much more natural conversational flow, especially with apps designed for home automation - eg: "Alexa, tell to " Now I realize there is phrase conflict with existing commands, eg "Alexa, tell me the time", but given that there is a fixed list of apps enabled on any given device, it wouldn't be too difficult to search for a prefix match against "tell to", and in the absence of any matches, delegating to the original command interpreter. A global intent routing/filtering system would be ideal, though it has some very interesting design challenges. Would it be possible to organize a tech talk from the echo dev team on how the current command interpreter works and how they handle probabilistic NLP?
Also hoping to see some sort of "global intent" in the near future. I'll admit to being a little disappointed on downloading the SDK to not see it :-( For me the biggest thing Echo needs is integration into lots of other ecosystems, and that needs to be seamless. The "Open FOO" is good for development, but not an app model for the future. Everyone wants to say "Tell me when Game of Thrones is on?" and no one wants to say "Open HBO and tell me when Game of Thrones is on?". Of course, global intents are hard, and cause lots of problem when they conflict. I wrote a simple app to tell me the temperature of my hot tub, but any mention of temperature tends to get routed to the weather service in the Echo. Perhaps routing to the "best match" is possible? Alternative, multiple services could be queried for a response and best, valid, response could be the one used? This would require services to have no side effects of course (mentioning temperature without a good degree of confidence in the request probably shouldn't turn the heating on) or at least flagged themselves as such. Anyway, random musing from a first day's playing with this.
> Of course, global intents are hard, and cause lots of problem when they conflict. I wrote a simple app to tell me the temperature of my hot tub, but any mention of temperature tends to get routed to the weather service in the Echo. I agree this is a difficult problem to solve in code, but I wonder if the issue can be best solved with a human-in-the-loop. I didn't happen to see if this is documented, but I imagine users will have the ability to select which applications are available to their echo. If that's the case, then perhaps the user also selects either 1) which application gets priority, 2) some samples utterances that they would like to say to interact with that application, or 3) the ability to completely disable other applications, like the weather app.