Респонсив бывает разным: три подхода к проектированию мобильного сайта
Прежде чем начинать разработку респонсив-сайта (сайта на основе responsive web-design), необходимо решить, каким будет его поведение при изменении ширины окна браузера. Это очень важное решение, поскольку им определяется конфигурация будущего контента сайта. Неправильный выбор может привести к огромным проблемам в будущем, особенно если контент сайта будет сложным и разнообразным (что характерно для медиа-ресурсов).
Как известно, у любого респонсив-сайта есть несколько изначально выбранных ширин экрана, называемых порогами разрешения. В этих точках конфигурация страниц сайта меняется, адаптируясь к параметрам окна. Пороги разрешения выбираются на основании эмпирических оценок ширин экрана наиболее распространенных на рынке мобильных устройств.
Говоря о респонсив-поведении, я имею в виду то, как ведет себя сайт между порогами разрешения. По сути, существует два типа респонсив-поведения: эластичное (fluid) и жесткое (fixed). Есть и третий вариант, на нем я остановлюсь позже.
Эластичное поведение
Канонический пример такого подхода к респонсиву – всем известный сайт bostonglobe.com.
Начните сужать окно браузера, и вы увидите, как плавно меняются параметры компонентов страницы. Уменьшаются не только ширины колонок и имиджей, но даже размер некоторых шрифтов. Сайт Boston Globe – один из наиболее проработанных и продуманных в респонсив-вселенной, не зря же в его создании участвовал Этан Маркотт, основоположник самой методики responsive web-design.
Этот подход теоретически самый правильный, поскольку в максимальной степени реализует концепцию адаптивного дизайн. Но он и наиболее сложен, поскольку необходимо просчитывать конфигурацию страницы на протяжении всей шкалы ширин окна, а не только в порогах разрешения. Представьте себе, что контентная единица сайта может включать в себя компоненты, располагающиеся по горизонтали: таблицы, например, или изображения с обтекающим их текстом. Как поведут себя эти компоненты при плавном уменьшении ширины окна, предугадать сложно; например, текст, обтекающий картинку, может стать нечитаемым. Поэтому эластичный респонсив-сайт больше подходит для простых ресурсов, например, для сайтов-визиток, где страниц немного и каждая может проектироваться отдельно. Либо вам придется долго и скрупулезно тестировать сайт, пробуя все возможные варианты и на всех доступных мобильных устройствах.
Жесткое поведение
По причинам, изложенным выше, большинство сайтов в респонсив-вселенной демонстрируют жесткое поведение, при котором конфигурация страницы между порогами разрешения не меняется.
Строго говоря, и сайт bostonglobe.com не является на 100% эластичным, поскольку у него есть верхний предел ширины окна 1430px, после которого страница больше не расширяется.
Жесткий подход менее совершенен с точки зрения UX, нежели эластичный, поскольку на устройствах, размер экрана которых отличается от выбранных при определении порогов разрешения, сайт не будет использовать всю ширину окна: страница будет обрамлена полями справа и слева, что не экономично. И тем не менее, на мой взгляд, это допустимый компромисс между учетом интересов пользователя и сложностью разработки.
Многие сайты демонстрируют смешанное респонсив-поведение. Например, оно характерно для css-фреймворка Bootstrap, который является жестким вплоть до наименьшего порога разрешения 800 px, после чего страница становится эластичной.
При проектировании сайта GreenEvolution.ru я выбрал предельный вариант жесткого поведения. На страницах этого сайта меняется только конфигурация меню и взаимное расположение компонентов; параметры же контента остаются неизменными при любом разрешении. Так, например, ширина основной колонки материала выбрана такой, чтобы ее не нужно было уменьшать даже после наименьшего порога разрешения.
Такое решение менее изящно, чем у bostonglobe.com, однако я пошел на него совершенно сознательно. Сайт разрабатывался в предельно сжатые сроки (от начала проектирования до открытия прошло всего полтора месяца), и на расширенное тестирование поведения контента времени не было. Была поставлена и дополнительная задача: предельно упростить для редакции создание контента, исключив любые проблемы с конфигурацией страниц, вне зависимости от количества и размера изображений на ней. Ну и наконец, нужно учитывать следующее: при всем желании учесть интересы мобильных пользователей, приоритетными для заказчика этого b2b-сайта всё равно остаются пользователи настольных компьютеров – доля мобильного трафика на сайт составляет около 5%. Предсказуемость отображения страниц на настольных компьютерах в данном случае объективно важнее комфорта мобильных пользователей. С другими сайтами ситуация может быть иной.
Мой подход также позволяет экономить дисковое пространство сервера, поскольку исключает необходимость генерации нескольких версий изображений для разных размеров экрана. Кстати, это не такая уж мелочь: при активном наполнении инфосайта дополнительные версии имиджей могут стоить несколько гигабайт в месяц.
Третий путь: веб-приложение
Всё сказанное выше относится к сайтам традиционного построения. Фактически, сегодня в большинстве случаев вы не сможете понять, что сайт является «отзывчивым», пока не начнете экспериментировать с шириной окна браузера. При первом взгляде на такой респонсив-сайт на экране настольного компьютера вы не отличите его от обычного.
Уверен, что уже через несколько месяцев ситуация станет иной: на смену традиционным сайтам (стационарным и респонсив) придут веб-приложения.
Традиционный сайт почти всегда имеет вертикальное построение. Подавляющее большинство компонентов страницы статичны, а сама страница имеет фиксированную ширину – даже если сайт эластичен, обычно он имеет конечное значение максимальной ширины, дальше которой не растягивается. Движение от страницы к странице осуществляется исключительно с помощью навигационных меню. Служебные элементы (логотип, меню, форма поиска, другие элементы шапки-header’а) могут занимать бо́льшую часть первого экрана страницы.
Медиа-приложения для мобильных устройств приучили нас совершенно к другому UX. Движение внутри приложения происходит в двух измерениях – по вертикали мы читаем текущую страницу, по горизонтали – «листаем», переходим от одной страницы к другой. Основную часть экрана занимает контент; все служебные элементы сосредоточены по краям страницы и чаще всего являются динамическими: открываются при наведении или нажатии и меняются в зависимости от контекста. При этом используется всё пространство экрана – так, чтобы обеспечить максимальное удобство и комфорт для пользователя.
Всё это противоречит традиционным подходам к веб-дизайну, но именно смена парадигмы от веб-сайта к веб-приложению позволит в полной мере реализовать концепцию Mobile First (изложенную, в том числе, и в одноименной книге Люка Вроблевски, русский перевод которой мне посчастливилось редактировать).
Пока среди крупных медиа-ресурсов таких сайтов немного. Переделать серьезный сайт с большим количеством контента непросто; изменить мировоззрение еще сложнее. И тем не менее, будущее за этим подходом. Сегодня чаще всего такими являются экспериментальные сайты или коммерческие шаблоны для WordPress и Joomla. Но не только: недавний редизайн одного из крупнейших IT-медиаресурсов Mashable.com стал решительным шагом именно в этом направлении. Надеюсь, что и новую версию моего сайта AlexSchneider.ru (на котором, надеюсь, вы читаете эти строки) можно, хотя бы в некоторой степени, отнести к категории веб-приложений.
Средняя жизнь сайта – около 5 лет. Вдумайтесь: уже в следующем году интернет-поиск с мобильных устройств будет осуществляться чаще, чем с обычных компьютеров, а большинство мобильных веб-пользователей составят владельцы планшетов. Какую бы нишу ваш сайт ни занимал, уже к середине срока его жизни львиная доля читателей будет просматривать его с экранов мобильных устройств. Весьма вероятно даже, что многие из них вообще перестанут пользоваться стационарными компьютерами.
Думая о новом сайте, забывать об этом ну никак нельзя.
Фото в начале статьи: labs.cooperhewitt.org.
Дайджест новых статей по интернет-маркетингу на ваш email
Новые статьи и публикации
- 2024-11-26 » Капитан грузового судна, или Как начать использовать Docker в своих проектах
- 2024-11-26 » Обеспечение безопасности ваших веб-приложений с помощью PHP OOP и PDO
- 2024-11-22 » Ошибки в Яндекс Вебмастере: как найти и исправить
- 2024-11-22 » Ошибки в Яндекс Вебмастере: как найти и исправить
- 2024-11-15 » Перенос сайта на WordPress с одного домена на другой
- 2024-11-08 » OSPanel 6: быстрый старт
- 2024-11-08 » Как установить PhpMyAdmin в Open Server Panel
- 2024-09-30 » Как быстро запустить Laravel на Windows
- 2024-09-25 » Next.js
- 2024-09-05 » OpenAI рассказал, как запретить ChatGPT использовать содержимое сайта для обучения
- 2024-08-28 » Чек-лист: как увеличить конверсию интернет-магазина на примере спортпита
- 2024-08-01 » WebSocket
- 2024-07-26 » Интеграция с Яндекс Еда
- 2024-07-26 » Интеграция с Эквайринг
- 2024-07-26 » Интеграция с СДЕК
- 2024-07-26 » Интеграция с Битрикс-24
- 2024-07-26 » Интеграция с Travelline
- 2024-07-26 » Интеграция с Iiko
- 2024-07-26 » Интеграция с Delivery Club
- 2024-07-26 » Интеграция с CRM
- 2024-07-26 » Интеграция с 1C-Бухгалтерия
- 2024-07-24 » Что такое сторителлинг: техники и примеры
- 2024-07-17 » Ошибка 404: что это такое и как ее использовать для бизнеса
- 2024-07-03 » Размещайте прайс-листы на FarPost.ru и продавайте товары быстро и выгодно
- 2024-07-01 » Профилирование кода в PHP
- 2024-06-28 » Изучаем ABC/XYZ-анализ: что это такое и какие решения с помощью него принимают
- 2024-06-17 » Зачем вам знать потребности клиента
- 2024-06-11 » Что нового в работе Яндекс Метрики: полный обзор обновления
- 2024-06-11 » Поведенческие факторы ранжирования в Яндексе
- 2024-06-11 » Скорость загрузки сайта: почему это важно и как влияет на ранжирование
Чтобы вырастить плодоносящий сайт - его полезно регулярно поливать и удобрять с помощью рекламы и оптимизации Компания "RedLine" |
Мы создаем сайты, которые работают! Профессионально обслуживаем и продвигаем их , а также по всей России и ближнему зарубежью с 2006 года!
Как мы работаем
Заявка
Позвоните или оставьте заявку на сайте.
Консультация
Обсуждаем что именно Вам нужно и помогаем определить как это лучше сделать!
Договор
Заключаем договор на оказание услуг, в котором прописаны условия и обязанности обеих сторон.
Выполнение работ
Непосредственно оказание требующихся услуг и работ по вашему заданию.
Поддержка
Сдача выполненых работ, последующие корректировки и поддержка при необходимости.