Эта статья о том, как мы разработали универсальную систему уведомлений для наших веб-приложений и что в итоге получилось.
Не буду утверждать, что полученный результат единственно правильный, но считаю его вполне неплохим.
Если у вас есть опыт решения подобной задачи, приглашаю вас поделиться им в комментариях.
Суть проблемы
Данный: веб-приложение для совместной работы.Для простоты будем считать, что это CRM или Task Tracker. Необходимый: оперативно оповещать пользователей о событиях в приложении, требующих их реакции.
В чем проблема?
Все было бы очень просто, если бы у нас было конкретное приложение со строго определенными сценариями работы и фиксированными ролями пользователей.Но в нашем случае это не так.
Мы разрабатываем различные системы автоматизации учета и бизнес-процессов на базе дизайнерской платформы.
А систему уведомлений нужно делать на уровне платформы, чтобы ее потом можно было использовать в любом приложении.
Первый блин Первое быстрое решение
Изначально был реализован самый простой вариант уведомлений — показ пользователям при входе в приложение всех изменений, внесенных другими пользователями.При небольшом количестве изменений этот метод имеет право на существование, но с увеличением объёма данных и числа пользователей мы получаем бесконечный список, на который нет времени, да и искать незачем.
через: 
Помимо слишком большого списка изменений, в этом блоке есть пункт «Что новогоЭ» и другие проблемы:
- Не видно, какие именно изменения произошли в данных (какое поле изменилось и как)
- Неизвестно, кто и когда внес эти изменения.
- Непонятно, обязан ли я (как пользователь) каким-либо образом реагировать на эти изменения.
Однако, как показывает практика, использовать журнал действий для получения оперативной информации о событиях в приложении неудобно.
Как правило, столь подробная информация об изменениях требуется в редких случаях – она используется руководителем при «разборе полетов».
А в реальном времени сотруднику нужно не так уж и много подробный , Сколько избирательный информация - с акцентом на интересующие его изменения.
Например, после «Завершения дела» (из примера выше) хотелось бы видеть следующую информацию:
Сегодня в 12:48 Иванов завершил дело P4D1: Подготовка документов заявки .Это если я лидер этих Ивановых и Петрова и хочу их максимально контролировать.Петров дело назначено P4D2: Получение оригинального заявления от клиента .
Если я Петров, то мне будет удобнее получить уведомление в таком виде:
Вам назначено дело P4D2: Получение оригинального заявления от клиента .Получается, что оповещения нужно настраивать по-разному для разных пользователей и разных событий.Срок выполнения: 2 дня.
(спасибо, Кэп) .
Пришло время проанализировать, в каких случаях и какие оповещения действительно нужны пользователям.
Классификация оповещений
По источнику возникновения
- Данные, которые меня интересуют, были изменены.
Например, если мне назначена задача, я хочу ее знать.
Если создаются или изменяются задачи, не имеющие ко мне никакого отношения, то мне это неинтересно.
- Указанный момент времени наступил.
Например, неделю назад мы договорились с клиентом, что я позвоню ему сегодня в 15:00. Если это не единственное мое соглашение на этой неделе, то есть большая вероятность, что я о нем с радостью забуду.
Так что мне будет полезно получить напоминание в нужное время (или за некоторое время до этого).
- Произошло определенное событие.
Например, была зафиксирована попытка входа в приложение с неверным паролем или с запрещенного IP-адреса.
Меня (как администратора приложения) это может беспокоить.
Кого необходимо уведомить
- Все пользователи.
На практике редко случается, что всех нужно оповещать об одних и тех же событиях.
Разве что это какие-то новости компании, о которых должны знать все сотрудники.
- Пользователи с определенной ролью.
Администратор настраивает, какие роли пользователей должны видеть какие оповещения.
- Конкретные пользователи.
Бывает, что какому-то пользователю нужен уникальный набор оповещений, и создавать для него новую роль только для настройки этого набора нет смысла.
Затем вы можете назначить оповещение конкретному пользователю.
Другая ситуация, когда это может понадобиться, — если администратор не возражает против того, чтобы пользователи сами выбирали, какие оповещения они хотят видеть.
В этом случае вам также необходимо сохранить настройку для конкретного пользователя.
- Вычисленные пользователи.
Например, при создании задачи необходимо уведомить только пользователя, указанного в поле «Ответственный».
Заранее (на этапе настройки) неизвестно, кто и за какую задачу будет назначен ответственным, поэтому назначить оповещение конкретному пользователю невозможно.
А при сохранении данных эта информация уже есть в системе — поэтому мы используем ее при формировании оповещения.
По способу уведомления
- В реальном времени.
Оповещения приходят в режиме реального времени.
Как только происходит событие, пользователю отображается сообщение прямо в браузере или в виде всплывающего окна в трее.
Сообщение может мигать и издавать звук, чтобы привлечь внимание.
- По СМС.
Этот метод оповещения имеет смысл, когда реакция на событие требуется немедленно, а у пользователя нет доступа к оповещению в реальном времени.
Как правило, этот метод используется для сообщения о важных событиях сотрудникам, работающим «в полях» без доступа к Интернету или просто без возможности держать браузер постоянно открытым.
- По электронной почте.
Уведомление в виде электронного письма имеет смысл для редких событий, не требующих оперативного реагирования.
Вы также можете использовать уведомление по электронной почте в качестве резервного варианта на случай, если пользователя не было в приложении в нужный момент.
- В ленту новостей.
Такие уведомления никак не привлекают внимания при появлении, но их можно просмотреть в любой момент по инициативе пользователя.
Это, скорее, даже не уведомления, а персональная история событий в приложении.
По сроку годности
- Он вообще не хранится в базе данных.
Мы сообщили пользователю о важном для него событии — отправили сообщение в браузер или письмо на электронную почту — и не можем контролировать, дошло ли оно до получателя.
Проблема этой опции в том, что в некоторых случаях пользователь может не получить уведомление — например, он закрыл браузер, не прочитав сообщение, или письмо попало в спам — и у нас не будет возможности узнать об этом.
И пользователь не будет знать, что он что-то пропустил.
- Удаляется автоматически после прочтения.
Подходящий вариант, когда оповещений много, но информация в тексте оповещения содержит мало информации.
Когда пользователю достаточно прочитать сообщение только один раз, и он сразу же может приступить к выполнению задачи.
- Помечено как прочитанное, требует явного удаления.
Подходит для случая, когда мы узнаем о задаче сейчас, но можем выполнить ее позже.
Тогда оповещение останется в списке как напоминание, а когда задача будет выполнена, его можно будет удалить вручную.
- Через некоторое время оно автоматически удаляется.
Если уведомлений много и они со временем теряют актуальность (например, уведомление о дне рождения коллеги или об изменении графика работы в определенный день), то имеет смысл удалить их автоматически через указанное время — независимо от того, прочитаны они пользователем или нет.
Результат
Итак, при анализе учтены все потребности.Кажется, ничего не забылось.
Теперь вам нужно придумать настройку, позволяющую генерировать любое оповещение.
О красоте интерфейса мы еще не подумали, но структура конфигурации получилась такая: 
Внимательный читатель заметит, что срок хранения оповещений в этой настройке не выбирается.
Мы решили, что эту настройку можно задать не для каждого отдельного оповещения, а на более высоком уровне — для всего приложения.
Это может быть временным решением, и точная настройка сроков хранения все равно будет необходима.
Опыт покажет.
Заключение
Как уже было сказано в начале статьи, найденное решение не претендует на идеальное.Я не исключаю, что в будущем он может быть как-то дополнен или даже полностью изменен.
Надеюсь найти в комментариях конструктивную критику и другие варианты решения проблемы.
Теги: #оповещения #настройки оповещений #уведомления #лента новостей #журналы событий #crm #веб-приложение #триггеры #ERP-системы #CRM-системы
-
Харви Фейнберг: Готовы Ли Вы К Неоэволюции?
19 Oct, 24 -
Корпоративная Шизофрения
19 Oct, 24 -
Расширение Интерфейса
19 Oct, 24 -
Искусственно Выращенный Бисфтекс
19 Oct, 24
