Английский архитектор Кристофер Рен однажды язвительно заметил, что его выбранное поле "направлено на Вечность", и есть что-то подкупающее в этой формуле: в отличие от веба, который часто чувствует себя направленным на следующую неделю, архитектура - это дисциплина, которая значительно определяется своим постоянством. Фундамент здания определяет его отпечаток, который определяет его конструкцию, которая формирует фасад. Каждый этап архитектурного процесса является более незыблемым, более неизменным, чем предыдущий. Креативные решения буквально формируют физическое пространство, определяя то, каким образом люди перемещаются через его границы в течение десятилетий или даже столетий.
Однако работа в веб-среде совсем другое дело. Она определяется быстротечностью, часто усовершенствуется или заменяется в течении года или двух. Непостоянная ширина окна, разрешение экрана, пользовательские настройки и установленные нашими пользователями шрифты лишь некоторые из нематериальных активов с которыми мы пытаемся “договориться”, когда публикуем нашу работу, и за эти годы мы стали невероятно искусны в этом.
Но пейзаж меняется, возможно, быстрее, чем нам могло бы нравиться. Мобильный браузинг, как ожидается, вытеснит десктопный в течении ближайших лет. Мы разрабатываем для мышей и клавиатур, для T9 клавиатур, для портативных игровых контроллеров и игровых консолей, для сенсорного интерфейса. Короче говоря, мы сталкиваемся с большим количеством устройств, режимов ввода, и браузеров, чем когда-либо прежде.
В последние годы я встречался с большим количеством компаний, которые просят "iPhone сайт" как часть их проекта. Это интересная фраза: На первый взгляд, конечно, это говорит о качественном мобильном WebKit в качестве браузера, а также мощном бизнес-плане, который выходит за пределы десктопа. Но, как дизайнеры, мне кажется, мы часто чуствуем себя комфортно в таких четких требованиях, так как они позволяют нам разложить по полочкам стоящие перед нами проблемы. Мы можем изолировать мобильный доступ на отдельных субдоменах, четко разграничить и отделить его от “не-iPhone сайта”. Но что же дальше? iPad веб-сайт? N90 сайт? Можем ли мы продолжать прилагать усилия на поддержку каждого нового пользовательского агента? В какой-то момент это начинает напоминать игру с нулевой суммой. Но как мы и наши проекты можем адаптироваться?
Гибкая основа
Давайте рассмотрим пример дизайна. Я построил простую страницу для гипотетического журнала - это простейшая двухколоночная разметка, основанная на плавающей сетке, приправленная несколькими гибкими изображениями. Как давний сторонник нефиксированных разметок, я давно чувствовал, что за ними будущее, просто потому, что она были независимы от разметок как таковых. И в определенной степени, это правда: гибкие конструкции не делают никаких предположений о ширине окна браузера, а также великолепно адаптируютя к устройствам, которые имеют портретный и ландшафтный режимы.
Но нет дизайна, фиксированного или плавающего, который легко масштабируется вне контекста, для которого он был первоначально предназначен. Наш пример дизайна прекрасно масштабируется, во время изменения размера окна браузера, но при более низких разрешениях быстро появляются точки напряжения. При просмотре с разрешением меньше 800 × 600, иллюстрация за логотипом становится обрезанной, текст навигации может выглядет неподобающим образом, а изображения в нижней части становятся слишком компактным и неразборчивыми. И этому подвержены не только низкие разрешения: при просмотре дизайна на широкоформатном дисплее, изображения быстро растут до громоздких размеров, вытесняя окружающий контекст.
Короче говоря, наша гибкая конструкция работает достаточно хорошо в десктоп ориентированном контексте, для которого она была спроектирована, но не оптимизирована для расширения далеко за пределы этого контекста.
Становимся отзывчивыми
Совсем недавно неожиданно появившаяся дисциплина под названием “отзывчивая архитектура” начала спрашивать, как физические пространства могут реагировать на присутствие людей, проходящих через них. Благодаря комбинации встроенной робототехники и текстильных материалов, архитекторы экспериментируют с художественными установками и стеновыми структурами, которые наклоняются, изгибаются и расширяются, как только к ним приближается толпа. Датчики движения могут быть соединены с системами климат-контроля для регулировки температуры помещения и освещения, как только оно наполняется людьми. Компании уже произвели "технологию смарт-стекла", которое автоматически может становится непрозрачным, когда посетители комнаты достигают определенного порога плотности, давая им дополнительный уровень конфиденциальности.
В своей книге “Интерактивная архитектура”, Майкл Фокс и Майлс Кемп описали это более адаптивным подходом, как "мультипетлевая система, в которой один вступает в разговор; постоянный и конструктивный обмен информацией". Курсив мой, так как я думаю, что это едва уловимое, но мощное различие: вместо создания незыблемого, неизменяемого пространства, которое определяет конкретный опыт, они предлагают жителя и структуру, которые могут и должны, взаимно влиять друг на друга.
Это наш путь вперед. Вместо того, чтобы “пришивать” дизайн для каждого из все больше появляющегося количества веб-устройств, мы можем рассматривать их как аспекты одного и того же опыта. Мы можем разрабатывать для оптимального качества просмотра, при этом встраивать в наши дизайн технологии, основанные на стандартах, чтобы сделать его не только более гибким, но и более адаптивными к медиа, которая его отображает. Короче говоря, мы должны практиковать отзывчивый веб-дизайн. Но как?
Встречайте media query
Со времен CSS 2.1, наши таблицы стилей пользовались некоторой степенью осведомленности об устройствах с помощью media types (медиа-типы). Если вы когда-либо создавали print style sheet, то вы уже знакомы с концепцией:
<link rel="stylesheet" type="text/css" href="/core.css"
media="screen" />
<link rel="stylesheet" type="text/css" href="/print.css"
media="print" />В надежде, что мы будем проектировать больше, чем аккуратно отформатированные распечатки страниц, спецификация CSS снабдила нас собранием приемлемых медиа-типов, каждый из которых предназначен для определенного класса веб-устройств. Но большинство браузеров и устройств никогда не следовали спецификации, в результате чего многие типы реализованы не полностью, или вообще игнорируются.
К счастью, W3C создал media queries (медиа-запросы) как часть CSS3 спецификации, улучшая существующие медиа-типы. Медиа-запрос позволяет нам определить не только определенные классы устройств, но и непосредственно проверить физические характеристики устройства, которые отображают нашу работу. Например, после роста мобильного WebKit, медиа-запросы стали популярной техникой на стороне клиента для доставки индивидуальных таблицы стилей для iPhone, Android-телефонов и им подобным. Чтобы сделать это, мы могли бы включить запрос в атрибут media таблицы стилей:
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px)"
href="/shetland.css" />Запрос состоит из двух компонентов:
- тип медиа (screen), и
- непосредственно запрос, заключенный в скобки, и содержащий конкретную возможность медиа (max-device-width) для проверки, которая сопровождается целевым значением (480px).
Говоря простым языком, мы запрашиваем у устройства: горизонтальное рарешение (max-device-width) равно или меньше 480px? Если тест пройден (другими словами мы просматриваем нашу работу на устройсвте типа iPhone), тогда устройство загрузит shetland.css. В противном случае, ссылка полностью игнорируется.
В прошлом дизайнеры экспериментировали со “знающей-о-разрешении“ разметкой, в основном полагаясь на JS-управляемые решения, такие как великолепный скрипт Камерона Адамса. Но спецификация медиа-запросов предоставляет множество возможностей, которые простираются далеко за пределы разрешение экрана, значительно расширяя рамки того, что мы можем протестировать с их помощью. Кроме того, вы можете проверить несколько значений свойств в одном запросе, соединяя их вместе ключевым словом “and”:
<link rel="stylesheet" type="text/css"
media="screen and (max-device-width: 480px) and (resolution: 163dpi)"
href="/shetland.css" />Более того, мы не ограничены в подключении медиа-запросов в наши ссылки. Мы можем включить их в наш CSS либо как часть правила @media:
@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}Или как часть директивы @import:
@import url("shetland.css") screen and (max-device-width: 480px);Но в любом случае, эффект будет один и тот же: если устройство проходит тест, выдвинутый нашим медиа-запросом, соответствующие CSS применяются к нашей разметке. Короче говоря, медиа-запросы являются условными комментариями для остальных из нас. Вместо того, чтобы определять конкретную версию конкретного браузера, мы можем хирургическим путем исправить проблемы в нашей разметке, как только она выходит за пределы своего первоначального, идеального разрешения.
Адаптируйся, реагируй и преодолевай
Давайте обратим наше внимание на изображения в основе нашей страницы. В разметке по умолчанию, соответствующий CSS может выглядеть вот так:
.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0; /* 21px / 633px */
width: 31.121642969984202211%; /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}Я опустил ряд типографических свойств, чтобы сосредоточиться на разметке. Каждый элемент .figure имеет размер примерно в одну треть от содержащей колонки, с обнуляющимся правым отступом для двух фотографий в конце каждой строки (li#f-mycroft, li#f-winter). И это работает довольно хорошо, пока просмотр либо заметно меньше, либо шире, чем наш оригинальный дизайн. С медиа-запросами мы можем применить специфические для разрешения точечные исправления, адаптируя наш дизайн для лучшего реагирования на изменения на экране.
Прежде всего, давайте разделим нашу страницу, как только просмотр упадет ниже определенного порога разрешения, скажем, 600px. Поэтому давайте создадим новый блок @media в нижней части таблицы наших стилей, например, так:
@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}Если вы посмотрите нашу обновленную страницу в современном десктоп-браузере и уменьшите размер окна ниже 600px, медиа-запрос отключит float на основных элементах дизайна, складывая в потоке документов каждый блок друг на друге. Таким образом, наш миниатюрный дизайн хорошо складывается, но изображения все еще не масштабируются. Если ввести другой медиа-запрос, мы можем изменить их расположение:
@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 48.341232227488151658%; /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}
Не обращайте внимание на неприглядные проценты; мы просто пересчитываем ширину плавающей сетки для учета вновь разделенного макета. Короче говоря, мы движемся от трехколоночной разметки к двухколоночной разметке, когда ширина окна просмотра падает ниже 400 пикселей, что делает изображение более заметным.
На самом деле мы может применить такой же подход для широкоформатных дисплеев. Для больших разрешений, мы могли бы адаптировать для наших изображений подход six-across, размещая их все в том же ряду:
@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%; /* 21px / 633px */
width: 13.902053712480252764%; /* 88px / 633px */
}
}Теперь наши изображения прекрасно работают на обоих концах спектра разрешения, оптимизируя размещение в ответ на изменения ширины окна и разрешения устройства.
Указывая более широкий min-width в новом медиа-запросе, мы можем сдвинуть изображения в разметку с одним единственным рядом.
Но это только начало. Работая с медиа-запросами, встроенными в наш CSS, мы можем изменить гораздо больше, чем размещение нескольких изображений: мы можем ввести новые, альтернативные разметки, настроенные на разный диапозон разрешений, возможно, делая навигацию более заметной при широкоформатном просмотре, или ее репозиционирование над логотипом на небольших дисплеях.
Но отзывчивый дизайн не ограничивается изменениями разметки. Медиа-запросы позволяют нам практиковать некоторые невероятно точные и тонкие настройки: мы можем увеличить целевую область ссылок для небольших экранов, для лучшей совместимости с законом Фиттса (Fitts’ Law) на сенсорных устройствах; выборочно показывать или скрывать элементы, которые могут усовершенствовать навигацию страницы; мы даже можем практиковать responsive typesetting постепенно изменяя размер нашего текста, оптимизируя читабельность.
НЕКОТОРЫЕ ТЕХНИЧЕСКИЕ ЗАМЕЧАНИЯ
Следует отметить, что медиа-запросы наслаждаются невероятно надежной поддержкой среди современных браузеров. Таике десктоп-бразуеры как Safari 3+, Chrome, Firefox 3.5+ и Opera 7+ все по умолчанию парсят медиа-запросы, также как и последние мобильные браузеры, такие как Opera Mobile и мобильный WebKit. Конечно, старые версии этих десктоп-браузеров не поддерживают медиа-запросы. И хотя Microsoft взяла на себя обязательство по поддержке медиа-запросов в Internet Explorer 9 (IE9 поддерживает медиа-запросы, прим. переводчика), в настоящее время он не предлагает собственную реализацию.
Однако, если вы заинтересованы в реализации поддержки медиа-запросов для устаревших браузеров, есть соответствующие JavaScript разработки:
- MediaQueries jQuery плагин с 2007 года предоставляет ограниченную поддержку, реализуя только min-width и max-width медиа-свойства, при закреплении за отдельными ссылочными элементами;
- css3-mediaqueries.js - библиотека, которая обещает что “IE 5+, Firefox 1+ и Safari 2 будут прозрачно парсить и применять CSS3 медиа-запросы” при включении через @media блоки. Релиз был многообещающим и я планирую следить за его разработкой.
Но если использование JavaScript не привлекает, то это вполне понятно. Однако, это укрепляет аргументы в пользу создания разметки поверх гибкой сетки, обеспечивая ваш дизайн определенной степенью гибкости для браузеров и устройств, которые не поддерживают медиа-запросы..
Путь вперед
Плавающие сетки, гибкие изображения и медиа-запросы - это три технических компонента для отзывчивого веб-дизайна, но это также требует другого образа мышления. Вместо того, чтобы ограничивать наш контент на разрозненный, устройство-специфичный опыт, мы можем использовать медиа-запросы для прогрессивного улучшения нашей работы в различных контекстах просмотра. Нельзя сказать, что нет экономического обоснования для отдельных сайтов, ориентированых на определенные устройства; например, если пользовательские цели для вашего мобильного сайта более ограничены по объему, чем его декстоп-эквивалент, то предоставление разного содержимого для каждого из них быть лучшим подходом.
Но такое мышление не должно быть нашим по умолчанию. Сейчас, более чем когда-либо, мы разрабатываем дизайн предназначенный для просмотра в разрезе диапазона различных устройств. Отзывчивый веб-дизайн предлагает нам путь вперед, наконец, позволяющий нам "делать дизайн для колеблющихся вещей".
