Типографика сканера QR-кода: подсказки и статусы в приложении

Экран сканирования QR-кода должен помогать навести камеру, не закрывая сам код. Для этого тексту отводят отдельное место и понятные состояния: краткая инструкция до наведения, спокойная подсказка во время поиска, точный ответ при ошибке и ясный переход после распознавания. Разберём, как выстроить такую типографику, чтобы человек понял действие с первого взгляда и не принял техническое сообщение за результат сканирования.

В отличие от обычной страницы, экран сканера совмещает живое изображение и интерфейс. Человек держит телефон, двигает его и смотрит попеременно на экран и объект перед собой. Длинное объяснение требует остановиться и вчитаться; мелкая надпись поверх камеры может потеряться на пёстром фоне. Поэтому типографика здесь обслуживает короткое действие, а не чтение абзаца.

До наведения достаточно сообщить, что делать: например, «Наведите камеру на QR-код». Фраза называет действие и предмет, поэтому понятна без отдельной легенды. Не нужно повторять её заголовком «Сканирование», затем дублировать на кнопке и ещё раз выводить под рамкой. Один основной сигнал, поддержанный визуальной зоной наведения, снижает конкуренцию за внимание.

Если приложение сканирует только определённые коды, ограничение лучше показать рядом с инструкцией: «Подойдёт код с билета или заказа». Так пользователь понимает, почему случайная наклейка может не сработать. Если поддерживается несколько сценариев, коротко предложите выбор до включения камеры; не помещайте несколько равноправных инструкций на сам видоискатель.

Сканирующий экран можно мысленно разделить на три слоя: живой фон камеры, зона наведения и текстовые элементы управления. Видоискатель должен оставаться главным: именно в нём человек ищет код. Рамка помогает удержать его в рабочей области, но не заменяет словесную инструкцию. Подпись под ней объясняет действие; статус сообщает, что изменилось.

Не накладывайте длинный текст на область, где может оказаться код. Если без наложения не обойтись, подложка или непрозрачная плашка должны сохранять контраст при любом изображении с камеры — от светлой стены до тёмной витрины. Цвет текста сам по себе не гарантирует читаемость: фон меняется каждую секунду. Apple в рекомендациях по типографике советует проверять контраст текста с его контейнером и сохранять читаемость при изменении размера.

Верхнюю часть экрана удобно отвести под заголовок или закрытие, нижнюю — под короткую подсказку и альтернативное действие. Старайтесь не ставить важные слова вплотную к системным областям и краям корпуса. При повороте, изменении размера окна или появлении системной панели текст должен оставаться внутри доступной области. Для устройств и режимов, где камера не занимает весь экран, проверьте, что подписи не попадают на отступы и не растягиваются в длинную строку.

Статус помогает понять, что делает приложение. Но он не должен заставлять человека гадать, сработала ли камера. Составьте список состояний до макета: ожидание, поиск кода, распознавание, несовместимый код, временная ошибка и результат. Для каждого состояния запишите короткое сообщение, его визуальное отличие и следующее доступное действие.

Ожидание. Камера ещё не готова или приложение ждёт разрешения. Покажите действие, которое можно выполнить сейчас, и не изображайте активное сканирование, если оно ещё не началось. Системный запрос на доступ к камере объясняет операционная система; собственная подпись до него должна говорить, зачем сканер нужен в этом сценарии.

Поиск. Когда камера работает, инструкция остаётся спокойной: «Поместите код в рамку». Не обновляйте её непрерывно и не выводите анимированный счётчик, если пользователь ничего не должен с ним делать. Если есть подсказка о расстоянии, формулируйте её условно и конкретно: «Подвиньте телефон ближе», когда кода не удаётся прочитать, а не универсальное «Ошибка».

Распознавание. Сообщите о результате коротким подтверждением и сразу покажите, что можно сделать дальше. Например: «Код найден» — затем название действия и кнопка «Открыть билет». Не оставляйте единственную информацию цветной рамкой: цветовой сигнал должен дублироваться текстом или понятным значком.

Сбой. Разведите ситуации, которые пользователь может исправить, и те, где требуется другой путь. «Код не читается» подсказывает изменить положение или освещение; «Этот код не поддерживается» объясняет, почему повторное наведение бессмысленно. Кнопка «Ввести номер вручную» полезна только тогда, когда такой способ действительно предусмотрен.

Основной текст должен читаться с расстояния, на котором человек держит смартфон, но не обязан быть крупнее заголовка на обычном экране. Выберите базовый текстовый стиль платформы или собственную шкалу, затем проверьте инструкцию, статус, кнопку и вспомогательную подпись при системном увеличении текста. Не уменьшайте кегль автоматически, чтобы уместить фразу: лучше перенести её, сократить второстепенные слова или перестроить панель.

Для текста поверх динамического изображения избегайте тонких начертаний и низкого контраста. Среднее или полужирное начертание обычно лучше сохраняет форму букв на небольшом экране, особенно когда камера под плашкой движется. При этом не делайте жирным всё подряд: выделяйте статус или ключевое действие, а инструкцию оставляйте спокойной. Иначе все элементы требуют внимания одновременно.

Рамка сканирования и короткая подпись могут работать парой: рамка указывает, куда направить камеру, а текст называет действие. Не пытайтесь компенсировать слабую композицию большими буквами, тенями и обводкой поверх видео. Более предсказуемая подложка, отступы и короткая формулировка обычно дают яснее результат. В руководстве Apple по Camera Control отдельно подчёркиваются короткие подписи и свободное пространство видоискателя; это полезный ориентир для камерных сценариев, хотя конкретный экран сканирования нужно проектировать под собственную задачу.

