Designing an alert system for web applications

    This article is about how we designed a universal alert system for our web applications and what happened in the end. I will not argue that the result obtained is the only true one, but I consider it quite good. If you have experience in solving this problem, I invite you to share it in the comments.

    Essence of the task


    Given: collaboration web application. For simplicity, we assume that it is CRM or Task Tracker.
    Required: timely notify users of events in the application to which their response is required.

    What is the problem?


    Everything would be very simple if we had a specific application with strictly defined work scenarios and fixed user roles. But in our case this is not so. We develop various systems of accounting and automation of business processes based on the design platform. And the notification system needs to be done at the platform level, so that later it can be used in any applications.

    The first pancake The first quick fix


    Initially, the simplest version of alerts was implemented - showing users when they enter the application all the changes made by other users. With a small number of changes, this method has the right to exist, but with an increase in the amount of data and the number of users, we get an endless list that there is no time, and there is no need to view it:



    In addition to too many changes, this block has “What's New?” and other problems:
    • It is not visible exactly what changes occurred in the data (which field has changed and how)
    • It is not known who and when made these changes.
    • It is unclear whether any response to these changes is required from me (as a user)

    It would seem that to answer all these questions there is an action log that stores the most detailed information about each transaction:



    However, as practice shows, using the action log to obtain operational information about events in the application is inconvenient. As a rule, such detailed information about changes is required in rare cases - it is used by the head during the “debriefing”. And in real time, the employee needs not so much detailed as selective information - with an emphasis on the changes that interest him. For example, after “Finishing a Case” (from the example above), I would like to see such information:
    Today at 12:48 PM Ivanov completed the case P4D1: Preparation of documents for filing an application .
    Petrov was assigned the case P4D2: Receiving the original application from the client .

    This is if I am the leader of these Ivanovs and Petrovs and want to control them as much as possible. If I am Petrov, then it will be more convenient for me to receive an alert in this form:
    You are assigned to P4D2: Receiving the original application from the client . The deadline is 2 days.

    It turns out that the alerts should be configured differently for different users and different events (thanks, cap) . It's time to analyze when and what alerts users really need.

    Alert Classification


    By source of occurrence

    • The data that interests me has been changed. For example, if a task is assigned to me, I want to know this. If tasks are created or changed that have nothing to do with me, then I am not interested.
    • The set point in time has arrived. For example, a week ago we agreed with a client that I would call him today at 15:00. If this is not my only agreement for this week, then it is likely that I will safely forget about it. So it will be useful to me at the right time (or some time before it) to receive a reminder.
    • A specific event has occurred. For example, an attempt was made to enter the application with the wrong password or from a forbidden IP address. It (me as the administrator of application) it can excite.

    By who needs to be notified

    • All users. In practice, it rarely happens that everyone needs to be notified about the same events. Unless it’s some kind of company news that all employees should know about.
    • Users with a specific role. The administrator configures which user roles which alerts should be displayed.
    • Specific users. It happens that some user needs a unique set of alerts, and creating a new role for him only to configure this set does not make sense. Then you can assign an alert to a specific user. Another situation where this may be necessary is if the administrator does not mind that users choose what alerts they want to see. In this case, you also need to store the setting for a specific user.
    • Calculated users. For example, when creating a task, you need to notify only the user specified in the Responsible field. It is not known in advance (at the setup stage) who in which task will be appointed responsible, therefore it is impossible to assign an alert to a specific user. And when saving data, this information is already in the system - this is what we use when creating an alert.

    By notification method

    • Real-time Alerts come in real time. As soon as the event occurs, the user is given a message directly in the browser or in the form of a pop-up window in the tray. To attract attention, the message may blink and make a sound.
    • By SMS. This notification method makes sense when the reaction to the event is required immediately, and the user does not have access to real-time notification. Typically, this method is used to report important events to employees working "in the fields" without access to the Internet or simply without the ability to keep the browser constantly open.
    • By email. A notification in the form of an e-mail message makes sense to use for rare events that do not require an immediate response. You can also use email alerts as a fallback in case the user was not in the application at the right time.
    • In the news feed. Such alerts do not attract attention at all at the time of appearance, but they can be viewed at any time at the initiative of the user. Rather, these are not even alerts, but a personal history of events in the application.

    By shelf life

    • Generally not stored in the database. They informed the user about an important event for him - they sent a message to the browser or an e-mail - and we have no control over whether it reached the addressee. The problem with this option is that in some cases the user may not receive a notification - for example, he closed the browser without reading the message, or the message got into spam - and we won’t know about it. And the user will not know that he missed something.
    • It is deleted automatically after reading. A suitable option is when there are a lot of alerts, and the information in the alert text is low. When the user just needs to read the message once and he can immediately begin to complete the task.
    • Marked as read; explicit deletion required. Suitable for the case when we learn about the task now, but you can complete it later. Then the notification will remain in the list as a reminder, and when the task is completed, it can be deleted manually.
    • It is deleted automatically after a while. If there are many notifications and they lose relevance over time (for example, a notification about a colleague’s birthday or about a change in the work schedule on a certain day), then it makes sense to delete them automatically after a specified time - regardless of whether they are read by the user or not.

    Result


    So, all needs are taken into account in the analysis. It seems they have not forgotten anything. Now you need to come up with a setting that allows you to generate any alert. We didn’t think about the beauty of the interface yet, and the configuration structure turned out like this:



    An attentive reader will notice that the storage period for notifications in this setting is not selected. We decided that this setting can be set not for each individual alert, but at a higher level - for the entire application. Perhaps this is a temporary solution, and fine tuning of the shelf life is still needed. Experience will show.

    Conclusion


    As already mentioned at the beginning of the article, the solution found does not claim to be ideal. I do not exclude that in the future it can be somehow supplemented or even completely changed. I hope to meet in the comments constructive criticism and other options for solving the problem.

    Also popular now: