NDTR-mobile (Ru)
friendly Network Data Treatment Rules for mobile developers
Базовые правила работы с сетевыми данными для позитивного UX в мобильных приложениях
Введение
В этом документе описаны базовые правила по отображению сетевых данных, ошибок получения этих данных, а также отправки форм и кэширования данных. Эти правила, или скорее рекомендации, носят общий характер и универсальны для всех мобильных платформ.
Использование приведённых правил поможет предоставить пользователю более позитивный UX.
Приведённые правила не распространяются на приложения с подходом Offline-first.
Благодарность за ревизию: Кирилл Розов, Сергей Чемкаев
Общие правила
Загружать данные во время открытия страницы. Во время загрузки следует показать уже доступные данные (например, заголовок и аватар пользователя). Нельзя сначала загружать данные, а потом открывать страницу.
В случае ошибки загрузки данных, на открытой странице показать не исчезающее сообщение об ошибке. У пользователя должна быть возможность повторить запрос (обновить страницу).
Приложение не должно блокироваться во время получения данных (можно переходить на другие страницы приложения).
Приложение в некоторых случаях может блокироваться во время отправки данных формы (см. Отправка форм).
Сохранять данные формы, введённые пользователем, на случай неожиданного закрытия приложения или случайного закрытия формы. Сохранение паролей не производится.
Ошибки
Сообщения об ошибках должны быть информативны для пользователя. Пользователь должен понимать, что операция не удалась, с указанием причины ошибки в общем виде (не нужно показывать детальную информацию об ошибке, например номер ошибки). Также нужно предложить пользователю вариант дальнейших действий.
Для простоты все ошибки, которые могут возникнуть в приложении, можно разделить на три группы: Проблемы с сетью, Ошибки от сервера, Ошибки в полученных данных. Далее перечислены случаи для обработки ошибок этих групп, а также примеры сообщений курсивом.
Ошибки сети
- Отсутствует соединение:
Нет подключения к сети - Таймаут:
[название сервиса/приложения] не отвечает, попробуйте позже
Ошибки сервера
- Обработать известную ошибку
- Неизвестная ошибка:
Невозможно получить [название страницы], попробуйте позже
Например: Невозможно получить профиль Андрея И, попробуйте позже
Ошибки в полученных данных
Полученные данные из сети удобно разделить по значимости на обязательные и дополнительные. Обязательные данные несут важную информацию, без которой отображение соответствующей страницы/секции не имеет смысла.
Проверять на валидность нужно как обязательные, так и дополнительные данные.
Например, для создания push-уведомления о сообщении от пользователя, обязательными является имя отправителя и его сообщение. Остальные данные здесь являются дополнительными.
- Если какие-либо обязательные данные некорректны, нужно показать пустую страницу/секцию с сообщением:
Ошибка получения [название страницы/секции], попробуйте позже - Если какие-либо обязательные данные некорректны, и требуется выполнить какую-то операцию с полученными данными, то эту операцию нужно отменить (см. выше пример с push-уведомлением)
- Невалидные дополнительные данные на странице/секции обозначается текстовым предупреждением или значком в месте размещения этих данных:
Не удалось получить [описание данных]
Например: Не удалось получить расписание работы офиса
Асинхронные сетевые операции, инициированные пользователем
Операция получения данных
В момент запуска запроса нужно блокировать или скрыть элемент интерфейса (кнопку), с помощью которого был запущен запрос, чтобы избежать повторного запуска. Возможно отображение прогресса в месте появления запрашиваемых данных.
Если операция завершилась успешно, вызывающий элемент интерфейса (кнопка) становится активным или же скрывается, если не предполагается повторный вызов операции.
В случае ошибки в операции, нужно показать исчезающее сообщение, только если пользователь находится на странице операции, а вызывающий элемент интерфейса (кнопка) становится снова активным. Если пользователь успел покинуть страницу до получения данных, сообщение об ошибке показывать не нужно.
Сохранение состояния
Если есть подключение к сети, нужно сразу же показывать успешное выполнение операции и одновременно выполнить запрос на бэкенд. Если операция завершилась с ошибкой, нужно отобразить предыдущее состояние соответствующих элементов, а также показать сообщение об ошибке. Сообщение об ошибке может быть исчезающим, если пользователь находится на странице операции. Если же пользователь успел перейти на другой экран и не видит изменений интерфейса в результате ошибки, нужно показать диалог с сообщением ошибки, в котором будет указано, что именно не удалось выполнить и по какой причине (см Ошибки). Во время выполнения операции не нужно показывать прогресс.
Формы
Неблокирующая форма
Если результат отправки данных не влияет на дальнейшую логику использования приложения пользователем, нужно закрыть страницу/секцию формы сразу после её отправки, предварительно сохранив данные формы локально. В случае ошибки отправки формы, нужно сообщить о ней в виде диалога на любой странице приложения. Если отправка формы является ключевой механикой приложения, следует присылать push-уведомление с ошибкой при закрытом приложении. В диалоге или push-уведомлении нужно предложить варианты действий для этой формы: Повторить (отправку), Отменить (отправку) и Повторить позже. Вариант Повторить позже может быть реализован по-разному: автоматическая отправка или напоминание о повторе операции. Если в приложении реализована автоматическая отправка, нужно сообщить об этом пользователю.
Блокирующая форма
Нужно блокировать поля формы и кнопку отправки, показать прогресс и заставить пользователя дождаться окончания операции. После успешной отправки формы нужно сразу отобразить следующую страницу. В случае ошибки нужно показать диалог или исчезающее сообщение об ошибке, остаться на текущей странице и разблокировать все элементы формы.
Кэширование
Кэширование данных, полученных из API
По возможности желательно кэшировать данные, полученные из API. Такое кэширование поможет улучшить UX (пользователь видит данные мгновенно), а также снизит нагрузку на API. Нужно продумать, на каком уровне разумнее применять кэширование. Например, кэширование поисковых запросов лучше реализовать на стороне API, а данные страницы профиля пользователя лучше кэшировать в мобильном приложении. Размер кэша для одной сущности определяется в зависимости от сценариев использования приложения. Например, кэш профиля пользователя может содержать только одну сущность, так как обычный сценарий с профилем заключается в просматривании его информации, а также контента пользователя, из которого будет осуществлен переход обратно в профиль. Кэш должен иметь срок годности (актуальность данных). Например, кэш профиля пользователя имеет время актуальности 5 минут. Это значит, что в течение этого времени, при открытии профиля, будут показаны данные из кэша без запроса к API. По истечении срока актуальности кэша, при открытии профиля, следует отобразить данных из кэша и сделать запрос к API, чтобы получить обновлённые данные профиля, затем отобразить их и сохранить в кэше. Если не удалось получить данные из API, нужно показать соответствующее сообщение об ошибке (см. Ошибки).
