Overview of feature
TimeZones/DND
Further, right now the DND feature is a sledgehammer - there's no ability to apply a sleep mode to specific skills while granting other skills the ability to notify. A case where this might be relevant is for something like AccuWeather. While most people don't want to be dragged from their slumber to learn that SpaceX is about to launch a Falcon 9 sometime in the next 24 hours, they probably DO want to be awoken if the government issues a tornado or wildfire warning for their area.
This leaves a lot of implementation details in the hands of the developers, then. Do you want to include special safeguards for people in radically different timezones than your notifying software? Want to silence some notifications at certain times of the day, but not others? Want to have multiple DND blocks in a single day? All of these things will need to be implemented as an additional layer in your skill. Further confounding this effect is that there's still not a good way to simply learn a user's timezone without asking each and every user to give it to you. A lookup based on the user's address in the device location API is possible, but there are ramifications therein that make it an unappealing choice.
Overnotifying
Subscriptions (and events)
The flipside, of course, is that you now have to manage your own subscription model and store user preferences. This is a non-trivial bit of additional work, and not everyone is going to want to take these steps. There's certainly room here for some third parties to step in and provide services to developers (in fact, we have a few things in the mix already), but we fully expect that there will be a sizable portion of the dev base who decides to either do a lazy implementation of notifications, or just skip them altogether.
Tying into this issue is that there are some weird architectural quirks about notifications that make the need for a solid "user preferences" and "notification subscriptions" mapping for each user important. If you run a skill where notifications are not central to your purpose, you'll often have users of your skill that are not notification subscribers, but if you are operating notifications off of an "all my users" approach you're going to end up with a ton of notification triggers aborted at the point halfway through the workflow where it becomes apparent that the permissions are missing.
Even in cases where subscriptions ARE being tracked, this last issue has potential to be a bugaboo, as skill disablement or notification permission revocation are both cases that result in notification triggers that cannot be completed. Amazon has begun to address this concern with their new Skill Events feature, but for the moment that feature is tucked away behind the SMAPI and not available to folks building through the developer console (aka "almost everyone").
Cert/Testing
This is the dilemma we faced the first time we went to submit. Rather than this approach, our idea was to provide an endpoint that the cert team could hit (a simple GET call with a key in the query param) which would simulate our daily cron job going off. Further, we set up a mock launch data provider which was guaranteed to always claim at least one upcoming launch in the next 24 hours. We expect something along these lines to be absolutely standard for the certification process.
The thing that makes this interesting is that it brings into focus the "bait-n-switch" concept, where the service backing the skill is changed after passing cert. For notifications, we sort of have to do this. But does that put Amazon in a weird position, requiring a bait-n-switch for one aspect of the platform but (weakly) forbidding it for others?
That's a tricky question, and one I'm not sure how the Alexa team will answer. In the meantime, there are some things I think they can definitely build on in the near term that will make the experience better for users...
Things to improve
- Disable auto-prompting: This is a feature request I've had in with the team since early in the beta. Right now, you choose either "notification permissions" or "no notification permissions". I propose that there should be a third option "notification permissions, but don't prompt upon skill enablement". This may sound weird, but consider a case where a skill is MOSTLY for non-notification use cases. Users who are signing up for the primary use case are going to see a request for notification permissions that they'll never use, and a big chunk of those users are going to abandon the skill at that moment and never actually use it. This is a well-observed phenomenon in the mobile world when apps aggressively pursue permissions, and it was a big deal recently when Android finally allowed permissions to be requested only at the time they are actually needed. It is our belief that Alexa needs a similar flow.
- TimeZones: As mentioned above, managing timezone preferences is a pain, and this has been one of the most requested features for a long time. Obviously device location alleviates this somewhat, but it would be much preferable if we could just know timezone without having to deal with having a user's personally identifying information (which address certainly is).
- Lookup: We can't talk about this a ton until the API is opened up to everyone, but something to consider is what happens in the life cycle of a notification after it is sent out. At this moment, the "post-send" options are barebones and quite frustrating to use. A little love on this feature set would go a long way.
- Users with no notifications-enabled devices: This is something we're not even sure is an actual issue, since we don't know how to test it, but what happens when a user thinks they should be getting notifications, but it turns out their Alexa-enabled smart toothbrush (or whatever) isn't able to do push? Do the notifications just linger and die? Should the user have even been able to sign up for notifications without an applicable device? What's the right UX here?
We're looking forward to seeing how folks address these problems, and indeed, as previously mentioned, we have some thoughts of our own on how to work around the shortcomings and provide additional value beyond just the basics of the feature. We'd love to hear what you guys think. Excited about notifications? Have ideas on how the UX should work? Hit us up directly or leave us a comment below!