Типографика экрана ожидания в мобильном приложении: статус и следующий шаг

Экран ожидания становится понятным, когда текст отвечает на три вопроса: что приложение делает, что уже известно о ходе работы и что пользователь может сделать сейчас. Если длительность операции неизвестна, не обещайте проценты и минуты: поставьте короткий статус на первое место, объясните причину ожидания вторым уровнем, а безопасное действие покажите отдельно. Так анимация не остаётся единственным сигналом.
Почему одного индикатора недостаточно
Круговой спиннер или движущаяся полоска показывают, что интерфейс занят, но не объясняют предмет ожидания. Пользователь может ждать обработки фотографии, загрузки файла, синхронизации списка или ответа сервера. Для него это разные ситуации: одну можно прервать без последствий, другая уже отправляет данные, а третья может завершиться в фоне.
Текстовая иерархия должна снять неопределённость без лишнего чтения. В верхней строке назовите действие: «Загружаем снимок» или «Сверяем данные». Ниже добавьте объяснение только там, где оно помогает принять решение: например, «Можно свернуть экран — мы сообщим, когда обработка завершится». Не дублируйте заголовок словами «Пожалуйста, подождите».
Полезно различать две характеристики операции. Если система действительно знает выполненную долю задачи, можно показывать измеримый прогресс. Если длительность или объём работы заранее неизвестны, используйте неопределённый индикатор и сообщайте о состоянии словами. Это соответствует различию determinate и indeterminate индикаторов в рекомендациях Apple для платформ её экосистемы; выбор формы индикатора зависит от конкретной платформы и компонента.
Разложите сообщение на три текстовых уровня
Соберите экран из трёх ролей, а не из набора равноправных подписей.
- **Статус** сообщает действие и меняется только при реальном переходе: «Подключаемся к серверу», «Обрабатываем файл», «Готовим результат».
- **Пояснение** описывает причину, ограничение или ожидаемое последствие: «Пока экран открыт, не закрывайте приложение» — только если это действительно важно; «Файл останется в очереди, если свернуть приложение» — только если это гарантирует продукт.
- **Действие** даёт выход или выбор: «Отменить», «Продолжить работу в приложении», «Повторить» после ошибки. Название действия должно отражать результат нажатия.
Для каждого уровня назначьте отдельный текстовый стиль в дизайн-системе. Заголовок статуса может быть заметнее вспомогательной строки, но не обязан выглядеть как рекламный заголовок. Используйте различие размера, веса и цвета умеренно: если заголовок, проценты, подпись и кнопка одновременно крупные и полужирные, внимание не понимает, куда направиться. Сначала проверьте контраст и читаемость на обычном экране, затем — при системном увеличении текста.
Не превращайте неизвестную длительность в фиктивную точность
Процент имеет смысл только тогда, когда отражает реальный измеримый этап. Если сервер не отдаёт долю завершённой работы, надпись «73%» создаёт ложное обещание и может надолго замереть. Та же проблема возникает с таймером «Осталось 10 секунд», когда приложение не может оценить оставшееся время.
Вместо выдуманной шкалы используйте спокойное, предметное сообщение и неопределённый индикатор. Если процесс состоит из понятных этапов, перечислите текущий этап без псевдоточности: «Проверяем файл», затем «Собираем результат». Не показывайте будущие этапы как выполненные. И не меняйте подпись каждую секунду ради ощущения активности: частое мигание и переформулировки заставляют перечитывать экран и могут мешать экранному диктору.
Когда точный прогресс известен, подпишите, что именно измеряется. «Загружено 4 из 10 файлов» понятнее, чем одинокие «40%», если задача состоит из отдельных объектов. Для файла в мегабайтах указывайте уже переданный объём только при наличии достоверных данных. Единицы измерения, числа и глагол действия должны быть собраны в одну короткую строку, а не разбросаны между индикатором и подписью.
Сохраните ясность на узком экране и при крупном тексте
Экран ожидания часто появляется вместе с системной клавиатурой, в листе поверх другого экрана или на компактном телефоне. Длинное пояснение может перенестись на несколько строк, а нижняя кнопка — оказаться под клавиатурой. Не решайте это уменьшением шрифта до нечитаемого размера или многоточием в ключевом статусе.
Проверьте сообщение на короткой ширине, при увеличенном системном размере текста и с длинной локализованной формулировкой. Статус должен естественно переноситься на вторую строку. Пояснение можно сделать сворачиваемым или убрать, если оно не меняет поведение. Кнопке отмены оставьте место, а если операция не отменяется — не показывайте отключённый «Отменить» без объяснения. Для разных языков проверяйте не только длину строки, но и высоту букв, диакритические знаки и переносы.
Если интерфейс перекрывает контент, выберите соответствующий контейнер: полноэкранное состояние уместно, когда продолжение работы невозможно; компактный индикатор рядом с обновляемым разделом удобнее, когда остальная часть приложения остаётся доступной. Не заставляйте пользователя читать отдельную страницу, если задача локальна для одной карточки. Текстом назовите объект: «Обновляем список поездок», а не «Загрузка».
Подберите слова для разных сценариев ожидания
Представьте обработку фотографии в приложении. На первом шаге напишите «Загружаем фотографию», под ним — «Можно оставить приложение открытым». Если пользователь вправе уйти, замените совет на точное обещание: «Можно перейти в другой раздел — обработка продолжится». В ходе операции показывайте следующий этап лишь тогда, когда приложение действительно перешло к нему. После завершения используйте отдельное состояние результата, а не оставляйте спиннер рядом с сообщением «Готово».
Для сетевой синхронизации подойдёт формулировка «Синхронизируем изменения». Если пользователь может продолжать редактирование, поясните, сохраняются ли новые правки локально. Если соединение потеряно, статус должен стать конкретным и предложить действие: «Нет соединения. Проверьте интернет и повторите синхронизацию». Простая замена текста на «Ошибка» не помогает понять, что произошло.
Фразы «Это займёт некоторое время» и «Скоро будет готово» полезны только когда приложение способно обосновать ожидание. Если оценка невозможна, лучше не обещать. Одно честное сообщение с понятным действием полезнее серии оптимистичных, но неверных прогнозов.
Решите, когда разрешать отмену и уход со страницы
Кнопка «Отменить» должна иметь определённое поведение: остановить операцию, удалить задачу из очереди или только закрыть экран. Это разные действия. Если процесс можно безопасно остановить, покажите отмену рядом с пояснением или в привычной нижней зоне действия. Если уход с экрана не прерывает операцию, прямо так и скажите. Если возврат невозможен или приведёт к потере введённых данных, сформулируйте последствия до нажатия, а не после.
Визуально отделите вторичную отмену от главного действия, которое понадобится после завершения. Не показывайте недоступную кнопку как серый текст без причины: либо кратко объясните, почему отмена сейчас невозможна, либо временно уберите действие. После нажатия на «Отменить» дайте короткое подтверждение фактического результата — задача остановлена, отмена не удалась или выполняется отмена. Не подменяйте завершение процесса исчезновением экрана.
Как проверить экран до выпуска
Попросите другого человека выполнить задачу без устного пояснения со стороны команды. Не подсказывайте, куда смотреть. После запуска спросите: что сейчас происходит, можно ли перейти в другой раздел, сохранится ли работа и как остановить процесс. Если ответы возникают из интерфейса, а не из догадок, текстовая система работает.
Проверьте также состояния, которые легко пропустить в макете: медленная сеть, потеря соединения, повторный запуск, сворачивание приложения, возврат к операции и ошибка после нескольких этапов. Отдельно тестируйте VoiceOver или TalkBack: текстовый статус и изменение состояния должны быть доступны, даже если человек не видит анимацию. Для веб-интерфейса критерий WCAG 2.2 4.1.3 описывает передачу статусных сообщений вспомогательным технологиям без перемещения фокуса; для нативных приложений используйте соответствующие платформенные средства доступности. Источник: W3C: Understanding Status Messages.
Чек-лист перед передачей в разработку
- В первой строке названо конкретное действие приложения.
- Каждому уровню задан стиль: статус, пояснение, действие.
- Процент или время показываются только при достоверном расчёте.
- Понятно, что можно делать во время ожидания и что сохранится.
- «Отменить» действительно отменяет и сообщает итог.
- Текст переносится при узкой ширине и системном увеличении.
- Ошибка предлагает следующий шаг, а не только сообщает о сбое.
- Экранный диктор может узнать статус без опоры на движение или цвет.
- Проверены медленная сеть, потеря соединения и возврат к задаче.
Частые ошибки
**Показывать только спиннер.** Человек видит активность, но не узнаёт, какую задачу выполняет приложение и сколько объектов затронуто.
**Указывать примерную длительность без основания.** Если обещание регулярно нарушается, пользователи перестают ему доверять. Оставьте неопределённое ожидание неопределённым и дайте понятный выбор.
**Менять шрифт на сверхмелкий, чтобы вместить подпись.** Это маскирует проблему компоновки и ухудшает читаемость. Сократите второстепенный текст, разрешите перенос или освободите пространство.
**Оставлять кнопку без ясного исхода.** «Закрыть» может означать закрыть экран или остановить работу. Назовите реальный эффект: «Свернуть», «Остановить обработку» или «Продолжить в фоне».
**Объявлять каждое изменение прогресса.** Частые сообщения могут перебивать чтение экранного диктора. Передавайте важные переходы состояния, а не каждое визуальное движение индикатора.
Вопросы об экране ожидания
Что написать, если операция может длиться сколько угодно?
Назовите действие и не обещайте срок: например, «Синхронизируем изменения». Добавьте только проверенное пояснение о том, можно ли свернуть приложение, продолжить работу или повторить попытку.
Нужно ли показывать процент рядом со спиннером?
Только если процент получен из реального измеримого прогресса. Если приложение не знает завершённую долю операции, оставьте неопределённый индикатор и понятный статус без фиктивных чисел.
Можно ли разрешить пользователю покинуть экран ожидания?
Да, если приложение сохраняет и продолжает задачу в фоне или в очереди. Сообщите об этом до ухода. Если переход прерывает операцию, назовите последствие и не обещайте продолжение.
Как сократить длинное сообщение на маленьком телефоне?
Сначала уберите повтор и второстепенные подробности, затем проверьте, можно ли перенести строку. Сохраняйте действие и объект в статусе; не сокращайте его многоточием и не уменьшайте размер текста до трудночитаемого.
Как показать отсутствие сети?
Назовите условие и доступный шаг: например, «Нет соединения. Проверьте интернет и повторите». Если попытка будет возобновлена автоматически, скажите это только при гарантированном поведении.
Как проверить доступность статуса?
Проверьте экран с VoiceOver или TalkBack и убедитесь, что важное изменение объявляется текстом, а не только движением индикатора. В веб-интерфейсе отдельно сверьтесь с WCAG 2.2, критерий 4.1.3.
Итог
Экран ожидания не должен угадывать длительность задачи. Выразите его типографикой: короткий статус — главным уровнем, проверенное пояснение — вторым, действие — отдельной ясной кнопкой. Если вы проектируете собственную гарнитуру или проверяете рукописный шрифт в приложении, соберите тестовый текст с длинными и короткими статусами и посмотрите, как он ведёт себя при переносе и увеличении размера на Fontgenerator.ru.