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.
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.
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...
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.
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.
RSS Feed