Какие виды оповещений используются в программе
Это руководство по проектированию было создано для Windows 7 и не было обновлено для более новых версий Windows. Большая часть рекомендаций по-прежнему применяется в принципе, но презентация и примеры не отражают наше текущее руководство по проектированию.
Уведомление сообщает пользователям о событиях, которые не связаны с текущим действием пользователя, кратко отображая выноску со значка в области уведомлений. Уведомление может быть вызвано действием пользователя или значительным системным событием или может предложить потенциально полезную информацию от Microsoft Windows или приложения.
Информация в уведомлении полезна и актуальна, но никогда не важна. Следовательно, уведомления не требуют немедленного действия пользователя, и пользователи могут свободно игнорировать их.
В Windows Vista и более поздних версий уведомления отображаются в течение фиксированной продолжительности 9 секунд. Уведомления не отображаются сразу, когда пользователи неактивны или выполняются экранные заставки. Windows автоматически помещает уведомления в очереди в течение этого времени и отображает в очереди уведомления, когда пользователь возобновляет регулярное действие. Следовательно, вам не нужно ничего делать, чтобы справиться с этими особыми обстоятельствами.
Разработчики: Вы можете определить, когда пользователь активен с помощью API SHQueryUserNotificationState.
Примечание: Рекомендации, связанные с областью уведомлений, панелью задач и выносками , представлены в отдельных статьях.
Это правильный пользовательский интерфейс?
Чтобы определиться, ответьте на вопросы:
- Является ли информация непосредственным, прямым результатом взаимодействия пользователей с приложением? В этом случае выведите синхронную информацию непосредственно в приложении, используя диалоговое окно, окно сообщения, выноску или пользовательский интерфейс на месте . Уведомления предназначены только для асинхронной информации.

В этом примере диалоговое окно исключений брандмауэра Windows отображается в виде прямого результата взаимодействия с пользователем. Уведомление здесь не будет подходящим.
- Актуальна ли информация только при активном использовании приложения пользователями? В этом случае отобразятся сведения в строке состояния приложения или другой области состояния.

В этом примере Outlook отображает состояние подключения и синхронизации в строке состояния.
- Быстро ли меняющаяся, непрерывная и непрерывная информация в режиме реального времени? К примерам относятся ход обработки, фондовые цитаты и спортивные оценки. В этом случае не используйте уведомления, так как они не подходят для быстро меняющихся сведений.
- Полезна ли информация и актуальна? Могут ли пользователи изменить свое поведение или избежать неудобств в результате получения информации? Если нет, не отображайте информацию или не помещите ее в окно состояния или файл журнала.
- Является ли информация критической? Требуется ли немедленное действие? В этом случае отображение информации с помощью интерфейса, требующего внимания, и его нельзя легко игнорировать, например модальное диалоговое окно или окно сообщения. Если программа не активна, вы можете привлечь внимание к критически важной информации, мигая кнопкой панели задач программы три раза и оставив ее выделенной, пока программа не будет активной.
- Являются ли ИТ-специалистами основного целевого объекта? В этом случае используйте альтернативный механизм обратной связи, например записи файла журнала или сообщения электронной почты. ИТ-специалисты настоятельно предпочитают файлы журналов для некритических сведений. Кроме того, серверы часто управляются удаленно и обычно выполняются без входа пользователей, делая уведомления неэффективными.
Принципы проектирования
Эффективные уведомления, которые повышают удобство работы с пользователем:
- Асинхронная. Это событие не является непосредственным результатом текущего взаимодействия пользователей с Microsoft Windows или приложением.
- Полезную. Существует разумный шанс, что пользователи будут выполнять задачу или изменять свое поведение в результате уведомления.
- Соответствующие. В уведомлении отображаются полезные сведения о том, что пользователи уже не знают.
- Некритично. Уведомления не являются модальными и не требуют взаимодействия с пользователем, поэтому пользователи могут свободно игнорировать их.
- Действия. Для тех уведомлений, которые предлагают выполнение действия, это действие инициируется щелчком уведомления. Однако действие всегда может быть отложено.
- Надлежащим образом представлено. Презентация уведомления (длительность, частота, текст, значок и интерактивность) соответствует его обстоятельствам.
- Не раздражает! Существует строгая линия между мягкой информированием пользователей о событии и вредительства им.
К сожалению, есть слишком много раздражающих, неуместных, бесполезных, неуместных уведомлений там. Рассмотрим эти уведомления из Windows XP Зал стыда:



В этих примерах Windows XP якобы пытается помочь пользователям в первоначальной настройке. Тем не менее, эти уведомления всплывают слишком часто и хорошо после того, как они полезны, поэтому они немного больше, чем незапрошенные объявления функций.
Поток пользователей должен поддерживаться
В идеале пользователи, погруженные в свою работу, не увидят ваши уведомления вообще. Скорее, они увидят ваши уведомления только в том случае, если их поток уже нарушен.
В Flow: Психология оптимального опыта, Михали Csikszentmihalyi говорит, что пользователи входят в состояние потока, когда они полностью поглощены активностью, во время которой они теряют свое чувство времени и имеют чувство большого удовлетворения.
Эффективные уведомления помогают пользователям поддерживать свой поток, предоставляя полезную, соответствующую информацию, которую можно легко игнорировать. Уведомления представлены в низком ключе, периферийном режиме, и они не требуют взаимодействия.
Не предполагайте, что если уведомления бессерверны , они не могут быть раздражающими прерывания. Уведомления не требуют внимания пользователей, но они, безусловно, запрашивают его. Вы можете разорвать поток пользователей следующими способами:
- Отображение уведомлений о том, что пользователи не заботятся.
- Слишком часто отображает уведомление.
- Использование нескольких уведомлений, когда достаточно одного уведомления.
- Использование звука при отображении уведомления.
В Windows 7 пользователи имеют полный контроль над уведомлениями. Если пользователи обнаруживают, что уведомления программы слишком раздражают, они могут отключить все уведомления из этой программы. Убедитесь, что пользователи не делают это в вашей программе, предоставляя полезную, соответствующую информацию и следуя этим рекомендациям.
Уведомления должны игнорироваться
Уведомления не требуют немедленного действия пользователя, и пользователи могут свободно игнорировать их.
Разработчики и дизайнеры часто хотят представить свои уведомления таким образом, чтобы пользователи не могли игнорировать их. Эта цель полностью подрывает основное преимущество уведомлений, так как это приведет к прерыванию потока пользователей. Если пользователи отвлекаются на уведомления или чувствуют себя обязанными читать их, ваш дизайн уведомлений завершился сбоем.
Если вы обеспокоены тем, что пользователи игнорируют уведомления, рассмотрите следующее:
- Если вы используете уведомления правильно, и они не требуют немедленного действия пользователя, то пользователи решили игнорировать их по дизайну. Не изменяйте это.
- Если событие требует немедленного действия пользователя, используйте альтернативный пользовательский интерфейс, который пользователи не могут игнорировать. Видите ли это правильный пользовательский интерфейс? для альтернативных вариантов.
Используйте прогрессивную эскалацию, если применимо
Если уведомление используется для события, которое пользователи могут спокойно игнорировать, но это должно быть решено в конечном итоге, альтернативный пользовательский интерфейс следует использовать, когда ситуация становится критической. Этот метод называется прогрессивной эскалацией.
Например, система управления питанием Windows изначально указывает на низкую батарею, просто изменив значок области уведомлений.

В этих примерах Windows управление питанием использует значок области уведомлений для уведомления пользователей о постепенном снижении заряда батареи.
По мере уменьшения заряда батареи Windows предупреждает пользователей о слабой мощности батареи с помощью уведомления.

В этом примере Windows управление питанием использует уведомление, чтобы сообщить пользователям, что их питание от батареи слабое.
Это уведомление появляется, пока пользователи по-прежнему имеют несколько вариантов. Пользователи могут подключаться, изменять параметры питания, завершать работу и завершать работу компьютера, игнорировать уведомление и продолжать работу. По мере того как питание от батареи продолжает сток, текст и значок уведомления отражают дополнительную срочность. Однако после того, как питание от батареи становится настолько низким, что пользователи должны действовать немедленно, Windows управление питанием уведомляет пользователей об использовании модального окна сообщения.

В этом примере Windows управление питанием использует модальное окно сообщения для уведомления пользователей о критически низкой мощности батареи.
Если вы делаете только три вещи.
- Используйте уведомления только в том случае, если вам действительно нужно. При отображении уведомления вы потенциально прерываете пользователей или даже раздражаете их. Убедитесь, что прерывание оправдано.
- Используйте уведомления для некритических событий или ситуаций, которые не требуют немедленного действия пользователя. Для критических событий или ситуаций, требующих немедленного действия пользователя, используйте альтернативный пользовательский интерфейс (например, модальное диалоговое окно).
- Если вы используете уведомления, сделайте его хорошим взаимодействием с пользователем. Не пытайтесь заставить пользователей просматривать уведомления. Если пользователи так погружены в свою работу, что они не видят ваши уведомления, ваш дизайн хорош.
Варианты использования
Уведомления имеют несколько шаблонов использования:
- Спроектируйте эту функцию, чтобы упростить обнаружение в контекстах, где она необходима.
- Не делайте ничего особенного и не позволяйте пользователям самостоятельно обнаруживать эту функцию.
Рекомендации
Общее
- Выберите шаблон уведомления в зависимости от его использования. Описание каждого шаблона использования см. в предыдущей таблице.
- Не используйте уведомления во время начального Windows. Чтобы улучшить первый интерфейс, Windows 7 подавляет все уведомления, отображаемые в течение первых нескольких часов использования. При разработке программы предполагается, что пользователи не увидят таких уведомлений.
Что уведомлять
Не уведомляйте об успешных операциях, за исключением следующих обстоятельств:
- Безопасность. Пользователи считают операции безопасности наиболее важными, поэтому уведомляют пользователей об успешных операциях безопасности.
- Недавний сбой. Пользователи не принимают успешные операции, если они завершались сбоем непосредственно раньше, поэтому уведомлять пользователей об успешном выполнении операции в последнее время.
- Предотвратить неудобства. Сообщите об успешных операциях при этом может избежать неуверенных пользователей. Следовательно, уведомляйте пользователей о том, что успешная операция выполняется неожиданным образом, например, когда операция длинна или завершается раньше или позже, чем ожидалось.
В других случаях либо не предоставляйте отзыв об успешном выполнении, либо не предоставляйте отзыв «по запросу». Предположим, что пользователи принимают успешные операции для предоставления. Вы можете отправить отзыв по запросу, отобразив значок (или изменив существующий значок) в области уведомлений во время выполнения операции и удалив значок (или восстановите предыдущий значок) после завершения операции.
Для шаблона FYI не предоставляйте уведомления, если пользователи могут продолжать работать нормально или вряд ли будут делать что-либо другое в результате уведомления.
Неправильно:

В этом примере информация полезна только в том случае, если у пользователя уже установлены порты. В противном случае пользователь, скорее всего, не будет делать ничего другого в результате.
Исключение: вы можете уведомить пользователей о сомнительной релевантности, если это необязательно, и пользователи согласились.
Правильно:

В этом примере пользователи получают уведомления при поступлении контактов в интернет, и они решили получить эти необязательные сведения.
Для некритических системных событий и шаблонов FYI используйте полные уведомления для одного события. Не показывайте несколько частичных.
Неправильно:

В этих примерах показаны только четыре из восьми уведомлений, отображаемых в Windows XP при подключении определенной USB-клавиатуры, каждый из которых добавляет дополнительные сведения.
Правильно:

В этом примере подключение USB-клавиатуры приводит к двум полным уведомлениям.
Когда следует уведомлять
- Отображение уведомления на основе шаблона конструктора:
- Если проблема может исправиться в течение нескольких секунд, отложите уведомление об ошибке в течение соответствующего периода времени. Если проблема исправляет себя, сообщите ничего. Уведомлять только после того, как прошло достаточно времени, что сбой заметен. Если вы сообщаете слишком рано, скорее всего, пользователи не замечают сообщение о проблеме, но они заметят ненужные уведомления.
Неправильно:

После этого выполните приведенные далее действия.

В этом примере в Windows Vista уведомление о отсутствии беспроводного подключения преждевременно, так как оно часто сразу же сопровождается уведомлением о хорошем подключении.
- Для успешного выполнения действий и шаблонов FYI используйте параметр реального времени, чтобы устаревшие уведомления не помещаются в очередь, когда пользователи работают с полноэкранным приложением или не активно используют свой компьютер.
- Для некритических системных событий не создавайте потенциал для штормов уведомлений путем ошеломляющих событий, связанных с известными событиями, такими как вход пользователя. Вместо этого привяжите событие к некоторому периоду времени после события. Например, вы можете напомнить пользователям о регистрации продукта через пять минут после входа пользователя.
Как долго уведомлять
В Windows Vista и более поздних версий уведомления отображаются в течение фиксированной продолжительности 9 секунд.
Как часто уведомлять
- Количество раз отображения уведомления основано на его шаблоне разработки:
- Для необязательных задач пользователей не пытайтесь поставить пользователей в отправку, постоянно отображая уведомления. Если задача требуется, сразу же отобразите модальное диалоговое окно вместо использования уведомлений.
Эскалация уведомлений
- Не предполагайте, что пользователи увидят ваши уведомления. Пользователи не увидят их, когда:
- Они погружены в свою работу.
- Они не обращают внимания.
- Они находятся далеко от своего компьютера.
- Они выполняют полноэкранное приложение.
- Администратор отключил все уведомления для своего компьютера.
Взаимодействие
- Сделать уведомления доступными для щелчка, когда:
- Пользователи должны выполнить действие. Щелкнув уведомление, должно отобразиться окно, в котором пользователи могут выполнить действие. Этот подход предпочтителен для сбоев действий и необязательных шаблонов проектирования пользовательских задач.
- Пользователи могут просмотреть дополнительные сведения. Щелкнув уведомление, должно отобразиться окно, в котором пользователи могут просматривать дополнительные сведения.
Значки
- Для шаблона сбоя действия используйте стандартный значок ошибки.
- Для шаблонов некритических системных событий используйте стандартный значок предупреждения.
- Для других шаблонов используйте значки, показывающие объекты, относящиеся к теме или предлагаемые ей, например щит для обеспечения безопасности или батареи для питания.
- Используйте значки на основе вашего приложения или фирменной символики компании, если целевые пользователи распознают их и нет лучшей альтернативы.
- Для прогрессивной эскалации рассмотрите возможность использования значков с постепенно более решительным появлением, так как ситуация становится более срочной.
- Не используйте стандартный значок сведений. Это уведомления являются информацией, не говоря уже.
- Рекомендуется использовать большие значки (32 x 32 пикселя), если:
- Пользователи быстро поймут значок, а не текст.
- Большие значки передают их смысл более четко и эффективно, чем стандартные значки размером 16 x 16 пикселей.
- Значок использует стиль Aero.

