Thursday, August 17, 2017

The Three Mobile Notification Tiers

Mobile device notifications have probably become the primary UI I use to engage with my mobile device. I'm constantly amazed at how poorly mobile app developers implement them. Here's an awesome post by Stan Otrovskiy (iOS engineer at AMEX) that gets into how to do the right thing when a user actually selects a notification; great read.

I wanted to get some high-level thoughts down on paper around the three notification constructs nearly all mobile OSes support. Use them wisely.

SMS

SMS (aka "text") notifications are presented by the OS and are generally end-user configurable. These reach the device whether or not data is enabled or disabled, and by definition involve server and mobile-device communication. In a connected-device world, SMS notifications are often considered the most reliable form of notifying the user of something because they run on a different carrier protocol and aren't as subject to the general horrors of "data connection" unavailability. Be careful though, if your users are going to use your application while on a commercial airplane flying at 30k'+, SMS doesn't work. In general though, SMS finds a way to get through when data/IP based messages simply can't. The downside to SMS is that it's archaic and poor in terms of features and functionality. On iOS (I don't recall about Android), these notifications do NOT require the end user to initially grant permission for use.

OS-Level

The various mobile platforms (e.g. iOS, Android) provide OS-level notification frameworks. These frameworks allow an application to present OS notifications. The quickest way to understand these as an end-user is to go into iOS Settings->Notifications, where you can see the various types of ways to notify/alert the user to something. If your mobile app has a backend component that wants to engage with the user with a notification (e.g. "Your Uber is arriving."), the user's mobile service needs to a) support data and b) have data enabled on their device. In this case, as should be obvious, the user CANNOT be in airplane mode, otherwise there's no way for corresponding IP packets to get to the OS. These notifications generally require user permission on a per-app basis.

In-App

These are notifications that live purely within your application. If your app is a game, perhaps you throw dialogs that say things like "you just won 100 coins" or whatnot. In-App notifications don't abide by any OS-configured rules such as "don't display on lock screen" because they live entirely within the application itself, and are only relevant/visible when the user has the application in the foreground. Of course, you can reflect some, or mirror all, in-app notifications to their OS-level notification counterparts.

Trust

At the root of all notifications is gaining the user's trust to send them along in the first place. Regardless of their OS-level notification settings (whether they're liberal and permit all notifications to be as loud and visible as they want to be at all hours, or whether they're conservative and disable all notifications all the time), you have to be wary of being too pushy with your notifications. Over-notifying, or notifying the user of something they don't care about, violates trust. While you may want to engage the user for one reason or another, considering when to do so is important. Users disengage from noisy apps. As time permits, give your users lots of control over the types of notifications they receive. Default settings win, but power-users will eventually want to control all the nooks and crannies of their interaction with your app.

When you're considering conveying a piece of information to a user, it's important to understand the matrix of various notification settings and operating environments your users are likely going to be in. For example, if your application is for rock-concert or major sports event attendees, they don't have data connections available due to cell tower network saturation, nor are they likely to hear or feel notifications/vibrations of any type. Thus, perhaps your only notifications will be In-App when you're guaranteed to have the user's attention.

The best notification/engagement schemes are quickly foiled by a user who has turned on Airplane Mode to save battery life. Make sure you're providing value to the user in all notification settings scenarios, or ensure you know your user-base's settings support what you want to do with notifications.


No comments: