Отображение ошибок в интерфейсе, часть 2 – Выбор способа отображения ошибки в интерфейсе
Привет! Это Настя Овсянникова, старший дизайнер Липтсофт. Продолжаю серию статей для дизайнеров про ошибки и их отображение в интерфейсе.
В предыдущей части разобрались, как и почему возникают ошибки. Разделили на виды, выделили контексты появления. Пришли к выводу, что есть 16 ситуаций, для которых нужно дизайн-решение.
В этой части рассмотрим все 16 ситуаций и упакуем в простую схему выбора способа отображения ошибки в интерфейсе.
На всякий случай напомню: технические штучки и примеры буду приводить для десктопного веб-сервиса. Но всё это можно с некоторыми поправками отнести к любому сайту или приложению на разных устройствах.
Все статьи серии
Копаем вглубь:
1. Как возникают ошибки
Систематизируем:
2. Выбор способа отображения ошибки в интерфейсе (вы здесь)
3. Выбор контента для описания ошибки Пользователю
Микросовет
Если ваш продукт миновал стадию концепции и давно «живёт», я бы посоветовала сначала пробежаться по экранам и собрать в одном месте существующие способы отображения ошибок. Попробуйте соотнести их с предложенной схемой. Может, есть компоненты и паттерны, которые стоит объединить. Или наоборот, их недостаёт.
Вид ошибки + контекст появления = способ отображения
Мне кажется, информация дальше будет восприниматься легче, если одновременно поглядывать на схемы.
Сбой Клиента
Как все ошибки, он может возникнуть в 4-х контекстах:
- приём данных от Пользователя;
- скачивание или подгрузка данных по инициативе Пользователя;
- перенаправление на другую страницу;
- перенаправление в модальное окно.
Но как мы обсудили в первой части, сбой Клиента означает, что он не может отобразить Пользователю на экране вообще никакую информацию. Будет пустая белая страница. Это состояние может длиться долго. Если обновить страницу или перенаправить Пользователя на другую, она также будет пуста.
Мы в команде пришли к такому решению: при сбое Клиента перенаправлять Пользователя на особенную страницу в виде config-item-а. По сути это системная единица, параметр со значением. Самое важное – контент, который «хранится» в этом config-item-е, доступен всегда и Клиент может отобразить его в любых обстоятельствах.
Но такой config-item существует вне информационной архитектуры системы. Попав на него, нельзя определить, откуда мы пришли, кто мы как Пользователь, внутри какого сценария мы находились. Поэтому невозможно задать разные варианты текста ошибки в зависимости от контекста.
Мы решили сделать эту страницу похожей на полноэкранную ошибку. Задали обобщённый текст, который подойдёт для любой ситуации.
Разработчики не рекомендуют располагать на такой странице динамический контент или интерактивные компоненты, т.к. страница не связана с остальной системой.
Сбой Клиента – редкая ошибка. Но даже если она возникла, это не тупик для Пользователя. Можно самостоятельно снова зайти на сайт или перезапустить приложение.
Итак, сбой Клиента в 4-х контекстах – одно дизайн-решение (страница-config-item). Мы «закрыли» 4 ситуации из 16.
Результат валидации данных
Этот вид ошибок имеет смысл рассмотреть только в одном контексте – приём данных от Пользователя. Даже если следом мы автоматически перенаправляем Пользователя на другую страницу. В первую очередь всё же происходит приём данных.
Ошибку, которая относится к конкретному полю, лучше отобразить рядом с ним. Например, в нашем продукте это поле в состоянии error.
Ошибку, которая относится к группе полей, лучше расположить так, чтобы она была логически связана не с отдельным полем, а с группой. Мы, например, используем alert вида danger и располагаем вверху группы полей. У вас может быть другое-дизайн решение.
Суммируя, результат валидации данных в одном контексте – component error state или alert danger. Остальные три контекста не имеют смысла. Мы «закрыли» 8 ситуаций из 16.
Потеря связи с Сервером
Обычно можно определить, когда связи с Сервером нет из-за отсутствия интернета, а когда проблемы у самого Сервера. В нашем продукте для обеих ситуаций мы используем одни и те же дизайн-решения, но с разным текстом (о текстах подробнее в следующей части).
Приём данных от Пользователя
Пользователь кликает на элемент (например, кнопку «Заказать»), который отправляет введённые данные на Сервер. Это может произойти и на странице, и в модальном окне. В первом случае мы показываем компонент banner c соответствующим текстом (подробнее о текстах в следующей части).
Во втором случае мы показываем alert под заголовком окна.
Скачивание и подгрузка данных по инициативе Пользователя
В нашем продукте для этого контекста мы используем те же решения, что и для приёма данных выше. У вас может быть по-другому.
Перенаправление на другую страницу
Здесь важно, в какой момент потерялась связь с Сервером, до или после перенаправления. Если после, значит, мы не получили контент страницы «назначения». Можно показать, например, полноэкранную техническую ошибку.
Если связь с Сервером потерялась до перенаправления, то на странице мы показываем banner …
… а в модальном окне – alert.
Перенаправление в модальное окно
Аналогично, если связь с Сервером потерялась после перенаправления, значит, мы не получили контент модального окна «назначения». Можно показать, например, alert.
Если связь с Сервером потерялась до перенаправления, то на странице «отправления» мы показываем banner.
Из модального окна в другое окно лучше не перенаправлять, и таких ситуаций у нас в продукте нет.
Возможно, в вашем продукте работает фоновая проверка связи с Сервером: посылается запрос раз в несколько секунд. Тогда сообщение о потери связи может появиться на экране само по себе. Я бы рекомендовала допускать это, только если Пользователь находится на странице. Если он находится в модальном окне, можно подождать, пока Пользователь что-то кликнет или закроет окно, прежде чем показать сообщение об ошибке.
Итого: 4 контекста потери связи с Сервером, 4 группы дизайн-решений. Мы «закрыли» 12 ситуаций из 16.
Схема больше предыдущих, смотрите сразу в большом размере.
Мы добрались до середины второй части. Она запутаннее остальных. Всё получится 💪
Держите под рукой схемы.
Результат обработки данных и команд
Напомню, что если связь с Сервером есть, то он всегда присылает ответ на действия Пользователя – код состояния. Даже если Сервер «упал» – он сообщит об этом. Нас интересуют коды 4__ и 5__ – это ответы Сервера, которые указывают на ошибку.
Приём данных от Пользователя
Пользователь кликает на элемент (например, кнопку «Заказать»), который отправляет введённые данные на Сервер. Это может произойти и на странице, и в модальном окне. В нашем продукте в обоих случаях мы показываем alert вида danger c соответствующим текстом.
Мы решили всегда показывать такой элемент вверху блока, с которым происходило взаимодействие. Вы можете выбрать другое место.
Скачивание и подгрузка данных по инициативе Пользователя
У нас в продукте немного таких элементов. Мы показываем текстовую строку прямо под элементом – как подсказку у поля в состоянии error.
Перенаправление на другую страницу
Если ошибка возникла после перенаправления на страницу «назначения», отображается полноэкранная ошибка с соответствующим текстом.
Если ошибка возникла до перенаправления, то на странице мы показываем alert подвида danger вверху блока …
… а в модальном окне – alert.
Перенаправление в модальное окно
Если ошибка возникла после перенаправления, можно показать, например, alert.
Если ошибка возникла до перенаправления, то на странице «отправления» мы показываем alert.
Из модального окна в другое окно, опять же, лучше не перенаправлять.
Всё, мы «закрыли» последние 4 ситуации.
Схема в большом размере.
Схема выбора способа отображения ошибки
По моему опыту достаточно один раз внимательно вникнуть в суть возникновения ошибок. Потом пользоваться схемой быстрее и проще.
В первой версии гайда по ошибкам я пыталась разместить все случаи на одной картинке. Итог – замучилась и запуталась (хотя уверена, что это возможно). Сейчас нам удобно пользоваться одной из четырёх схем в зависимости от вида ошибки. По крайней мере, я уверена, что здесь учтены все ситуации.
В дизайн-системе или базе знаний такую схему можно сопроводить подробным описанием технического процесса. Описание будут читать новички и учиться пользоваться схемой.
Итак, для каждого вида ошибки мы определили элемент отображения во всех возможных контекстах. Какой там разместить текст (и другой контент) – в следующей части:
Отображение ошибок в интерфейсе, часть 3 – Выбор контента для описания ошибки Пользователю