В этом примере пользователи могут быстро понять характер уведомления с помощью большого значка.
Очередь уведомлений
Примечание: Уведомления помещаются в очередь всякий раз, когда они не могут отображаться немедленно, например, когда отображается другое уведомление, пользователь запускает приложение на полноэкранном экране или пользователь не использует компьютер. Уведомления в режиме реального времени остаются в очереди только в течение 60 секунд.
- Для шаблонов успешного выполнения действий и FYI используйте параметр реального времени, чтобы уведомление не помещалось в очередь в течение длительного времени. Эти уведомления имеют значение только в том случае, если они могут отображаться немедленно.
- Удалите уведомления из очереди, если они больше не актуальны.
- Разработчики: Это можно сделать, задав флаг NIF_INFO в uFlags и присвоив параметру szInfo пустую строку. В этом нет никакого вреда, если уведомление больше не находится в очереди.
Системная интеграция
- Если приложение не всегда имеет значок в области уведомлений при его запуске, отобразите значок временно во время асинхронной задачи или события, вызвавшего уведомление.
текст
Текст заголовка
- Используйте текст заголовка, кратко описывающий наиболее важные сведения, необходимые для общения с пользователями с четким, простым, кратким, конкретным языком. Пользователи должны иметь возможность быстро и с минимальными усилиями понять назначение информации уведомления.
- Используйте фрагменты текста или полные предложения без прекращения пунктуации.
- Используйте выделение прописных букв, как в предложении.
- Для локализации используйте не более 48 символов (на английском языке). Заголовок имеет максимальную длину 63 символов, но при переводе текста на английский язык необходимо разрешить расширение на 30 процентов.
Основной текст
Используйте основной текст, который предоставляет описание (без повторения сведений в заголовке) и( при необходимости), который предоставляет конкретные сведения об уведомлении, а также позволяет пользователям узнать, какое действие доступно.
Используйте полные предложения с окончанием пунктуации.
Используйте выделение прописных букв, как в предложении.
Для локализации используйте не более 200 символов (на английском языке). Основной текст имеет максимальную длину 255 символов, но при переводе текста на английский язык необходимо разрешить расширение на 30 процентов.
Включите важную информацию в основной текст, например имена конкретных объектов. (Примеры: имена пользователей, имена файлов или URL-адреса.) Пользователям не нужно открывать другое окно, чтобы найти такие сведения.
Поместите двойные кавычки вокруг имен объектов.
- Исключение: Не используйте кавычки, если:
- Имя объекта всегда использует прописную букву в стиле заголовка, например с именами пользователей.
- Имя объекта смещается двоеточием (например, имя принтера: мой принтер).
- Имя объекта можно легко определить из контекста.
Если для локализации необходимо усечь имена объектов до фиксированного максимального размера, используйте многоточие, чтобы указать усечение.

В этом примере имя объекта усекается с помощью многоточия.
Если уведомление доступно для действий, используйте следующее выражение:
Если пользователи могут щелкнуть уведомление, чтобы выполнить действие:

В этом примере пользователи могут щелкнуть, чтобы выполнить действие.
Если пользователи могут щелкнуть уведомление, чтобы просмотреть дополнительные сведения:
Щелкните для получения дополнительных сведений.

В этом примере пользователи могут щелкнуть дополнительные сведения.
Не говоря уже о том, что пользователь должен выполнить действие в уведомлении. Уведомления предназначены для некритических сведений, которые пользователи могут свободно игнорировать. Если пользователи действительно должны выполнить действие, не используйте уведомления.
Если пользователи должны выполнить действие, сделайте его понятным.
Для сбоев действий и некритических шаблонов системных событий опишите проблемы на простом языке.
Неправильно:

В этом примере проблема описывается с использованием слишком технического, но неуказаного языка.
Правильно:

В этом примере проблема описана на простом языке.
Опишите событие таким образом, который относится к целевым пользователям. Уведомление имеет смысл, если есть разумный шанс, что пользователи будут выполнять задачу или изменять их поведение в результате уведомления. Часто это можно сделать, описывая уведомления с точки зрения целей пользователя, а не технологических проблем.
Документация
При обращении к уведомлениям:
- Используйте точный текст заголовка, включая прописную букву.
- Обратитесь к компоненту как к уведомлению, а не как к выноске или оповещению.
- Чтобы описать взаимодействие с пользователем, нажмите кнопку мыши.
- По возможности отформатируйте текст заголовка полужирным шрифтом. В противном случае поместите заголовок в кавычки, только если это необходимо для предотвращения путаницы.
Пример. Когда появятся критические обновления для установки уведомления, щелкните уведомление, чтобы начать процесс.
Проектирование системы оповещений для веб-приложений
Эта статья о том, как мы проектировали универсальную систему оповещений для наших веб-приложений и что в итоге получилось. Не стану утверждать, что полученный результат является единственно верным, однако считаю его достаточно хорошим. Если у вас есть опыт решения подобной задачи, приглашаю поделиться им в комментариях.
Суть задачи
Дано: веб-приложение для совместной работы. Для простоты будем считать, что это CRM или Task Tracker.
Требуется: своевременно уведомлять пользователей о событиях в приложении, на которые требуется их реакция.В чем проблема?
Первый блинПервое быстрое решениеВначале был реализован самый простой вариант оповещений – показ пользователям при входе в приложение всех изменений, выполненных другими пользователями. При небольшом количестве изменений такой способ имеет право на существование, однако при росте количества данных и числа пользователей получаем бесконечный список, который некогда, да и незачем просматривать:

- Не видно, какие именно изменения произошли в данных (какое поле поменялось и как)
- Неизвестно, кто и когда внес эти изменения
- Непонятно, требуется ли от меня (как от пользователя) какая-то реакция на эти изменения

Однако, как показывает практика, пользоваться журналом действий для получения оперативной информации о событиях в приложении неудобно. Как правило, такая подробная информация об изменениях требуется в редких случаях — ее использует руководитель при «разборе полетов». А в реальном времени сотруднику нужна не столько подробная, сколько выборочная информация — с акцентом на интересующие его изменения. Например, после «Завершения дела» (из примера выше) мне хотелось бы видеть такую информацию:
Получается, что оповещения должны настраиваться по-разному для разных пользователей и разных событий (спасибо, кэп). Пришло время проанализировать, в каких случаях и какие оповещения действительно нужны пользователям.
Классификация оповещений
По источнику возникновения
- Изменены интересующие меня данные. Например, если на меня назначена задача, я хочу это знать. Если создаются или меняются задачи, не имеющие ко мне никакого отношения, то мне это неинтересно.
- Наступил заданный момент времени. Например, неделю назад мы договорились с клиентом, что я позвоню ему сегодня в 15:00. Если это не единственная моя договоренность за эту неделю, то велика вероятность, что я о ней благополучно забуду. Так что мне будет полезно в нужный момент (или за некоторое время до него) получить напоминание.
- Произошло определенное событие. Например, зафиксирована попытка входа в приложение с неверным паролем или с запрещенного IP-адреса. Меня (как администратора приложения) это может волновать.
По тому, кого нужно оповещать
- Всех пользователей. На практике редко бывает, что всех надо оповещать об одних и тех же событиях. Разве что это какие-то новости компании, о которых должны знать все сотрудники.
- Пользователей с определенной ролью. Администратор настраивает, каким ролям пользователей какие оповещения должны показываться.
- Конкретных пользователей. Бывает, что какому-то пользователю нужен уникальный набор оповещений, и создавать для него новую роль только для настройки этого набора нет смысла. Тогда можно назначить оповещение для конкретного пользователя. Другая ситуация, когда это может понадобиться — это если администратор не против, чтобы пользователи самостоятельно выбирали, какие оповещения они хотят видеть. В этом случае тоже надо хранить настройку для конкретного пользователя.
- Вычисляемых пользователей. Например, при создании задачи нужно оповещать только пользователя, указанного в поле «Ответственный». Заранее (на этапе настройки) неизвестно, кто в какой задаче будет назначен ответственным, поэтому назначить оповещение на конкретного пользователя невозможно. А при сохранении данных эта информация в системе уже есть — вот ее и используем при формировании оповещения.
По способу оповещения
- Real-time. Оповещения приходят в реальном времени. Как только наступило событие, пользователю выдается сообщение прямо в браузере или в виде всплывающего окна в трее. Для привлечения внимания сообщение может мигать и издавать звук.
- По SMS. Такой способ оповещения имеет смысл в том случае, когда реакция на событие требуется незамедлительно, а у пользователя нет доступа к real-time оповещению. Как правило, такой способ используется для сообщения о важных событиях сотрудникам, работающим «в полях» без доступа к интернету или просто без возможности держать браузер постоянно открытым.
- По email. Уведомление в виде письма на электронную почту имеет смысл использовать для редких событий, не требующих оперативного реагирования. Также можно использовать оповещение по email как запасной вариант на случай, что в нужный момент пользователь не был в приложении.
- В ленту новостей. Такие оповещения никак не привлекают к себе внимания в момент появления, зато их можно просмотреть в любое время по инициативе пользователя. Это, скорее, даже не оповещения, а персональная история событий в приложении.
По сроку хранения
- Вообще не хранится в базе. Сообщили пользователю о важном для него событии — отправили сообщение в браузер или письмо на почту — и никак не контролируем, достигло ли оно адресата. Проблема такого варианта в том, что в некоторых случаях пользователь может не получить уведомление — например, закрыл браузер, не прочитав сообщение, или письмо попало в спам — и мы никак об этом не узнаем. И пользователь не узнает, что что-то пропустил.
- Удаляется автоматически после прочтения. Подходящий вариант, когда оповещений много, а информации в тексте оповещения содержится мало. Когда пользователю достаточно один раз прочитать сообщение и он может сразу приступить к выполнению задачи.
- Помечается прочитанным, требуется явное удаление. Подойдет для случая, когда о задаче узнаем сейчас, а выполнить ее можно и позже. Тогда оповещение останется в списке в качестве напоминания, а когда задача будет выполнена, его можно удалить вручную.
- Удаляется автоматически через некоторое время. Если оповещений много и они теряют актуальность со временем (например, оповещение о дне рождения коллеги или об изменении графика работы в определенный день), то имеет смысл удалять их автоматически по прошествии заданного времени — независимо от того, прочитаны они пользователем или нет.
Результат
Итак, все потребности учтены при анализе. Вроде ничего не забыли. Теперь нужно придумать настройку, позволяющую сформировать любое оповещение. Над красотой интерфейса мы пока не думали, а структура настройки получилась вот такая:

Внимательный читатель заметит, что срок хранения оповещений в этой настройке не выбирается. Мы решили, что эту настройку можно задавать не для каждого отдельного оповещения, а на более высоком уровне — для всего приложения. Возможно, это временное решение, и тонкая настройка сроков хранения всё же понадобится. Опыт покажет.
Как в 1С вывести сообщение пользователю (бесплатная статья по Программированию в 1С)
из цикла статей «Первые шаги в разработке на 1С»Статья продолжает цикл статей «Первые шаги в разработке на 1С».
В ней мы рассмотрим способы информирования пользователя, которые присутствуют в платформе «1С:Предприятие» 8, а также акцентируем ваше внимание на некоторых особенностях работы этих механизмов, эти особенности связаны с режимом использования модальности.
Применимость
В статье рассматривается функциональность:
- Интерфейса в варианте «Версии 8.2» для конфигурации, разработанной на платформе «1С:Предприятие» 8.2.19.130
- Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.4.496 до 8.3.9+
- Интерфейса «Такси» для конфигурации, разработанной на платформе «1С:Предприятие» 8.3.10-8.3.11
Как в 1С вывести сообщение пользователю
Вывод сообщений в пользовательском режиме решает ряд задач:
- отражение хода выполнения текущего процесса (показ стадии выполнения процесса; показ расчетных значений, полученных в ходе работы алгоритма);
- выдача ошибок пользователю для возможного их исправления;
- выдача рекомендаций;
- терминирующие, которые останавливают выполнение программы и не дают продолжить ее, пока пользователь не ознакомится с этим сообщением и не выполнит определенные действия. Например, на экран пользователю будет выдан вопрос, на который нужно будет ответить Да или Нет. Пока пользователь не ответит – программа не выполняет дальнейшие действия;
- ознакомительные сообщения, которые просто выводятся для пользователя и позволяют работать дальше (т.е. используются в режиме оповещения).
Терминирующими сообщениями должны быть сообщения об ошибках, а ознакомительными: рекомендации, сообщения о текущем этапе процесса и показ расчетных значений (отладочная печать).
Ознакомительные сообщения
Ознакомительные сообщения предназначены для того, чтобы выдать пользователю некоторую информацию.
Необходимо, чтобы пользователь с ней обязательно ознакомился и, возможно, предпринял какие-то действия, которые описаны в этом сообщении.
Очень важно, чтобы пользователь действительно читал эти сообщения, поэтому они должны содержать только важную информацию.
Тестовые и отладочные сообщения выдавать пользователю не стоит, т.к. рано или поздно он начнет игнорировать абсолютно все сообщения.
В концепции управляемого интерфейса несколько изменился подход к выдаче сообщения. Оно теперь привязано к форме, в которой возникло. Его уже нельзя закрыть так, чтобы текст было совсем невидно.
Открепить от формы окно с сообщением нельзя.
Т.е. первым параметром является сам текст.
Второй параметр (статус сообщения) является необязательным. Для статуса можно указывать значения: Обычное, Важное, ОченьВажное и т.д.
От данного значения зависит, какой значок будет расположен рядом с сообщением. Однако это работает только в обычном интерфейсе.
В концепции управляемого интерфейса значок всегда в виде восклицательного знака, переопределить его нельзя.

