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