Жесты и касания: правила для сенсорных экранов

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

Чем касание отличается от указателя

Различия не косметические, из них следуют почти все требования к мобильному интерфейсу.

• Нет промежуточного состояния. Курсор можно подвести и посмотреть, что произойдёт, палец сразу нажимает.
• Палец закрывает то, во что попадает. Подтверждение действия под пальцем человек не увидит.
• Точность ниже. Попасть в мелкую цель на ходу, в транспорте или одной рукой заметно труднее.
• Экран одновременно поверхность ввода и поверхность прокрутки, поэтому любой жест конкурирует с прокруткой страницы.
• Края экрана частично заняты системными жестами операционной системы.
• Клавиатура закрывает нижнюю половину экрана, и форма во время ввода выглядит иначе, чем на макете.

Базовые правила

Эти требования проверяются в первую очередь, до обсуждения оформления.

Зоны экрана и расположение элементов

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

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

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

Жесты: какие уместны

Жест удобен, когда он привычен и когда о нём не обязательно знать. Мы используем ограниченный набор.

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

Главное правило: жест не должен быть единственным способом выполнить действие. О скрытом жесте просто не догадаются, а подсказка, которую показывают один раз при первом заходе, забывается к следующему визиту. Всё, что делается жестом, должно делаться и кнопкой.

Не стоит переопределять системные жесты: свайп от края, вызов панелей, возврат назад. Интерфейс, который спорит с операционной системой, всегда проигрывает.

Формы и ввод на телефоне

Форма — то место, где мобильные ошибки стоят дороже всего: здесь теряются уже готовые обращения.

• Минимум полей. Каждое лишнее поле — повод закрыть страницу.
• Подпись над полем, а не внутри: подсказка внутри исчезает при вводе, и человек забывает, что заполнял.
• Правильный тип поля, чтобы открывалась нужная клавиатура и работало автозаполнение.
• Проверка после заполнения поля, а не только по нажатию кнопки.
• Кнопка отправки видна при открытой клавиатуре или доступна прокруткой без потери контекста.
• Согласие на обработку данных — обычным чекбоксом достаточного размера, не мелкой строкой.
• После отправки — понятное подтверждение на той же странице или на отдельной, чтобы не возникало сомнений, ушла ли заявка.

Частые ошибки

Список собран по результатам аудитов, эти пункты повторяются из проекта в проект.

• Подсказка или выпадающее меню, появляющиеся только при наведении.
• Мелкие ссылки в тексте вплотную друг к другу, особенно в списках и подвале.
• Кнопка удаления рядом с кнопкой сохранения без подтверждения.
• Перехват прокрутки внутри блока: страница перестаёт прокручиваться, пока палец над картой или таблицей.
• Элементы, попадающие под системные жесты у краёв экрана.
• Всплывающие окна, которые нельзя закрыть, потому что крестик оказался за пределами экрана.
• Горизонтальная прокрутка всей страницы из-за одного широкого блока.
• Таблицы, свёрстанные без прокрутки: часть столбцов недоступна.

Как проверять

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

1. Берём реальный телефон, а не эмулятор, и мобильный интернет, а не офисный вайфай.
2. Держим устройство одной рукой, стоя, — так, как это делают люди.
3. Проходим три главных сценария целиком: найти услугу, узнать цену, отправить заявку.
4. Повторяем сценарий с открытой клавиатурой и в горизонтальном положении экрана.
5. Проверяем на устройстве с небольшим экраном и на телефоне с крупным системным шрифтом.
6. Записываем каждое место, где пришлось перехватить телефон, промахнуться или вернуться назад.

Список замечаний после такого прохода обычно короткий, но почти каждое из них влияет на обращения. Исправление размеров целей, расстояний и порядка блоков — недорогие правки, которые делаются в рамках обычной доработки вёрстки.

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

Такую логику мы закладываем на этапе прототипа — это проектирование пользовательских интерфейсов до начала разработки.