3PO-LABS: ALEXA, ECHO AND VOICE INTERFACE
  • Blog
  • Bots
  • CharacterGenerator
  • Giants and Halflings
  • The Pirate's Map
  • Responder
  • Neverwinter City Guide
  • About
  • Contact

3PO-Labs: Alexa, Echo and Voice Interface

"Finally", aka "The Alexa Settings API"

8/22/2018

3 Comments

 
After what seems like an unconscionably long wait, the Alexa team announced earlier this week that they were finally giving us a way to look up the timezone of a given user. The feature was detailed in a blog post, with a new page documenting the "Settings API" (which is what contains the timezone feature) going up simultaneously. This may seem like a pretty straightforward change, but between the history and the implementation, there's actually a fair bit to unpack here. So let's dive in...


Remembering the dark time (zone?)

So, lets start by talking about how this problem was solved before the feature dropped. For the first year and a half that people were building Alexa skills, the only choice was to literally ask a user "Hey, where do you live?". This was a bad solution. It forced users to manage long-term persistence for a trivial item, even when they didn't otherwise need it, and it created clunky user flows, with each developer implementing the process slightly different. Not to mention that, speaking as a consumer of the platform, it always felt weird telling an Alexa skill, speaking with Alexa's voice, a piece of information that Alexa clearly already knew.

Flash-forward to April 2017, when Amazon dropped the Device Address API. This feature allows developers to gather location data for the device they're interacting with, either as a physical address or as a postal code. And therein lies the problem with using it as a vector for gathering timezone. If the lack of a solution was like trying to crack a walnut with your bare hands, the Device Address API was like using a sledgehammer. It gave way too much, and too granular, detail, and along with that came everything else that comes with handling PII - Permission Cards (also clunky), Privacy Policies (otherwise optional), and user avoidance due to perceived overzealous permission escalation.

The Users Make Their Case

As a result of the poor options and the obvious nature of the feature, it quickly became the most requested feature. The Uservoice thread here (which it's worth noting was created by Christian Nowak immediately after the service became available again after it was first wiped) has 134 upvotes - almost twice as many as the next highest item. Digging through the forums for the first request for timezone as a piece of information that could be accessed for a given user, it was all the way back in January 2016, and I was pleasantly surprised to find that ​I was the one who answered the question, essentially echoing what this blog post is saying 2.5 years later. Since that time, there have been no shortage of other people showing up on the forums trying to figure out how to implement this simple feature that they are sure must exist (because why wouldn't it?).

So, yeah, it was obviously a highly desired feature.

Twitter weighs in

And the result was predictable among the development community:

It's X-mas in August #VoiceFirst crew!!https://t.co/bEb5lF3LxP

— Memo Döring (@memodoring) August 21, 2018

But my birthday was yesterday :)

— Charles LaPress (@chucklapress) August 21, 2018

Alexa developer heads around the world exploding. Timezone API finally released.

— Bob Stolzberg (@BobStolzberg) August 21, 2018

But what IS the feature, even?

So yeah, people were obviously pumped at the feature, but lost in the revelry was pretty much any analysis of the implementation itself, and I think there's quite a lot to discern from the way this thing was built.

So, on further review, what have we actually been given? Timezone is what people were clamoring for, but that was only one piece of what we actually got - default unit of temperature and distance are also options you can request. There hasn't been nearly as much feedback about the need for those properties, but it made sense to tack them on while tackling the timezone problem... maybe.

You see, the way the feature was built is actually a little bit different than what was requested, and what we all expected would happen. The sort of de facto shared notion of what this would eventually look like was that it would be a field that would come in on every request, much in the way the Locale field does today. Given that they are both vaguely geographic data, and that they are reasonably ubiquitous (presumably all devices have a timezone, default or otherwise), it would've been a natural progression of the Alexa request object.

Instead, what we have is a new endpoint on the Alexa API, which can be accessed via a GET call with the user's apiAccessToken (which comes in on every request). The request URL includes the deviceId in question, and the response is a plaintext string describing the value of the property requested. It's an extremely simple endpoint, and should be trivial to integrate against.

The major con to this approach is that the skill doesn't just have the timezone information natively, it has to actively seek it out via an API call. Even worse, the endpoint as implemented provides no way to get all settings at once, so if you need two or three of these properties, you're waiting on two or three roundtrips. In a case where a tenth of a second might be the difference between a user not noticing a delay versus a user getting frustrated at how long they're waiting, that matters.

