От автора: Сегодня не найти такого веб-разработчика, который не слышал бы о концепции отзывчивого веб-дизайна (responsive web design или RWD). С тех пор как Итан Маркотт придумал данный термин в мае 2010 года, отзывчивый веб-дизайн был признан одним из лучших направлений, успел сформироваться, а также появилось множество возможностей и способов его реализации.
Это помогло нам подстроить веб-сайты и приложения под устройства, которые используются в настоящее время, и сделать так, чтобы они работали одинаково хорошо, вне зависимости от того, какие устройства будут придуманы в будущем.
Однако, несмотря на, несомненно, огромный успех отзывчивого веб-дизайна, он имеет также и свои недостатки.
Одной из наиболее сложных для реализации задач стала работа над созданием отзывчивых изображений, хотя сейчас мы уже близки к ее решению благодаря встроенной поддержке браузером атрибута srcset и элемента picture.
Теги video и audio позволяют решить проблему поддержки медиа-контента путем добавления нескольких элементов source для того, чтобы браузеры могли выбрать подходящий им файл. Однако это обходится ценой появления большого количества дополнительной разметки (даже тогда, когда нам известно, что для конкретного устройства понадобится только один файл).
Обе задачи являются частью гораздо более сложной проблемы – проблемы контента и контекста. Мобильный контекст – это целый мир потенциальных ограничений, включающий пропускную способность Интернет-соединения, размеры экранов и мощность процессора (CPU). Независимо от того, какое устройство используется, мы, как веб-разработчики, должны всегда стремиться к тому, чтобы отправлять пользователю только те ресурсы, которые действительно необходимы.
Безусловно, для каждого из вышеприведенных примеров мы будем отправлять все ресурсы, которые могут потребоваться, возлагая на браузер задачу – разобраться в том, что действительно нужно.
Помимо этих больших задач, есть задачи и поменьше, такие как, например, недостаточные функциональные возможности самого устройства. Во фронт-энде (front-end) данная задача в большинстве случаев решается за счет использования JavaScript, после полной загрузки страницы. Однако тогда работоспособность сайта или приложения будет сильно зависеть от JavaScript, появится еще больше кода, который необходимо будет загрузить пользователю. И это часто может привести к некорректной отрисовке страницы, после того как решение будет применено.
Что такое адаптивный веб-дизайн?
Все это ведет нас к тому, что я надеюсь, станет следующей фазой развития в веб-разработке: адаптивный веб-дизайн (adaptive web design или AWD).
Данную концепцию называют иногда отзывчивый дизайн + серверные компоненты (responsive web design + server side components или RESS). Но, независимо от названий, она подразумевает принятие решений со стороны сервера о том, что должно или не должно быть отправлено пользователю, т.е. чтобы не было отправлено ничего лишнего. Вот несколько плюсов адаптивного веб-дизайна:
Уменьшение нагрузки на пропускную способность соединения – за счет того, что вы можете для каждого видеофайла на вашем сайте отправить что-то наподобие следующего:
|
1 |
<video src="..."></video> |
..вместо чего-то такого:
|
1 2 3 4 5 6 7 8 9 10 11 |
<video> <source src="...mp4" type="video/mp4"> <source src="...webm" type="video/webm"> <object type="application/x-shockwave-flash" data="...swf"> <param name="allowfullscreen" value="true"> <param name="allowscriptaccess" value="always"> <param name="flashvars" value="file=...mp4"> <!--[if IE]><param name="movie" value="...swf"><![endif]--> <p>Ваш браузер не может корректно отображать содержимое HTML5 элемента video. Загрузить файл.</p> </object> </video> |
Модули, отвечающие за контекст, – т.е. вы можете использовать модуль «Позвоните нам» только на устройствах, поддерживающих прямой вызов, модуль «Камера» — только на устройствах, имеющих камеры, и т.д.
Использование скорости сервера для обработки – Обычно сервера все равно работают немного быстрее, чем любое другое устройства, используемое для обработки веб-данных. Поэтому, почему бы не поручить серверу выполнять всю тяжелую работу по обработке данных, а затем просто доставлять на устройство готовый к просмотру контент.
Серверные модули для работы с кэшем – И как только вся тяжелая работа будет выполнена на сервере, почему бы не использовать кэш для того, чтобы не нужно было заново обрабатывать данные при каждой загрузке страницы?
Более быстрая загрузка страниц – Благодаря созданию и кэшированию данных модулей на сервере и их отправке вместе с остальной частью страницы, вы избавитесь от задержек и дополнительного HTTP-запроса, который потребуется, если JavaScript будет определять, что необходимо, и отправлять запрос через Ajax.
Выбор языка программирования – Что касается браузера, то выбор здесь очевиден – это JavaScript. Однако ваш сервер может использовать какой угодно язык программирования, лишь бы на выходе получался код, который сможет обработать браузер.
Конечно, концепция процесса определения устройств не является новой. Она появилась на самых ранних этапах развития мобильных устройств (обычно чтобы переадресовать пользователя на совершенно другой сайт и/или URL), и она даже относится к еще более раннему этапу развития Интернета, когда JavaScript использовался для получения информации о клиентском приложении (User-Agent), чтобы определить, каким образом наш «запутанный» код будет функционировать.
Позже мы узнали о том, что принцип определения характеристик является более надежным и расширяемым подходом, но он требует доступа к браузеру, а это означает, что он должен реализовываться во фронт-энде. Итак, как же сервер может определить, какое устройство отправляет запрос?
По иронии судьбы, мы снова возвращаемся к процессу определения клиентского приложения – но, на этот раз, уже со стороны сервера – и смотрим на строку с информацией о клиентском приложении, которая приходит вместе с первоначальным заголовком запроса. В инструментах разработчика браузера Chrome это будет выглядеть примерно так:
Серверный код, отвечающий за адаптивность, получит эти данные, сравнит их со значениями в базе, и выдаст информацию уже с учетом данного устройства. Не правда ли легко?
За исключением небольшого словосочетания «значениями в базе»…
Заметьте, что в строке с информацией о клиентском приложении не говорится четко, что это «настольная» или какая-то другая версия клиентского приложения.
Это означает, что требуется человеческое вмешательство для того, чтобы перечислить и разбить на категории строки с информацией о клиентском приложении, а также относящиеся к ним устройства. Вот почему любой, кто пойдет по данному пути, скорее всего, захочет, чтобы какой-нибудь сервис проделал всю рутинную работу по сбору и сортировке данных за него (об этом чуть позже).
Похоже, что это подходящий момент упомянуть несколько слабых сторон адаптивного веб-дизайна:
Поддержка библиотеки определения устройств – В том момент, когда библиотека определения устройств обновляется, она уже будет устаревшей, потому что новые устройства, новые браузеры и новые версии браузеров появляются каждый день, если не каждую наносекунду…
Возможные задержки во время определения устройства сервером – В зависимости от того, как работает ваша библиотека определения устройств, могут возникать небольшие задержки, пока сервер будет определять устройство и начинать обработку страниц.
«Разные сайты» на разных устройствах – Некоторым пользователям может не понравится то, что при использовании одного устройства они могут найти тот или иной модуль или контент, но не могут этого сделать при использовании другого устройства (хотя этого можно избежать, если всегда предлагать пользователям ссылку на различные версии ваших сайтов).
Таким образом, адаптивный веб-дизайн необязательно должен использоваться на всех сайтах. Если ваш сайт не нуждается в различном контенте в различных контекстах, или на нем не используется множество изображений, или аудио, или видео, тогда вам вполне можно обойтись только отзывчивым веб-дизайном. И это будет здорово!
Любой хорошо разработанный «резиновый» сайт с хорошим дизайном должен корректно отображаться при любых разрешениях экрана, и пока вы не будете засорять все вокруг ненужным кодом, чтобы все работала как надо, ваши пользователи будут любить вас, и, вероятно, им будет нравиться посещать ваш сайт. Еще здесь?
Если вы все еще продолжаете читать, значит, скорее всего, вам это интересно. Хорошо. Тогда давайте перейдем сразу к делу!
Здесь будет уместным развернутое объяснение, т.к. я работаю в компании Netbiscuits, и данная компания представляет сервис по обнаружению устройств. Однако есть несколько других сервисов, которые отличаются набором опций и стоимостью, поэтому это будет вашим небольшим домашним заданием – решить, какой сервис или продукт больше подходит под ваши нужды и бюджет. Вне зависимости от того, какое решение вы выберите, в конечном счете, ваши серверные шаблоны будут содержать примерно следующее:
|
1 2 3 4 5 6 7 8 9 |
if (device.type === 'mobile phone') { // вставляет модуль, предназначенный только для мобильных телефонов } else if (device.type === 'tablet') { // вставляет модуль, предназначенный только для планшетов } else { // вставляет модуль, предназначенный для всех остальных устройств } |
Или:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
if (device.video.format === 'mp4') { // это устройство поддерживает "mp4", поэтому отправляем только тот тег <video>, который содержит данный кодек. echo '</video><video src="...mp4" type="video/mp4"></video>'; } else if (device.video.format === 'webm') { // это устройство не поддерживает "mp4", но поддерживает "webm", поэтому отправляем только тот тег <video>, который содержит данный кодек. echo '</video><video src="...webm" type="video/webm"></video>'; } else if (device.video.format === 'swf') { // это устройство не поддерживает ни один из вышеуказанных кодеков, но поддерживает "swf", поэтому отправляем только этот код: echo '<object type="application/x-shockwave-flash" data="...swf">'; echo ' <param name="allowfullscreen" value="true"/>'; echo ' <param name="allowscriptaccess" value="always"/>'; echo ' <param name="flashvars" value="file=...mp4"/>'; echo ' <!--[if IE]><param name="movie" value="...swf"/>< ![endif]--> '; echo '</object>'; } else { // это устройство ничего не поддерживает, поэтому отправляем пользователю ссылку для загрузки файла… echo '<p>Ваш браузер не отображает содержимое тега video. Загрузить файл.</p>'; } |
Возможности, которые вы получите, и экономия, которую вы предоставите своим пользователям, целиком и полностью зависят от того сервиса, который вы выберите, и какую пользу вы извлечете из его использования.
На сайте компании Netbiscuits, например, мы используем сервис по определению устройств для того, чтобы выяснить, какой CSS-файл отправлять пользователю, что определяет, помимо всего прочего, каким образом будут отображаться иконки: через SVG data-URI, PNG data-URI, PNG URL, или PNG URL, пропущенный через фильтр «только IE» для обеспечения прозрачности иконок.
У нас также есть доступ к информации об операционной системе (OS) устройства, ее версии, названии браузера и его версии, и все это делается через HTML-атрибуты data-. Таким образом, мы можем добавить отдельный CSS-файл для всех «вредных» устройств, не желающих вести себя, как полагается. Вот два примера:
И поскольку эти значения расположены на сервере, до отправки чего-либо устройству, то не возникает никаких раздражающих визуальных помех, а также нет необходимости в дополнительной отрисовке страницы, когда JavaScript определил нужные значения во фронт-энде.
Таким образом, нуждаетесь ли вы в решении, использующем принципы адаптивного веб-дизайна, или вам будет достаточно сайта с отзывчивым веб-дизайном, будем надеяться, что вы теперь лучше понимаете концепцию адаптивного веб-дизайна и те возможности, которые открываются перед вами и вашими пользователями.
Автор: Aaron T. Grogg
Источник: //www.sitepoint.com/
Редакция: Команда webformyself.