Дело в том, что если сообщение будет формироваться в момент записи элемента справочника, может произойти следующая ситуация.
Пользователь нажимает на кнопку Записать и закрыть, в этом случае сообщение выводится в соответствующее окно (справа формы).
Но форма моментально закрывается, и пользователь не увидит, что для него выводилась какая-то информация.
Поэтому в концепции управляемого приложения ознакомительные сообщения рекомендуется выводить с помощью так называемых оповещений. Пример неправильного использования функции Сообщить представлен на рисунке.

Тем не менее, функция Сообщить может использоваться для вывода информации о некоторых ошибках, например в момент проведения документа.
В этом случае системе можно сообщить, что форму закрывать не нужно, и показать пользователю, какие ошибки возникают при проведении документа.
Функция Сообщить полностью поддерживается в Платформе 8.3. Ее можно использовать, и она будет работать (и в файловом варианте, и в клиент-серверном).
Но также следует отметить, что у функции Сообщить есть дальнейшее развитие – это класс сообщения пользователю, который позволяет помимо того, что выводить сообщение, привязывать его контекстно к каким-либо элементам формы.
Например, сообщение об ошибке можно привязать к элементу формы, что для пользователя очень наглядно. Несколько позже к рассмотрению этого вопроса мы вернемся. У функции Сообщить есть интересная особенность.
Так, программный код в Платформе 8.3 может быть исполнен как на стороне Клиента, так и на стороне Сервера.
При этом клиентский программный код отвечает за взаимодействие с пользователем, т.е. на стороне клиента открываются формы, выводятся отчеты.
Различные диалоговые документы также отображаются только на клиенте. На сервере они не могут быть исполнены, поскольку сервер не имеет возможности взаимодействия с пользователями.
Но функция Сообщить может быть исполнена как на стороне Клиента, так и на стороне Сервера. При этом использование метода Сообщить на Сервере вовсе не означает, что сообщение будет выводиться именно на Сервере, там их просто некуда выводить.
Это означает, что если мы в серверной процедуре будем выводить сообщение с помощью этого метода, они будут накапливаться в некотором буфере и выведутся они на экран только тогда, когда серверная процедура закончится и произойдет возврат на Клиента.
В этот момент система запросит данные из буфера и выведет их на экран.
Эта же особенность касается и класса СообщениеПользователю. На рисунке приведен пример использования метода Сообщить на стороне Сервера.

В результате использования метода Сообщить на стороне Сервера вывелись сообщения на экран на стороне Клиента.

Механизм оповещений
Механизм оповещений нужен, чтобы информировать пользователя о том, что в системе “что-то” произошло и это “что-то” требует внимания пользователя. Оповещения создаются двумя сценариями:
- Самой платформой при интерактивной записи или изменении объекта
- Разработчиком при вызове в коде метода ПоказатьОповещениеПользователя().
Само оповещение представляет собой небольшое окошко, которое появляется, как правило, в нижнем правом углу и сообщает о совершенном действии. В течение нескольких секунд оно постепенно гаснет и пропадает. При этом, если навести на оповещение курсор мышки, оно не гаснет и можно внимательно его прочитать.

Кроме того, к оповещениям можно обратиться в соответствующей области информационной панели (кнопка “История” слева внизу формы приложения в варианте интерфейса «Версии 8.2»).
Чтобы создавать свои собственные оповещения, необходимо использовать метод глобального контекста ПоказатьОповещениеПользователя(). Его синтаксис до редакции 8.3.10 представлен ниже:
В первом параметре передается текст, который будет выводиться в оповещении.
Далее вторым параметром можно передать некую навигационную ссылку на какой-либо элемент информационной базы (тот элемент, который соответствует тексту нашего сообщения). При нажатии пользователем на оповещение будет выполнен переход по этой ссылке.
С помощью третьего параметра можно передать пояснение для сообщения, т.е. какое-то расширенное описание.
Также можно присвоить картинку, отображающую статус оповещения.
Следует отметить, что все эти параметры являются необязательными для заполнения. Ниже приведен пример использования данного метода (в конфигураторе и в пользовательском режиме в варианте интерфейса «Версии 8.2»).


В редакции платформы 8.3.10.216 для интерфейса в варианте «Такси» механизм оповещений был существенным образом доработан с целью повышения удобства работы как в тонком, так и в веб-клиенте. По этой причине изменились и передаваемые параметры в метод ПоказатьОповещениеПользователя(). Теперь синтаксис выглядят так:
Видно, что второй параметр, ранее называемый НавигационнаяСсылка, получил новое имя ДействиеПриНажатии. Это связано с тем, что теперь в него стало возможным передавать не только строку с навигационной ссылкой, но и описание оповещения. Это проиллюстрировано скриншотом ниже:

Как видно из примера, у нас появилась возможность программным образом обрабатывать нажатие на окно с оповещением, согласно той логике, которая необходима.
Следующий параметр СтатусОповещенияПользователя появился впервые. В нем указывается статус оповещения (Информация или Важное).
В случае варианта Важное, если пользователь не отреагировал на сообщение, то после того, как оно будет скрыто с экрана, его можно будет прочитать через Центр оповещений (о нем ниже). В случае же варианта Информация, оповещение удаляется без запоминания в этом центре. Давайте перепишем код из нашего примера, как показано ниже:

После выполнения команды получим приблизительно такой вид окна приложения:

В панели инструментов появилась кнопка с пиктограммой звонка, по которой вызывается упомянутый выше Центр оповещений. В нем накапливаются новые важные оповещения, на которые пользователь пока никак не отреагировал.
Если в Центре есть какие-то оповещения, то рядом с ним появляется маленькая оранжевая точка, чтобы привлечь внимание пользователя. Пользователь может открыть Центр оповещений, прочитать текст и, если необходимо, выполнить какие-то действия.

Из Центра оповещение убирается нажатием на кнопку очистки, однако если с оповещением связано какое-то действие, то, как только пользователь щелкнет мышью по тексту сообщения, оно тоже пропадет.
И наконец, последним добавленным параметром стал КлючУникальности. С его помощью можно найти отображенное на экране оповещение и изменить его. Если же оповещения с таким параметром нет, то будет показано новое оповещение.
Как видим, возможностей, предоставляемых соответствующим методом, стало еще больше! Но это не все изменения в механизме оповещений.
Как вы уже, наверное, успели заметить, изменился их внешний вид. Теперь оповещения выглядят более современно и эргономично, но их нельзя перемещать по экрану и изменять их размер. Обратите внимание, в нашем примере, текст оповещения попросту не поместился целиком в самом окне, и прочитать его полностью пользователь сможет, только открыв Центр Оповещений. Поэтому не стоит в текст оповещения писать большое количество текста.
Также к новым возможностям относится и одновременное отображение на экране до трех оповещений.
На этом завершим наше знакомство с программным формированием оповещений. Однако вспомним, что оповещения формируются не только разработчиком программно, но и самой платформой в момент интерактивной записи или изменения объекта. И часто этот факт вызывает непонимание в первую очередь у начинающих пользователей: зачем нужны эти служебные оповещения, которые, кстати, нельзя отключить?
Давайте представим такую простую ситуацию: пользователь установил фильтр в каком-то списке для удобства. Допустим, он сделал это в форме списка справочника Номенклатуры. Потом, через какое-то время, решил ввести новый элемент с наименованием “Стул”, который не соответствует установленному ранее фильтру. Вводит его, записывает и…? И не видит его в списке. Что будет делать среднестатистический пользователь? Конечно, введет его второй раз, но опять не увидит. Дальше может последовать третий, четвертый, пятый раз. Когда ему надоест вводить одно и тоже, он, наконец, спросит у вас: а куда все пропадает?
Вот именно поэтому платформа и отображает эти служебные оповещения, информируя пользователя о том, что его действие выполнено. В нашем примере в момент интерактивной записи пользователь увидит следующее оповещение:

Терминирующие сообщения
Терминирующие сообщения – это те сообщения, которые не позволят работать, пока пользователь не произведет определенные действия, т.е. пока он не обработает сообщение.
О возможности использования терминирующих сообщений в Платформе 8.3 мы поговорим немного позже (в последнее время их стараются не использовать, поэтому рассмотренный пример больше касается Платформы 8.2).
Существуют два метода для выдачи терминирующих сообщений Предупреждение и Вопрос. Предупреждение отличается от Вопроса тем, что у него есть единственная кнопка ОК.
В вопросе могут определяться разные наборы вариантов ответов (ДаНет, ДаНетОтмена, ОК, ОКОтмена, ПовторитьОтмена, ПрерватьПовторитьПропустить), которые задаются с помощью параметра.
Выведем какое-нибудь предупреждение с помощью строки (например, в модуле управляемого приложения):
Предупреждение(“Сейчас будет открыта база”);
Чтобы открыть модуль управляемого приложения, следует в дереве конфигурации выбрать объект Конфигурация, вызвать контекстное меню и выбрать пункт Открыть модуль управляемого приложения.

В данном случае, при запуске приложения, будет выводиться окно, которое является модальным. Модальное окно перекрывает собой все окна, которые существуют в приложении. Пока мы не обработаем это окно, дальнейшие действия невозможны.

Аналогичным образом работает и функция Вопрос.
Обязательными являются только первые два параметра. Для второго параметра тип данных составной (РежимДиалогаВопрос или СписокЗначений). Третий параметр ( ) характеризует интервал времени в секундах, в течение которого система будет ожидать ответа пользователя.
По истечении интервала окно вопроса будет закрыто. Аналогичный параметр( ) есть и у функции Предупреждение.
В качестве примера использования функции Вопрос можно использовать следующий код, записанный в модуле управляемого приложения:


Обращаю Ваше внимание, что данные методы (Предупреждение и Вопрос) не доступны на Сервере. И это логично, потому что интерфейсные методы не могут быть выполнены на Сервере, где нет пользователя.
Особенности использования модальных окон в Платформе 8.3
В платформе 8.3 существуют режимы работы с использованием и без использования модальности. По умолчанию стоит настройка Не использовать режим модальности.
В этом случае использование терминирующих сообщений невозможно. В случае необходимости использования терминирующих сообщений (функции Предупреждение и Вопрос) следует изменить значение свойства конфигурации Режим использования модальности на Использовать.

Модальное окно выводится на самый верх и блокирует работу с другими окнами до завершения действий с модальным окном. Кроме того, останавливается выполнение программного кода на том месте, где происходит вызов этого окна. Выполнение кода продолжится только после закрытия модального окна.
Во-первых, проблемы по использованию модальных окон возникают для мобильного приложения. Во-вторых, в браузере модальность окон реализуется с помощью отдельных всплывающих окон.
В настройках браузера по умолчанию всплывающие окна зачастую запрещены. Пользователя приходится заставлять устанавливать разрешение на эти окна.
Браузеры для планшетных компьютеров и для телефонов в большинстве случаев вообще не поддерживают всплывающие окна.
Для замены функций Вопрос и Предупреждение разработаны новые методы: ПоказатьВопрос, ПоказатьПредупреждение.
Эти методы позволяют вызывать окно, но не останавливать выполнение программного кода. Технически это реализуется формированием псевдоокна внутри родительского окна. Псевдоокно не перекрывает родительское окно. После открытия такого окна код продолжает выполняться.
Получение и обработка введенных пользователем значений осуществляется в отдельной процедуре, которая вызывается при закрытии диалогового окна.
Синтаксис функции ПоказатьПредупреждение:
Тип данных: ОписаниеОповещения.
Содержит описание процедуры, которая будет вызвана после закрытия окна предупреждения.
Синтаксис функции ПоказатьВопрос:
Обязательными являются первые три параметра.
Ниже приведен пример использования функции.


Класс СообщениеПользователю
Основное удобство класса сообщений СообщениеПользователю заключается в том, что это контекстное сообщение (в отличии от методов Предупреждение и Вопрос).
Сообщения могут быть привязаны к конкретному экранному элементу. Этот объект доступен и на Сервере.
Следует обратить внимание, что, во-первых, данный объект нужно создавать. Например: Сообщение = Новый СообщениеПользователю;
Таким образом мы создаем экземпляр данного объекта.
Во-вторых, нужно прописывать текст сообщения в отдельном свойстве.
В-третьих, в свойстве Поле можно указать, к какому элементу формы данное сообщение должно быть привязано.
Внимание! Для привязки к нужному полю формы обратите внимание на инициализацию свойств ПутьКДанным и КлючДанных. Применительно для документа при размещении кода в модуле объекта можно писать:
Сообщение.ПутьКДанным = “Объект”;
Сообщение.КлючДанных = ЭтотОбъект.Ссылка;Чтобы открыть модуль документа, следует в окне редактирования объекта (документа) на закладке Прочее нажать на кнопку Модуль объекта.
Для эксперимента в модуле объекта какого-либо документа разместим код.

