Адаптивность

Контур развивает экосистему продуктов для бизнеса. Задачи могут настигнуть предпринимателя или сотрудника в любой момент — по пути на встречу, в очереди в налоговой или во время обеда. Некоторые дела просто удобнее решать с помощью смартфонов и планшетов, например отсканировать QR-код, загрузить фотографию документа или прочитать обратную связь от коллеги.

Адаптивность — это способность интерфейса меняться в зависимости от типа и размера устройства. Адаптивный интерфейс — это интерфейс, который:

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

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

Адаптивность Контур.Фокуса

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

• Если часть пользователей заходит в сервис с мобильных устройств — это уже повод задуматься об адаптивной версии.
• Если у вас есть мобильное приложение, а мобильное устройство — важная точка входа. Адаптивная версия подстрахует, если с приложением что-то случится.
• Если планируется расширение аудитории и вы хотите привлечь пользователей, которые работают с телефонов и планшетов.
• Если пользователю важно быть в курсе событий в сервисе и он готов проверять обновления даже с телефона.

1. Соберите данные. Соберите или запросите статистику входа с различных устройств в вашем сервисе.
2. Обсудите детали с командой. Проконсультируйтесь с фронтенд-разработчиками и тестировщиками. Возможно, существуют технические ограничения, которые могут повлиять на реализацию адаптивного дизайна. Также стоит учесть, что после завершения разработки может потребоваться увеличение количества тест-кейсов у тестировщика. Предупредите всю команду о будущих изменениях.
3. Определите охват и приоритеты. Решите, какие страницы продукта станут адаптивными и в каком порядке будет идти работа. Рекомендуем сделать адаптивность минимум для главной страницы, так как это первая точка входа. Далее можно двигаться по одному из сценариев:

   Если у вас в сервисе нет главной страницы, сделайте адаптивной стартовую страницу — это страница, которая открывается по прямой ссылке или сразу после авторизации.

   • адаптировать в первую очередь ключевые сценарии и разделы;
   • идти по порядку — отдавая в разработку макеты по мере готовности;
   • внедрять адаптивность в рамках текущих продуктовых задач.
4. Выберите брейкпоинты. Ориентируйтесь на статистику размеров экранов по вашему продукту и другим сервисам Контура.
5. Продумайте логику адаптивности основных элементов интерфейса. Опишите, как будет адаптироваться навигация и контентная область интерфейса в выбранных брейкпоинтах. Сформулируйте универсальные правила, чтобы адаптировать практически любой экран с минимальными усилиями.
6. Выберите и настройте дизайн-токены. Для каждого брейкпоинта опишите изменения базовых параметров визуальной системы, если они нужны.

   Дизайн-токены — это переменные, в которых зафиксированы базовые значения визуальной системы: отступы, цвета, типографика, стили объектов, анимация и пр.

7. Нарисуйте макеты. Ориентируйтесь на правила, которые описаны выше.

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

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

Брейкпоинты можно адаптировать под нужды конкретного продукта. Например, если интерфейс включает широкие таблицы, имеет смысл переходить к десктопному виду уже при ширине 1 300 px. Можно также добавить брейкпоинт для ультрашироких экранов ( > 1 920 px).

В продуктах Контура один из основных лейаутов включает в себя боковое меню.

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

Если пространство ограничено — меню сворачивается в узкий столбец с иконками.

На мобильных устройствах место ещё более ограничено — здесь меню прячется в бургер или превращается в табы.

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

После выбора брейкпоинтов важно продумать, как будет вести себя интерфейс между ними.

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

Контентная область подстраивается под ширину экрана

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

Контентная область имеет фиксированную ширину между брейкпоинтами

Часто можно встретить сочетание обоих подходов, например, часть колонок фиксированной ширины, а остальные тянутся.

Сочетание разных подходов для адаптивности контентных областей

На мобильных устройствах контентная область обычно занимает всю ширину экрана.

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

Проектировать и верстать интерфейсы проще, когда есть система. Для построения системы используются дизайн-токены: цвета, шрифты, отступы, тени, скругления и другие визуальные элементы.

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

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

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

Изменение размера шрифтов на разных брейкпоинтах

Изменение размеров отступов на разных брейкпоинтах

Такие таблицы помогут систематизировать размеры элементов на разных разрешениях экранов и не запутаться в них.

На мобильных устройствах доступно меньше пространства, чем на десктопах, поэтому важно критически оценить каждый элемент интерфейса.

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

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

При этом структура самих элементов может остаться прежней — достаточно изменить порядок расположения.

Чтобы эффективно использовать пространство на маленьком экране, можно уменьшать размер заголовков, отступов, иконок или картинок. Так можно сэкономить место на экране и поместить на нём больше информации.

Например, на мобильном устройстве можно отказаться от острова, уменьшить размер шрифта в заголовке и отступы:

Иногда простое уменьшение размера или скрытие части информации недостаточно. В таких случаях можно использовать альтернативное представление компонентов — менять не только размеры, но и сам вид элемента.

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

В адаптивной вёрстке рекомендуем использовать размеры Medium и Large для контролов, даже если в десктопе использовались Small. Во-первых, контролы Small слишком малы для комфортного взаимодействия на мобильных устройствах — по ним трудно попасть пальцем, особенно если это иконки-кнопки. Во-вторых, в iOS шрифты меньше 14 px автоматически масштабируются, это может сломать визуальное представление интерфейса.

Если всё же используете компактный элемент, обязательно увеличьте кликабельную область — она должна быть не меньше 40×40 px. Например, так сделано с иконкой закрытия в модальных окнах.

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

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

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

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

Также полезно добавить кнопку «Свернуть» на клавиатуре, чтобы пользователи могли легко скрывать её, не целясь в пустую область экрана.

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

Допустимо

Правильно

Залипающие элементы следует использовать с осторожностью. На мобильных устройствах они конкурируют за место с клавиатурой и браузерной панелью. Если без залипающего элемента можно обойтись — лучше отказаться от него.

Неправильно

Правильно

Правильно

Проверьте, можно ли увеличивать ваш интерфейс с помощью жестов. Это особенно важно для пользователей с ослабленным зрением — возможность приблизить текст или изображение делает интерфейс более доступным.

По возможности используйте векторную графику (SVG).

Если у вас в сервисе используются растровые изображения, учитывайте, что они могут открываться на экранах с высокой плотностью пикселей (ретина и супер ретина). У таких экранов количество пикселей на дюйм (PPI) выше, чем у обычных. Если использовать обычное изображение в масштабе @1x на ретина-дисплеях, то оно будет выглядеть плохо.