Dustin Coates in Alexa

AWS re:Invent Day 3 Notes

AWS re:Invent day three has been the best so far, with a fun workshop and Alexa-specific announcements. Today’s schedule saw Echo buttons, skill permissions, and monetization (and more).

Build a Game Skill for Echo Buttons

This has been my favorite session so far. If you attend re:Invent, I recommend the workshops. Listening to presentations has been great, but there’s nothing better than getting to pull up your text editor and coding along. I’m going to have a very detailed post about this soon and will give you the highlights now.

Alexa (and voice-first in general) is going multi-modal. There’s the Echo Show and Fire TV, plus Google’s announced integration between Home and Chromecast. Adding screens has added a new mode of receiving information (even if you can touch the Show screen, I don’t think people often do). Buttons are a new mode, and they’re all about user input. They’re geared toward games—I believe it came from the games group—but aren’t limited to the diversionary. This isn’t limited to the Echo Buttons, either. As they did with Alexa proper, the Gadget API is open to third party builder to builder their own input devices.

Two new core concepts are the game engine and gadget commands. The game engine listens for input events from the buttons. The gadget commands that control the buttons. The team was clear that right now they control lights on the buttons, but this is a generic interface that can later be used for many types of control.

(A general note that doesn’t fit in elsewhere: the dev simulator doesn’t currently work with buttons and will error out if you try. The CLI also doesn’t support the new interface. I imagine both will be fixed by the time there is a general roll-out.)

Listening for the buttons involves GameEngine.StartInputHandler specifying a timeout (how long to listen for gadget interactions), proxies (gadget identifiers), recognizers (conditions that the gadgets may match at any given time), and events (where recognizers are grouped together that trigger an action from your skill when all of the recognizers are matched). This must be done before the buttons can begin go interact with the skill.

Setting lights on the buttons is done through the GadgetController, specifically GadgetController.SetLight. You can specify:

  • Animations
  • Blending of colors
  • Triggers for the lights
  • Different configurations can be sent to different buttons (the example that the Amazon team gave was a button for the player who answered correctly now has a different light and trigger because they’re in a “bonus” state)

Perhaps the biggest new piece of information is a change to the behavior of ShouldEndSession. This is the new behavior:

  • true: unchanged; closes sessions
  • false: unchanged; keeps microphone open
  • undefined/null: new; doesn’t keep the microphone open, but listens for button events

I’m excited about the new gadget API. Do I see myself using it all of the time? Not at the outset, as I’m not much of a games guy. But I could see this extending beyond just games into useful new interactions. The one thing that might be holding users back from using it more often or developers baking it in for general interaction is that the buttons sleep to preserve battery and must be woken up and re-connected to a skill if enough time has passed. An understandable trade-off.

Handling Alexa Permissions to Build More Personal Experiences

This session had a lot of questions from attendees, so you could tell it resonated. It was around using Alexa and IAM permissions for skill building. It was more conceptual, which was a good balance for the people in the crowd.

This information is covered in-depth on the official Amazon site, so I’ll focus on a couple items that were mentioned that may not be there, concerning the permissions framework and how permissions work with skills that are used without explicit enablement.

The permissions framework covers device address and lists right now, but it’s a framework. It can be extended. The presenters gave no indication about which new permissions might be added, but I found it interesting that they mentioned this without prompting. I hope this hint point toward more information available for developers.

Permissions are revoked when a skill is disabled by the user. But what about the recent announcement that skills can be used without going to the skill marketplace and enabling them first? The answer was that these skills are enabled when users interact with them. They still show in the Alexa app and can be disabled. I wonder if this will be confusing to users who think they’re interacting with Alexa, but are really interacting with a skill. The example in the announcement was “Alexa, start a metronome.” Do users really go look at their enabled skills in the app?

Alexa State of the Union

This session was about selling the vision of Alexa and voice interaction. Less on the technical side, of course. Top takeaways (for me):

  • The goal for routines is to have them control anything that you can do with Alexa. (This was a throwaway line, but one that interested me.)
  • A newly announced Destiny 2 speaker and skill. I’m not a gamer so I thought this was old until someone pointed it out.
  • 3 new monetization options for skill developers: subscriptions, in-skill one-time purchases, and integration with Amazon Pay. This is for more than just commerce, as non-profits will begin using it to take donations.
  • 10,000 English-language skills are available in India.
  • Australia and New Zealand will be available in early 2018; developers can start building now.
  • Expansion of “up to an additional $100 million” for the Alexa fund, focused on experiences outside of the US.