Ниже представлен полученный в пользовательском режиме результат для Платформы 8.3.

Следует отметить, что сообщения, выводимые с помощью нового объекта системы СообщениеПользователю в общем случае не являются терминирующими. Т.е. система позволит пользователю продолжить дальнейшие действия не отреагировав на выводимые сообщения.
Но, во-первых, данные сообщения достаточно заметны. Во-вторых, обычно сообщения пользователю выводятся в момент записи элементов справочников или проведения документов, т.е., когда выполняются какие-то проверки. И если были обнаружены ошибки, то пользователь увидит эти самые сообщения.
Соответственно, в момент обнаружения ошибок отменяется транзакция, т.е. запрещается запись элемента справочника, либо запрещается проведение документа.
Таким образом, происходит своего рода эмуляция терминирующего сообщения. Потому что действие отменяется, пока пользователь не отреагирует на вводимое сообщение, завершить действие, например, провести документ, будет нельзя.
Но, с другой стороны, есть возможность закрыть документ без проведения, никак не прореагировав на сообщение. Поэтому данные сообщения пользователю не являются терминирующими.
Уведомление о состоянии процесса
Существует специальная функция, с помощью которой можно отображать примерный ход выполнения какого-либо процесса.
Синтаксис: Состояние(, , , )
Параметры: и – не обязательные, тип – Строка.
Текст выводится на специальную панель состояния.
параметр тоже необязательный, но наглядный.
Тип: Число. Значение индикатора прогресса (от 1 до 100).
тоже необязательный параметр.
При обработке какого-либо события могут использоваться периодические вызовы функции типа:
При этом могут меняться надписи, а могут изменяться значения параметра Прогресс.
Функция может вызываться как из одной процедуры (функции), так и из нескольких. Таким образом можно отслеживать состояние выполнения процесса.

Если вы хотите ознакомиться с механизмом уведомления более подробно, то прямо сейчас прервитесь и прочтите нашу новую статью Отображение прогресса длительных операций в 8.3.10. В ней уже не на уровне новичка объясняются все тонкости и подводные камни работы этого механизма.
Мы же завершаем знакомство со способами информирования пользователя. Надеемся, что у вас сложилось понимание, в каких ситуациях следует применять тот или иной способ.
Хочется еще раз акцентировать ваше внимание на том факте, что если ваша конфигурация (версии 8.3.3+) предполагает работу с помощью веб-клиента, то:
- на уровне конфигурации должна быть установлена настройка режима модальности «Не использовать»
- в коде должны использоваться методы асинхронной модели взаимодействия с пользователем. Такие методы начинаются со слов Показать или Начать.
Более подробно об отказе от использования модальных окон в платформе 1С:Предприятие 8.3 можно почитать в финальной статье цикла. А мы идем дальше и, наконец, приступаем к изучению долгожданного интерфейса «Такси», который уже не раз упоминался в наших материалах.

PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Вы можете скачать эту статью в формате PDF по следующей ссылке:
Ссылка доступна для зарегистрированных пользователей)Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)Похожие публикации:
- Как удалить учетную запись если забыл пароль
- Как узнать h
- Как узнать видеокарту по серийному номеру
- Как узнать занят порт или нет
Проектирование системы оповещений для веб-приложений
Эта статья о том, как мы проектировали универсальную систему оповещений для наших веб-приложений и что в итоге получилось. Не стану утверждать, что полученный результат является единственно верным, однако считаю его достаточно хорошим. Если у вас есть опыт решения подобной задачи, приглашаю поделиться им в комментариях.
Суть задачи
Дано: веб-приложение для совместной работы. Для простоты будем считать, что это CRM или Task Tracker.
Требуется: своевременно уведомлять пользователей о событиях в приложении, на которые требуется их реакция.В чем проблема?
Всё было бы очень просто, если бы у нас было конкретное приложение со строго определенными сценариями работы и фиксированными ролями пользователей. Но в нашем случае это не так. Мы разрабатываем различные системы учета и автоматизации бизнес-процессов на основе платформы-конструктора. И систему оповещений нужно сделать на уровне платформы, чтобы потом можно было ее использовать в любых приложениях.
Первый блинПервое быстрое решениеВначале был реализован самый простой вариант оповещений – показ пользователям при входе в приложение всех изменений, выполненных другими пользователями. При небольшом количестве изменений такой способ имеет право на существование, однако при росте количества данных и числа пользователей получаем бесконечный список, который некогда, да и незачем просматривать:

- Не видно, какие именно изменения произошли в данных (какое поле поменялось и как)
- Неизвестно, кто и когда внес эти изменения
- Непонятно, требуется ли от меня (как от пользователя) какая-то реакция на эти изменения

Однако, как показывает практика, пользоваться журналом действий для получения оперативной информации о событиях в приложении неудобно. Как правило, такая подробная информация об изменениях требуется в редких случаях — ее использует руководитель при «разборе полетов». А в реальном времени сотруднику нужна не столько подробная, сколько выборочная информация — с акцентом на интересующие его изменения. Например, после «Завершения дела» (из примера выше) мне хотелось бы видеть такую информацию:
Сегодня в 12:48 Иванов завершил дело P4D1: Подготовка документов на подачу заявки.
Петрову назначено дело P4D2: Получение оригиналов заявки от клиента.Это если я руководитель этих Иванова и Петрова и хочу максимально их контролировать. Если же я Петров, то мне будет удобнее получить оповещение в таком виде:
Вам назначено дело P4D2: Получение оригиналов заявки от клиента. Срок выполнения – 2 дня.
Получается, что оповещения должны настраиваться по-разному для разных пользователей и разных событий (спасибо, кэп). Пришло время проанализировать, в каких случаях и какие оповещения действительно нужны пользователям.
Классификация оповещений
По источнику возникновения
- Изменены интересующие меня данные. Например, если на меня назначена задача, я хочу это знать. Если создаются или меняются задачи, не имеющие ко мне никакого отношения, то мне это неинтересно.
- Наступил заданный момент времени. Например, неделю назад мы договорились с клиентом, что я позвоню ему сегодня в 15:00. Если это не единственная моя договоренность за эту неделю, то велика вероятность, что я о ней благополучно забуду. Так что мне будет полезно в нужный момент (или за некоторое время до него) получить напоминание.
- Произошло определенное событие. Например, зафиксирована попытка входа в приложение с неверным паролем или с запрещенного IP-адреса. Меня (как администратора приложения) это может волновать.
По тому, кого нужно оповещать
- Всех пользователей. На практике редко бывает, что всех надо оповещать об одних и тех же событиях. Разве что это какие-то новости компании, о которых должны знать все сотрудники.
- Пользователей с определенной ролью. Администратор настраивает, каким ролям пользователей какие оповещения должны показываться.
- Конкретных пользователей. Бывает, что какому-то пользователю нужен уникальный набор оповещений, и создавать для него новую роль только для настройки этого набора нет смысла. Тогда можно назначить оповещение для конкретного пользователя. Другая ситуация, когда это может понадобиться — это если администратор не против, чтобы пользователи самостоятельно выбирали, какие оповещения они хотят видеть. В этом случае тоже надо хранить настройку для конкретного пользователя.
- Вычисляемых пользователей. Например, при создании задачи нужно оповещать только пользователя, указанного в поле «Ответственный». Заранее (на этапе настройки) неизвестно, кто в какой задаче будет назначен ответственным, поэтому назначить оповещение на конкретного пользователя невозможно. А при сохранении данных эта информация в системе уже есть — вот ее и используем при формировании оповещения.
По способу оповещения
- Real-time. Оповещения приходят в реальном времени. Как только наступило событие, пользователю выдается сообщение прямо в браузере или в виде всплывающего окна в трее. Для привлечения внимания сообщение может мигать и издавать звук.
- По SMS. Такой способ оповещения имеет смысл в том случае, когда реакция на событие требуется незамедлительно, а у пользователя нет доступа к real-time оповещению. Как правило, такой способ используется для сообщения о важных событиях сотрудникам, работающим «в полях» без доступа к интернету или просто без возможности держать браузер постоянно открытым.
- По email. Уведомление в виде письма на электронную почту имеет смысл использовать для редких событий, не требующих оперативного реагирования. Также можно использовать оповещение по email как запасной вариант на случай, что в нужный момент пользователь не был в приложении.
- В ленту новостей. Такие оповещения никак не привлекают к себе внимания в момент появления, зато их можно просмотреть в любое время по инициативе пользователя. Это, скорее, даже не оповещения, а персональная история событий в приложении.
По сроку хранения
- Вообще не хранится в базе. Сообщили пользователю о важном для него событии — отправили сообщение в браузер или письмо на почту — и никак не контролируем, достигло ли оно адресата. Проблема такого варианта в том, что в некоторых случаях пользователь может не получить уведомление — например, закрыл браузер, не прочитав сообщение, или письмо попало в спам — и мы никак об этом не узнаем. И пользователь не узнает, что что-то пропустил.
- Удаляется автоматически после прочтения. Подходящий вариант, когда оповещений много, а информации в тексте оповещения содержится мало. Когда пользователю достаточно один раз прочитать сообщение и он может сразу приступить к выполнению задачи.
- Помечается прочитанным, требуется явное удаление. Подойдет для случая, когда о задаче узнаем сейчас, а выполнить ее можно и позже. Тогда оповещение останется в списке в качестве напоминания, а когда задача будет выполнена, его можно удалить вручную.
- Удаляется автоматически через некоторое время. Если оповещений много и они теряют актуальность со временем (например, оповещение о дне рождения коллеги или об изменении графика работы в определенный день), то имеет смысл удалять их автоматически по прошествии заданного времени — независимо от того, прочитаны они пользователем или нет.
Результат
Итак, все потребности учтены при анализе. Вроде ничего не забыли. Теперь нужно придумать настройку, позволяющую сформировать любое оповещение. Над красотой интерфейса мы пока не думали, а структура настройки получилась вот такая:

