Selecting Real-Time UI Messages

Displaying notifications in the user interface is an essential feedback mechanism. They inform the user that something of interest has happened. A virtual machine that belongs to them, and one of the disks is no longer accessible. The user might want to know about something like this as it could pose a serious threat to their business. Imagine this type of thing happening and we get notified by the guest operating system when we try to write to the missing disk. Better to let the user know as soon as something like this happens, using appropriate messages, perhaps even guiding their next course of action. The problem with this type of notification is that the user didn't trigger it. It was triggered triggered by the autonomous background behavior of the system. And so, displaying these types of notifications indiscriminately could pose a problem. The UI needs to select which messages to display.

The underlying technology used in delivering and filtering real-time message notifications isn't as important as understanding the filter logic, and why we're doing it in the first place. The actual notification could be a web socket message, or we could be polling the API for messages, but the problem is the same nonetheless. There is only so much space to display notification after notification. There are two kinds of space a notification occupies. There is the graphical space as well as the mental space inside the user's head. There is a finite amount of space in each, and as they fill up, each new notification is devalued.

This is why any user interface displaying messages such as the one about a virtual machine's disk disappearing needs to consider other messages first. These state changes that occur as side-effect of something else happening in the system, and not as a direct result of a user action, are passive in nature. Sure, the user needs to know about it, it is important — they'll want to intervene as this is a severe problem. But injecting a note about this problem into a flurry of other notification activity doesn't help. In only further increases the mass of notifications on the user's screen. The idea is to guide, to provide insight. Not to confuse and cause chaos.

That said, we need to filter the displayed real-time notifications. But how? We don't want to over-filter and trigger the reverse problem of the user not receiving enough information about the state of the system. I don't think there is a generic strategy one can take and apply to various application domains. There are few best practices that apply across the board. For example, feedback on an action the user just performed. Active messages as opposed to passive messages. After which, perhaps we think about the state of the user's screen. Are they already being flooded with messages? How will this increase their understanding of what is happening right now? Then we have the more domain-specific filtering rules to consider. The most important rule to apply — a bit of a catchall — of the potential messages we could be displaying right now, which ones provide the most value to the user?