Basis
Notifications serve as means of engaging the user around timely or important information from different facets of an app—its core content, marketing, etc.
Permissions
Before an app can send a notification, iOS offloads perms acquisition onto each app, apps will make the most convincing argument to why they should receive notification perms to the user. Often this takes the form of some enticing messaging paired with a design that primes the user to accept the native-served Perms modal. The apps often also give users the chance to opt out of notifications without opting out through Apple’s perms modal, as each app only gets the chance to serve that notification once, and the choice is binary, no escape valve. If the user accepts, the app gains the ability to send notifications out into iOS’ aggregation point, the Notification Center. Settings has more fine-grained control about which permissions and styles of notifications are available on an app-by-app basis. Notifications from apps are also allowed or disallowed on a per-app basis by different focus modes on Apple’s products.
Notification Center
Notification Center is iOS’ aggregation point for all notifications from apps with permissions. It allows users to view and manage notifications, by either dismissing or tapping to engage with a notification.
Notification Center is present on a user’s lock screen by default, meaning it is often one of the first things a user sees when interacting with an Apple product. It is also omnipresent when using an apple product, hidden behind a gesture but with the ability to override the screen from anything below it (other than Apple Pay/Wallet). Its prominence allows users to receive timely and important pushes from the apps they subscribe to, serving as a parallel to organic engagement with apps, as I mentioned previously.
How Notification Center handles notifications
Notifications from apps are served in chronological order. If multiple notifications are present from the same app, Notification Center groups them to prevent unnecessary context switching. A “Stack” of notifications from each app is also ordered chronologically, meaning that the believed importance of the notification sent by a creator doesn’t override recency.
Interruption Levels and Focus Modes
Interestingly, Apple requires builders to set an interruption level for every noncommunication notification their application sends. This ranges from Passive →Active→Time Sensitive→Critical, with the final two breaking through focus and overriding scheduled delivery. Critical level notifications override Silent mode on iPhone, however you have to request perms from Apple to use this level.
I don’t get the sense Apple restricts the use of the other three Interruption levels, but lays out best practices for using Time Sensitive notifications as they break through conditions the user has enabled to prevent notifications. The implication is that Apple wants creators to believe that users will disable all notifications for their app if trust is broken. That being said, Apple also provides guidelines for promotional or marketing notifications that it seems most apps don’t follow.
Focus modes are user-defined modes that allow additional controls on which apps can push notifications to a user when engaged. These modes, if blocking a notification from an app, will queue into a scheduled delivery when that mode is disabled, or rather when the user enters a mode where that app has notification perms again. Scheduled delivery is also available outside of Focus Modes as a concept and users can choose which apps are included in the scheduled summaries delivered at user-selected points.
Implications
-
Today, health apps by default have permission to notify a member at any point or engage the member in any way. We may earn the right for that not to be true at some point in the near future.
-
Our notification tray is a similar centralized point to iOS’ Notification Center, but isn’t accessible other than from the Homepage. There are practical benefits to exploring other ways of allowing engagement from any point within MBA, especially if we’re worried about thorough notification engagement or completion in the future.
-
Notification management is a concept that we have opted to not take on up until this point—we have a naïve system that equates tapping a notification to completing whatever action is associated with that notification. This is true of iOS’ system as well, with the insight that as long as we enable the proper routing structure (deep-linking to content or interaction), the onus for having a user complete the desired action should fall on the Health App. Interestingly a notification that prompts the user into a high-friction action like a CarePod visit likely won’t fit well into this system.
Meta Commentary
-
Interesting that our structure today feels very similar to iOS’, however fails the user in multiple ways. We only recently allowed correct deep-link routing, for example. We also do not present the notifications up front, I’d be much more likely to engage with a health app that has a badge than the notification bell in the top right, as other apps have trained me to believe these bells with red dots are often useless.
-
iOS offloads the optimal content onto the apps using the platform. If we centralize our content, it’s likely that we’ll scale the system of possible templates rapidly, but making sure these templates are relevant to the Health App in question becomes a larger task.
-
iOS also offloads the engine for pushes to each app as well, outside of OS-related blocks like Focus Modes or Scheduled Deliveries. We have no notion of an engine outside of a naïve if statement around the presence of new content (intentionally, we didn’t need anything else).