They know how to fix notifications
Tags: ios, android, mobile, ux
Published: 2022-10-09 20:08:13

# The problem
The notifications on mobile devices are terrible. On all of them. Once in a while, mobile operating systems get new notifications-related features claiming to give the users more control over the notifications flooding their space visually and auditorily. While providing more flexibility, those features usually burden the users with maintaining the correct settings. Misconfiguring the notifications could result in missing important notifications. However, even if the users do keep their configuration perfect, they will still get spammed, regardless, since there is no control over frequency.

Now, I would like to avoid speculating on the mobile operating systems developers' motives for not providing any control over the frequency. However, one thing is crystal clear: they know about the problem.

Let us talk about one simple idea for solving this problem. Imagine the following situation.
> [11:15:02] Text notification 1 arrives
> [11:15:03] Text notification 2 arrives
> [11:15:04] Text notification 3 arrives

In total, these events would fire three notifications. However, was there any thinkable purpose for the last 2 of them? Did they bring any actionable information? The only thing that comes to mind is the number of messages. Although, what if there were ten messages? Would we still count the beeps, or would we just conclude that a bunch of messages has been delivered? That kind of conclusion could be driven without listening to 10 eternally annoying beeps.

# Frequency suppresion
One simple thing to do would be to work smart with the _reminder-notifications_ which usually fire with certain interval after the first or the last unread notification, depending on the platform and the app.

Let us look at the conventional way first. 
![Conventional](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l7h140af6hfdxpi1vnyd.png)

As you can see, each event fires a notification, and there are also the reminder-notifications. For simplicity, let us assume that notifications are read/released/forgotten by the system after a reminder is fired.

A way to handle a series of single-type events here would be to only fire a notification instantly when there are no unread notifications. All subsequent events would only affect the **interval** and the **tone** of the reminder notification.
- The tone is changed so that the user can hear that the reminder notification is getting more urgent.
- The interval is shortened so that the delay is appropriate for the suspected urgency.

Here is how it would look.
![Suggestion](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7h8at15kszh3xiytbk56.png)

The apparent effects this strategy brought are:
- The number of notifications fired is down to 6 from 13.
- The chance of two notifications being fired with almost no interval has significantly decreased (it happened only once in the second chart).

# Types, sources and caveats
The mentioned frequency suppression strategy can be applied globally or together with an event grouping strategy, including, but not limited to:
- By notification type
- By app, which dispatched the notification
- By notification urgency level declared by the dispatcher
- By contact or other app-level sources

This part could be much bigger than implementing the core of the strategy itself, and this is also the kind of thing that cannot be investigated in a short dev.to piece in your free time. The complications of the event grouping may be precisely why this or a similar notification frequency suppression strategy is not implemented.

Nevertheless, the notification frequency problem exists. Suppose you are not ready to disable some apps' notifications entirely. In that case, it is currently an unsolvable problem, regardless of how much effort you are ready to invest in configuring mobile notifications.