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