Внимательный читатель заметит, что срок хранения оповещений в этой настройке не выбирается. Мы решили, что эту настройку можно задавать не для каждого отдельного оповещения, а на более высоком уровне — для всего приложения. Возможно, это временное решение, и тонкая настройка сроков хранения всё же понадобится. Опыт покажет.
Заключение
Как уже было сказано в начале статьи, найденное решение не претендует на идеальность. Не исключаю, что в дальнейшем оно может быть как-то дополнено или даже полностью изменено. Надеюсь в комментариях встретить конструктивную критику и другие варианты решения задачи.
- оповещения
- настройка оповещений
- уведомления
- лента новостей
- журналы событий
- crm
- веб-приложение
- триггеры
- ERP-системы
- CRM-системы
Какие виды оповещений используются в программе
Чтобы держать пользователей в курсе изменения важных данных и наступления важных событий в «1С:Документообороте» предусмотрены уведомления. Существует два типа уведомлений:
Уведомления о событиях сообщают пользователю о важных для него событиях, при этом программа самостоятельно проверяет важность события для пользователя. Примером такого уведомления служит уведомление о новых задачах: если пользователь подписан на такое уведомление, то он будет получать уведомления обо всех задачах, которые адресованы ему, роли, исполнителем которой он является, или пользователю, который делегировал ему права работы с задачами.
Уведомления по объектам сообщают пользователю о событиях по конкретному объекту, на который он подписался. Например, уведомление о появлении новых файлах в конкретной папке.
Метаданные
Используемые метаданные отнесены к подсистеме Уведомления . Рассмотрим эти метаданные подробнее.
Общие модули
В общих модулях РаботаСУведомлениями и РаботаСУведомлениямиПереопределяемый реализована основная логика работы подсистемы уведомлений. Подробнее данные модули описаны ниже.
Регламентные задания
Функциональные опции
Общие формы
- Да означает, что пользователь хочет получать уведомление по объекту, например, получать уведомления о ходе выполнения процесса, автором которого он не является.
- Нет означает что пользователь не хочет получать уведомление по объекту, например, не получать уведомления о ходе процесса, автором которого он является.
- Авто означает, что пользователь хочет получать уведомление в соответствии с настройками уведомлений о событиях. Например, получать уведомления о ходе процесса, автором которого он является.
Константы
Перечисления
Перечисление НастройкиУведомлений содержит в себе настройки уведомлений, доступные для настройки:
Перечисление СобытияУведомлений содержит в себе события, о которых можно рассылать уведомления, но которые при этом невозможно классифицировать как бизнес-события (например, факт, что задача просрочена, нельзя отнести к бизнес-событиям).
Перечисление СпособыУведомления содержит в себе различные способы уведомления пользователей. В текущей реализации используется только один способ уведомления — по почте.
Регистры сведений
Внутреннее устройство
Права доступа, роли, делегаты
Уведомления рассылаются с учетом прав доступа. Если у пользователя нет прав на чтение объекта, с которым произошло событие, он не получит уведомление. Проверка прав доступа осуществляется при формировании очереди уведомлений в регламентных заданиях ОбработкаПроизошедшихБизнесСобытий , КонтрольОкончанияСрокаДействия , КонтрольСрокаЗадач , КонтрольСрокаКонтроля . В регистр сведений ОчередьУведомлений попадают только те объекты, по которым уже выполнена проверка прав доступа. Дополнительная проверка прав доступа перед рассылкой не требуется.
Для исполнителей задач используется ролевое уведомление. Если исполнителем задачи является роль, то уведомления получат все исполнители этой роли. Для каждого исполнителя роли проверка прав выполняется независимо. В регистр сведений ОчередьУведомлений попадают записи для рассылки уже по конкретным исполнителям роли, а не по роли в целом.
Делегаты получают уведомления по событиям тех пользователей, права которых они получили. Для пользователя, от которого делегированы права, и для каждого делегата проверка прав выполняется независимо. В регистр сведений ОчередьУведомлений попадают записи для рассылки уже по конкретным пользователям, включая делегатов.
Настройка уведомлений
В модуле РаботаСУведомлениями за настройку уведомлений отвечают следующие процедуры и функции:
В модуле РаботаСУведомлениямиПереопределяемый за настройку уведомление отвечают следующие процедуры и функции:
Обработка бизнес-событий
Обработка бизнес-событий начинается в модуле РаботаСУведомлениями в процедуре ОбработатьБизнесСобытие . При обработке бизнес-события из него обрабатываются следующие важные поля:
Основная логика формирования очереди прописана в процедурах, вызываемых из процедуры ДобавитьУведомлениеПоОбъекту . Пример такой процедуры — ДобавитьУведомленияПоБизнесПроцессу . В ней прописана особая логика обработки бизнес-событий для процессов различных событий. Например, в ветке события ВыполнениеЗадачи прописано логика работы подписки на событие Ход выполнения процесса :
Доступны следующие служебные процедуры, которые используются для формирования очереди уведомлений:
Контроль сроков
Контроль сроков для уведомлений выполняется в модуле РаботаСУведомлениями в процедурах КонтрольСрокаЗадача , КонтрольОкончанияСрокаДействия , КонтрольСрокаКонтроля . Данные процедуры состоят из двух этапов — из этапа контроля срока и этапа контроля просроченных.
В первую очередь формируется состав данных с подписчиками, по которым могут быть уведомления. Выбираются данные, на которые оформлена подписка (с учетом делегирования и ролевой адресации) и которые подходят с точки зрения прикладной логики (например, активные задачи), Это формирование данных вынесено в следующие функции:
После формирования данных, по которым могут отправляться уведомления, выполняется формирование подписчиков (исходя из сформированных ранее данных) и чтение настроек подписчиков.
После этого начинается обработка каждой записи из сформированных ранее данных: проверяются настройки подписчиков, удовлетворяет ли запись конкретной настройке конкретного подписчика; выполняется проверка прав. Если проверка выполнена успешно, формируется запись в очереди уведомлений, а данная запись отмечается как обработанная. Отметка записи как обработанной необходима для контроля частоты рассылки уведомлений в соответствии с настройками — уведомления рассылаются не каждый раз при запуске задания, а только когда подойдет срок в соответствии с указанной частотой и датой последней обработки.
Рассылка уведомлений
Рассылка уведомлений выполняется в модуле РаботаСУведомлениями в процедуре ОбработатьУведомленияВОчередиУведомлений . В рамках данной процедуры выполняется отправка ранее сформированных уведомлений из очереди. Для каждого уведомления из очереди выполняется три попытки отправки. При успешной отправке запись удаляется из очереди. При неуспешной отправке запись остается в регистре. После трех неудачных попыток запись больше не обрабатывается и остается в очереди уведомлений. В журнале регистрации записи о рассылке уведомлений сохраняются по событию Уведомление о новых событиях .
Перед рассылкой выполняется попытка группировки уведомлений по получателю с помощью процедуры СформироватьУведомленияПоВидуБизнесСобытия . Например, уведомление о 10 новых задачах будет сгруппировано в одно письмо именно с помощью данной процедуры.
При включенной настройке выполнения задач по почте уведомление о новых задачах не группируется. Темы, тексты и файлы писем при этом формируются в модуле ВыполнениеЗадачПоПочтеСервер в функциях СформироватьТемуУведомленияПоЗадачеСВозможностьюВыполненияПоПочте , СформироватьТекстУведомленияПоЗадачеСВозможностьюВыполненияПоПочте и СформироватьФайлыУведомленияПоЗадачеСВозможностьюВыполненияПоПочте .
По несгруппированным уведомлениям будет выполнено формирование тем и текстов в СформироватьУведомленияПоСобытиям . Например, при выполнении задач по почте уведомление о новой задаче будет отправлено отдельным письмом с помощью данной процедуры.
В целом формирование текстов уведомлений для всех видов событий одинаково — формируется описание по всем объектам уведомлений. Формирование описания происходит в функциях, вызываемых из СформироватьПредставлениеОбъекта . Для изменения порядка формирования представления для объекта следует внести изменения в функцию СформироватьПредставлениеОбъектаПереопределяемый общего модуля РаботаСУведомлениямиПереопределяемый .
Навигационные ссылки, используемые в уведомлениях, формируются особым образом. Формирование ссылок происходит в функции ПолучитьНавигационнуюСсылкуУведомления — ссылка формируется с учетом адреса публикации на веб-сервере.
Непосредственная рассылка уведомлений производится в ОтправитьУведомлениеПоПочте . Адреса для рассылки формируются из контактной информации пользователя и дополнительных адресов для рассылки уведомлений, указанных в персональных настройках. Данная логика прописана в функции ПолучитьДанныеСпособаУведомления . Рассылка может выполняться по внешней и внутренней маршрутизации. При этом исходящие письма в базе не сохраняются.
Рекомендации по поддержке
Как настроить уведомления в первый раз
Настройка уведомлений выполняется следующим образом:
Что делать, если не приходят уведомления
Если не приходят уведомления, то для начала следует убедиться, что настройка уведомлений в первый раз выполнена. Если настройка выполнена верно, то уведомления должны приходить. Далее следует проверить журнал регистрации по событию Уведомление о новых событиях . При наличии ошибок информация, предоставленная в журнале регистрации, должна помочь избавиться от источника проблемы (например, невозможно подключиться к почтовому серверу).
Если первая настройка выполнена корректно и в журнале регистрации нет ошибок, то следует выявить, на каком именно этапе возникает проблема:
Что делать, если приходят уведомления о просроченных задачах, хотя задача уже выполнена
Скорее всего, где-то развернута копия базы, которая рассылает уведомления. Это либо серверная копия базы, на которой не включена блокировка регламентных заданий, либо файловая база. Для исправления ошибки следует либо выявить данную копию базу и заблокировать работу регламентных заданий, либо сменить в рабочей базе пароль на системную учетную запись, с которой выполняется рассылка уведомлений.
Рекомендации по доработке
Как изменить текст уведомления
Изменить тексты уведомлений можно с помощью доработки конфигурации, внося изменения в общий модуль РаботаСУведомлениямиПереопределяемый .
В первую очередь необходимо определиться, что нужно изменить:
Пример
Рассмотрим второй вариант (доработку представления объекта в уведомлении, связанное с событием уведомления) на примере уведомления о новой задаче. Считаем, что исполнение задач по почте не используется.
1. Откажемся от группировки уведомлений о новых задачах. Пусть по каждой задаче приходит отдельное письмо.
Для этого необходимо внести изменения в процедуру ВидыСобытийДляГруппировкиПереопределяемый общего модуля РаботаСУведомлениямиПереопределяемый , удалив из стандартного состава видов событий для группировки, группировка по созданию задачи.
2. Изменим тему писем с уведомлениями.
Для этого необходимо внести изменения в функцию СформироватьТемуУведомленияПоСобытиюПереопределяемый общего модуля РаботаСУведомлениямиПереопределяемый – для создания новой задачи будем формировать тему уведомления. При этом для остальных уведомлений важно оставить результат работы функции в значении пустой строки, чтобы обозначить необходимость использования стандартного формирования темы письма.
3. Изменим текст писем с уведомлениям.
Для этого необходимо внести изменения в функцию СформироватьТекстУведомленияПоСобытиюПереопределяемый общего модуля РаботаСУведомлениямиПереопределяемый – для создания новой задачи будем формировать текст уведомления. При этом для остальных уведомлений важно оставить результат работы функции в значении пустой строки, чтобы обозначить необходимость использования стандартного формирования текста письма.
В результате пользователь будет получать уведомление о новых задачах следующего вида:

Как изменить логику формирования очереди уведомлений
Для изменения логики формирования очереди уведомлений необходима доработка конфигурации.
Рассмотрим пример изменения логики работы для папки файлов. В первую очередь необходимо определить, для какого объекта необходимо внести изменения. Допустим, мы хотим, чтобы при подписке на папку файлов уведомления приходили не только при добавлении в данную папку, но и при добавлении во все вложенные папки.
Основная логика добавления уведомлений прописана в модуле РаботаСУведомлениями в процедуре ДобавитьУведомлениеПоОбъекту . Находим ветку для нужного объекта — в нашем случае это ДобавитьУведомленияПоПапкеФайлов . Чтобы обработать произошедшие событие и для подписок на родительскую папку, необходимо сделать вызов ДобавитьУведомлениеПоОбъекту , передав в него папку родителя.
Чтобы логика работы поменялась только для одного вида события, создадим ветку, соответствующую данному виду бизнес-события. Старый код вынесем в отдельную ветку, чтобы сохранить прежнее поведение для всех остальных бизнес-событий.
Другие рекомендации
При добавлении нового объекта, по которому возможна подписка (например, вид документа, если необходимо добавить возможность подписаться на событие по конкретному виду документа):
При добавлении нового объекта, по которому возможна рассылка уведомлений (например, вид документа, если необходимо уведомлять об изменении в настройках вида документа):
При добавлении нового события, по которому возможно уведомление (например, событие изменении настроек вида документа, если необходимо уведомлять об изменении в настройках вида документа):
Как включать в уведомление внешние ссылки, открывающие тонкий клиент
Помимо открытия веб-клиента из внешних почтовых ссылок при рассылке уведомлений есть возможность открытия тонкого клиента. Возможность не является типовой и сложна в поддержке, но может оказаться полезной.
При расположении базы на веб-сервере открывать тонкий клиент вместо веб-клиента не получится. При расположении базы на сервере «1С:Предприятия» такая возможность имеется. Для этого необходимо:
Настройка функции оповещения в 1С:УХ 3.0
В данной статье мы с вами рассмотрим, как создавать и настраивать 1С оповещения пользователей в УХ 3.0, как включить оповещения.
Для того чтобы использовать функцию оповещения для определенного пользователя в Управление Холдингом 3.0, нужно перейти в раздел «Процессы и согласования», далее «Управление оповещениями» и «Настройки оповещений». Теперь мы перешли с вами в раздел настройки оповещений. Тут нужно выбрать, под какую именно категорию попадут оповещения. Для примера выберем «Лот». Нажимаем кнопку «Создать» — перед нами открылось окно «Настройки оповещений(создание)». Галочка оповещение включено будет стоять всегда в автоматическом режиме работы, если мы захотим отключить данное оповещение, то данный флажок просто снимаем. Далее мы видим, что есть 3 подраздела.
2. Категории оповещения
В подразделе «Принадлежность» есть поля обязательные к заполнению.

1) «Категория оповещения»
Тут мы выбираем категорию оповещения. Это может быть напоминание либо различные виды оповещений. Оповещения и напоминания имеют немного разный функционал программы.

2) «Событие системы»
Здесь указываются виды события оповещения. В основном они все предопределенные, но можно так же создать и свой.

3) «Связанный объект»
Под связанным объектом подразумевается, какой именно это будет объект. Либо это «Справочник ИБ», либо 1С «Документ текущей ИБ».
В подразделе «Шаблон» мы можем добавить и расписать непосредственно сам шаблон для оповещения. Тут можно настроить что будет написано в оповещении.
В подразделе «Оповещаемые» сразу будет указан в реквизите «Оповещаемый по умолчанию» Ответственный за объект согласования. В реквизит «Дополнительные оповещаемые» можно добавить дополнительных пользователей для оповещения. Также можно настроить приход оповещений по ролям.

Если в реквизите «Категории оповещения» выбрать «Напоминание», то появится два новых реквизита:
1) Напомнить за: календарных дней до даты наступления события
2) Повторять напоминания: каждые часов
В первом типе реквизите 1С мы указываем за сколько календарных недель/дней до наступления определенного события будет приходить напоминание.
Во втором типе реквизитов 1С указывается частота присылаемых напоминаний в часах.
Уведомления
Кроме Toast-уведомлений, существует также другой тип уведомлений, который выводится за пределами вашего приложения, а именно, в верхней части телефона в системной строке состояния в виде значка с небольшим текстом.
Далее пользователь должен сдвинуть строку состояния экрана, чтобы увидеть расширенную информацию об уведомлении — текст, картинку. Также можно прямо в уведомлении сделать какое-то действие — написать ответ, поставить на паузу музыку и т.п. Для привлечения внимания к уведомлению можно подключить звук и вибрацию.
Уведомление может висеть в строке состояние сколь угодно долго, пока сам пока пользователь не отреагирует на него, в отличие от Toast-сообщения, которое исчезнет через несколько секунд. В Android 5.0 добавилась возможность выводить уведомление в виде отдельного небольшого всплывающего окна (если устройство не заблокировано). В особых случаях уведомление можно выводить и на экран блокировки.
Пользователь может в настройках вашего приложения отключить уведомления в любой момент. Поэтому не стоит спамить пользователя ненужными сообщениями. Также нелишним будет проводить проверку, что уведомление будет выведено на экран.
Обратите внимание, что в имени класса спрятан кот (Notification), что намекает на целевое использование уведомлений. Уведомляйте пользователя только о самом важном, например, что пора кормить кота.