Представьте сканер билета. До наведения человек видит строку «Наведите камеру на QR-код билета», под ней — рамку; при успешном распознавании появляется карточка события и кнопка продолжения. Здесь заголовок «Сканирование билета» необязателен: он повторяет инструкцию и отнимает место у вида камеры. Если аудитории незнаком термин QR-код, можно написать «Наведите камеру на квадратный код билета» только в первом сценарии знакомства, а затем проверить, не перегружает ли это экран.

Для этикетки товара та же рамка может вести к другому результату: «Наведите камеру на код товара», затем название и цена. Не подменяйте статус «Код найден» коммерческим обещанием вроде «Выгодная покупка», пока пользователь не увидел, какой именно товар распознан. Типографическая иерархия должна показывать сначала факт идентификации, затем данные, потом действие.

Если несколько кодов попали в кадр, не выдавайте случайный результат без подтверждения. Короткое сообщение «Найдено несколько кодов» объясняет паузу; список вариантов или приближение помогают выбрать. Названия вариантов выравнивайте в одном стиле: одинаковая роль — одинаковый размер, насыщенность и расположение. Иначе пользователь может принять вторичное имя за основной результат.

Статичный прототип на однотонном фоне не покажет слабые места. Проверьте экран на видео с яркими вывесками, бликами, тёмными участками, мелким рисунком и движением. Именно в таких условиях тонкая подпись или прозрачная плашка теряет контраст. Смотрите не только на скриншот, но и на запись использования: успевает ли человек прочитать инструкцию, пока двигает телефон?

Проверьте минимальную и увеличенную системную настройку текста, самый узкий экран, крупные системные отступы, светлый и тёмный режимы, а также язык с более длинными словами. Не обрезайте статус многоточием, если он объясняет, как исправить ситуацию. Для длинного объяснения предусмотрите отдельное раскрытие или экран помощи. Рекомендации Apple по адаптивной вёрстке предлагают проверять разные размеры текста и локализации; это особенно важно для интерфейса, где место занято изображением камеры.

На Android также тестируйте реальные системные настройки масштаба, а не только изменённый размер в дизайнерском файле. Компоненты могут вести себя по-разному, если текст помещён в фиксированную высоту или разметка не допускает переносов. Если приложение использует CameraX, учитывайте необходимость разрешения на камеру и проектируйте видимые состояния вокруг фактического доступа к ней, как описывает документация Android CameraX. Техническая проверка здесь дополняет визуальную: сначала убедитесь, что нужное состояние вообще наступает, потом оценивайте его подпись.

Сообщать только цветом. Зелёная рамка может быть незаметной или недоступной для части людей. Добавьте короткое текстовое подтверждение и не используйте оттенок как единственный признак состояния.

Писать длинную инструкцию поверх изображения. Во время наведения её неудобно читать. Перенесите подробности в отдельный экран, оставив на видоискателе одно действие.

Использовать обрезку как экономию места. Обрезанное «Код не…» не помогает разобраться. Сократите текст осмысленно или разрешите перенос; если статус важен, покажите его целиком.

Оставлять одинаковую подпись для разных состояний. Когда «Наведите камеру» висит и после распознавания, интерфейс выглядит неотзывчивым. Меняйте сообщение только тогда, когда сменилось состояние, и подтверждайте результат.

Забывать об отказе в разрешении. Пустой чёрный экран легко принять за поломку. Объясните, что камера недоступна, и покажите путь в настройки или другой способ продолжить, если он предусмотрен.

Он полезен, если человек может перепутать сценарий или должен выбрать тип кода. Если инструкция и сама рамка однозначно показывают задачу, заголовок может дублировать их. Освободившееся место лучше оставить видоискателю.

Можно, когда текст короткий и контраст сохраняется на меняющемся фоне. Используйте устойчивую плашку или область, заранее проверенную на сложных сценах. Не размещайте сообщение поверх области, куда пользователь должен навести код.

Сообщите результат текстом, затем покажите следующий шаг. Короткая фраза вроде «Код найден» отвечает на вопрос о состоянии; карточка с распознанным объектом помогает проверить, что результат правильный. Цвет или вибрация могут дополнять это сообщение, но не заменять его.

Покажите краткую причину и одно действие, которое пользователь может выполнить сейчас. Объяснение технических подробностей вынесите в помощь. Если текст всё равно длинный, разрешите перенос или отдельный экран вместо обрезки.

Да. Переведённые фразы могут занимать больше места, менять порядок слов или направление чтения. Проверьте каждый ключевой статус в реальной локализации, включая переносы и положение кнопок; не обрезайте слова ради сохранения русского макета.

Не обязательно: человек может не заметить рамку или вернуться к экрану после короткого отвлечения. Оставьте краткую постоянную инструкцию, если она не мешает обзору, а временные статусы выводите отдельно. На успех и ошибку текст должен реагировать явно.

Хорошая типографика сканера оставляет камере пространство, а человеку — ясный ответ на каждом шаге. Сначала сформулируйте действие, затем спроектируйте подтверждение и исправимые ошибки, после чего проверьте их на меняющемся изображении, при увеличении текста и в локализациях. Если создаёте собственный рукописный стиль для приложения, подготовьте и сравните его варианты в Fontgenerator, а затем испытайте на реальном экране сканера.