Scott
В центре уведомлений нужно различать «я это видел» и «я с этим разобрался». Открытие обсуждения дизайна не означает, что вопросы в комментариях решены. Снятие отметки о непрочитанном не отключает будущие обновления. Когда эти действия объединены в один элемент управления, люди теряют своё место в работе или перестают получать сообщения об обсуждениях, за которыми ещё нужно следить.
Рассмотрим, как чтение, разбор личной очереди и подписки могут работать вместе на примере командного центра уведомлений о ревью дизайна. Цель — очередь, которую можно оставить и позже уверенно продолжить разбирать, а не счётчик, который ненадолго показывает ноль.
Прочтение, личная обработка и подписка отвечают на разные вопросы
Прежде чем проектировать действия в строке, определите смысл каждого состояния. Статус прочтения показывает, видел ли этот человек соответствующее обновление. Состояние в личной очереди — хочет ли он оставлять уведомление среди активных. Подписка — должен ли он получать будущие обновления. У самого ревью или задачи есть отдельное состояние, которое может быть общим для команды.
| Вопрос | Состояние в этом центре уведомлений | Чего оно не означает |
|---|---|---|
| Я видел текущее обновление? | Не прочитано / Прочитано | Прочтение не завершает ревью и не убирает его из активной очереди. |
| Это ещё нужно в моей очереди? | В активной очереди / Обработано в моей очереди | Завершение работы с уведомлением в личной очереди не закрывает обсуждение для команды. |
| Нужно ли присылать мне будущие обновления? | Отслеживается / Не отслеживается | Отключение обновлений не удаляет ревью и не меняет чьи-либо права доступа. |
| Хочу ли я сохранить это для дальнейшего обращения? | Сохранено / Не сохранено | Сохранение не обязательно делает уведомление непрочитанным, активным или отслеживаемым. |
Это независимые характеристики, а не четыре взаимоисключающих статуса. Ревью может одновременно быть прочитанным, активным, сохранённым и отслеживаемым. Необязательно показывать каждую характеристику отдельным значком, но действия должны сохранять эти различия.
Документация GitHub об уведомлениях (на английском) описывает отдельные действия для прочтения, завершения обработки, сохранения и отмены подписки. При этом некоторые последствия связаны: отмена подписки также убирает текущее уведомление. GitHub может уведомить человека снова при прямом упоминании, упоминании команды или запросе на ревью. Учитывайте эти документированные последствия, определяя правила своего центра уведомлений; отдельные элементы управления не всегда имеют независимые эффекты.
Определите, что представляет одна строка
В примере с ревью одна строка соответствует одному обсуждению — «Сообщение об ошибке при оформлении заказа». Три новых комментария в нём обновляют одну и ту же строку. Она показывает последнее событие и объясняет, почему человек получил уведомление, например: «Вас упомянули» или «Вы следите за этим ревью».
Такая группировка не даёт активному разговору занять весь список, но требует определиться с подсчётом. Значок «3» может означать три непрочитанных обсуждения, три непрочитанных события или три элемента, требующих действия. Выберите единицу подсчёта и объясните её. Здесь счётчик учитывает непрочитанные обсуждения только в активной очереди, без раздела «Обработанные». Перенос непрочитанного обсуждения в этот раздел исключает его из счётчика, даже если статус прочтения не меняется. Три комментария в одном активном непрочитанном обсуждении считаются одним обсуждением, а не тремя.
Явно поясняйте связанные показатели. Надпись «12 активных · 3 непрочитанных» показывает, что прочтение трёх обсуждений не опустошит рабочую очередь. Не называйте смешанный счётчик «Задачи», если он включает информационные обновления и разговоры, на которые не требуется отвечать.
Если в вашем продукте одна строка соответствует отдельному событию, определите, что происходит с предыдущими событиями после очередного изменения того же объекта. Способ группировки — дизайнерское решение; незаметное переключение между обсуждениями и событиями запутывает людей.
Добавьте в строку контекст для выбора следующего действия
Полезная строка отвечает на четыре вопроса, не заставляя открывать всё подряд: что изменилось, где это произошло, кто вызвал обновление, если это важно, и почему оно попало в эту очередь. Для обсуждения оформления заказа можно показать заголовок, название проекта, сообщение «Майя упомянула вас» и короткий фрагмент комментария.
Фрагмент должен добавлять полезный контекст, а не повторять заголовок. Вопрос «Можно объяснить, какие реквизиты карты нужно проверить?» помогает дизайнеру решить, стоит ли открыть ревью сейчас. Сообщение «Новый комментарий в обсуждении „Сообщение об ошибке при оформлении заказа“» почти ничего не добавляет к остальным полям.
Обозначайте непрочитанное не только едва заметным изменением цвета. Можно сочетать понятную подпись, точку с описанием для вспомогательных технологий и типографическое выделение. После прочтения заголовок и важный контекст должны оставаться разборчивыми: уменьшение акцента не должно превращаться в недостаточный контраст.
Относительное время помогает быстро просматривать список, но «Вчера» не должно быть единственной подсказкой о последовательности событий. При необходимости показывайте точное местное время и не меняйте смысл события только потому, что человек находится в другом часовом поясе.
Определите, когда обновление становится прочитанным
Выбор строки сразу отмечает её как прочитанную, делает это после загрузки панели подробностей или требует отдельного действия? Ответ должен соответствовать тому, что интерфейс действительно способен установить. Перемещение клавиатурного фокуса на строку не доказывает, что человек прочитал её содержимое.
В этом примере выбор строки загружает обсуждение в панели подробностей. Отмечайте доступное на этот момент обновление как прочитанное после успешного отображения содержимого. Если загрузка не удалась, сохраните статус непрочитанного и предложите повторную попытку. Не обнуляйте счётчик только потому, что сетевой запрос начался.
Новый комментарий может прийти, пока человек читает обсуждение. Отслеживайте, какое обновление было показано, а не просто устанавливайте логический признак при открытии панели. Если в панели показаны комментарии вплоть до события 18 включительно, а затем приходит событие 19, прежнее подтверждение прочтения не должно скрывать новое событие. Продукт может сразу показать новый комментарий или сообщить о доступном обновлении; в обоих случаях нужно последовательное правило прочтения.
Оставьте действие «Отметить как непрочитанное», если люди используют его как напоминание. Его результат должен быть личным и предсказуемым. При командном ревью такая отметка не должна сообщать автору, что его вклад отклонён, или сбрасывать чужой статус прочтения.
Позвольте вернуть обработанное уведомление в свою очередь
Ответив на вопрос об оформлении заказа, дизайнер отмечает уведомление как обработанное. В этом центре уведомлений обсуждение уходит из его активной очереди в личный раздел «Обработанные». Это не закрывает обсуждение для всех, не утверждает дизайн экрана и не удаляет комментарии.
Короткой метки «Обработано» достаточно, если из контекста интерфейса понятно, что она относится только к личной очереди. Если здесь же есть общее для команды действие «Завершить обсуждение», различайте их и по названию, и по расположению. Две галочки с разными последствиями легко перепутать.
Предусмотрите немедленную отмену действия и возможность вернуться к уведомлению позже через раздел «Обработанные». Когда строка исчезает, переводите клавиатурный фокус на подходящий соседний элемент или заголовок пустой очереди. Не оставляйте фокус на элементе управления, которого больше нет.
Определите, возвращает ли новое значимое событие обработанное уведомление в активную очередь. В этом примере новое упоминание возвращает обсуждение как непрочитанное, а не связанное с ним фоновое обновление — нет. Это явно выбранное правило данной очереди, а не универсальный принцип. Показывайте причину возвращения, чтобы статус «Обработано» не казался ненадёжным.
При отмене подписки объясняйте, какие уведомления будут приходить дальше
Действие «Перестать отслеживать» меняет доставку будущих уведомлений. В нашем центре уведомлений о ревью оно отключает обычные обновления, но оставляет текущее обсуждение там, где оно уже находится: в активной очереди или в разделе «Обработанные». Отметка об обработке остаётся отдельным действием. Объясните это рядом с элементом управления, чтобы отмену подписки не приняли за очистку текущей очереди.
В этом примере новое прямое упоминание всё равно возвращает обсуждение в активную очередь как непрочитанное, даже после отключения обычных обновлений. Подтверждение может звучать так: «Отключить обычные обновления? Вы по-прежнему будете получать уведомления, когда вас упоминают». Другие продукты могут делать исключения и для упоминаний команды или назначенных ревью; описывайте только те правила, которые продукт действительно поддерживает.
Не предлагайте общую кнопку отмены подписки для обновлений, которые нельзя отключить по правилам продукта. Вместо этого объясните доступную настройку. Кроме того, подписка не даёт права читать закрытое обсуждение: доставка уведомлений и доступ — разные вещи.
Проследите путь одного ревью в очереди
Следующая последовательность делает правила наглядными. Это предлагаемое поведение центра уведомлений о ревью дизайна, а не описание собственной системы уведомлений Pixso.
| Событие или действие | Результат в личном центре уведомлений | Результат в общем обсуждении |
|---|---|---|
| Майя упоминает дизайнера в обсуждении «Сообщение об ошибке при оформлении заказа». | Обсуждение появляется в активной очереди как непрочитанное; причиной получения указано упоминание. | Комментарий входит в существующее обсуждение. |
| Дизайнер открывает обсуждение, и его текущее содержимое загружается. | Показанное обновление становится прочитанным. Обсуждение остаётся активным. | Обсуждение не завершается, а дизайн не утверждается. |
| Дизайнер отвечает и отмечает уведомление как обработанное. | Обсуждение перемещается в личный раздел «Обработанные». | Ответ добавляется; обсуждение остаётся открытым, если его не завершили отдельным действием. |
| Приходит новое упоминание, пока дизайнер продолжает следить за обсуждением. | По правилам этой очереди обсуждение снова становится активным и непрочитанным. | Новый комментарий добавляется в то же обсуждение. |
| Дизайнер перестаёт получать обычные обновления. | Обычные обновления больше не приходят. Текущая строка остаётся в прежнем разделе; новое прямое упоминание всё равно вернёт её в активную очередь как непрочитанную. | Обсуждение и подписки остальных участников не меняются. |
Сохраняйте эти результаты согласованными в списке, панели подробностей и переходах по ссылкам из писем. Человек, вернувшийся из письма, должен попасть в нужное обсуждение или обновление, а не в необъяснимо пустой центр уведомлений из-за того, что элемент переместился в раздел «Обработанные».
Сохраняйте место пользователя при ошибках и изменении доступа
Действие со строкой может завершиться ошибкой уже после того, как интерфейс предварительно убрал её из списка. Если отметка об обработке не подтверждена, восстановите строку с понятным сообщением или иначе оставьте её доступной, обозначив незавершённое действие. Исчезновение строки не должно выглядеть как надёжно сохранённый результат, если сервер его отклонил.
Если самого объекта больше нет, объясните, что он недоступен, и разрешите убрать уведомление. Если доступ отозван, не продолжайте показывать сохранённый в кеше фрагмент закрытого обсуждения. Восстановление должно учитывать текущие права: ссылка из уведомления не позволяет обойти ограничения доступа.
При фильтре «Непрочитанные» прочтение строки может убрать её из списка. Не давайте панели подробностей исчезнуть раньше, чем человек закончит читать. Можно обновить список, оставив открытое обсуждение видимым и ясно обозначив выбор. Возврат к фильтру «Все» должен сохранять удобную позицию, а не перебрасывать к постороннему элементу.
Проверьте модель центра уведомлений в Pixso
Создайте в Pixso макет со списком и панелью подробностей, добавив несколько реалистичных обсуждений дизайна. Включите непрочитанное упоминание, прочитанное, но активное обсуждение, обработанное уведомление, которое возвращается после нового упоминания, и неудавшееся действие. Отдельно подпишите состояние личной очереди и состояние общего обсуждения.
Попросите участника проверки прочитать вопрос Майи, не убирая его из своей очереди, затем разобраться с ним и отключить обычные обновления. Выслушайте, каких последствий он ждёт от каждого действия. Если «Обработано» воспринимается как утверждение дизайна, сначала уточните текст или отделите общее действие и лишь затем дорабатывайте значки.
Свяжите основные состояния экранов для проверки и поясните поведение, которое ещё предстоит реализовать: подтверждение прочтения конкретного обновления, фокус после удаления строки, исключения из подписки и изменения прав доступа. Кликабельный прототип передаёт задуманную последовательность, но не доказывает, что эти правила уже реализованы.
Спроектируйте понятный центр уведомлений в Pixso →
Создайте очередь, на которую можно положиться
Счётчик непрочитанного помогает распределять внимание, личная отметка об обработке — организовать работу, а подписки управляют будущей доставкой. Не смешивайте эти обещания, позволяйте отменять изменения состояния и объясняйте, почему уведомление вернулось. Центр уведомлений становится полезным, когда люди могут предсказать, где будет их работа, а не просто обнулить значок.