Когда пользователь открывает расширенное сообщение, Android запускает объект Intent, который определён в соответствии с уведомлением. Можно также конфигурировать уведомление с добавлением звука, вибрации и мигающих индикаторов на мобильном устройстве.
Этот вид уведомления удобен в том случае, когда приложение работает в фоновом режиме и должно уведомить пользователя о каком-либо важном событии. Фоновое приложение создаёт уведомление в строке состояния, но не запускает активность самостоятельно для получения пользовательского взаимодействия. Это должен сделать только сам пользователь в удобное ему время.
Чтобы создать уведомление в строке состояния, необходимо использовать два класса:
- Notification — определяем свойства уведомления строки состояния: значок, расширенное сообщение и дополнительные параметры настройки (звук и др.)
- NotificationManager — системный сервис Android, который управляет всеми уведомлениями. Экземпляр NotificationManager создаётся при помощи вызова метода from(), а затем, когда надо показать уведомление пользователю, вызывается метод notify()
Показываем уведомление
Добавим на экран активности кнопку и напишем для демонстрации работы уведомления.
Для начала вам надо создать идентификатор уведомления. Он нужен, чтобы можно было различать уведомления друг от друга. Ведь вы можете создать идеальное приложение, которое уведомляло бы хозяина, что кота надо покормить (первое уведомление), погладить (второе уведомление), почистить лоток (третье уведомление). Если у вас будет один идентификатор, то каждое новое уведомление затрёт предыдущее и хозяин не увидит свои недоработки. Это не дело. Для идентификатора используйте какое-нибудь число. Только не надо оригинальничать, ничего не имею против числа 836, но вам определённо нужно сходить к психологу.
Также следует создать идентификатор канала. Каналы появились в API 26, но старые устройства будут просто игнорировать данный параметр при вызове конструктора NotificationCompat.Builder.
Далее формируется внешний вид и поведение уведомления через построитель NotificationCompat.Builder. Вы можете задать текст уведомления, значок, заголовок и прочие атрибуты. Для простого примера оставил минимальный набор настроек.
Выводится уведомление с помощью метода notify() — своеобразный аналог метода show() у Toast из предыдущего урока.
Не забывайте использовать вместо строк строковые ресурсы, пример лишь для знакомства.
Запустим пример и нажмём кнопку. В строке состояния появится значок. Раскроем уведомление и увидим текст. Уведомление можно смахнуть в сторону для удаления.


Затем можете снова нажать кнопку и создать новое уведомление. Покормили кота, снова удалили уведомление. А можете нажать несколько раз, но уведомление будет только одно. Так что, если кот научится нажимать кнопки, то не сможет создать бесконечную ленту уведомлений.
Реакция на уведомления
Нажатие на уведомление ни к чему не приведёт. Нужен дополнительный код.
Создадим новые объекты Intent и PendingIntent, которые описывают намерения и целевые действия. В нашем случае мы хотим запустить нашу активность, когда пользователь среагирует на уведомление. Присоединяем объекты через setContentIntent().
Теперь можно создать уведомление и затем закрыть приложение. Если нажать на уведомление, оно откроет заново ваше приложение.
Сделаем уведомление более красивым, добавив другие необязательные настройки.
Теперь в уведомлении мы видим картинку. Метод setTicker() выводит сообщение в строке состояния на короткое время, а затем исчезает. Это работает только на старых устройствах и сейчас можно уже не использовать.

Как я уже упоминал, если вам нужно обновить уведомление, то просто ещё раз отправьте его устройству под этим же идентификатором, но с другим текстом и картинкой.
Если уведомления разного типа, то нужно обновлять идентификаторы. Вспомним урок по подсчёту ворон и изменим код.
Теперь будут появляться новые уведомления. Обычно выводятся три значка для одного приложения (на новых устройствах), потом они группируются и на экране остаётся только один значок. Проверьте самостоятельно.
Совсем не обязательно запускать своё приложение, хотя это является распространённой практикой. Можете задать нужное поведение, например, запустить свой сайт по указанному адресу. Переделаем код:
Можно вывести индикатор прогресса, чтобы указать текущий ход выполнения задачи. Можно установить бесконечное выполнение:
Удаление собственных уведомлений
Вы можете из программы удалить своё уведомление, посланное по глупости (не вздумайте удалять уведомления про кормёжку кота!).
Если уведомления с указанным идентификатором не будет, то ничего страшного при удалении не произойдёт, поэтому проверку не нужно устраивать.
Использование настроек по умолчанию
Можно добавить вибрацию, звуковой сигнал или мерцание светодиодами для ваших уведомлений при помощи настроек по умолчанию. В свойстве defaults вы можете сочетать следующие константы:
- Notification.DEFAULT_LIGHTS
- Notification.DEFAULT_SOUND
- Notification.DEFAULT_VIBRATE
Чтобы к уведомлению добавить звук и вибрации по умолчанию, используйте код:
Если хотите установить сразу все значения по умолчанию, задействуйте константу Notification.DEFAULT_ALL.
Звуковое сопровождение
Использование звуковых оповещений для уведомления пользователя о событиях, связанных с устройством (например, входящий звонок), стало привычным. Большинство стандартных событий, от входящих звонков до новых сообщений и низкого заряда батареи, объявляются с помощью звуковых мелодий. Android позволяет проигрывать любой звуковой файл на телефоне в качестве уведомления. Чтобы это сделать, нужно присвоить свойству sound путь URI:
Также можно использовать собственный звуковой файл, загруженный на устройстве или добавленный в проект в качестве ресурса.
Виброзвонок
Вы можете использовать функцию виброзвонка в телефоне, чтобы сопровождать ваше уведомление вибрацией для привлечения внимания пользователя.
Чтобы использовать виброзвонок, передайте в свойство vibrate объекта Notification массив значений типа long. Постройте массив, учитывая, что значения, отвечающие за продолжительность вибрации (в миллисекундах), чередуются со значениями, которые означают длину паузы между вибрациями.
Прежде чем использовать виброзвонок в своем приложении, необходимо получить нужные полномочия, прописав их в манифесте:
В следующем примере показано, как изменить уведомление, чтобы одна секунда вибрации сменялась одной секундой паузы на протяжении пяти секунд:
Светодиодная индикация
Объект Notification включает в себя свойства для настройки цвета и частоты мерцания светодиодов устройства. Здесь стоит обратить внимание, что конкретные модели устройств могут не содержать светодиодные индикаторы или иметь другие цвета.
Свойство ledARGB может устанавливать цвет для светодиодной подсветки. Свойства ledOffMS и ledOnMS позволяют регулировать частоту и поведение светодиодов. Вы можете включить светодиоды, присвоив свойству ledOnMS значение 1, а ledOffMS – 0. Присвоив им обоим значения 0, светодиоды можно выключить.
Настроив работу со светодиодами, необходимо также добавить флаг FLAG_SHOW_LIGHTS к свойству flags объекта Notification.
В следующем фрагменте кода показано, как включить на устройстве красный светодиод:
Текущие и настойчивые уведомления
Вы можете делать уведомления текущими и/или настойчивыми, устанавливая флаги FLAG_INSISTENT и FLAG_ONGOING_EVENT. Уведомления, помеченные как текущие, используются для представления событий, которые выполняются в данный момент времени (например, загрузка файла, фоновое проигрывание музыки). Текущие уведомления необходимы для сервисов, работающих на переднем плане. Пример установки флагов:
В расширенной статусной строке текущие события отделены от обычных, чтобы вы сразу могли их отличить.
Настойчивые уведомления непрерывно повторяют звуковые сигналы, вибрируют и мерцают светодиодами, пока не будут остановлены. Подобные уведомления, как правило, используются для событий, которые требуют немедленного и своевременного внимания, таких как входящий звонок, срабатывание будильника или время кормёжки кота. В следующем фрагменте кода показано, как сделать уведомление настойчивым:
В методе getActivity() может понадобиться изменить флаг, например.
Существуют и другие флаги. Хотя в большинстве случаев используется просто 0.
В Android 5.0 пользователь может установить собственный уровень оповещений, нажав на кнопки увеличения громкости на домашнем экране. Появится диалоговое окно, в котором задаётся один из трёх доступных уровней.

Запустить запущенную активность
Не сразу бывает заметно, но на самом деле, когда при нажатии на уведомлении у вас запускается активность, то запускается не старая активность, которая была на экране до этого, а новая. Это можно увидеть в примере, если, например, есть текстовое поле с текстом. Введите какой-нибудь текст в активности, а потом создайте уведомление, вызывающее активность. Вы увидите, что запустится новая активность с пустыми текстовым полем, хотя мы ожидали увидеть запущенную активность. Если вам нужен именно этот вариант, то используйте флаги для намерения.
Либо вы можете прописать в манифесте для нужной активности атрибут android:launchMode=»singleTop».
Меняем цвет значка
По умолчанию, значок выводится в сером круге. Вы можете изменить цвет круга, вызвав новый метод setColor(), который появился в API 21:

Анимированный значок для уведомления
Покажу один фокус. Возьмём код из примера и заменим одну строчку, которая отвечает за вывод маленького значка — .setSmallIcon(android.R.drawable.stat_sys_upload):
Запускаем код и создаём уведомление. Вы увидите, что в строке состояния выводится анимированный значок стрелки. Такой способ стоит использовать для действительно важных сообщений, чтобы понапрасну не раздражать пользователя.

Возможно, если вы опустите метод setTicker(), то значок уже не будет анимированным, где-то работало, где-то нет. Проверяйте самостоятельно.
Вы можете попробовать поискать другие системные анимации, например, android.R.drawable.stat_sys_download или создать собственную анимацию.
На странице http://forum.xda-developers.com/showthread.php?t=1088677 энтузиасты выложили несколько готовых примеров анимации, которые можно скачать.
Расширенные возможности уведомлений
В Android 4.1 Jelly Bean появились дополнительные возможности для уведомлений через настройку стилей.
Добавьте на экран четыре кнопки.
Уведомление с тремя кнопками
Начнём с первого варианта. Теперь в уведомлениях можно размещать до трёх кнопок. Это может быть удобным, если приложение состоит из нескольких активностей или нужно предложить три разных варианта развития сценария. За появление кнопок в уведомлении отвечает метод setAction().

Обратите внимание, что у кнопок текст может обрезаться и пользователь не увидит текст, поэтому вам следует придумать «говорящие» значки, по которым будет понятен смысл нажатия. В нашем примере при нажатии на любой из трёх кнопок запустится вторая активность.
На некоторых устройствах можно увидеть уведомление без значков и с текстом. Также были варианты, когда выводились только значки.

Уведомление с длинным текстом. BigTextStyle().bigText()
Если вы внимательно смотрели на уведомление, то могли увидеть, что длинный текст, помещённый в метод setContentText(), вывелся на экран не полностью. Если информация слишком важная и вам хочется её показать в уведомлении полностью, то подойдёт вариант со стилем BigTextStyle:

Уведомление с большой картинкой: BigPictureStyle().bigPicture()
Пример с большой картинкой аналогичен с предыдущим примером. Только мы задаём уже другой стиль для уведомления. Вместо стиля длинного текста используется стиль BigPictureStyle().bigPicture():

Слишком большая картинка будет обрезана.
Уведомление в стиле InboxStyle
Есть ещё один стиль InboxStyle, напоминающий стиль писем в папке Входящие. Стиль разместит до пяти ваших строк в виде списка. Весь код приводить не буду, меняется только вызов setStyle()

Уведомление в стиле мессенджера: MessagingStyle
Стиль MessagingStyle пригодится для отображения сообщений из мессенджера или чата. Появился в Android Nougat.
В конструкторе MessagingStyle вы должны указать имя текущего пользователя, который будет видеть свои сообщения.
У класса Person есть другие полезные методы: setIcon() (значок), setData() (картинки) и др.
В setConversationTitle() указываем название беседы, удобно при разговоре двух и более котов. В поздних версиях не имеет эффекта, можно убрать.
Разговор строится через цепочку вызовов методов addMessage(), в которых указывается текст сообщения, время, отправитель. Количество сообщений может быть любым. При большом количестве (задано в MessagingStyle.MAXIMUM_RETAINED_MESSAGES) старые сообщения начнут удаляться автоматически.

Подводя итоги, следует отметить, у уведомлений очень много методов, которые можно использовать в своём приложении. Вот как может выглядеть полный набор:
- setSmallIcon() устанавливает маленький значок, который выводится в строке состояния, а также в правой части открытого уведомления.
- setLargeIcon() устанавливает большой значок, который выводится в открытом уведомлении слева.
- setWhen() определяет время для уведомления, по умолчанию время создания уведомления
- setTicker() выводит временную строку в строке состояния, которая затем исчезает. Остаётся только маленький значок (см. выше)
- setNumber() добавляет число справа от уведомления (не везде работает)
- setShowWhen() — показывать ли время в уведомлении (в Android 7.0 по умолчанию не показывается)
- setUsesChronometer() выводит счётчик вместо времени, показывающий сколько прошло от времени when. Полезно для уведомления секундомера или звонка
- setContentInfo() добавляет текст справа от уведомления (в новых версиях сверху)
- setColor() закрашивает значок и название приложения указанным цветом
- setOngoing() выводит уведомление поверх обычных уведомлений, такое уведомление нельзя закрыть или смахнуть.
- setVibrate() — виброзвонок
- setSound() — звук
- setLights() — цвет LED-индикатора
- setPriority() устанавливает приоритет от -2 (NotificationCompat.PRIORITY_MIN) до 2 (NotificationCompat.PRIORITY_MAX)
- setTimeoutAfter() (появилось в API 26) — устанавливает таймаут, после которого уведомление удалится
- setProgress() — индикатор прогресса
Приоритет
Не все уведомления одинаковы важны. Например, напоминание о том, что пора кормить кота — это сверхважное сообщение (не обсуждается). Угроза землетрясения, цунами, урагана — тоже очень важные сообщения. Новые версии программы, новое письмо и т.д. — не слишком важные уведомления, которые можно почитать после того, как покормили кота.
В API 16 появился новый метод setPriority() с константами по мере увеличения: NotificationCompat.PRIORITY_MIN, NotificationCompat.PRIORITY_LOW, NotificationCompat.PRIORITY_DEFAULT, NotificationCompat.PRIORITY_HIGH, NotificationCompat.PRIORITY_MAX.
Чем выше приоритет уведомления, тем выше он находится среди остальных уведомлений. Таким образом, важные сообщения всегда будут наверху, даже если поступили позже других менее важных сообщений. Не злоупотребляйте этой возможностью и трезво оцените важность вашего уведомления.
В Android 5.0 произошли небольшие изменения в поведении. Если установлены максимальные приоритеты Notification.PRIORITY_HIGH или Notification.MAX, то при вызове сначала уведомление появится в виде плавающего окна в верхней части экрана, а только потом закроется и останется в виде стандартного уведомления в строке состояния.

