Permission To Send Notifications

[Mikenux]

Goals

Asking users if they want to receive notifications is intended to give them the ability to:

• Receive app news;
• Configure notifications directly with options such as the exception in "Do not disturb" mode;
• Preserve battery power based on backend options and app activity restrictions, as the app needs to run.

User Experience: When To Ask?

Three possibilities:

• (1) When the app is launched for the first time. The user is asked only once. I'm not a fan of this user experience because the user doesn't see anything about the app before being asked.
• (2) When the app is closed. The app can send notifications freely while it is running, but it needs permission when it is closed. This matches the user experience of apps that can have activity while running with a window open, but need permission to continue being active when they are closed.
• (3) When the app loses the focus. The app can freely send notifications when it has the focus; these are in-app notifications, but rely on external notifications. Permission to send notifications is required when an app window loses the focus. This user experience follows the logic that the app can only be active when the user interacts with it. In my opinion, this goes well with saving battery power by default. However, this has the disadvantage that desktop environment designers must find the right time to pop up the request when the user navigates away from the app without closing it (e.g. window switching, workspace switching).

What do you think of each user experience?

Portal User Interface

There are two options when an application requests to send notifications: the access backend and the custom backend (i.e. the backend specific to a desktop environment).

With the access backend, the question would be like "Allow Application to send notifications?" and the responses are "Allow" and "Deny". This is the classic way to prompt the user.

However, the custom backend allows to customize the way to prompt the user and to expose other options specific to a desktop environment. See the example below.

Custom Backend: Example

The question is "Application can give news using notifications. When to receive them?".

Responses are divided into three sections, allowing for advanced configuration of notifications.

The first section is called "When?" and allows to configure when to receive notifications. The responses are as follows, and may be accompanied by a battery saving indicator.

• When Opening the App. Description: Receive news when opening the app. Battery Saving Indicator: Best, Saves battery power.
• Scheduled. Description: Set when to receive news. A summary will be presented. Battery Saving Indicator: Good, Moderate battery power saving. As options, several predefined times can be presented where all apps with a given selected time check and send notifications at that time (e.g. Every hour).
• Anytime. Description: Receive news at any time. Battery Saving Indicator: Bad. The app may consume battery power at any time.

The second section is named "Do Not Disturb", which allows to directly configure the reception of notifications for the "Do Not Disturb" mode. This section is active only when the "When Opening the App" option in the "When?" section has not been selected. The available options are "Scheduled" and "Anytime" if the "Anytime" option has been selected in the "When?" section. However, if the "Scheduled" option has been selected, only that option is available in the "Do Not Disturb" section, with only predefined times greater than the one defined in the "When?" section being available (for example, if "Every 30 minutes" has been selected, the user can only select "Every 30 minutes" and times greater than that as options, but not less than that such as 15 minutes).

The last section is "Screen Unlock" and allows to set whether notifications can be received when the screen is unlocked. This is not really a section, but an independent and complementary option to the options in the first and second sections.

Configuration around notifications on the lockscreen can also be present if wanted.

App Background Activity

Restrictions

For the "Scheduled" and "Anytime" options, the app can be active only to send notifications.

A system to restrict background activity is needed. A general system allowing to suspend (suspend to RAM and/or to disk) and wake up apps like CRIU (https://criu.org/Main_Page) or Nyrna (https://github.com/Merrit/nyrna?tab=readme-ov-file) may be a solution.

In any case, it is necessary to restrict activity by managing the permissions an app has: the app is not allowed to do anything other than check and send notifications when relevant. However, what is needed in terms of permissions and other restrictions that indicate that an app checks for notifications and sends them? It certainly needs network (Internet) access. What about write access? What should an app "download"? For example, should we expect a news app to download full articles (e.g. offline use) or just minimal information to say there is news? Are other permissions needed? Also, is it possible to dynamically adjust resources such as CPU usage, RAM usage, and network activity in relation to checking and sending notifications?

Without Restrictions

Is it useful to implement such permission without background activity restrictions? It certainly depends on what users can think, what they can infer when asked for permission. In case, it can be indicated (in the user interface) whether activity restrictions will be active or not.