But there are also some pros. Doing it via an API call means that any time you have the access token, like maybe in the case of a push notification workflow that happens outside of the normal interaction model, you are able to get timezone. This is something that could be super relevant in the case of AstroBot, for example, where timezone ambiguity for an upcoming launch event could easily cause people to miss it.

Maybe more importantly, this approach allows the endpoint to be easily extensible, and I suspect Amazon might have a very good reason for being interested in that...


Some sort of timezone pun about the future... you guys get it...

So, everything from here on out is pure speculation, and some of it may be closer to wish fulfillment than anything. As someone with occasional access to pre-release features, as well as access to Alexa engineers and product folks, one of the topics I've advocated for a few times is the idea of solving the "repeat preferences" problem. My pet cause has been the idea of a cross-skill user id, and I'm sure Amazon is tired of hearing me push that agenda, but I believe strongly that it makes no sense for a user who chooses one set of preferences in CompliBot to have to redefine those preferences in InsultiBot. It's a bad user experience done in the name of privacy.

At one point, however, I had a discussion go a different direction, where instead I suggested to the Amazonian I was talking to that maybe a shared preferences system, which persisted from skill-to-skill, would be a way to mitigate the lack of a cross-skill id. Something with a limited enumeration of properties that were likely to be applicable to many skills. A user in one skill could assert that they were comfortable hearing profanity, and other skills could take that into account without having to run the user through a preferences setup, for example.

And what we have today with this settings API looks an awful lot like the theoretical approach I proposed. That's not to say that they will use it that way, but they certainly could use it that way with very little technical effort. And even if there's never anything configurable from within our skills, I could certainly see a case where a little bit more information is revealed about the user's settings.

As a developer, wouldn't you like to know whether a user had Alexa Brief Mode enabled? I know I would.
Let me know what you all think of the new feature, what it's missing, or if you have other ideas about solving the cross-skill problem. 
3 Comments
custom paper writing service reviews link
9/21/2018 05:19:41 am

Amazon's Alexa is one of the greatest inventions involving artificial intelligence. When I first found out about its features, I admit that I was a bit skeptical and doubtful that it would work. Who would believe that with a speaker, you will be able to have a virtual assistant? It truly proves how advanced our technology is today and I think that is both impressive and scary. It terrifies me a little bit because it makes me wonder what more can people invent using the technology we have today.

Reply
drastic ds emulator apk link
11/5/2018 07:49:50 pm

There are some interesting points in time in this article but I don’t know if I see all of them center to heart. There is some validity but I will take hold opinion until I look into it further. Good article, thanks and we want more! Added to Feed Burner as well

Reply
uk custom essay link
12/18/2018 04:49:29 pm

Artificial Intelligence nowadays are really becoming one of those helpful strategy in any industry. Trying this artificial intelligence in financial and marketing industry really works out and makes the work much easier. It would be a matter of employment on the other hand. I guess that having improved the technology will lessen the man force and that is a bit problem. Technology plays an important role in the society, before it was only used for communicating, but seeing it evolved right mow makes me think that investing to technology means no bankruptcy.

Reply



Leave a Reply.

    Author

    We're 3PO-Labs.  We build things for fun and profit.  Right now we're super bullish on the rise of voice interfaces, and we hope to get you onboard.



    Archives

    May 2020
    March 2020
    November 2019
    October 2019
    May 2019
    October 2018
    August 2018
    February 2018
    November 2017
    September 2017
    July 2017
    June 2017
    May 2017
    April 2017
    February 2017
    January 2017
    December 2016
    October 2016
    September 2016
    August 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015

    RSS Feed

    Categories

    All
    ACCELERATOR
    ALEXA COMPANION APPS
    BOTS
    BUSINESS
    CERTIFICATION
    CHEATERS
    DEEPDIVE
    EASTER EGG
    ECHO
    FEATURE REQUESTS
    MONETIZATION
    RECAP
    RESPONDER
    TESTING
    TOOLS
    VUXcellence
    WALKTHROUGH

Proudly powered by Weebly
  • Blog
  • Bots
  • CharacterGenerator
  • Giants and Halflings
  • The Pirate's Map
  • Responder
  • Neverwinter City Guide
  • About
  • Contact