В Android 8.0 вместо приоритетов стали использовать важность — IMPORTANCE_XXX.
Напоследок дам совет — читайте документацию. Google постоянно вносит какие-то изменения и добавления. Практически в каждой новой версии Android что-то менялось. Я не в состоянии отслеживать новинки и оперативно добавлять в статью.
Пример изменений, которые произошли в API 23:
- Удалили метод setLatestEventInfo()
- Добавили новые методы getLargeIcon() и getSmallIcon()
- Добавили новое поле класса CATEGORY_REMINDER и объявили устаревшими поля icon и largeIcon.
В уведомлениях можно использовать собственный макет, используя RemoteViews. Для стилизации макета изучите классы DecoratedCustomViewStyle и DecoratedMediaCustomViewStyle. Подключается через метод setCustomContentView().
В уведомлениях появилась возможность вводить собственный текст для ответа на какое-то сообщение. Для этого используется механизм Direct Reply, который использует RemoteInput API.
NotificationListenerService. Прослушка уведомлений
В API 18 (Android 4.3) появился новый класс NotificationListenerService, позволяющий следить за уведомлениями. С тех пор я не следил за этой темой. Материал был написан по горячим следам в 2015 году. Если не работает, то разбирайтесь самостоятельно.
Новый класс является службой, которая получает сигналы от системы, когда появляются или удаляются уведомления. Таким образом вы можете отслеживать не только свои уведомления (они и так вам известны), но и уведомления от других приложений. Это может быть полезным для каких-то расширений к приложениям.
Вам нужно наследоваться от данного класса, зарегистрировать его в манифесте с разрешением BIND_NOTIFICATION_LISTENER_SERVICE и включить в него специальный фильтр намерения.
У службы есть два метода onNotificationPosted() и onNotificationRemoved() с параметром StatusBarNotification, который содержит полезные методы об уведомлении.
Пользователь должен явно разрешить приложению следить за уведомлениями через Настройки | Безопасность. Если на устройстве нет приложений, которые следят за уведомлениями, то в настройках вы не увидите никаких пунктов о разрешении. Когда вы создадите такое приложение, то там появится новый пункт Доступ к уведомлениям.

Щёлкнув на нём, вы попадёте на страницу со списком программ, желающих следить за уведомлениями. Поставим флажок у своей программы.


После этого в настройках будет указано число приложений, имеющих соответствующее разрешение.

Перейдём к практической части. Подготовим разметку из нескольких кнопок и текстовой метки для вывода информации.
Создадим новую службу.
В манифесте добавляем новый блок.
Первая кнопка запускает уведомление, чтобы увидеть, что приложение работает. Если вы хотите увидеть, как приложение следит за другими уведомлениями, то запустите Play Market и скачайте какую-нибудь игру или программу. Во время скачивания и установки генерируются уведомления. На следующем скриншоте видны уведомления от приложения Загрузки во время скачивания (com.android.providers.downloads) и от процесса установки (com.android.vending).

Если вы помните, в предупреждающем сообщении говорилось о возможности удалять уведомления. Третья кнопка позволяет это сделать. Вот почему эта настройка относится к разделу безопасности — ваша программа может удалять поступающие уведомления без ведома владельца устройства.
Вы можете программно запустить раздел с разрешением на использование службы.
«БИП: Бизнес-Процессы». Примеры использования. Часть №5. Система оповещений
Это продолжение предыдущих частей Часть №1, Часть №2, Часть №3 и Часть №4, в которых речь шла о различных вариантах и аспектах использования системы


«БИП: Бизнес-Процессы».- Часть №1: «БИП: Бизнес-Процессы». Примеры использования. Часть №1.
- Часть №2: «БИП: Бизнес-Процессы». Примеры использования. Часть №2.
- Часть №3: «БИП: Бизнес-Процессы». Примеры использования. Часть №3. Права и связи.
- Часть №4: «БИП: Бизнес-Процессы». Примеры использования. Часть №4. Графика.


Программный продукт «БИП: Бизнес-Процессы» предназначен для настройки произвольных бизнес-процессов в пользовательском режиме в любых конфигурациях 1С, работающих на технологической платформе «1С:Предприятие 8.3» в режиме управляемого приложения. Продукт может использоваться как отдельная конфигурация для моделирования бизнес-процессов, как дополнение для встраивания в существующие конфигурации и как расширение. Каждый вариант сертифицирован и имеет официальный статус «1С:Совместимо!».
Программный продукт предлагается в 2 вариантах:
- Основная поставка
«БИП: Бизнес-Процессы»; - Базовая версия
Расширение для настройки бизнес-процессов «Зодиак».
Эта часть будет посвящена автоматической системе оповещений по сценариям в системе


«БИП: Бизнес-Процессы».
- В интерфейсе программы подсистема вынесена в отдельный раздел.

Описание функционала

Подсистема «Сигнал» включает набор инструментов, предоставляющих следующие возможности:
- настройка правил формирования и отправки автоматических оповещений (сообщений) пользователям в рамках сценариев подсистемы


«БИП: Бизнес-Процессы». - настройка правил формирования и отправки автоматических оповещений группам пользователей.
- выбор типа оповещения. В текущей версии доступны оповещения:
в системе взаимодействия;
- в рамках общих обсуждений,
- в рамках контекстных обсуждений.
- для простой отправки автоматических уведомлений пользователям,
- использование чат-бота для взаимодействия с системой.
Подсистема
«Сигнал» не влияет на функционирование подсистемы 

«БИП: Бизнес-Процессы», а работает параллельно с ней.
После подключения подсистемы на форме сценария появляется дополнительная кнопка Настройка оповещений .

Чтобы не перегружать форму настройки сценария, весь функционал настройки оповещений вынесен на отдельную форму.

Правила отправки оповещений указываются для любого шага сценария.
При этом, для 1 шага может быть добавлено несколько правил оповещения.
Это может использоваться в следующих случаях:
- для шагов вида
Выбор варианта и
Условие, когда для различных вариантов и при разных результатах проверки условий должны отправляться разные оповещения. - для других шагов, когда требуется отправлять несколько оповещений (например, для одних пользователей по электронной почте, для других — в систему взаимодействия и т.п.).
Добавление нового правила для шага осуществляется двойным щелчком по шагу в общем списке шагов сценария.
Виды событий
При добавлении нового правила требуется указать момент, в который будет отправлено оповещение.

Для шагов вида Действие (Задача) это могут быть события:
создание новой задачи;
взятие задачи в работу;
выполнение задачи.
просрочка задачи.

Для шагов вида Вложенный процесс это могут быть события:
- />создание нового вложенного процесса;
- />завершение вложенного процесса.
Для всех остальных шагов оповещения настраиваются для событий вида
Завершение шага: успешно завершился шаг
Старт (т.е. процесс по сценарию успешно запущен) — возникает событие «При выполнении шага
Старт», произведен
Выбор варианта (вручную пользователем или автоматически программой) — возникает событие «При выполнении шага
Выбор варианта» и т.д.Получатели
После установки вида события, требуется указать Получателя оповещения.

Получателем может быть:
- Автор процесса или задачи;
- Исполнитель задачи;
- Наблюдатель по задаче;
- Роль пользователя. В этом случае, оповещение получат все пользователи, наделенные указанной ролью;
- Произвольный пользователь из списка пользователей.
Типы оповещений
Когда Получатель указан, требуется выбрать тип оповещения:
- оповещение в
системе взаимодействия, - оповещение по
электронной почте. - оповещение в
Telegram.


Для того, чтобы пользователь успешно получил оповещение в системе взаимодействия, пользователь должен быть авторизован в этой системе. Если пользователь новый, то ему достаточно зайти в программу. После этого работа с системой взаимодействия будет для него доступна.

При типе оповещения Электронная почта, в настройках пользователя на закладке «Адреса, телефоны» должен быть указан адрес электронной почты.


Для того, чтобы пользователь успешно получал оповещения в Telegram, он должен быть внесен в список пользователей Telegram (см. инструкцию, входящую в комплект поставки расширения).
Текст сообщения
Сообщение для отправки вводится в отдельном окне и может содержать параметры.

- [_Процесс] — текущий процесс,
- [_Задача] — текущая задача,
- [_УсловиеВыбор] — результат проверки условия или выбора варианта.
Кроме основных параметров можно указать производные от них параметры в виде [Параметр.ИмяРеквизита]. Примеры использования:
- [_Процесс.Объект] — основной объект процесса. Источник события, при котором был запущен процесс, или объект, указанный при ручном создании процесса.
- [_Задача.Комментарий] — комментарий к выполненной задачи.
- и т.д.
Также, в квадратных скобках могут быть использованы прочие функции:
- [ТекущаяДата()],
- [вн_ОбщиеФункции.ПолучитьЗадолженностьКлиента(_Процесс.Объект)]
- и т.д.
Тема/Контекст оповещения

Если выбран тип оповещения Система взаимодействия, то требуется указать контекст оповещения.

Контекстом могут быть:
- Текущий процесс,
- Основной объект процесса,
- Текущая задача,
- Общее обсуждение. Общее обсуждение выбирается из общего списка общих обсуждений системы взаимодействия.



Если выбран тип оповещения Электронная почта, то требуется указать тему письма.


Если выбран тип оповещения Telegram, то в этом поле ничего указывать не требуется.
Настройка оповещений о просроченных задачах

Для типа события При просрочке задачи дополнительно требуется указать расписание оповещения о просрочке.

В расписании можно настроить:
- Периодичность отправки уведомлений о просроченных задачах.
Периодичность может быть указана в минутах, часах или днях. - Количество уведомлений о просроченных задачах.
Если количество повторов не указано (0), то уведомления будут отправляться до тех пор, пока задача не будет
Выполнена или
Отменена.
Обработка правил оповещений
Настроенное правило отображается в списке правил оповещений по сценарию отдельной строкой.

Теперь правило будет автоматически обрабатываться системой.
- События, при наступлении которых могут отправляться уведомления, записываются в регистр сведений «События» и обрабатываются регламентным заданием.
- По обработанным событиям, в соответствии с настроенными правилами, формируются оповещения.


*В оповещениях системы взаимодействия дополнительно выводятся ссылки на процесс и задачу.


- Оповещения сохраняются в регистре сведений «Сообщения» и отправляются автоматически при записи нового сообщения.

*Если оповещение отправляется в общее обсуждение системы взаимодействия, то получателями будут все участники этого обсуждения.
- Если, по каким-то причинам, отправка сообщения не удалась, то это сообщение сохранится в общем списке с отметкой об ошибке и детальным описанием причины этой ошибки.

- Система будет автоматически пытаться повторно отправить сообщение до тех пор, пока оно не будет отправлено или пока оно не будет вручную удалено из списка сообщений.
На примере выше, письмо будет отправлено получателю, как только у пользователя будет указан адрес электронной почты.



- Дополнительно, имеется возможность создать сообщение вручную. Оно будет отправлено автоматически при записи.
- Если в новом ручном сообщении указать будущую дату, то сообщение запишется с признаком отложенной отправки и будет обработано системой (отправлено) при наступлении указанной даты.

На изображении ниже приведен простейший пример настройки оповещений.
- Процесс состоит из 1 задачи.
- При
создании задачи отправляется оповещение Автору в контекстное обсуждение текущего процесса . - При
взятии задачи в работу отправляется оповещение Автору в контекстное обсуждение текущего процесса . - При
выполнении задачи отправляется оповещение Автору в контекстное оповещение текущего процесса .

Заключение
Подсистема
«Сигнал» позволяет повысить удобство использования системы 

«БИП: Бизнес-Процессы» за счёт расширения информационного пространства, в котором она функционирует.Система автоматических оповещений обеспечивает своевременное информирование сотрудников по ключевым этапам рабочих процессов, держит в курсе событий сотрудников, принимающих решения и контролирующих процессы предприятия, снижает вероятность несвоевременного выполнения задач и повышает качество работы в целом.
Система проста в подключении и настройке и доступна для использования с системой


«БИП: Бизнес-Процессы», начиная с версии 1.0.3.2.Похожие публикации:
- Как удалить канал из вайбера
- Hetman software что это за программа
- Какой адрес сервера писать в vpn
- Sql server 11 какая версия
Программа лояльности. Как поддерживать через разные каналы

