Sunday, January 15, 2012

User-friendly push notifications for iOS

iOS apps allow notifying the end users about things of interest. Notifications may include alerts, sounds and icon badges. They are "pushed" to users' devices automatically, without users' intervention. This ability has been present in the platform for a while now, and many apps are using it. However, in my opinion, most of them are doing it wrong.

The way they're doing it is that as soon as you launch an app that you just installed, you'll be greeted with something like this:


There are 2 issues with this prompt. First is the timing. I just installed this app and I'm now trying it for the first time. Unless I'm familiar with the brand, at this point I don't really know enough about this app, to trust it to allow it to bug me with future notifications. Is this really the best time to ask me for this ? Probably not. I always reject it. And there goes your chance. Once the end user rejected the prompt for allowing push notifications you don't get a second chance. That is, the app can't programatically make this prompt appear again. The only way to revert this initial rejection is if the end user goes to Settings and manually overrides it for this app, under the "Notifications" section. Or if the user uninstalls the app and keeps it uninstalled for at least one day.

Perhaps a better way would be to ask the end user to allow notifications only after she used the app for a while, to the point where she would have built up the trust for the app. Asking for such notifications is done programatically, via calls to the

- (void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types

method of UIApplication, so it's entirely within the control of the app. We could track users' engagement with the app, perhaps by keeping a record of how many times the app was launched or how much time has been spent in the app. Then we can choose to show the prompt only after the user has shown a sufficient level of interest in the app. That would increase the chance of the prompt being accepted.

The other issue with the prompt could be asking for permission for some potentially intrusive notifications, as it's the case in this example. Remember, there are 3 possible types: badges, alerts and sounds. While for most apps, a badge update would make sense, would alerts and sounds be appropriate ? For a magazine app, like in this example, that's hardly the case. When you do the interaction design for the app you'll need to ponder what types of notifications it makes sense to send, and request permission only for those. That's controlled through the parameter passed to the registerForRemoteNotificationTypes method.

Apple could also improve the visual representation of these prompts, perhaps by including some icons or color coding that better depicts the types of notifications the end user is asked to accept.