Сайт красиво выглядит на компьютере, но на телефоне меню перекрывает страницу, подпись формы обрезается, а таблица уезжает за край. Это пример того, почему адаптив нельзя принимать только по двум картинкам макета. Мы в «Гуси-Лебеди» предлагаем проверять, может ли человек прочитать содержание и выполнить своё действие на разных экранах. Разбираем, что входит в адаптивный дизайн, какие правила нужно согласовать и как проверить готовый сайт.
Что такое адаптивный дизайн сайта
Адаптивный дизайн предусматривает изменение расположения и представления элементов под условия просмотра. На широком экране блоки могут стоять рядом, на узком выстраиваться друг под другом. При этом назначение страницы, важное содержание и нужные действия должны оставаться понятными.
Дизайн описывает решение, а вёрстка реализует его в браузере. Поэтому проверка макета и проверка работающей страницы являются разными этапами. Даже согласованная схема не показывает, что случится после появления ошибки, длинного названия товара или дополнительного пункта меню.
В документации встречается термин Responsive Web Design. MDN связывает его с представлением и поведением сайта на разных устройствах. В русскоязычных обсуждениях слова «адаптивный» и «отзывчивый» могут использоваться по-разному; на старте работы полезнее согласовать конкретное поведение, чем спорить о переводе.
| Решение | Что означает | Что проверить |
|---|---|---|
| Гибкое расположение | Размеры и порядок блоков реагируют на доступное место | Промежуточные ширины и реальное содержание |
| Перестроение по условиям | В определённой ситуации меняются правила интерфейса | Поведение до и после точки изменения |
| Отдельная мобильная версия | Предусмотрено отдельное представление сайта | Содержание, адреса, переходы и согласованность изменений |
Не сводите задачу к уменьшению десктопного экрана. Мелкий текст и тесные кнопки остаются неудобными, даже если страница целиком поместилась в окно. Для обсуждения терминов пригодится наш словарь веб-дизайна для заказчика.
Как выбирать сетку, размеры и точки перестроения
Брейкпоинт обозначает условие, при котором применяются другие правила расположения. Например, если карточки становятся слишком узкими, их можно перестроить в меньшее число колонок. Это решение должно опираться на содержимое и сценарий, а не только на популярные размеры устройств.
В руководстве MDN по медиазапросам предлагается изменять ширину и смотреть, где содержание требует другого представления. Такой подход помогает заметить проблему между готовыми макетами.
Мы рекомендуем обсуждать сетку вместе с настоящими материалами. Длинная фамилия, название услуги или цена с пояснением могут занимать больше места, чем временная заглушка. Если продукт поддерживает другие языки, проверяйте и предусмотренные переводы.
- Колонки. Когда карточки переходят в другой порядок и сохраняется ли логика чтения.
- Текст. Как переносятся заголовки, ссылки, подписи и значения.
- Отступы. Остаются ли связанными подпись и поле, карточка и её действие.
- Приоритеты. Что человек видит раньше и где находится следующий шаг.
Mobile First означает начало проектирования или реализации с ограничений узкого экрана. Это полезный способ расставлять приоритеты, но не обязательное доказательство качества. В любом порядке работы нужно проверить и широкий, и узкий, и промежуточный вариант. Требования к таким сценариям можно включить в проектирование интерфейса сайта.
Как должны вести себя меню, формы и состояния
На телефоне особенно заметны решения, зависящие от места и способа ввода. Указатель мыши позволяет навести курсор, сенсорный экран требует другого взаимодействия. Важную информацию нельзя делать доступной только при наведении.
Меню должно открываться и закрываться понятным способом. Проверьте доступ к последнему пункту, возврат к странице и поведение при прокрутке. Закреплённая шапка не должна прятать значительную часть текста или перекрывать место ввода.
Форма требует видимых подписей, понятных ошибок и доступной кнопки отправки. Откройте её с экранной клавиатурой и убедитесь, что человек может продолжить действие. После ошибки введённые данные не должны исчезать без предусмотренной причины.
Состояния нужно показать отдельно: загрузку, отсутствие данных, недоступную функцию, ошибку и успешный результат. Статичный макет с идеальными данными не объясняет, как интерфейс помогает в остальных ситуациях. Требования к подписям полей описаны в руководстве W3C по формам.
Мы советуем принимать ключевой сценарий целиком: открыть нужный раздел, найти информацию, заполнить поля и увидеть предусмотренное подтверждение. По отдельности красивые кнопка и форма ещё не показывают, работает ли путь пользователя.
Что делать с таблицами, изображениями и сложными блоками
У таблицы и обычного текста разные требования. Если для сравнения важны строки и колонки, бесконечное уменьшение шрифта делает данные менее понятными. Можно предусмотреть прокрутку внутри отдельного контейнера или другое представление, сохраняющее смысл сравнения.
W3C объясняет перестроение содержания и отдельно рассматривает элементы, которым нужна двумерная структура, включая таблицы данных. Это не повод разрешать горизонтальное переполнение всей страницы: остальной текст должен оставаться удобным для чтения.
Изображения должны помещаться в свой блок без искажения пропорций. При кадрировании проверьте, не исчез ли важный объект или текст. Иллюстрацию со встроенными мелкими подписями нельзя считать читаемой только потому, что файл загрузился.
Карточки и фильтры проверяйте на разных количествах данных. Заголовок, цена и действие должны оставаться связаны. Если фильтр открывается отдельной панелью, человеку нужен понятный способ применить выбор, сбросить его и вернуться к результатам.
Вес ресурсов тоже влияет на опыт: удобная сетка не поможет, если страница долго остаётся пустой. Подбирайте размеры и варианты изображений под место использования, проверяйте загрузку в согласованных условиях. Автоматический выбор темы или конструктора не отменяет проверки наполненного сайта.
Как проверить адаптивный сайт перед приёмкой
Начните с важных типов страниц и действий. Для магазина это может быть поиск товара и оформление заказа; для сайта услуг изучение предложения и отправка заявки. Перечень должен отражать ваш проект. Мы рекомендуем записать ожидаемый результат каждого сценария и условия проверки.
| Проверка | Что должно быть понятно |
|---|---|
| Разные ширины | Блоки перестраиваются без потери важного содержания |
| Длинные данные | Текст не перекрывает действия и соседние элементы |
| Меню и формы | Можно завершить путь, включая исправление ошибки |
| Таблицы | Сравнение доступно без переполнения всей страницы |
| Клавиатура и фокус | Текущий элемент заметен, действия доступны |
| Загрузка | Ресурсы появились и интерфейс отвечает в проверенных условиях |
Эмуляция в браузере помогает быстро проверить размеры. Она не воспроизводит все особенности реального устройства, его клавиатуры, браузера и соединения. Для ключевых сценариев дополните её проверкой на доступных устройствах, а в отчёте укажите, что фактически проверено.
Если нашли ошибку, зафиксируйте адрес страницы, размер окна, действие, ожидаемое и фактическое поведение. Скриншот полезен, но последовательность действий делает задачу воспроизводимой. После исправления повторите затронутый сценарий.
В «Гуси-Лебеди» мы предлагаем согласовывать реализацию адаптивного интерфейса вместе с критериями приёмки. Планы развития и повторяющиеся компоненты удобно обсуждать через дизайн-систему проекта, а дальнейшие проверки закреплять в условиях сопровождения после запуска. Адаптивность подтверждается поведением готовых страниц в проверенных условиях, а не названием подхода в презентации.