Progressive Responses & AstroBot

We wanted to take just a moment to talk about a new Alexa feature, our implementation of it in AstroBot (our space API aggregator skill), and thoughts about how to best take advantage of the new capability.

---

---

The Feature

Earlier this week Amazon enabled a feature called the "Progressive Response API", which you can read about here:

​https://developer.amazon.com/blogs/alexa/post/d9e00269-1c6c-44d1-91ec-0d8c92a919db/keep-users-engaged-entertained-while-processing-skill-responses

The feature essentially allows you to send the Alexa equivalent of a "loading icon" for long-running requests, providing text or audio that informs the user that you're working on preparing the information for them, rather than having awkward dead air while waiting for a response. It's a fairly small feature, and one that is pretty easy to implement, but it's one of those things that is a clear value-add in terms of the customer experience, even if it's not as flashy as other recent announcements (like push notifications or releases to new countries).

It's like this, but for voice user interface...

Our implementation

We were lucky enough to be included in the beta for this program via AstroBot. We haven't ever really talked about much about what AstroBot is doing behind the scenes, but there are a few cases here that made us a good fit. One of the calls you can make to AstroBot is to ask for the location of the ISS. While this might seem pretty straightforward, the process on our server actually goes something like this:

1. Lookup ISS coordinates from open-notify.
2. Given the coordinates, lookup the name of the place from google maps API.
3. If response is null, assume coordinate is over a body of water, and do a lookup via geonames.
4. Depending on THAT response, do some post-processing and make educated guesses.

Each of the three possible API calls can take up to 2 seconds, and along with the natural latency of User -> Alexa - > Lambda -> EC2 and back, that can result in some pretty lengthy dead air waiting to find out where the ISS is currently. In the past, we had actually capped this time at closer to 4 seconds, choosing to return an error message "quickly" rather than wait for a slow response that may or may not be successful.

With this new API, we now have the option to provide a "wait for it..." type message, which is a much better experience for the user than sitting on dead air, not knowing whether something is going to happen or not. And because we could inform the user about what was going on, we were able to extend our internal timeout out much closer to the 8 second maximum, meaning we are now much less likely to return a response with no answer. Everybody wins!

Best Practices

As we noted, it's a fairly simple feature, but in testing there are still a couple things we stumbled upon that we believe are "best practices" for progressive responses:

1. Vary your progressive responses! This is not really surprising, as it's a good idea to have a variety of different responses for a lot of the minutiae of your skill (like goodbye messages, confirmations, etc). It keeps the conversation feeling more fresh - there's an uncanny valley type effect that happens when your skill always says the exact same thing in the exact same way for a given action. Additionally, there's a caveat in the Progressive Response API saying that if you send the same content multiple times (as you can do up to 5 progressive responses) for a given request, "duplicates" will be discarded. In our case, we built a little random "progressive response generator" utility that we'll use across all future skills.
2. Short content. You want your progressive response messages to be short, because they are blocking! If it takes Alexa 2 seconds to read out your progressive response, but your main thread returns after 1 second, you're actually making the user wait an extra second (plus some buffer) to hear the thing they requested. With that in mind, you definitely want to keep your quips succinct.
3. This is not a cache replacement. There's a second place in AstroBot that we use progressive responses, and that's in looking up upcoming launches, which is something we can actually cache pretty well. We look up this information no more than once every 15 minutes. The ideal is to just quickly returned our content, so we have an if-block that checks our cache ttl. If it's expired, we return a progressive response, but if it's still good we return the response straightaway with no progressive response (which would block the response, as noted in #2).

Shortcomings and Future Expansion of the Feature

There are also a couple things we noticed that the feature could do better or enable in the future.
​

• Right now, it's only for custom skills, but it seems like there's no reason it shouldn't be applicable to smarthome or flashbriefing skills (although flashbriefing skills do some sort of mysterious pre-flight or cache-based thing that we've never been able to get an Alexa developer to actually describe to us).
• Another thing to understand is that this doesn't make it so you can take longer to provide your response from your main thread. It could, though, in the future. Amazon could easily say "You may have a 12 second timeout, as long as you provide progressive responses to keep the user engaged".
• And finally, there's no option for a visual progressive response for screen devices like the Show. It's sort of a funny coincidence that the perfect analogy we have to describe the feature - the spinning wheel - is something you can't actually implement in a literal way.

---

Had a chance to play with the feature, or have an interesting case that might apply? We'd love to hear what you guys are thinking about it, and happy to answer any questions you might have about our implementation or other proposed implementations.