“Удержать нельзя привлечь” – для опытного маркетолога правильная расстановка знаков препинания в этой фразе очевидна. В зависимости от особенностей бизнеса, привлечение нового покупателя может стоить в 5-10 раз дороже, чем удержание имеющегося. Более того, неумолимая статистика говорит, что средний чек у постоянных клиентов на 67% выше, чем у новичков.
Поэтому и ведется битва за каждого клиента, в которой все средства хороши.
Главный инструмент такой борьбы за сердца и кошельки, а точнее, за повторные продажи, – программа лояльности.
Мало создать и внедрить такую программу, наибольшая сложность состоит в том, чтобы заставить ее эффективно работать на ваш бизнес.
Что дает программа лояльности компании
По данным исследования COLLOQUY Loyalty Census, 57% участников выходят из программы лояльности из-за слишком сложного или длительного процесса накопления бонусов. В то же время 54% участников не проявляют активности. Почему так происходит? Потому что клиенты не увидели ценности в предложенной системе поощрений, по сравнению с затраченными усилиями.
Так что, если планируется внедрение бонусной программы лояльности, в первую очередь важно определить, что можно предложить клиентам в награду за верность, и почему это будет для них ценно.
С помощью системы лояльности для клиентов компания может решить такие вопросы:
- установить и поддерживать долгосрочные отношения со своей аудиторией;
- привлекать новых покупателей;
- повысить лояльность клиентов;
- увеличить размер среднего чека и продажи;
- отслеживать поведение покупателя. По данным бонусной карты можно выяснить предпочтения клиента, частоту и сумму покупок, его географическое положение.
Что будет с объемом продаж?
Действительно ли лояльные клиенты покупают больше? Исследования, проведенные в преддверии праздников, показывают, что да! И бонусы – новая валюта покупателей:
- 50% покупателей используют бонусы для приобретения подарков, которые они при отсутствии дополнительного стимула не приобретали бы;
- 41% – тратят баллы вознаграждения на незапланированные покупки себе;
- 26% – приобретают с помощью бонусов подарки тем, кого не собирались одаривать.
Такие цифры позволяют сделать вывод, что грамотно построенная система вовлечения клиентов приводит к увеличению объемов продаж.
Системы лояльности во всем многообразии
Под программой лояльности часто подразумевают дисконтную систему, но это не всегда и не совсем так. Скидка повышает ценность разовой покупки, а бонусы увеличивают шанс повторных заказов. Невозможно удержать покупателя только низкой ценой (как в случае с фиксированными скидками), поэтому часто используются бонусы и подарки. Так формируется приверженность клиента к определенному бренду или компании.
Важно, чтобы участники программы осознавали ценность накопленных баллов: на этом базируется эффект привлечения и удержания. Когда покупатель знает количество доступных бонусов, он придет именно в это заведение и вряд ли решит искать что-то другое. Что уже будет показателем формирования долгосрочного взаимодействия.
Выражать признательность своим клиентам можно по-разному. Основные модели удержания клиентов делятся на такие виды:
- материальные;
- нематериальные;
- многоуровневые;
- комбинированные;
- партнерские.
Про особенности каждого вида расскажем ниже, выбирайте подходящий и адаптируйте к своему бизнесу.
Материальные виды программ лояльности
Для многих клиентов и даже собственников бизнесов программа лояльности – это скидки в той или иной форме, поэтому с них и начнем.
Скидочные системы используют в таких видах:
Накопительная бонусная программа лояльности
Это самая распространенная и простая модель, при которой постоянным клиентам начисляют баллы за покупки, а при следующем обращении в компанию эти баллы превращаются в материальные выгоды: скидки, подарки, дополнительные услуги.
Внедряя такую систему лояльности, важно не усложнять. Мудреные условия начисления бонусов могут запутать не только покупателей, но и персонал, ответственный за предоставление вознаграждения. Здесь целесообразно придерживаться принципа: чем проще и понятнее, тем лучше
Правила начисления и использования бонусов нужно объяснить на берегу.
Например, в ювелирном интернет-магазине Gold.ua бонусная программа реализована следующим образом: за каждую единицу товара начисляются бонусы, количество бонусов за покупку указана на сайте рядом с ценой изделия.

Сумма бонусов указывается и в корзине при заказе украшения:

В момент активации бонусов клиенту приходит емейл о том, что бонусный счет пополнен.
Бонусами можно оплатить до 50% следующей покупки.
Подобные бонусные программы широко распространены в ритейле. Наибольшую эффективность они показывают в сферах с высокой частотой покупок: супермаркеты, кондитерские, магазины косметики, аксессуаров и т.д.
Альтернативный вариант реализации бонусной системы для клиентов
Бонусная система скидок может быть изменена в зависимости от специфики бизнеса компании.
Например, “Спортмастер” дополнил систему бонусов и добавляет баллы своим клиентам не только за покупки, но и за определенные действия или по случаю какого-нибудь события.
Как работает система:
- за покупки начисляются бонусы, которые можно использовать на следующие приобретения уже через 2 недели;
- дополнительные бонусы можно получить за выполнение условий: покупку на определенную сумму, самовывоз товара из магазина;
- бонусные баллы также могут быть начислены в честь праздничной даты: дня рождения, 8 марта, Дня защитника;
- бонусами можно оплатить до 30% стоимости покупки;
- бонусы, начисленные по условиям акций или в честь праздников, имеют ограниченный срок действия и сгорают, если не были использованы. Так компания стимулирует большую частоту покупок;
- о начислении бонусов клиента информируют по электронной почте и в Вайбере.


Чем привлекает клиентов такая программа:
- простотой получения бонусов (не нужно годами суммировать баллы, чтобы получить ощутимую скидку, можно воспользоваться баллами за акцию);
- весомостью скидок с использованием бонусов;
- понятными условиями начисления и расходования бонусных баллов.
Скидочная или дисконтная программа
Принцип работы похож на предыдущую. Различие в том, что накапливается оговоренная сумма покупок, и это дает право на постоянную скидку. Как только сумма покупок превышает условленный порог, размер скидки в процентном отношении увеличивается.
Дисконтную программу можно реализовать в простом или многоуровневом варианте.
Простой – может быть полезен на этапе открытия бизнеса для привлечения постоянных клиентов. Например: всем покупателям, совершающим покупки на большую сумму, чем устанавливает компания, выдается дисконтная карта с фиксированным процентом скидки на следующие покупки. На практике встречается редко. В качестве примера можно привести скидочную программу одного из киевских кинотеатров (сам кинотеатр называет ее бонусной). Посетителям предлагают купить за 420 гривен карту номиналом в 500 грн и потратить эти деньги на билеты в кино и продукцию в баре. Фактически это скидка в 16%:

Многоуровневая дисконтная программа предполагает дифференциацию скидок в зависимости от суммы сделанных заказов. Рассмотрим такую программу на примере магазина “Антошка”.
Стать участником программы лояльности и получить дисконтную карту может клиент, скупившийся на 100 грн и более. Чтобы сумма накапливалась, нужно перед оплатой каждой следующей покупки предъявлять дисконтную карту на кассе или вводить ее номер в форме заказа на сайте. Когда сумма заказов превысит 500 грн, начинают действовать скидки. Градация следующая:

При этом учитывается стоимость покупок за календарный год. Если в текущем году не накопилось заказов на сумму, за которую положена скидка, номинал карты понижается до предыдущего уровня. Это правило не распространяется на покупателей, совершивших покупки на 25 000 грн. Номинал их дисконтной карты остается неизменным.
Карты называются: Start, Start plus, Elite и Elite plus.
Использование данной системы позволяет не только поощрять постоянных клиентов, VIP, но и делает удобным сегментирование по категориям.
Нематериальные программы лояльности
Это предоставление подарков и/или услуг при выполнении определенных условий или же начисление бонусов с возможностью обменять их на призы.
Такую бонусную систему использует Starbucks. Накопленные бонусы можно обменять на блюдо из меню или напиток:

Комбинированная программа лояльности
Найти баланс между ценностью приза, частотой поощрения и усилиями для получения вознаграждения, при этом не упустить выгоду компании (если клиенты будут слишком быстро получать максимальное вознаграждение, программа не принесет ожидаемую прибыль) – вот основная задача маркетологов при подготовке системы лояльности. Поэтому виды поощрений часто миксуют для достижения лучшего эффекта.
При такой системе даже за наименьшее действие клиент получает призы или бонусы, а те кто демонстрируют лояльность годами, могут рассчитывать на более существенные награды. Этот подход позволяет удерживать внимание и поддерживать интерес к участию в программе.
Главное преимущество комбинированных моделей перед простыми бонусными и дисконтными заключается в том, что покупатель может получить как краткосрочные, так и долгосрочные выгоды.
Длительный и сложный процесс накопления не так интересен клиентам, т.к. интервал между покупкой и получением поощрения получается слишком продолжительным. Нередки случаи, когда они забывают о программе или не стремятся ей пользоваться.
В связи с этим комбинированные системы получили широкое распространение, особенно в бизнесе с большой приверженностью: в авиакомпаниях, hospitality-индустрии и страховании, а также в ритейле.
Для примера рассмотрим программу лояльности авиакомпании “МАУ”, Panorama club.
По ее условиям баллы лояльности начисляются в милях за все перелеты рейсами авиакомпании “МАУ” или компаний-партнеров. Накопленные мили можно обменять на авиабилеты. О начислении миль пассажиру сообщают письмом:

Участником программы может стать любой пассажир в возрасте от 2 лет.
Используются три категории карт:
- Временная – активируется при регистрации в программе;
- Classic – выдается при накоплении 3000 миль;
- Premium – до этой категории карта повышается при накоплении от 20 000 миль за календарный год.
Но не только возможность получить наградные билеты за накопленные мили привлекает клиентов в эту программу. Участники получают дополнительные преимущества:
- Повышение класса обслуживания на рейсах МАУ;
- Скидки в отелях и при аренде автомобилей;
- Приоритет в очередности заказов перед пассажирами, не участвующими в программе;
- Возможность перевозить дополнительный багаж и увеличить размер ручной клади;
- Скидки в компаниях-партнерах (15% для держателей карт Classic и 20% для обладателей статуса Premium).
Партнерские программы
Одна карта и много скидок – мечта каждого шопоголика. Это – о программе лояльности Fishka, в которой участвуют магазины одежды, обуви, электроники, косметики, супермаркеты, аптеки, автозаправки, турагентства и многие другие компании. Баллы можно накапливать и тратить в любых компаниях-участниках. Например: получить бонусы за покупку обуви в Intertop и израсходовать их на приобретение бензина на OKKO.
Вот далеко не полный перечень участников:

MAXI CARD – еще один пример партнерской скидочной программы. В числе участников – аптеки, магазины, кинотеатры, страховые компании.
Все актуальные предложения включаются в емейл-рассылки, которые подписчики получают от 2 до 4 раз в месяц. В письмах используется динамический контент. Так что акция тернопольского ресторана не будет показана киевлянам.
Вот пример письма:

Участие в партнерских программах не отменяет возможность разработки собственной программы лояльности.
Еще один вариант партнерки – когда бренд рассылает своим подписчикам предложения от дружественных компаний. Например, Приватбанк отправляет емейлы с подборками предложений партнеров или магазинов, где можно воспользоваться кредитом или услугой “Оплата частями”.
Вот такие письма:

Какие каналы используются для поддержания программы лояльности
Наш опыт показывает, что для поддержания лояльности покупателей чаще всего используется емейл в сочетании с другими каналами: “Вайбером”, СМС и мобильными пушами. Кстати, популярность последних растет с каждым днем, так как все больше ритейлеров и представителей HORECA запускают свои мобильные приложения, в которых и происходит основная коммуникация с пользователями. Здесь можно посмотреть информацию про действующие акции, сделать заказ, получить бонусы за покупку. Например, у ресторана Casta карта постоянного гостя интегрирована в приложение:

Автоматизация программы лояльности – дело, которому стоит уделить внимание. Какие процессы можно автоматизировать и какие каналы целесообразно использовать:
- начисление бонусов за покупку (емейл+СМС+мобильный пуш)
- уведомление об истечении срока действия бонусов (емейл+мобильный пуш)
- повышение номинала дисконтной карты (емейл+Viber+мобильный пуш)
- начисление подарочных баллов или предоставление скидки ко Дню рождения клиента (емейл+Viber)
- персональные рекомендации, на что потратить бонусные баллы (емейл)
- напоминание о наличии бонусов на счету (емейл)
Логика следующая: когда необходимо проинформировать участника программы, отправляются сообщения в нескольких каналах: по электронной почте, СМС и в мобильном приложении. Можно добавить проверку прочтения и, если клиент получил информацию, дальнейшую отправку уведомлений данной цепочки остановить. Почему здесь СМС? Этот канал дешевле “Вайбера”. Если нет необходимости показывать красивую картинку, текстовое сообщение хорошо справится с задачей.
Когда важен визуал, в цепочке лучше использовать Viber и емейл.
Если задача триггера не донести новую информацию, а просто напомнить о компании, то письма будет достаточно.
Повышайте лояльность омниканально
Примеры сценариев для поддержания программы лояльности
- Персональные рекомендации:

- начисление бонусов;
- информирование о дополнительных скидках ко Дню рождения (без проверки прочтения, так как поздравлений много не бывает и клиенту будет приятно внимание).

Скидки или бонусы?
На этот вопрос в каждой компании есть свой ответ. Во время подготовки материала мы заметили, что сейчас многие компании, долгое время использовавшие скидки для привлечения клиентов, переходят к системе бонусов.
Вот как изменилась программа лояльности сети ресторанов Gurmania:

Чего хотят клиенты?
Продолжая ресторанную тематику, обратимся к статистике. Каким системам поощрения отдают предпочтение сами посетители кафе и ресторанов? Компания Oracle провела исследование среди клиентов кафе и ресторанов в Великобритании, Франции, США, Бразилии, Австралии, Японии и поделилась такими данными:
- 71% потребителей, принявших участие в опросе, хотят получать скидки;
- 63% – желают получать подарки за посещения;
- Всего 6% опрошенных в Великобритании и Франции категорически не хотят становиться участниками программ лояльности.
В какой форме должна быть реализована программа поощрений:
- мобильное приложение – 40% ;
- пластиковые карты для участников – 62% ;
- карты для сбора отметок о посещении – 45% .

Как оценивать программы лояльности
Для определения KPI системы поощрений можно использовать один из трех методов оценки ее экономической эффективности:
- Узнать, сколько тратил покупатель до вступления в программу и после того, как стал ее участником.
- Сравнить прибыль от покупателей, участвующих в программе, и нет.
- Проанализировать отток среди участников программы и остальных клиентов.
Хватит думать, пора действовать!
Теперь, когда вы знаете гораздо больше о том, как повысить лояльность клиентов, приступайте к разработке и внедрению бонусной программы. А может, у вас появились идеи, как улучшить существующую? Делитесь с нами инсайтами, и пусть у вас станет больше лояльных клиентов!



































