Web Application Alerts and Notifications
- Web Application Alerts and Notifications
- What type of notifications do we focus on?
- Why should we create a notification?
- Notification Scope
- Local Notification Scope
- Section Notification Scope
- Global Notification Scope
- Message Options
- Browser API Notifications
Notifications and Alerts are essential parts of a concrete application. All the applications should inform the user about an unexpected error or provide some feedback about the result of an action.
Every action should have a corresponding reaction.
The problem is that in a modern web environment there endless ways to create a notification. Unlimited collections of alert and notification libraries. We will try to distinguish our requirements and pick the right tool for our needs.
Users want to stay informed while using your web or mobile applications. Always use the opportunity to show your users well-formed and clear notifications. If needed (e.g. error message notifications), add extra information about the specific nature of a problem and a way to solve it. Try to keep your notifications simple and straight to the point. Your users will love knowing exactly what is going on and being able to get themselves out of a tight spot.
What type of notifications do we focus on?
During our daily interaction with our devices we meet notification everywhere. Emails and SMS are an easy way to have a notification. A popover window on our running application is also a notification.
As we can see, there is a huge variety of notification types. We separate in 2 categories, the internal and external. Internal notifications are created directly during our interaction with the application. External notifications are usually indirect. We meet in emails, sms, or a messaging section in our application. In this article we focus on the internal notifications. Aiming that the other type of notifications are more straightforward.
Why should we create a notification?
It is very helpful to identify when and why we have to create a notification. In a modern application there are a lot of processes that take place during the interaction of the user. The user applies some actions on the UI. The actions usually triggers reactions in the entire stack of the application. Those reactions can cause a variety of failures. (server error, connection issues, etc). When the user performs a mutable operation, the application should inform him about the result. The result could be accomplishment successful or unsuccessful. This is a meaningful usage of a notification.
In the other hand, it is very easy to overuse the notifications. When we pipe it with any logging process. When we use it for errors that can automatic resolved. The verbosity can decrease the usability of an application.
A critical design decision regards the proper placement of the notification. This decision differentiate according to the running environment. Each OS and Platform creates different notifications. We will try to take an universal choice, in order to cover as many requirements as possible. We will categorize the notification placement in ascending scope.
Local Notification Scope
We find local notification scopes is cases like a form, that we notify the user about the existence of his username. This notification can placed on top of the username input field. Another example is when we apply an action by clicking a button, we could change the text of the button, or append some text near the button, in order to inform the user about the result.
Most of the time, we use local notification scopes in unique reactions. I cases that there is no effect on the entire application.
It is quite aesthetic and user friendly as the user receive instant feedback for his actions. Aiming that when the user clicks a button, he receive feedback close to the button area.
It needs special treatment for each place that is going to run. It creates a lot of code, and special cases that are difficult to maintain. Additionally, it adds a respectable amount of time on each design iteration and develop process.
Section Notification Scope
We can find this type of notifications on the top of an entire view section. For instance, we can place the notification of a successfully submitted form, on top of the form.
Notifies the user that an action has accomplished on a specific segment of the page. It can also adjust the notification view for more specific purposes.
Programmer should implement each segments of the page that contain the notifications. This process adds an significant amount of code and generates additionally ui decisions.
Global Notification Scope
Usually, global notifications created in a fixed place on the application layout. They can be triggered by any component of the application. Global notifications are very easy to use. Whatever is happening in your system,
you can call the global notification module and launch a notification. We meet this notifications as
- Popup windows
- After header
Very easy to use.
Can easily overused and verbose the user with an unnecessary stack notifications.
As a convention, we usually use the same names that bootstrap uses for the notification types.
|primary (or default)||page’s default color scheme|
There is a discussion under the proper usage of the red color. The red color is for danger. Usually, we meet it in critical errors that effect the application stability. This kind of errors are server errors or connection timeouts. Red color takes all the user’s notice. It makes him feel unconformable. Warning color scheme is an elegant alternative. Even the fact that it provides the feeling that something is going wrong, it does not scare the user.
Red is the most common color used to highlight error fields. It’s effective in making them visible, but it can also overstimulate users and raise their pulse rate, making them feel like they’ve seriously screwed up on the form. Red is also associated with danger, which is not what you want users to feel when they make a mistake.
Notification Duration (lifecycle)
The notification lifecycle has 3 fundamental states.
The lifecycle of a message can vary on duration and way of removal. It can be dismissed after:
- A time period
- By another notification
- By user
- Page change
Usually, notifications that are dismissed after a time period, are used to notify the user for a non-important action. It is friendly for the user because he knows that it is not something major and it will disappear after some period.
If only one notification allowed to be displayed in the application, then it is a singleton notification. Singleton notifications are unique solutions in some systems. For instance, if the notifications are based on modals, then only one modal can be shown on the entire application.
On global scope, multiple notifications are more functional. Multiple notifications have the ability to show more than one notification in a time frame. It prevents the application from some minor bugs. For instance, if 2 errors occurred simultaneously, then the user will be informed for both of them. As a result, there will be any notification overlapping.
Position and Smaller Screens
The position of notifications is not a straightforward issue. In the web, we meet many different combinations. The most common are:
Small Popup Windows
Are placed in the edge of the screen, usually with small dimensions. Most of the times, in the right side.
Covers the entire screen. Popover a window in aligned in the center of the screen.
It is inside the body of the application. Usually, we meet it after the header of the page, and it covers the entire width. There are 2 approaches for this implementation. First, the notifications will be sawn in a sticky form, so the user will be able to see it independent to his current scroll position. Second, non sticky form. Apparently, a mechanism that notifies the user about the notification should be implemented. The auto-scroll on the notification section is useful option.
In smaller screens or mobile environments, small popup windows are user-unfriendly. It is not easy see them and it goes against the mobile design principles. Modals are acceptable, but it is a singleton approach. Sticky-header notifications that are placed after the header, with auto-scroll functionality is the save solution for many reasons.
- Multiple notifications can be launched.
- The message is very clear and works fine in small screen environments.
- User is able to browse the application while the notifications are shown.
Browser API Notifications
Apart from the main implementation of the notifications, there are a lot of tools in the browser API. Assisting to achieve an integrated notification workflow.
<title>Your app (1)</title>
Special text, that indicates the notification, can added in the document’s title.
Browser Theme Color
<meta name="theme-color" content="#db5945">
The browser’s theme color can changed due to a notification. The color can also combined with the message’s type color scheme.
new Notification('Hi there!')
Notifications is a relative new feature in the browser API. It does exactly our job, but in this article we focus on the internal notifications. This api is owns on the external notification tools.
The most easy way to notify the user. It can be categorize on the singleton notification approaches. Even the fact that it is exactly the tool that we need, the current browser implementations are not so elegant. A poor popup window covers the entire screen, without any possibility to style it. In cases that we would like to use this API, there are many wrapping libraries over the
window.alert(). It is heavily suggested to gain the benefits of those libraries that support:
- Html content
- Promises implementation. So the current running thread will not be blocked.
- Theme customization
A modern API, dedicated mostly for mobile devices. It allows you use the vibration hardware. The usage of this kind of tools is forbidden, because it agitates the user, in a manner worst than the red color.