Тим Кедлек
АДАПТИВНЫЙ
ДИЗАЙН
Делаем сайты
для любых устройств
Москва • Санкт-Петербург - Нижний Новгород • Воронеж
Ростов-на-Дону ♦ Екатеринбург • Самара - Новосибирск
Киев - Харьков - Минск
2013

ББК 32.988.02-018
УДК 004.738.5
КедлекТ.
К34 Адаптивный дизайн: делаем сайты для любых устройств. — СПб.: Питер, 2013. —
288 с: ил. — (Серия «Библиотека специалиста»).
ISBN 978-5-496-00631-6
Новые устройства и платформы появляются каждый день. У разработчиков мобильных при-
ложений и сайтов существует реальная проблема: как корректно и качественно отобразить весь
контент на экране любого размера и соотношения сторон. Для решения этой задачи предназначен
адаптивный веб-дизайн.
Целью адаптивного веб-дизайна является создание универсальных веб-сайтов и приложений
для различных устройств. Для того чтобы с веб-сайтом или приложением было удобно работать
на устройствах с различным разрешением и различного формата, по технологии адаптивного ди-
зайна не нужно создавать отдельные версии для каждого вида устройств. Неважно, что будет ис-
пользоваться для просмотра сайта: смартфон, планшет, ноутбук или телевизор, подключенный
к Интернету.
Книга Тима Кедлека, известного специалиста в области веб-дизайна, рассказывает, как грамот-
но создать сайт с использованием «резиновой верстки» модулей media queries и fluid media, как
с самого начала правильно организовать рабочий процесс создания сайта в адаптивном дизайне
и как учитывать особенности различных устройств.
12+ (Для детей старше 12 лет. В соответствии с Федеральным законом от 29 декабря 2010 г.
ISBN 978-0321821683 англ.
ISBN 978-5-496-00631-6
© 2013 Tim Kadlec
© Перевод на русский язык ООО Издательство
«Питер», 2013
© Издание на русском языке, оформление
ООО Издательство «Питер», 2013
Права на издание получены по соглашению с New Riders
Publishing. Все права защищены. Никакая часть данной книги
не может быть воспроизведена в какой бы то ни было форме
без письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из ис-
точников, рассматриваемых издательством как надежные.
Тем не менее, имея в виду возможные человеческие или тех-
нические ошибки, издательство не может гарантировать абсо-
лютную точность и полноту приводимых сведений и не несет
ответственности за возможные ошибки, связанные с использо-
ванием книги.
Заведующий редакцией А. Кривцов
Руководитель проекта А. Кривцов
Ведущий редактор Ю. Сергиенко
Художественный редактор Л. Адуевская
Переводчик И. Рузмайкина
Корректор В. Ганчурина
Верстка Л. Родионова
ООО «Питер Пресс», 192102, Санкт-Петербург,
ул. Андреевская (д. Волкова), д. 3, литер А, пом. 7Н.
Налоговая льгота — общероссийский классификатор
продукции ОК 005-93, том 2;
95 3005 — литература учебная.
Подписано в печать 30.05.13. Формат 70x100/16.
Усл. п. л. 23,220. ТЪраж 2000. Заказ 468.
Отпечатано по технологии CtP
в ООО «Полиграфический комплекс «ЛЕНИЗДАТ».
194044, Санкт-Петербург, ул. Менделеевская, 9.
Телефон / факс (812) 495-56-10.

Содержание
Благодарности 10
Предисловие от Аарона Густавсона 12
Дополнительные материалы 14
ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ 15
Неверный выбор 17
Все новые и новые устройства 18
Размер экрана • 21
Скорость соединения 21
Поддержка стандартов 21
Методы ввода 22
Контекст 23
Отдельные сайты 23
Многообразие 25
Адаптивность 27
Прогрессивное улучшение 28
Подробнее о планах на будущее 30
Зачем снова об этом писать? 32
О чем эта книга? 33
Для кого эта книга? 34
Примеры кода 35
Сопроводительный сайт 35
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ 37
Варианты компоновки 39
Фиксированная ширина 39
«Резиновая» компоновка 41
Эластичная компоновка 42
Гибридные компоновки 43
Наиболее адаптивный подход 44
Размер шрифта 45
Пикселы 45
Единицы em 46
Проценты 48
Дополнительный вариант: единицы гет 50

СОДЕРЖАНИЕ
Наиболее адаптивный подход 51
Преобразование единиц измерения 51
Сетки 54
Контент как основа 55
Настройка сетки 56
Комбинация «резинового» и жесткого макетов 61
Макеты на основе таблиц 63
Подводя итоги 68
ГЛАВА 3. МЕДИАЗАПРОСЫ 69
Области просмотра 73
Пиксел это пиксел. Но не всегда 74
Тег Viewport и его свойства 75
Структура медиазапроса 80
Типы носителей 81
Медиафункции 83
Логические операторы 83
Стили 86
Встроенные и внешние медиазапросы 86
Порядок медиазапросов 88
От версии для настольных компьютеров 88
От версии для мобильных устройств 89
Основной интерфейс 93
Точки перехода 95
Контент как точка отсчета 95
Усовершенствование для больших экранов 99
Единицы em 101
Навигация 103
Переключение 105
Поддержка Internet Explorer 109
Подводя итоги НО
ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ 111
Истоки проблемы 112
Производительность 113
Изображения для мобильной версии 116
JavaScript 117
Introducing matchMedia 118

СОДЕРЖАНИЕ
Создание адаптивных изображений 122
Борьба с браузером 122
Отказ от борьбы 122
Обращение к серверу 123
Варианты адаптивных изображений 123
Сервис Sencha.io Src 123
Сервис Adaptive Images 124
И что же делать? 127
Фоновые изображения 128
Раз уж мы об этом заговорили 130
Экраны с высоким разрешением 132
ЯзьисБУв 134
Другие элементы фиксированной ширины 135
Видео 136
Улучшение интерфейса 137
Баннеры 140
Подводя итоги 143
ГЛАВА 5. ПЛАНИРОВАНИЕ 145
Выбор в пользу адаптивности 146
Факторы, которые нужно учесть 147
Производительность 147
Контекст 148
Контент сайта 148
Временные рамки 149
Поддержка 150
Реклама 150
Заключение 151
Статистические данные 151
Перекос в статистических данных 153
Какая статистика имеет значение 154
Данные о доле на рынке 155
Контент сайта ". 158
Аудит контента 159
Таблицы страниц 162
Выбор устройств 163
Оптимизирован для некоторых, доступен для многих 164

СОДЕРЖАНИЕ
Интерфейс для различных устройств 164
Испытательный стенд 167
Реальные устройства 167
Эмуляторы 170
Сторонние сервисы 170
Подводя итоги ; 172
ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ 173
На вкус и цвет 174
Интерактивная среда 175
Сотрудничество 175
Системное мышление 181
Сначала мобильные 181
Развитие мобильного Интернета 182
Необходимость концентрации 183
Увеличение ваших возможностей 185
Инструментарий 186
Каркасы 186
Прототипы 189
Руководства по стилям 195
Подводя итоги 199
ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ 201
Начиная с контента 202
Типы контента 203
Предназначение 204
Создание 204
Структура 204
Выбор контента для отображения 206
Удаление контента 207
Совершенствование контента 209
Изменение порядка отображения контента 214
И снова структура 215
Направление развития 217
Трудная ситуация с кодом 217
Первые шаги 219
Создание API 219
Подводя итоги 221

СОДЕРЖАНИЕ
ГЛАВА 8. ТЕХНОЛОГИЯ RESS 223
Распознавание агента пользователя 225
Анатомия строки агента пользователя 227
Зачем нужно распознавание агента пользователя? 227
Распознавание функций 228
Modernizr 229
Переход на сервер 230
Объединение распознавания агента пользователя и функций.. .232
RESS: лучшее из обоих миров 233
Сложное положение 234
Установка WURFL 238
Конфигурация 239
Возможности распознавания 241
Телефонные звонки 246
Оптимизация для сенсорных экранов 249
Подводя итоги 252
ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ 255
Система датчиков 256
Сеть 258
Что можно сделать 259
Контекст 262
Классификация контекстов 265
Наблюдайте и исследуйте 266
Функциональные возможности 267
Типы ввода в HTML5 267
API 272
Подводя итоги 281
ПОСЛЕСЛОВИЕ. ГЛЯДЯ В БУДУЩЕЕ 283
Благодарности за фото 287
Об авторе 288
О научном редакторе 288

Моей жене и нашим прекрасным
доченькам.
Благодарности
Часто говорят, что книги пишут в одиночестве. Возможно, в не-
которых случаях это действительно так, но я о себе подобного
сказать не могу. Эта книга получилась благодаря тяжелой работе,
терпению и отзывчивости всех, кто помогал мне в процессе
работы над ней.
Я обязан сказать вам огромное спасибо...
Майклу Нолану (Michael Nolan), первым предложившему мне
написать книгу. Спасибо за то, что поверил в меня.
Маргарет Андерсон (Margaret Anderson) и Гретхен Дейкстра
(Gretchen Dykstra), снисходительно относившимся к моим ошиб-
кам в пунктуации. Благодаря вашей работе возникло впечатле-
ние, что я формулирую фразы намного лучше, чем умею делать
это на самом деле.
Даниэль Фостер (Danielle Foster), придавшей этой книге совер-
шенно фантастический вид и даже в последнюю минуту уму-
дрившейся внести в макет усовершенствования. А также Роуз
Вайсберд (Rose Weisburd), Джою Дину Ли (Joy Dean Lee), Арин
Стрейер (Aren Straiger), Мими Хефт (Mimi Heft), Ребекке Винтер
(Rebecca Winter), Глену Бизиньяни (Glenn Bisignani) и остальным
членам команды издательства New Riders за помощь, благодаря
которой эта книга увидела свет.
Эду Мерритту (Ed Merritt), Брэду Фросту (Brad Frost), Гаю Под-
жарны (Guy Podjarny), Хенни Свои (Henny Swan), Люку Вро-
блевски (Luke Wroblewski), Тому Маслену (Tom Maslen) и Эрику
Раньону (Erik Runyon) за их потрясающие дополнения. Именно
ваше желание поделиться накопленным опытом сделало книгу
намного богаче, чем она была до этого.
Джейсону Григсби (Jason Grigsby), следившему за фактической
точностью излагаемого материала, делавшему ценные (и часто

БЛАГОДАРНОСТИ 11
очень забавные) замечания и вдохновлявшему меня в про-
цессе работы. Джейсон не только умнейший из людей, которых
я знаю, — он всегда готов прийти на помощь. Я благодарен за
возможность называть его своим другом.
Аарону Густавсону (Aaron Gustafson) за написание такого заме-
чательного предисловия. Я учился у Аарона с первых моментов
своей работы в Сети, поэтому сказать, что смущен и польщен
оказанной мне честью, будет явным преуменьшением,
Стивену Хею (Stephen Hay), Стефании Ригер (Stephanie Rieger),
Брайану Ригеру (Bryan Rieger), Дереку Пенникафу (Derek
Pennycuff), Итану Маркотту (Ethan Marcotte), Крису Робин-
сону (Chris Robinson), Полу Томпсону (Paul Thompson), Эрику
Видеману (Erik Wiedeman), Cape Вочер-Боэчер (Sara Wachter-
Boettcher), Лайзе Денжер Гарднер (Lyza Danger Gardner), Кри-
стоферу Лэйону (Kristofer Layon), Зои Джилленуотер (Zoe
Gillenwater), Джефу Брюссу (Jeff Brass), Биллу Зоэлю (Bill Zoelle),
Джеймсу Кингу (James King), Майклу Лехману (Michael Lehman),
Мэтту Маркусу (Mat Marquis), Нишанту Котари (Nishant Kothary),
Энди Кларку (Andy Clarke), Ронану Кремину (Ronan Cremin),
Дениз Джекобе (Denise Jacobs) и Сеннид Боулз (Cennydd Bowles)
за их идеи, отзывы и подбадривания, сопровождавшие меня на
всем протяжении творческого процесса. Эта книга своим по-
явлением во многом обязана их присутствию.
Я хотел бы также поблагодарить всех, разговоры с кем, как лич-
ные, так и в Сети, вдохновили меня на ряд комментариев, позднее
вошедших в книгу. Вокруг меня было множество незаурядных
людей, и я счастлив быть частью такого коллектива.
Большое спасибо моим родителям за их любовь и поддержку.
Любимым дочерям, напоминавшим мне о необходимости иногда
отрываться от работы, чтобы поиграть с ними, и наполнявшим
мои дни смехом, поцелуями и объятиями. И моей потрясающей
жене Кэйт. Эта книга и все остальное хорошее, что я сделал в этой
жизни, — прямой результат ее нежной поддержки и одобрения.
Нет слов, чтобы выразить, как сильно я ей благодарен.

Предисловие от
Аарона Густавсона
Несколько лет назад легендарный фотограф Чейс Ярвис (Chase
Jarvis) очень верно заметил: «Лучшая Камера та, которая у вас
с собой». Для того времени это было слегка шокирующим за-
явлением, но оно несло зерно истины: совершенный кадр прак-
тически никогда не планируется. Он настигает вас неожиданно.
Возможно, свет идеально подчеркнет осеннюю листву во время
вечерней прогулки. Или ваша дочь в первый раз в жизни встанет
на обе ноги. В такие моменты совершенно не важно, что на полке
в соседней комнате покоится фотоаппарат фирмы Leica или что
вы забыли в машине свой Canon EOS 10D. Главное, чтобы под
рукой оказалась хоть какая-нибудь камера для запечатления этих
быстро проходящих мгновений.
Взяв эту аналогию за основу, Стефани Ригер (Stephanie Rieger)
доказала, что лучший браузер — тот, который у вас под рукой.
Ведь наша жизнь непредсказуема. Возможности появляются и ис-
чезают. Вдохновение настигает нас там, где мы этого и не ждем.
Представьте, что вы занимаетесь исследованиями рака. Вы пере-
лопатили гору литературы в поиске способа увеличить производ-
ство интерферона, чтобы подстегнуть естественную способность
человеческого организма тормозить развитие опухолей. Чувства
подсказывают, что ответ уже совсем рядом. И вот однажды утром
во время приема душа вас внезапно озаряет. Эврика! Кажется,
что решение у вас в руках, нужно только свериться со статьей,
которую вы читали на прошлой неделе.
Вы вылетаете из ванны и приземляетесь на коврик. Хватаете
с полочки мобильный телефон и заходите на сайт журнала.
Только затем, чтобы вас перенаправили на «облегченную» версию
сайта, которая содержит лишь общие сведения и предложение
оформить подписку.
1 Аарон Густавсон — автор книги «Adaptive Web Design: Crafting Rich Experiences
with Progressive Enhancement» (вышла в издательстве Easy Readers в 2011 году).

ПРЕДИСЛОВИЕ ОТ ААРОНА ГУСТАВСОНА 13
Ваши пальцы оставляют на экране мокрые полосы, пока вы фа-
натично прокручиваете страницу в поисках бесценной ссылки на
полную версию сайта. После перехода по ней вы оказываетесь на
главной странице, стоящей из такого количества разрозненных
фрагментов, что кажется, будто ее специально сделали макси-
мально неудобной.
Через несколько минут щипков, масштабирования и ввода
данных вы находите-таки нужную статью, но выясняется, что
она представлена в формате PDF и практически нечитаема на
миниатюрном экране телефона. Остается только отложить теле-
фон и вернуться в душ, чтобы попытаться смыть разочарование.
К сожалению, попытки заходить в Интернет с мобильного теле-
фона слишком часто заставляют испытать разочарование. А ведь
такого быть не должно.
На страницах этой книги мой друг Тим рассказывает, какие шаги
вы можете (и по большому счету должны) предпринять, чтобы
гарантировать всем пользователям создаваемых вами сайтов
незабываемый опыт, рассчитанный на функциональность его
устройства и учитывающий, что его время, терпение и данные
ограничены. Пусть вас не вводит в заблуждение его молодость:
Тим хорошо знает свое дело. Я многое узнал из его книги и уве-
рен, что вы сможете сказать о себе то же самое.

14 ДОПОЛНИТЕЛЬНЫЕ МАТЕРИАЛЫ
Дополнительные материалы
Адаптивный дизайн является предметом бурных обсуждений.
Эта книга как бы подводит итог дискуссиям, которые разверну-
лись в нашем сообществе по данному вопросу. Поэтому я пред-
ложил некоторым участникам написать небольшие статьи, ис-
ходя из собственного опыта работы и проектов, в которых они
принимали участие.
Вот эти статьи в порядке их появления в книге:
• Медиазапрос вертикальных размеров, автор Эд Мерритт,
страница 90.
• Адаптивный дизайн и производительность, автор Гай
Поджарны, страница 120.
• Большие ожидания маленьких смартфонов, автор Том
Маслен, страница 156.
• Адаптивный дизайн и доступность, автор Хэни Свои,
страница 161.
• Продвижение адаптивного дизайна, автор Брэд Фрост,
страница 179.
• Практическое применение технологии RESS, автор Эрик
Раньон, страница 236.
• За пределами макета, автор Люк Вроблевски, страница 270.
Все эти авторы лично экспериментируют с адаптивным дизайном
с момента появления этой концепции. Они реализуют обсуж-
даемые в данной книге техники и вносят свой вклад в обсужде-
ние. Для меня большая честь включить в свою книгу их статьи,
написанные на основе полученного в процессе работы опыта.

Глава 1
Интернет на
каждом шагу
Только самонадеянный человек верит, что
он может спроектировать город, и только
у человека, лишенного воображения, может
возникнуть такое желание.
Джон Кэй

1 б ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Под конструк-
тивным решени-
ем (form factor)
подразумевают
размер, конфигу-
рацию и физиче-
ские характери-
стики устройства.
Неправдоподобно нестабильная среда
Новые операционные системы появляются не так уж редко. То
и дело сменяют друг друга браузеры. Каждый день нам пред-
ставляют устройства большего размера, устройства меньшего
размера, устройства, обладающие удивительной способностью
бороздить просторы Интернета, устройства с экзотическими
браузерами, устройства с сенсорными экранами и клавиатурой.
И при этом старые устройства и браузеры продолжают исполь-
зоваться. Технология развивается с удивительной скоростью,
но это не означает, что все новинки обязательно останутся на
рынке. Иногда новое устройство появляется только для того,
чтобы через несколько месяцев кануть в Лету.
Поэтому усвоить следует только одно. Правомерные сегодня вещи
могут оказаться совершенно некорректными завтра. И именно
это является причиной хаоса.
Впрочем, положительные моменты в данной ситуации тоже есть.
Хаос порождает путаницу, но он же питает творческие способ-
ности и тягу к изобретению нового. При появлении на рынке
новых конструктивных решений и все более функциональных
браузеров экспоненциально растет количество приложений
и ситуаций, для которых мы можем создавать свою продукцию.
Интернет универсален. Мы сталкиваемся с ним на каждом шагу.
В отличие от всех предшествующих ему сред, он адаптируем
к любому экрану и любому контексту. Он гибок и эластичен по
своей сути.
В этой главе мы обсудим следующие темы.
• Растущее многообразие сетевых устройств.
• Такие факторы, как размер экрана, скорость соединения,
поддержка стандартов, методы ввода и контекст.
• Обреченное на поражение стремление создавать отдельные
интерфейсы под конкретные ситуации.
• Необходимость адаптивного дизайна и значение термина
«адаптивный».
• Что вы найдете в остальных главах.
• Для кого предназначена данная книга.
• Принципы форматирования кода.

НЕВЕРНЫЙ ВЫБОР 17
Неверный выбор
Наблюдение за моими маленькими дочками учит многому.
Любая новая игрушка на некоторое время поглощает их внима-
ние, но потом они возвращаются к старым куклам. Они ищут
одинаковые черты, пытаются установить связь между старым
и новым. И через определенный период эксплуатации новой
вещи в подобной манере выявляют все, на что она годна.
Это имеет смысл, ведь прошлое мы изучили, меж тем как буду-
щее нам неведомо. Мы используем знакомые нам ментальные
модели. Мы предпочитаем безопасное и знакомое рискованному
и неизвестному. Но проблема в том, что постоянная опора на
прошлый опыт затрудняет эволюцию новых идей и сред.
Интернет не является исключением.
Как дизайнеры мы пытаемся перенести в Интернет наш опыт
работы с печатными страницами. Этот образ мышления влияет
на способ создания сайтов. Мы нацеливаемся на определенные
браузеры, оптимизируем страницу под определенную ширину,
прибегаем к различным трюкам в попытке получить один и
тот же вид в различных браузерах и на различных платформах.
Мы готовы на все, чтобы взять управление ситуацией в свои
руки, но по факту в Интернете управление находится в руках
пользователей.
Именно они выбирают браузеры. Они меняют масштаб стра-
ниц, чтобы увеличить или уменьшить размер букв. Они могут
как развернуть браузер на весь экран, так и просматривать
страницы в окошке, составляющем половину их реального
размера. Они покупают как плоды самых новых технологий,
так и модели, уже три года пылящиеся на полках с уцененной
продукцией. Они пользуются как встроенными браузерами, так
и многочисленными бесплатными альтернативами. Они про-
сматривают сайты как на бегу, так и в спокойной обстановке
дома. Именно они выбирают, где и каким способом посмотреть
созданный нами контент.
Впрочем, дизайнеры уже начинают это подозревать, хотя от
представления о том, что сайт должен всегда и везде выглядеть
одинаково, отказаться не так уж просто. А сделать это нужно.
Ментальной
моделью (mental
model) называется
представление
человека о том, как
функционируют
различные объекты.

18 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Данная истина становится все более очевидной благодаря по-
явлению на сцене все новых и новых устройств и платформ.
Все новые и новые устройства
Я в некотором роде параноик. Я не боюсь летать на самолетах, но
все время опасаюсь опоздать на рейс. В результате я постоянно
оказываюсь в переполненной зоне ожидания аэропорта задолго
до посадки и мне нужно как-то убить время.
И я начинаю наблюдать за людьми. Точнее, за устройствами,
которые они используют. В последний раз я оказался в малень-
ком провинциальном аэропорту из тех, где проверка багажа
занимает по пять минут. В зоне ожидания болтались примерно
два десятка людей. Но боже, что у них была за аппаратура!
Устройства Android и iPhone, хотя, конечно, попалось и несколько
обычных телефонов. Кто-та забился в угол с электронной книгой
Nook. Сидевшая рядом со мной пожилая леди читала новости
с планшета iPad.
Мы оказались на борту. Как только стюардесса объявила, что
можно пользоваться электронными устройствами, люди тут
же полезли в сумки. Та самая пожилая леди теперь достала
электронную книгу Kindle. После приземления она спрятала ее
и извлекла на свет iPhone.
Только вдумайтесь: один человек за какие-то пять часов ис-
пользовал для доступа к информации три различных аппарата.
Хорошее напоминание о том, сколько отличных от компьютера
устройств появилось на рынке за последние годы.
На конец 2011 года по всему миру было зарегистрировано
5,9 млрд мобильных устройств, что на тот момент соответство-
вало 87 % населения земного шара1. И эта цифра постоянно
растет: в первый раз общие поставки смартфонов превысили
поставки компьютеров в первой четверти 2010 года2.
Данные из статьи The World in 2011: ICT Facts and Figures, расположенной по
адресу: www.itu.int/ITU-D/lct/facts/2011/material/lCTFactsRgures2011.pdf
По данным со страницы http://evanwillhite.com/blog/web-now-mobile

ВСЕ НОВЫЕ И НОВЫЕ УСТРОЙСТВА 19
Растет также количество выходов в Интернет с мобильных
устройств, так как теперь телефоны предлагают для этой цели
намного более удобный, чем прежде, интерфейс. Раньше не-
многочисленные телефоны, с которых был возможен доступ
в Интернет, поддерживали только самые элементарные функ-
ции. Крайне ограниченным было и аппаратное обеспечение.
Устройства воспринимали только упрощенную версию XML,
так называемый WML (Wireless Markup Language — язык
разметки для мобильных устройств). Сети были ужасающе
медленными, размеры экранов — крайне малыми, а методы
ввода — неудобными.
Но как и любая технология, мобильные устройства имеют тен-
денцию к развитию. Первые более или менее функциональные
аппараты появились в начале 2000-х, но коренным образом ситу-
ация изменилась только к моменту появления первого смартфона
iPhone в 2007 году. Внезапно на мобильных устройствах появился
«настоящий Интернет». Интерфейс iPhone и следующих за ним
смартфонов превзошел все, что появлялось до этого.
Обеспечивая устройства приличным интерфейсом, мы увели-
чиваем частоту их использования. Например, радио Pandora
в 2011 году получило 60 % трафика именно с мобильных
устройств, в то время как в 2009 году эта цифра составляла
всего 25 %. За тот же временной промежуток количество по-
сетителей, которые пользовались мобильными устройствами,
для того чтобы войти в Твиттер, возросло с 25 до 55 % (рис. 1.1)1.
Фактически в 2010 году трафик мобильных сайтов увеличился
на целых 600 %2.
Среди мобильных устройств для захода в Интернет чаще всего
используются телефоны, но это далеко не единственный фактор,
влияющий на приведенные ранее показатели. Планшеты, наи-
более распространенным среди которых является iPad от Apple,
представляют собой промежуточный вариант между телефоном
и портативным компьютером. Обладая портативностью смарт-
фонов, площадью экрана они напоминают небольшой ноутбук.
Данные взяты со страницы http://therealtimereport.com/2011/10/21/mobile-devices-drive-more-
than-half-of-traffic-to-twitter-and-pandora/
Данные со страницы http://news.bango.com/2010/02/16/600-percent-growth-in-mobiie-web-usage/

20 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
По предварительным оценкам, к 2015 году доход от продажи
планшетов составит около $49 млн1.
Рис. 1.1.
Процентное
соотношение
мобильного
трафика сайтов
Twitter и Pandora
с 2009 по 2011
годы
60
50
40
30
20
PANDORA
TWITTER
2009
2010
2011
Телевидение, функционирующее через Интернет, на рынке
появилось относительно недавно, но учитывая усилия, пред-
принимаемые такими монстрами, как Google и Apple, продажи
этой услуги могут вырасти уже в ближайшем будущем. В то же
самое время игровые устройства, такие как Microsoft Xbox 360
и Nintendo Wii, поставляются со встроенными браузерами, по-
зволяя пользователям выводить содержимое сети Интернет
непосредственно на телеэкраны.
Устройства для чтения электронных книг, среди которых до-
минирует продукция от Amazon Kindle, а также марка Nook от
фирмы Barnes and Noble, также имеют встроенные браузеры. По
детализации и элегантности интерфейса они уступают браузе-
рам планшетов, смартфонов и компьютеров, но это не мешает
людям применять их по назначению. В эпоху повсеместно рас-
пространенной возможности подключения лучшим является
тот браузер, которым вы можете воспользоваться в данный
момент.
Я думаю, теперь вы убедились в том, что в настоящее время, как
никогда ранее, сайты должны допускать возможность использо-
вания на самых разных устройствах. При том что каждое из них
предлагает собственную комбинацию ограничений и доступных
функций.
1 По материалам www.businessweek.comAechnology/content/apr2011/tc20110418_512247.htm

ВСЕ НОВЫЕ И НОВЫЕ УСТРОЙСТВА 21
Размер экрана
Размер экрана во все времена был переменной величиной,
но по крайней мере было понятно, к чему нужно стремиться.
В 1984 году появился фирменный компьютер от Macintosh
с разрешением 512x342 пикселов. И в дальнейшем разреше-
ние становилось все больше и больше. Десятью годами позже,
в 1994 году был выпущен монитор Apple Multiple Scan 17" Display
с разрешением 1024x768. Но ситуация довольно быстро запута-
лась. Появились мобильные устройства с возможностью подсо-
единения к Интернету. После появления в 2007 году смартфона
iPhone с разрешением 320x480 стало невозможно уверенно
утверждать, что данный параметр будет только расти.
Сейчас ширина экрана популярных устройств варьируется от
280 до 1920 пикселов. Фактически у нас из-под ног выбили по-
чву — стандартного разрешения, увы, не существует.
Скорость соединения
Скорость соединения с Интернетом сильно влияет на опыт работы
с сетевыми ресурсами. К сожалению, этот параметр также значи-
тельно варьируется. Один посетитель ресурса может использовать
высокоскоростное проводное соединение, в то время как другой
вполне может просматривать его через мобильную сеть EDGE
с ужасной низкой скоростью и большим временем задержки.
Некоторые устройства и носители позволяют пользователям
создавать мобильные точки доступа, с помощью которых они
получают возможность подсоединять портативные компьютеры
к мобильной сети. Смартфоны, как и настольные компьютеры,
могут подсоединяться к беспроводным сетям. В итоге чем
дальше, тем слабее становится корреляция между устройством
и сетью, с которой оно работает. Дизайнерам остается только
строить предположения относительно этого параметра.
Временем за-
держки (latency)
называется время
перехода данных
из одной точки
в другую.
Поддержка стандартов
Увеличение числа платформ, браузеров и устройств приводит
к постоянной конкуренции. Новые стандарты и функции по-
являются быстрее, чем когда бы то ни было.

22 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Возросший темп эволюции, к сожалению, приводит к хаосу.
Слово «поддержка» давно уже трактуется более чем свободно.
Это уже не булево свойство, у него появилось множество сте-
пеней. Многие браузеры поддерживают одну и ту же функцию,
используя слегка различающийся синтаксис. Другие соответ-
ствуют стандартам только частично. Есть еще и третьи, самые
ужасные, в которых стандарты смешиваются с собственными
реализациями, что приводит к путанице в синтаксисе.
Дальнейшую неразбериху провоцируют новейшие устройства,
щеголяющие браузерами с ограниченной поддержкой стандар-
тов. Вспомним хотя бы крайне популярные электронные книги
Kindle. Их экраны сделаны на основе технологии электронных
чернил (e-ink), а значит, и встроенный браузер отображает все
данные в оттенках серого.
Конечно, это не настолько плохой браузер, как, к примеру, Internet
Explorer 6, но в плане поддержки стандартов его нельзя назвать
высококлассным. При этом данный браузер довольно активно
используется. Поэтому как бы ни был силен соблазн сбросить
со счетов браузеры с ограниченной поддержкой стандартов,
поддаваться ему не стоит, так как зачастую они встраиваются
в новые высококачественные устройства.
Методы ввода
Долгое время взаимодействие пользователей с компьютерами
осуществлялось одним и тем же способом. Клавиатура знакома
нам со времен пишущих машинок, а мышь — с момента появле-
ния в 1984 году первого Apple Macintosh. (На самом деле первые
упоминания о манипуляторе «мышь» возникли еще в 50-е годы
прошлого века, но популярность этот метод ввода данных обрел
только после интеграции с Macintosh.)
Но постепенно средства ввода также эволюционировали. По-
явились мыши с колесом прокрутки, трекпады и эти ужасные
маленькие кнопки со стрелками, которые так сложно нажимать
(наверное, у меня просто слишком толстые пальцы).
После появления устройств, реагирующих на касание, все еще
больше усложнилось. Они требуют особого подхода. Теперь
объекты должны иметь размер, допускающий управление при

ОТДЕЛЬНЫЕ САЙТЫ 23
помощи пальца. В отличие от устройств с непрямым управле-
нием, теперь невозможно предварительно навести на объект
указатель. Одновременно появилось поле для более естественных
движений: скольжения, протягивания для обновления и пере-
таскивания. Все это означает, что для устройств с сенсорными
экранами требуются совсем не такие сценарии и стили, как для
обычных компьютеров.
Контекст
Учитывать следует не только физические и архитектурные
характеристики устройств. Важен и контекст, в котором они
используются.
Люди выходят в Интернет в разных ситуациях: дома, на улице,
на автобусной остановке, ночью, днем, в кругу друзей или среди
незнакомцев. И этот контекст можно связать с типом устройства.
С телефонами обычно работают на ходу, но ими вполне можно
воспользоваться дома, лежа на диване. Портативный компьютер
могут поставить на стол в офисе, а могут на собственные колени
в электричке.
Контекст является сложной темой, но игнорировать его мы не
можем. Подробно он будет обсуждаться в главе 9. А пока вам
достаточно уяснить, что именно понимание контекста позво-
ляет перейти от Интернета, подстраивающегося под устройства,
к Интернету, подстраивающемуся под людей.
Потрясающее разнообразие устройств приводит к хаосу. Человек
же, вообще говоря, предпочитает стабильность. Поэтому не-
удивительно, что при виде открывшегося многообразия первым
делом возникнет порыв создать для каждого случая собственный
вариант сайта.
Отдельные сайты
На момент написания данной книги общепринятым являлось
создание версий одного и того же сайта под определенный тип
устройств (или же усилия вообще ошибочно направляются
на создание сайта под отдельное устройство). Часто это озна-

24
ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
чает наличие одной версии сайта для мобильного Интернета,
а другой — для обычных компьютеров (рис. 1.2). Но при этом
постоянно увеличивается число компаний, имеющих версию
для настольных компьютеров, версию для планшетов, версию
для мобильных устройств с сенсорным экраном и упрощенную
версию для мобильных устройств, у которых сенсорного экрана
нет. То есть для одной фирмы создаются четыре различных сайта.
Такой подход имеет свои преимущества. Например, намного
проще подстроить интерфейс под конкретные задачи в области
как контента сайта, так и поведения отдельных элементов. Стоит
ли придерживаться этого подхода? Это зависит от проекта, ком-
мерческих целей, пользователей, квалификации рабочей группы,
бюджета и прочих факторов, которые невозможно не учитывать.
Рис. 1.2. Теле-
канал CNN
имеет как сайт
для обычных
компьютеров,
так и версию
для мобильных
устройств
К сожалению, при этом сильно затруднено масштабирование,
ведь обновлять, тестировать и поддерживать приходится все
четыре сайта. Часто даже для одного сайта требуются несколько
разработчиков. Поэтому только представьте, какая нагрузка ло-
жится на плечи каждого сотрудника при увеличении количества
поддерживаемых сайтов! Некоторые также считают, что для

ОТДЕЛЬНЫЕ САЙТЫ 25
каждого сайта следует создавать собственное наполнение, что
требует еще больших времени и усилий.
Многообразие
Может быть, стоит обратить внимание на сходные черты? Разве
нельзя решить множество сложных задач, сузив количество
доступных устройств и платформ? К сожалению, это вовсе не
выход из положения.
В статье «Наступает зомби-апокалипсис», которая, несомненно,
является одним из лучших материалов по интересующей нас
тематике, Скотт Дженсон (Scott Jenson) аргументированно по-
казывает, что разнообразие будет только увеличиваться. Ведь
движущей силой в данном случае является не только быстрое
развитие технологий, но и уменьшение цен:
Наполнение рынка смартфонами — это только начало. Пониже-
ние цен на интегрированные одночиповые решения для мобиль-
ных устройств в сочетании с бесплатными версиями Linux типа
Android породило изобилие не просто дешевого оборудования,
но оборудования, ориентированного на облачные сервисы. Это
применимо как к телефонам типа Sony Ericsson Live View, так и к
бытовой технике, например музыкальной системе Sonos.
Это всего лишь начальные признаки большой, новой волны
дешевых устройств, готовых войти в нашу жизнь. Своего рода
зомби-апокалипсис с электроникой в роли зомби1.
И происходящее на рынке вполне укладывается в рамки этой
теории. Смартфоны становятся все более доступным товаром.
Некоторые версии смартфона iPhone, долгое время считавшегося
одним из самых дорогих телефонов, теперь можно получить бес-
платно при условии заключения контракта.
По мере падения цены на производство аппаратуры на рынке
появляются все новые и новые производители, наполняющие
его все новыми и новыми системами и устройствами. Поэтому
нужно не сосредоточиваться на поиске сходных черт, а пытаться
найти в океане новых устройств форм-факторы, пригодные для
работы с Интернетом.
Оригинал статьи на странице http://uxmag.com/articles/the-coming-zombie-apocalypse

26 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Рис. 1.3. Про-
тотип устройства
OmniTouch от
Microsoft позво-
ляет использо-
вать в качестве
экрана даже
собственную руку
Пока мы еще можем позволить себе создавать сайты под кон-
кретные устройства, но что будет завтра? Что произойдет, если
к Интернету начнут подсоединять даже холодильники? Неужели
придется разрабатывать новую модель интерфейса — оптими-
зированную для холодильников?
Что нас ждет, когда экран будет располагаться где угодно?
В 2011 году фирма Microsoft выпустила прототип устройства
OmniTouch — громоздкого, некрасивого аппарата, закрепля-
емого на плече. Но недостаток эстетики в данном случае ис-
купается потрясающей идеей. Ведь OmniTouch позволяет пре-
вратить любую поверхность — стену, пол и даже, как показано
на рис. 1.3, вашу собственную руку — в интерактивный дисплей,
позволяющий набирать буквы, цифры и даже рисовать. Инте-
ресно, когда появятся первые сайты, оптимизированные под
человеческую руку?
Подход, проповедующий создание отдельных сайтов для раз-
личных типов устройств, увы, слабо ориентирован на будущее.
А для выживания среди надвигающегося на нас многообразия
устройств важно по максимуму использовать гибкость Ин-
тернета.

АДАПТИВНОСТЬ 27
Адаптивность
В мае 2010 года Итан Маркотт (Ethan Marcotte) написал для
журнала A List Apart статью Responsive Web Design («Отзывчи-
вый веб-дизайн»). Описанный им подход был одновременно
простым и революционным. При помощи трех инструментов
(медиазапросов, «резиновой» сетки и масштабируемых изо-
бражений) он создал сайт, прекрасно выглядящий при разных
разрешениях (рис. 1.4).
В статье он настоятельно рекомендует дизайнерам пользоваться
преимуществами уникальных особенностей Сети:
Это наш путь вперед. Вместо подгонки разрозненных вариантов
дизайна под все новые и новые устройства мы можем предста-
вить их как грани одного и того же интерфейса. Можно взять
за ориентир оптимальное качество просмотра, одновременно
встраивая в дизайн технологии на основе стандартов, что обе-
спечит не только его гибкость, но и способность подстраиваться
под средства визуализации1.
Статья получила хвалебные отзывы, и вполне заслуженно. Мар-
котт показывает, что обеспечить различные устройства замеча-
тельным интерфейсом можно, не игнорируя их различия и не
пытаясь контролировать, а позволив им жить своей жизнью
и приняв изменчивость Сети.
Для начала расставим точки над i: реагирующий и мобильный
сайт — это не одно и то же. Данный постулат часто вызывает
путаницу и горячие споры. Разумеется, изрядная часть привле-
кательности адаптивного подхода именно в том, что он может
быть частью мобильной стратегии, но это не более чем непро-
думанное решение.
Адаптивным может быть сайт как для мобильного устройства, так
и для обычного компьютера или планшета. Маркотт прояснил
это в своей статье Toffee-Nosed:
Когда я говорю или пишу про адаптивный дизайн, я пытаюсь
выделить кое-что жирным шрифтом: адаптивный дизайн не
означает «сконструированный для мобильных устройств». Точно
так же это не означает «сконструированный для настольных
1 Страница www.alistapart.com/articles/responsive-web-design/

28 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Независимым
от устройства
(device-agnostic)
называется нечто
(компонент, ком-
поновка и т. п.)
совместимое
с устройства-
ми различных
типов и разными
операционными
системами.
компьютеров». Тут речь идет о более гибком, не зависящем от
устройства подходе к разработке для Интернета1.
Концепция независимости от устройства крайне важна. Мы
не знаем, какими устройствами люди пользуются для доступа
в Интернет. Не существует другой среды, доступ в которую
осуществлялся бы таким широким спектром устройств и таким
количеством пользователей. Дизайнеры должны использовать
это в своих целях.
Окончательно концепция еще не сформирована, но благодаря
тяжелой работе и многочисленным экспериментам адаптив-
ный подход претерпел значительные улучшения. В основе
остались все те же три элемента (медиазапросы, «резиновая»
сетка и масштабируемые изображения), но это только вер-
хушка айсберга.
Как оказалось, успешный адаптивный подход строится на тех
же самых принципах, что и прогрессивное улучшение. Попро-
сту говоря, он представляет собой расширенное прогрессивное
улучшение.
Прогрессивное улучшение
Долгое время интернет-сообщество придерживалось концепции
отказоустойчивости (graceful degradation)* позаимствованной из
других областей компьютерной науки, таких как работа с сетями.
Идея состоит в том, что при создании сайта с применением но-
вейших функций (которые работают только в самых последних
браузерах) следует сделать так, чтобы более старые браузеры,
несмотря на непонятную им разметку, все равно имели доступ
к контенту сайта.
Может показаться, что в этом нет ничего страшного, но в ре-
зультате мы получили менталитет, в котором практически не
рассматривается способ получения контента старыми браузе-
рами. Если данные в какой-либо форме доступны — не важно,
какого количества усилий это требует, — значит, вы успешно
практикуете отказоустойчивость.
Страница http://unstoppablerobotninja.com/entryAoffee-nosecl/

АДАПТИВНОСТЬ 29
Рис. 1.4. Исходный демон-
страционный сайт Итана
Маркотта показывает, что
адаптивный сайт может
работать с разными раз-
решениями при единой
кодовой базе

30 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Подробнее о планах на будущее
В книге вам не раз попадется словосочетание ориентированный на будущее {future
friendly). Именно оно является названием нашего манифеста.
Написанный группой разработчиков для мобильных устройств, манифест представ-
ляет собой набор принципов, которых имеет смысл придерживаться при реализации
вариантов веб-дизайна. Они задают намеренно высокий уровень. Конкретные тех-
ники со временем будут выходить из обращения, но характеристики, на которых они
основываются, никуда не денутся. Именно на них следует ориентироваться, выбирая
техники для реализации своих проектов.
Цитаты взяты с сайта http://futurefriend.ly.
• Точная фокусировка. Мы не можем подстроиться под все возможные
устройства. Чтобы выжить в мире, где сложность устройств постоянно рас-
тет, нужно сфокусироваться на наиболее важных для заказчиков и бизнеса
факторах.
• Концентрация на данных. Экосистема устройств требует общей совме-
стимости, и проще всего этого достичь с помощью устойчивого обмена
данными. Реагируйте на существующие и появляющиеся возможности,
определяя данные таким способом, чтобы обеспечить гибкие формы до-
ступа и уведомлений, использовать совместимые стандарты, сконцентри-
роваться на долгосрочной целостности, включить значимые и постоянные
ссылки на весь контент, поддерживать как операции чтения, так и операции
записи.
• Универсальный контент. Хорошо структурированный контент является
частью плана. Продумывайте, как с учетом имеющихся ограничений и ха-
рактеристик поместить данные в различные контейнеры. Смело исследуйте
новые возможности, но помните, что в будущем могут быть различные
варианты.
• Классификация устройств. Реагируя на возможные вариации устройств,
крайне сложно создать общий дизайн. Процесс адаптации могут упростить
наборы сходных стандартов высокого уровня для разных типов устройств.
• Управляйте целым флотом. Широкий диапазон доступных устройств по-
зволяет распределять между ними задачи и информацию. Соответственно,
каждый аппарат может осуществлять взаимодействие, к которому он
лучше всего приспособлен. В результате исчезает необходимость следить
за всеми аспектами работы каждого из устройств, а пользователь получает
возможность работать в экосистеме их функций.

АДАПТИВНОСТЬ 31
Но такой подход не слишком ориентирован на будущее. Он де-
монстрирует недостаток уважения к пользователям более старых
браузеров и игнорирует постоянно растущее количество новых
(мобильных) устройств, которые также работают с не слишком
функциональными браузерами.
В 2003 году Стивен Шампион (Steven Champeon) и Ник Финк
(Nick Finck) на фестивале «К югу от юго-запада» (SXSW — South
by Southwest) представили новую концепцию, которая называлась
прогрессивным улучшением1.
Новая концепция, по сути, ставит отказоустойчивость с ног на
голову. Вместо того чтобы создавать дизайн для самых новых
браузеров, позволяя более старым версиям обходиться тем, что
останется, нас призывают начинать строительство сайта с базо-
вой версии. При этом требуется использовать семантическую
разметку и структуру, фокусируясь на представлении контента
в чистой, практичной форме.
Затем добавляется следующий, более интерактивный слой, при-
чем таким образом, чтобы сохранить базовый интерфейс, обе-
спечив дополнительные возможности при просмотре в более
новых браузерах.
Аарон Густавсон (Aaron Gustafson), давний сторонник данного
подхода, сравнивает прогрессивное улучшение с показанной на
рис. 1.5 конфетой M&M's: контент в этой аналогии представлен
в виде ореха, внешний вид (CSS) — это шоколад, а интерактив-
ность (JavaScript) — оболочка конфеты. Контент сам по себе
готов к употреблению, но функциональный слой делает его вкус
намного богаче2.
Адаптивный дизайн использует аналогичный подход при обе-
спечении различных устройств подходящим контентом и ком-
поновкой. Начинать следует с некоего базового интерфейса,
который затем при помощи таких техник, как «резиновые» сетки
и медиазапросы, оптимизируется для устройств с большим ко-
Информация со страницы www.hesketh.com/thought-leadership/our-publications/inclusive-web-
design-future
Из книги Gustafson A. Adaptive Web Design: Crafting Rich Experiences with
Progressive Enhancement (Easy Readers, 2011).

32 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Рис. 1*5* Три слоя
конфеты M&M's
представляют
собой прекрас-
ную аналогию
для прогрессив-
ного улучшения.
Орех — контент,
шоколад —
внешний вид,
оболочка — инте-
рактивность1
личеством функций и большей площадью экранов (это не всегда
одно и то же!).
Зачем снова об этом писать?
Создать адаптивный дизайн непросто. Он требует полного
пересмотра наших подходов к Интернету. Имеющиеся у нас
инструменты и процессы создавались для немного иных задач.
Поэтому имеет смысл сделать шаг назад и задать себе несколько
вопросов.
• Следует ли принять в качестве интерфейса по умолчанию
интерфейс для настольных компьютеров?
• Какие изменения нужно внести в рабочий процесс, чтобы
начать разрабатывать дизайны и прототипы для различных
устройств и экранов разных размеров?
• Как лучше всего структурировать контент?
• Являются ли системы управления контентом (CMS) и ви-
зуальные редакторы (WYSIWYG) изначально несовершен-
ными?
Иллюстрация взята из книги Adaptive Web Design: Crafting Rich Experiences with
Progressive Enhancement с разрешения автора.

О ЧЕМ ЭТА КНИГА?
33
• Следует ли преодолеть наше давнее отвращение к стро-
кам user-agent (UA)?
• Как сделать контент переносимым?
• Как организовать поддержку множества устройств, ко-
торые могут появиться в будущем?
• Способны ли текущие стандарты (HTML, CSS) выдержать
грядущее разнообразие устройств?
• Как охватить различные контексты, не теряя согласован-
ности интерфейсов?
На часть этих вопросов ответить легко, на часть — сложно,
а часть до сих пор является предметом дискуссий. Написав
в мае 2010 года свою статью, Маркотт не просто познакомил
нас с новой техникой — он инициировал важное обсуждение,
включающее необходимое развитие нашей профессии.
Именно этому посвящена данная книга — принятию идеи
о гибкости Сети и созданию надежного адаптивного дизайна.
В следующих главах вы познакомитесь с техниками, необходи-
мыми для улучшения ваших сайтов и создания интерфейса, с
которым будет приятно работать на любом устройстве. Книга
содержит ответы, но вы найдете здесь и немало вопросов. Та-
кова природа среды, развивающейся такими темпами, как Сеть.
Строка user-agent
передается клиент-
ским приложением
веб-серверу и
содержит информа-
цию, позволяющую
идентифицировать
браузер и версию
операционной си-
стемы пользователя.
О чем эта книга?
Книга состоит из девяти глав, включая введение, которое вы
читаете в данный момент. Следующие три главы посвящены
трем догматам адаптивного дизайна.
• Глава 2 «"Резиновые" макеты». Здесь мы поговорим
о том, как отойти от дизайна с фиксированной шириной и
перейти к «резиновым» макетам и «резиновым» шрифтам.
• Глава 3 «Медиазапросы». Она знакомит вас с медиаза-
просами: типами запросов, принципами их применения
и способами определения точек перехода.
• Глава 4 «Адаптивные элементы». Здесь рассматриваются
такие элементы фиксированной ширины, как изображе-

34 ГЛАВА 1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
ния, видеоролики и рекламные баннеры, а также возмож-
ности встраивания их в адаптивные макеты.
Дальнейший материал посвящен влиянию данных догматов на
остальную часть процедуры конструирования сайта.
• Глава 5 «Планирование». Здесь вы узнаете, какие шаги,
следует предпринять для успешного планирования адап-
тивного сайта.
• Глава б «Процесс проектирования». Рассказывается, как
адаптивность дизайна влияет на процесс его создания.
Отдельно рассматриваются исходные материалы и этапы
конструирования, а также изменения, которые следует
внести в привычную процедуру.
• Глава 7 «Адаптивный контент». Здесь обсуждаются пла-
нирование, создание и отображение контента адаптивного
макета.
• Глава 8 «Технология RESS». Материал посвящен способу
объединения такого мощного инструмента, как адаптив-
ный дизайн, с исполнением части процессов на стороне
сервера, что позволяет получать более надежные решения.
• Глава 9 «Адаптивные интерфейсы». В заключительной
главе рассматриваются примеры применения адаптивного
мышления к практике работы в Сети. Вы узнаете, как
воспользоваться контекстом и уникальными функциями
устройств для создания адаптирующихся под нужды поль-
зователей интерфейсов.
Для кого эта книга?
Эта книга написана для дизайнеров и разработчиков, которые
хотят создавать сайты, корректно отображающиеся и функ-
ционирующие на самых разных устройствах. Опыта в области
адаптивного дизайна не требуется — первые пять глав обеспечат
вас всей необходимой информацией.
Но вы должны знать языки HTML и CSS и иметь представление
о JavaScript. В главе 8 также встречается код РНР, но понять опи-
сываемые концепции можно и без знания этого языка.

ПРИМЕРЫ КОДА 35
Примеры кода
В книге вы найдете множество примеров кода. Они выглядят
примерно так:
1. <html>
2. <head>
3. <title>Geolocation</title>
4. <meta name-"viewport" content="width=device-width" />
5. </head>
6. <body>
7. <p>Testing the geolocation API.</p>
8. <div ida="results"></div>
9. </body>
Изменения кода выделяются, что позволяет легко их обнару-
жить.
В некоторых случаях для экономии места неизменные фрагменты
кода сворачиваются. Свертка обозначается тремя точками. В при-
веденном далее фрагменте она находится в строчке 7:
1. <html>
2. <head>
3. <title>Geolocation</title>
4. <meta name="viewport" content="widthsdevice-width" />
5. </head>
6. <body>
7.
8, </body>
Сопроводительный сайт
Весь представленный в данной книге код доступен на сайте http://
implementingresponsivedesign.com. Также сайт является местом про-
верки опечаток и дополнительных ресурсов по обсуждаемым
в издании темам.
Большинство фрагментов кода из книги используются для
создания страниц вымышленного журнала Yet Another Sports
Site. Выполнять предлагаемые по ходу повествования задания
рекомендуется, но вы можете обойтись и без этого. Данная книга
не является практическим пособием, и понять обсуждаемые
концепции вполне возможно, не открывая редактор кода.

36 ГЛАВА1. ИНТЕРНЕТ НА КАЖДОМ ШАГУ
Немного о JavaScript
Среднестатистическая страница в Интернете в настоящее время имеет смешной вес
1 Мбайт. Из них 200 Кбайт приходятся на JavaScript. За последние годы количество
кода JavaScript увеличилось до 52,6 %. Это очень тревожная тенденция1.
По большей части это явление связано с массированным использованием фреймвор-
ков и подключаемых модулей. Идея пользоваться готовыми средами для упрощенной
разработки весьма соблазнительна, так как они уже стандартизированы и протести-
рованы. Но это требуется далеко не всегда.
В этой книге все фрагменты кода JavaScript написаны без применения популярных
фреймворков. Строго говоря, я ничего против них не имею. В этой книге вы познако-
митесь с несколькими полезными подключаемыми модулями jQuery. Но я выступаю
за тщательный отбор компонентов для страниц. Если вам требуется фреймворк, вос-
пользуйтесь им. В противном случае лучше написать собственный код, сэкономив
ресурсы на обработку страницы.
Сравнение данных за 15 июня 2012 года и 15 июня 2011 года выполнено на сайте
http://httparchive.org

&.
Глава 2
«Резиновые» макеты
Могучий дуб был выкорчеван ветром... Он
упал на траву и спросил у нее: «Удивительно,
почему такие легкие и слабые травинки не
страдают от этих сильных ветров?» Травинки
ответили: «Ты боролся с ветром, и поэтому он
тебя победил; мы же гнемся даже перед легким
ветерком и остаемся невредимыми».
Эзоп. «Дуб и тростник»

38 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
В басне «Дуб и тростник» ветры со всех сторон овевали могучий
дуб и маленькие травинки. Высокий и крепкий дуб пытался
сопротивляться любым ветрам. И в конце концов упал, побеж-
денный.
Травинки же предпочитали гнуться. И дело не только в том, что
они были готовы наклониться. Главное, у них была эта возмож-
ность. Они не боролись с ветром, а позволяли себе двигаться
вместе с ним. В результате их сгибало и скручивало, но не вы-
рывало из земли.
Долгое время мы создавали сайты, подобные дубам, — с жестко
заданной шириной. Они потрясающе выглядели, пока не сталки-
вались с неизбежной непредсказуемостью Сети. Значит, нужно
не бороться с этой непредсказуемостью, а принять ее.
Именно эту точку зрения выдвинул Джон Олсоп (John Allsopp)
в 2000 году в своей статье «Дао веб-дизайна»1 для издания A List
Apart. В индустрии, где общепринятые сегодня практики завтра
могут быть подняты на смех, откровения Олсопа оказались на
удивление пророческими. Он утверждал, что веб-сообществу
нужно принять гибкость Сети и прекратить считать недостаток
контроля ограничением:
Фактор, который я считаю величайшей силой Сети, часто рас-
сматривается как ограничение или даже дефект. Но гибкость
заложена в саму природу Сети, и мы, дизайнеры и разработчики,
должны принять этот факт и создавать гибкие страницы, которые
будут доступны всем.
Олсоп понял, что с гибкостью и непредсказуемостью не нужно
бороться. Это не дефекты, а свойства. Именно они обеспечивают
уникальность Сети, превращая ее в более мощную среду, чем
печатные издания.
По мере роста разнообразия устройств доступа игнорировать
внутреннюю гибкость и непредсказуемость Сети становится
все труднее. В результате 12 лет спустя индустрия приняла идеи,
высказанные Олсопом в статье. И первым небольшим шажком
к принятию гибкости Сети является создание «резиновых» ком-
поновок, подстраивающихся под размер устройства.
1 Ознакомиться со статьей можно на странице www.alistapart.com/articles/dao/

ВАРИАНТЫ КОМПОНОВКИ 39
В этой главе будут рассмотрены следующие темы.
• Четыре типа компоновок.
• Различные способы задания размера шрифта.
• Как создать макет на основе «резиновой» сетки.
• Как поступать с ресурсами, имеющими фиксированную
ширину, например с изображениями, в случае с «резино-
вым» макетом.
• Как скомбинировать «резиновые» столбцы и столбцы
с фиксированной шириной при помощи свойства
display:table.
Варианты компоновки
Чтобы понять, для каких ситуаций лучше всего подойдет «рези-
новая» компоновка, нужно рассмотреть все доступные варианты.
Только в этом случае вы сможете принять правильное решение
и обеспечить оптимальный вид сайта в различных средах.
В своей замечательной книге Flexible Web Design1 Зои Джилле-
нуотер (Zoe Mickley Gillenwater) определила четыре типа ком-
поновок: с фиксированной шириной, жидкая (или «резиновая»),
эластичная и гибридная.
Каждый тип имеет свои достоинства, ограничения и неодно-
значности.
Фиксированная ширина
При компоновке этого типа ширина сайта ограничена опреде-
ленным количеством пикселов — в настоящее время чаще всего
960 пикселами. В 2006 году Камерон Молл (Cameron Moll) напи-
сал в своем блоге статью «Оптимальная ширина для разрешения
1024 пиксела?», так как именно это разрешение тогда набирало
популярность. После появления браузера Chrome для маневров
осталось пространство шириной от 974 до 984 пикселов. Число
960 лучше всего подходит для макетов на основе модульных сеток
1 Gillenwater Z. M. Flexible Web Design (New Riders, 2008).

40 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
(так как оно делится на 3,4, 5, 6, 8,10,12 и 15, а значит, обеспе-
чивает разные варианты сеток). Кроме того, оно хорошо соот-
ветствует стандартам объявлений Международной ассоциации
интерактивной рекламы (IAB — Interactive Advertising Bureau)1.
В результате прижился именно этот размер.
Компоновки с фиксированной шириной реализуются в Сети чаще
всего. Они дают вам иллюзию контроля. Точное знание ширины
сайта позволяет создавать графически насыщенные варианты
дизайна, имеющие одинаковый вид на различных экранах.
Самой большой проблемой такой компоновки является слишком
большое число допущений, к которым приходится прибегать
при ее создании. При выборе ширины сайта нужно догадаться,
какой именно размер лучше всего будет выглядеть на устройствах
максимального количества посетителей. Это намного сложнее,
чем кажется. Еще до появления таких устройств, как смартфоны
и планшеты, размер экранов мог очень сильно различаться.
И это только часть проблемы. Некоторые пользователи не раз-
ворачивают окно браузера на весь экран. Другие устанавливают
дополнения, которые отображаются в браузере в виде боковой
панели, значительно уменьшая пространство, в котором будет
демонстрироваться сайт.
Также не следует обольщаться стабильностью, которую гаран-
тирует дизайн с фиксированной шириной. Если ширина вашего
сайта составляет 960 пикселов, а посетитель зашел на него
с устройства, ширина экрана которого, к примеру, всего 800 пик-
селов, он увидит только часть контента, а снизу появится полоса
горизонтальной прокрутки, как показано на рис. 2.1.
Проблемы будут и у посетителей со слишком большими мони-
торами. У них справа появится незапланированное белое про-
странство. Нет, оно даже может быть частью дизайна. Но от его
неожиданного переизбытка никому нет никакой пользы.
Жесткая компоновка с фиксированной шириной стала еще
большей проблемой в современной насыщенной экосистеме
устройств. Многие современные наиболее функциональные
телефоны и планшеты уменьшают масштаб таких сайтов, чтобы
1 Материал со страницы www.cameronmoll.com/archives/001220.html

ВАРИАНТЫ КОМПОНОВКИ
41
поместить их на экране. Пользователь при этом сам может менять
масштаб движением пальцев. Конечно, это лучше, чем невозмож-
ность менять масштаб или полное отсутствие доступа к сайту,
тем не менее процедура является довольно трудоемкой и особой
радости не приносит.
Рис. 2.1. Если
ширина экрана
оказывается
меньше ширины
сайта с фикси-
рованной ком-
поновкой, внизу
появляется полоса
горизонтальной
прокрутки
«Резиновая» компоновка
В «резиновых» вариантах компоновок размеры задаются не
в пикселах, а в процентах, что значительно увеличивает при-
способляемость конечного результата. Поэтому можно за-
дать ширину основного столбца как 60 % ширины контейнера,

42 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
ширину правой панели — 30 %, а зазора между ними — 10 %.
В результате не важно, каким образом на сайт попадет пользо-
ватель — с настольного компьютера, на котором ширина окна
браузера составляет 1024 пиксела, или с планшета с шириной
экрана 768 пикселов. Размер элементов страницы будет коррек-
тироваться соответствующим образом.
Для дизайна, построенного на основе такой компоновки, просто
не существует большей части проблем, с которыми приходится
сталкиваться при компоновке с фиксированной шириной. Гори-
зонтальная прокрутка по большей части просто не появляется.
Благодаря способности дизайна подстраиваться под ширину окна
браузера сайт лучше распределяется в доступном пространстве,
заполняя пустоты.
Намного проще при «резиновой» компоновке реализуются
и адаптивные стратегии, такие как медиазапросы и предназначен-
ные для оптимизации при различных разрешениях стили. (О них
мы поговорим чуть позже.) Словом, вам приходится решать на-
много меньше проблем, а значит, писать меньше правил CSS. Но
сама по себе «резиновая» компоновка не гарантирует, что сайт
будет корректно выглядеть на любом устройстве от смартфона
до телевизора. Столбцы могут оказаться слишком широкими
на больших экранах и слишком узкими — на маленьких. И это
только одна из возникающих проблем. Более подробно эта тема
будет рассмотрена в следующих главах.
Эластичная компоновка
В отличие от предыдущего случая, при эластичной компоновке
ограничения определяются размером шрифта и обычно измеря-
ются в единицах em. I em равен высоте используемого по умолча-
нию шрифта. Предположим, размер основного текста 16 пикселов.
В этом случае 1 em равен 16 пикселам, а 2 em — 32 пикселам.
Эластичные компоновки обеспечивают строгий типографский
контроль. Многочисленные исследования показывают, что
идеальной читабельностью обладают строки длиной от 45 до
70 символов1. Эластичная компоновка позволяет задать ши-
1 Чаще всего в этом случае ссылаются на книгу Роберта Брингхерста «Основы
стиля в типографике».

ВАРИАНТЫ КОМПОНОВКИ
43
рину контейнера равной, к примеру, 55 em. Это гарантирует
корректную длину строк внутри контейнера. Кроме того, если
посетитель решит поменять масштаб шрифта, пропорционально
изменятся и остальные элементы эластичной компоновки. На
этом мы остановимся более подробно в разделе, посвященном
размерам шрифтов.
К сожалению, эластичная компоновка не гарантирует отсут-
ствия горизонтальной прокрутки. Если при размере шрифта
16 пикселов вы задаете ширину контейнера 55 em, на любом
экране с разрешением ниже 880 пикселов (16x55) появится го-
ризонтальная прокрутка. Ситуация в данном случае еще менее
предсказуема, чем при фиксированной ширине. Если посетитель
увеличит размер шрифта, предположим, до 18 пикселов, ширина
контейнера тут же станет равна 990 пикселам (18x55).
Гибридные компоновки
Ну и, наконец, вы можете воспользоваться гибридной компо-
новкой, которая представляет собой комбинацию двух или трех
ранее предложенных вариантов.
Предположим, что под объявление выделено пространство
шириной 300 пикселов. Можно сделать боковую панель фик-
сированной ширины 300 пикселов, указав размер остальных
столбцов в процентах. Это дает возможность поддерживать
разработанную для объявления графику. (Что крайне важно,
учитывая жесткие требования сторонних рекламных сервисов.)
Остальная же часть компоновки будет растягиваться, заполняя
пространство в окне браузера.
При наличии плавающих блоков этот подход может привести
к полному хаосу на странице. Если задать ширину бокового
столбца равной 300 пикселам, оставив для основного столбца
70 % площади окна, на экранах размером менее 1000 пикселов
будет появляться горизонтальная прокрутка. Иначе говоря, если
размер боковой панели превышает 30 % области просмотра,
на основной столбец остается менее необходимых ему 70 %.
К счастью, существует альтернативный подход к созданию
гибридных компоновок, который будет рассмотрен чуть позже.
Областью
просмотра
(viewport) называ-
ется та часть окна
браузера, в кото-
рой отображается
сайт.

ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Медиазапросы
(media queries) по-
зволяют назначать
странице опреде-
ленные стили в за-
висимости от таких
характеристик
устройства, как ши-
рина, ориентация
и разрешение.
Тонка перехода
(breakpoint) явля-
ется местом при-
менения следую-
щего медиазапроса.
Например, кон-
трольная точка на
позиции 980 пик-
селов означает, что
как только ширина
окна браузера ста-
новится больше или
меньше этого числа,
в силу вступает но-
вый медиазапрос.
Наиболее адаптивный подход
Итак, какой же из методов лучше всего подойдет для разных
устройств и сред? В конечном счете это зависит от конкретного
проекта. Каждый из подходов имеет свои сильные стороны
и свои ограничения.
Чаще всего правильным будет выбор одного из гибких подхо-
дов — «резинового», эластичного или гибридного, так как они
намного сильнее ориентированы на будущее, чем компоновка
с фиксированной шириной.
Медиазапросы позволяют переходить от одной компоновки
с фиксированной шириной к другой. В результате можно полу-
чить красивые версии сайта для некоторого набора разрешений,
промежуточные же варианты все равно будут выглядеть не очень
хорошо. В итоге если устройство, с которого осуществляется
просмотр сайта, не отвечает указанным вами параметрам, сайт
будет выглядеть ненамного лучше, чем если бы вы его вообще
никак не пытались оптимизировать.
Так что хотя вариант с переключениями представляет собой шаг
в правильном направлении, по сути это все равно что бегать по
утрам, а потом ложиться на 30 минут на диван, поедая мороженое.
Вероятно, это лучше, чем ничего, но вы не получите при этом
максимально возможных результатов.
«Резиновая» компоновка дает вам куда больше. Даже без по-
мощи медиазапросов дизайн сможет подстраиваться под раз-
личные области просмотра, хотя результат может быть и не
идеальным.
Подробно познакомившись с медиазапросами (им посвящена
следующая глава), вы сможете забыть про большую часть за-
труднений, связанных с эластичными или «резиновыми» ком-
поновками. В результате большую часть работы сделает за вас
«резиновая» компоновка. Вы сможете ограничиться меньшим
количеством точек перехода и написанием меньшего количе-
ства CSS. При «резиновой» компоновке медиазапросы превра-
щаются в инструмент редактирования дизайна, а не его полной
перестройки.

РАЗМЕР ШРИФТА 45
Размер шрифта
Концепция гибкости Интернета означает, что размер шрифта
также является переменной величиной. Существует ряд единиц
изменения этого параметра, но в основном дизайнеры оперируют
пикселами, процентами и единицами em.
Пикселы
Продолжительное время пикселы были основным методом изме-
рения шрифтов. Причина этого очень проста: дизайнер мог точно
контролировать размер текста в браузере. Присвоив свойству
font-size значение 18 рх, вы гарантировали, что размер данного
текста во всех браузерах будет составлять ровно 18 пикселов.
К сожалению, за такой контроль приходится платить. Например,
становятся невозможными каскады, то есть размер шрифта роди-
тельского элемента никак не влияет на размер шрифта дочернего
элемента. В результате данный параметр приходится отдельно
определять для каждого элемента, отображающего текст другого
размера. Поддерживать подобные страницы очень сложно. При
попытке увеличить размер всего текста на странице потребуется
корректировать каждое из значений по отдельности.
Кроме того, шрифт, размер которого задан в пикселах, может
затруднить читаемость. Основные браузеры позволяют менять
масштаб страницы. Эта операция обрабатывается двумя спо-
собами. Во-первых, масштабированию могут подвергаться все
элементы страницы. Соответственно, при увеличении масштаба
увеличится не только текст (рис. 2.2). Этот метод работает вне
зависимости от того, как именно был задан размер шрифта.
Во-вторых, можно менять масштаб текста, оставляя остальные
элементы страницы в прежнем виде. Долгое время этот прием
был общепринятым, и некоторые браузеры до сих пор реализуют
данное поведение.
К сожалению, шрифты, размер которых задан в пикселах, не
масштабируются в браузере Internet Explorer. Соответственно,
для всех, кто пользуется версиями младше IE9, в которую мае-

46
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
штабирование шрифта встроено по умолчанию, размер букв на
странице будет недоступен для редактирования.
Проблема с изменением размеров наблюдается во многих ста-
рых устройствах, не имеющих сенсорного экрана. В некоторых
случаях не масштабируется вообще ничего. Иногда отдельные
элементы могут менять свой размер, в то время как шрифты
остаются неизменными.
ш
ш
Рис. 2.2. В неко-
торых современ-
ных браузерах
увеличивается
масштаб всех
элементов стра-
ницы, а не только
текста
Возможность регулировать размер текста дает пользователю
контроль над сайтом и увеличивает его удобочитаемость. Не-
которые посетители не в состоянии разобрать слишком мелкий
текст. Увеличив его масштаб, они все-таки получают доступ
к контенту сайта.
Задавать размер шрифта в пикселах не очень хорошо и с точки
зрения перспективы на будущее. Различные устройства имеют
разный размер экрана и разную плотность пикселов. В результате
шрифт, приемлемо выглядящий на одном устройстве, может
оказаться слишком большим на другом и нечитаемо мелким на
третьем (подробно эта тема будет рассматриваться в разделе
«Размеры шрифтов по умолчанию»). Задание размера шрифта
в пикселах можно считать одним из самых наглядных примеров
противодействия гибкости Сети.
Единицы em
Намного более гибким и все более популярным способом задания
размера шрифта являются единицы em. Как мы уже выяснили,

РАЗМЕР ШРИФТА 47
1 em равен размеру основного шрифта. Если для всей страницы
установлен шрифт 16 рх, то
• 1 em = 16 рх;
• 2ет = 32рх.
Единицы ет допускают изменение размеров в различных бра-
узерах. Также они дают возможность создания каскадов, что
одновременно и хорошо, и плохо. С одной стороны, упрощается
поддержка страницы. Чтобы пропорционально изменить размер
всех элементов, достаточно отредактировать базовый параметр,
все остальное изменится автоматически.
С другой стороны, эта возможность иногда все усложняет. На-
пример, рассмотрим следующий фрагмент кода:
<body>
<div id="main">
<hl>Question One <span>Please choose an answer from below.</
spanx/hl>
<p>In which book did H.G. Wells write: "Great and strange ideas
transcending experience often have less effect upon men and
women than smaller, more tangible considerations."</p>
l>
<li>The War of the Worlds</li>
<li>The World Set Free</li>
</body>
Стиль в данном случае задает следующий код CSS:
body {
font-size: 16px; /* базовый размер шрифта задан в пикселах */
}
Ы {
font-size: 1.5em; /* 24рх / 16рх */
}
span {
font-size: lem; /* 16px / 16px */
}
В приведенном примере базовый размер шрифта равен 16 рх.
Элемент hi имеет размер шрифта 1,5 em, что эквивалентно
24 пикселам. Мы хотим визуализировать содержимое контейнера
размером 16 пикселов, поэтому ему присваивается значение 1 em.
Но в результате меняется контекст. Основным становится не
текст тела документа, имеющий размер 16 пикселов, а заголо-

48
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
вок первого уровня размером 24 пиксела. Поэтому контейнер
будет отображать содержащийся в нем текст вместо ожидаемых
16 пикселов размером 24 пиксела.
Поэтому нам потребуется отредактировать размер шрифта
внутри контейнера:
span {
font-size: .666666667em; /* 16рх / 24рх */
Селектором
потомков
(descendant
selector) в CSS
называется меха-
низм, применяю-
щий стили ко всем
потомкам указан-
ного элемента.
Пытайтесь структурировать код CSS и HTML таким образом,
чтобы размер шрифта был предсказуемым. Например, если ис-
пользовать для основной части контента базовый размер шрифта,
а масштабировать только элементы заголовков, описанная про-
блема просто не возникнет. Ну а при использовании тщательно
продуманного HTML-кода эти проблемы можно легко решить
с помощью селектора потомков.
Проценты
Шрифты, размер которых указан в процентах, также легко под-
даются масштабированию и подчиняются принципу каскадиро-
вания. В данном случае если размер базового шрифта составляет
16 пикселов, то 100 % составляют 16 пикселов, а 200 % — 32 пиксела.
Хотя, теоретически, значительной разницы между единицами em
и процентами нет, первые постепенно становятся все более
предпочтительными единицами измерения шрифтов в Сети.
Технических причин для этого нет, единицы em употребляют
в основном потому, что они непосредственно связаны с раз-
мерами текста.
Но из-за одного из самых популярных браузеров Internet Explorer
задание размера базового шрифта в единицах em связано с одной
проблемой. При масштабировании Internet Explorer преувеличи-
вает степень уменьшения и увеличения шрифта. Предположим,
вы указали, что базовый размер шрифта составляет 1 em, а раз-
мер элементов hi — 2 em. В большинстве браузеров заголовки
первого уровня будут примерно в два раза больше основного
текста. А в Internet Explorer из-за данной неполадки они окажутся
намного больше.

РАЗМЕР ШРИФТА 49
Избежать этой проблемы можно, задав размер основного текста
в процентах:
body {
font-size: 100 %;
}
Что замечательно, заданный по умолчанию размер шрифта будет
относительно одинаков и равен 16 пикселам в большинстве бра-
узеров и устройств (немного подробнее эта тема будет раскрыта
в следующем разделе). Указав, что размер шрифта основного
текста страницы равен 100 %, вы гарантируете возможность
точного масштабирования, без преувеличений и преуменьше-
ний. После этого размер остального текста можно задать уже
в единицах em.
Размеры шрифтов по умолчанию
С некоторых пор базовым для настольных компьютеров считается размер шрифта
основного текста 16 пикселов. Соответственно, задав размер шрифта тела документа
как 100 %, вы получите согласованно масштабируемый шрифт.
Для других типов устройств это не всегда верно. Например, при тестировании смарт-
фона BlackBerry с операционной системой Blackberry 6.0 размер шрифта по умолчанию
составляет 22 пиксела. Еще сильнее отличается этот параметр для электронной книги
Kindle Touch: он начинается с 26 пикселов.
Такое разнообразие объясняется очень просто. Плотность пикселов у многих новых
устройств так высока, что шрифт размером 16 пикселов выглядит чересчур маленьким.
В большинстве случаев проблема решается передачей в браузер другого разрешения.
Например, разрешение экрана iPhone 4 составляет 640x960, в то время как браузер
демонстрирует контент с разрешением 320x480.
Другие устройства, такие как электронная книга Kindle Touch, отображают контент
браузера при полном разрешении, для компенсации увеличив размер шрифта по
умолчанию.
В конечном счете важен не реальный размер в пикселах, а читабельность шрифта
на экране. Используйте для размера базового шрифта значение 100 %, но помните,
что размер в пикселах может и не равняться 16. Именно тут имеет смысл прибег-
нуть к единицам em для определения медиазапросов. Но об этом мы поговорим
в следующей главе.

50 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Дополнительный вариант: единицы rem
Существует еще один гибкий вариант указания размера шриф-
тов, обладающий большим потенциалом: единицы rem (кор-
невой em). Они имеют одно важное отличие от единиц em:
всегда соотносятся с размером шрифта корневого элемента —
элемента HTML.
Единицы rem позволяют избежать проблем, связанных с каска-
дированием, возникающих при наличии вложенных элементов.
Обновим наш код CSS таким образом, чтобы стиль элементам
списка назначался с использованием единиц rem:
html {
font-size: 100 %; /* составляет примерно ~16рх */
}
Ы {
font-size: 1.5em; /* 24рх / 1брх */
}
span {
font-size: lrem; /* 1брх / 1брх */
}
В этом примере элемент hi до сих пор использует шрифт разме-
ром 24 пиксела. А вот элемент span будет отображаться размером
16 пикселов. Благодаря корневым единицам em элементы насле-
дуют размер шрифта от элемента html, а не от контейнера div.
Впрочем, прибегать к единицам rem нужно с оглядкой. В общем
случае они поддерживаются в браузерах для настольных компью-
теров, например в Internet Explorer 9+, Firefox 3.6+, Chrome 6.0+,
Safari 5.0+ и Opera 11.6+. Обеспечена их поддержка и в iOS 4.0+
и Android 2.1+. Но на момент написания книги остальные мо-
бильные платформы (в том числе популярная Opera Mobile)
с единицами rem не работали.
Поэтому нужно предусмотреть запасной вариант с размерами
в пикселах:
span {
font-size: 16px;
font-size: lrem;
}
При этом браузеры, поддерживающие единицы rem, будут рабо-
тать именно с ними, так как они объявлены в конце. А браузеры,

РАЗМЕР ШРИФТА
51
не имеющие подобной поддержки, проигнорируют первое
объявление и воспользуются размерами в пикселах.
Наиболее адаптивный подход
Для выбора корректного подхода потребуется сравнительный
анализ. Единицы em не только обеспечивают масштабирование
шрифта, но и упрощают поддержку. Для масштабирования
шрифта на всем сайте достаточно скорректировать значение
в процентах размера шрифта тела документа. Если же вы
предпочитаете единицы rem, из-за наличия дополнительного
варианта с размерами в пикселах потребуется обновить все
использующие эти размеры элементы кода.
Начиная с этого момента в книге будут использоваться размеры
в процентах для тела документа и размеры в единицах em — для
всего остального.
Преобразование единиц измерения
Было бы здорово, если бы каждый проект начинался с чистого
листа, позволяя плавно выстраивать дизайн в браузере. Но
в большинстве случаев речь идет о переходе от одного вари-
анта к другому, и при этом не обойтись без умения превращать
фиксированные размеры в нечто более гибкое.
С учетом этого факта рассмотрим представленный на рис. 2.3
фрагмент текста, размер которого был задан в пикселах.
Совет
Частично пробле-
мы с поддержкой
позволяют решить
такие препро-
цессоры CSS, как
SASS (http://sass-lang.
com) и LESS (http://
lesscss.org), а также
использование
переменных.
Рис. 2.3. Раз-
мер текста задан
в пикселах. Кра-
сиво, но совер-
шенно негибко

52 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
body {
font-size: 16рх;
font-family: Helvetica, sans-serif;
}
hi {
font-size: 24px;
}
span {
font-size: 12px;
Как видите, размер текста тела документа составляет 16 пиксе-
лов. Для элемента hi он равен уже 24 пикселам, а для элемента
span — 12 пикселам.
Перейти к более гибким единицам довольно просто. Начнем
с задания размера текста тела документа:
body {
font-size: 100 %;
font-family: Helvetica, serif;
}
Помните, что значение 100 % для большинства браузеров оз-
начает размер шрифта 16 пикселов. Также оно дает нам гибкую
базу для дальнейшей работы.
Указать размер остального текста в единицах em просто. Для
этого существует базовая формула.
Не волнуйтесь, вам не потребуется вычислять косинусы, извле-
кать квадратные корни или оперировать числом тс. Все намного
проще:
Цель/контекст = результат.
К примеру, возьмем элемент hi. Размер шрифта заголовка 24 пик-
села. Контекстом является размер шрифта элемента, в данном
случае это 16 пикселов элемента body. Значит, нужно разделить
24 на 16. В результате получится 1,5 em:
hi {
font-size: 1.5em; /♦ 24px / 16px */
}
Обратите внимание на комментарий, следующий за объявле-
нием. Как человек, которому часто приходилось чесать в затылке

РАЗМЕР ШРИФТА 53
в процессе просмотра ранее написанного кода, я настоятельно
рекомендую сразу же оставлять пояснения, откуда взялась та
или иная цифра.
Теперь можно применить данную формулу и к элементу span.
Так как он включен в элемент hi, контекст меняется. В результате
в новых единицах шрифт имеет размер 0,5 em (12/24).
После преобразования код CSS будет выглядеть следующим
образом:
1. body {
2. font-size: 100 %;
3. font-family: Helvetica, sans-serif;
4. }
5. hi {
6. font-size: 1.5em; /* 24px / 16px */
7. }
8. span{
9. font-size: .5em; /* 12px / 24px */
le. }
Рис. 2.4. Шрифт в новой
размерности ничем не
отличается от исходного,
заданного в пикселах, но
при изменении масштаба
сохраняются пропорции
всех частей текста

54
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Совет
Посмотреть дан-
ный пример в дей-
ствии можно на
странице http://
implementing-
responsivedesign.
com/ex/ch2/
ch2.1.html.
Теперь размер шрифта стал гибкой величиной. Если вам потре-
буется поменять размер основного текста, пропорционально
изменится и размер заголовков, как показано на рис. 2.4.
Сетки
Практика представления дизайна в виде сетки весьма популярна
и появилась за десятилетия до возникновения Сети. Сетки по-
могают сбалансировать, распределить и сгруппировать контент
сайта. Хорошо реализованная система сеток позволяет избежать
перенасыщения страниц лишними деталями, а также увели-
чивает читабельность и индексируемость сайта поисковыми
механизмами.
Немного о программах
В Интернете можно найти множество программ для создания дизайна на основе
сеток. Они комплектуются шаблонами и правилами CSS и помогают быстро полу-
чить один из стандартных макетов. Некоторые из них являются довольно гибкими,
другие этим похвастать не могут. По большей части программы предлагают сетки из
12 и 16 столбцов. Весьма соблазнительна идея задействовать любимую программу
для каждого нового проекта, но мы подойдем к делу более творчески.
Разумеется, сетка из 12 столбцов не имеет никаких внутренних дефектов, но посто-
янное ее применение даст вам только набор скучных однотипных макетов. Пре-
имущества дизайна на основе сеток проявляются только при наличии новых идей
для каждого проекта.
Не бойтесь комбинировать разные варианты и реализовывать сетки из трех или пяти
столбцов. Основой наиболее красивых сайтов зачастую является макет, отличный
от распространенных 12-столбцовых. Иногда более простой вариант и есть самый
лучший.
В книге «Как спроектировать современный сайт» Чои Вин1 вы-
деляет четыре основных преимущества дизайна на основе сеток.
Вин Ч. Как спроектировать современный сайт. СПб.: Питер, 2011.

сетки 55
• Сетки обеспечивают более упорядоченное, творческое
и гармоничное представление информации.
• Сетки позволяют посетителям лучше ориентироваться
на сайте и догадываться о местонахождении нужной им
информации.
• Сетки позволяют добавлять новую информацию, не на-
рушая общей целостности представления данных.
• Сетки облегчают совместную разработку отдельных ре-
шений, не нарушающих видения решения в целом.
Контент как основа
Первым делом вам нужно выбрать рабочую область. Именно
ее размеры определят сетку. Ширину рабочей области нужно
разделить на желаемое количество столбцов (3,5,9 и даже 12).
Как уже упоминалось, в Интернете отсутствуют привычные для
нас размерности. Значит, нужно взять за основу контент: пусть
именно он задаст параметры будущей сетки.
Сразу оговорюсь, что под словом «контент» я не имею в виду
только текст. Это могут быть также рекламные объявления,
видео, изображения. И каждый из этих типов данных влияет
на вид сетки. Например, если вы делаете сайт для фирмы, полу-
чающей доход главным образом от рекламы, для вычисления
размера ячеек сетки имеет смысл взять за основу размеры
объявлений, соответствующие стандартам IAB. А при рекон-
струкции большого сайта с множеством картинок именно на
них нужно ориентироваться при выборе параметров сетки.
Выбирать дизайн сайта, взяв за основу его контент, имеет смысл
и с практической точки зрения. Уже не вы пытаетесь втиснуть
картинки и рекламные объявления в предустановленную сетку,
а сетка поддерживает их с самого начала. В результате вы полу-
чаете целостность дизайна всех страниц сайта.
Впрочем, достаточно разговоров, давайте немного попракти-
куемся.

56
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Совет
Посмотреть на
полученный ре-
зультат можно на
странице http://
implementing-
responsivedesign.
com/ex/ch2/ch2-
start.html.
Примечание
На этой странице
для более полно-
го воплощения
задуманного
используются
несколько эле-
ментов HTML5.
Более подробно
об этом языке
можно почитать,
например, в кни-
ге Кристофера
Шмитта и Кай-
ла Симпсона
«HTML5. Рецеп-
ты программиро-
вания».
Настройка сетки
Начнем мы с создания вымышленного спортивного издания с на-
званием Yet Another Sports Site. Точнее, нам нужно разработать
сетку для страницы со статьей. Цвет и шрифты заданы использу-
емыми по умолчанию стилями. (Но заголовок и нижний колонти-
тул будут добавлены только в следующей главе, когда мы дойдем
до этой темы.) Итак, вот код, с которым нам предстоит работать:
1. <body id*"top">
2. <div id="container">
3. orticle class="main" role="main">
4. <hl>That guy has the ball</hl>
5. <p class="summary">In what has to be considered
a development of the utmost importance, that man
over there now has the ball.</p>
<p class="articleInfo">By Ricky Boucher |
<time>Danuary 1, 2012</timex/p>
<section>
<img src="images/football.jpg" alt="Football" />
6.
7.
8.
9.
10.
п.
12.
13.
14.
is.
16.
17.
is.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
</section>
</article>
<aside>
<section class="related">
<h2>Related Headlines</h2>
<ul>
<a href="#">That Guy Knocked Out the Other Guy</a>
</section>
<section class="ad">
<img src="images/ad.png" alt="Boombox ad unit" />
</section>
<section class="article-tags">
<h2>Tagged</h2>
<ul class="tags">
<lixa href="#ll>Football</a></li>
</section>
<section class="soundbites">
<h2>Sound Bites</h2>
<blockquote>
..this much is clear to me. If I were in his shoes,
I would have already won 5 Super Bowls.
<citexa href="#">-Guy with big ego</ax/cite>
</blockquote>
</section>
</aside>
<div class="more-stories">

СЕТКИ
57
41.
42.
43.
44.
45.
47.
48.
49.
50.
si.
52.
53.
<h2>More in Football</h2>
<ul class="slats">
<li class="group">
<a href="#">
<img src="images/ball.jpg"
alt=MLook, it's a ball!" />
<h3>Kicker connects on record 13 field
goals</h3>
</div>
</div><!-- /«container -->
</body>
Мы, как разработчики высокой квалификации, уже подробно
познакомились с будущим содержимым страницы и создали для
него пространственную структуру. Мы знаем, что это будет ста-
тья. А каждая статья снабжается заголовком, представленным
элементом hi, именем автора и кратким обзором, за которым
следует основной текст, разделенный на абзацы.
Также каждая страница со статьей должна содержать боковую
панель с последними заголовками в виде неупорядоченного
списка. Поскольку издание Yet Another Sports Site не берет
денег за публикацию, я должен зарабатывать по-другому. Зна-
чит, требуется дополнительное место для баннера размером
300x250 пикселов. Это первое ограничение, от которого мы
будем отталкиваться при конструировании сетки.
Ну и, наконец, боковая панель будет содержать список связанных
со статьей тегов и несколько цитат. Теги мы представим в виде
неупорядоченного списка, а цитаты выделим тегом blockquote.
Начнем с создания сетки старым способом, с применением раз-
меров в пикселах. Вместо разбиения на 12 столбцов ширины
960 пикселов возьмем сетку из девяти столбцов. Каждый из
них имеет ширину 84 пиксела, а зазор между ними составляет
24 пиксела. Итоговая ширина сетки составит 948 пикселов.
Баннер размером 300 пикселов хорошо поместится в последние
три столбца, оставив шесть для статьи.
Для начала зададим ширину контейнера:
#container{
width: 948px;
Совет
Множество
шаблонов сеток
для Photoshop
или Fireworks
доступны в хра-
нилище GitHub
Робби Мэнсона по
адресу: https://
github.com/robbie-
manson/960px-
Grid-Templates.

58
ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Совет
Посмотреть на
полученный ре-
зультат можно на
странице http://
implementing-
responsivedesign.
com/ex/ch2/
ch2.2.html.
Затем, при помощи свойства float выровняем статью и вспомо-
гательные элементы, попутно указав их ширину:
aside {
float: right;
width: 300px;
.main {
float: left;
width: 624px;
Теперь макет выглядит неплохо. Сетка создает единый дизайн,
длина строк статьи оптимальна для чтения. Но при попытке
уменьшить размер окца браузера возникает проблема. Как только
ширина окна становится меньше 948 пикселов, появляется го-
ризонтальная полоса прокрутки, а контент перестает умещаться
на экране (рис. 2.5).
Рис. 2.5. Страница
хорошо выглядит
на большом экране,
но уменьшение
окна сопровожда-
ется проблемами
Мы создали сетку, но дизайн корректно отображается только
у небольшой части аудитории. С этим нужно что-то делать.
ПЕРЕХОД К ГИБКОМУ ДИЗАЙНУ
Приведенной ранее формулой вычисления размера шрифта
(цель / контекст = результат) можно воспользоваться и для преоб-

сетки 59
разования макета в нечто более гибкое. Контекст в данном слу-
чае задает контейнер, ширина которого составляет 948 пикселов.
В результате мы можем легко получить «резиновый» макет:
aside {
float: right;
width: 31.6455696%; /* 300/948 */
}
.main {
float: left;
width: 65.8227848%; /* 624/948 */
}
Ну и, наконец, давайте сделаем «резиновым» раздел с дополни-
тельными историями:
.main {
float: left;
margin-right: 2.5316456%; /* 24px / 948px */
width: 31.6455696%; /* 300/948 */
Теперь, когда оба столбца стали гибкими, можно удалить ука-
зание фиксированной ширины контейнера. Соответственно,
вместо размера 948 пикселов зададим размер 95 % ширины
экрана и добавим небольшие поля:
#container{
width: 95%;
padding: .625em 1.0548523% 1.5em; /* 10px/16px, 10px/948,
24px/16px */
margin: auto 0;
В данном примере размер верхних и нижних полей задан в еди-
ницах em, а размер правых и левых полей — в процентах. Это
связано с контекстом. Ведь верхние и нижние поля определя-
ются размером шрифта.
Примечание
Почему 95%? Ни-
какого научного
обоснования у
этой цифры нет.
Просто я попро-
бовал несколько
разных вариантов,
и именно этот луч-
ше всего подошел
для браузеров раз-
личного размера.
Иногда решения
в дизайне находят
опытным путем.
ОБЪЕКТЫ ФИКСИРОВАННОЙ ШИРИНЫ
Следующая проблема связана с картинками. При изменении раз-
мера окна именно они становятся больным местом. Увеличишь
окно — картинка занимает только часть столбца. Уменьшишь —
она становится чересчур большой. К счастью, скорректировать
такое поведение очень легко.

60 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Алгоритм рассчета размеров
Если вы взяли на себя труд рассмотреть используемые по умолчанию стили, то, скорее
всего, обратили внимание на следующие три строчки:
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
По умолчанию размер контейнера в CSS рассчитывается несколько нелогично* Вы
указываете ширину, а к ней добавляются все задаваемые вами поля* Например, при
создании столбца шириной 300 пикселов и добавлении к нему слева и справа полей
размером 20 пикселов вы получите столбец, ширина которого составит 340 пикселов.
Это крайне неудобно при проектировании макетов на основе сеток для «резиновых»
сайтов»
Но присвоив свойству box-sizing значение border-box, вы объясняете браузеру, что
поля должны размещаться внутри контейнера указанных размеров. Это значительно
упрощает планирование «резиновых» макетов.
. зоОрх
Без свойства box-sizing (справа) контейнер размером 300 пикселов с полями 20 пик-
селов в итоге приобретет размер 340 пикселов. При значении box-sizing: border-box
контейнер сохранит размер 300 пикселов по ширине и высоте
Наличие вендорных префиксов (в нашем примере это -moz- и -webkit-) указывает на
хороший уровень поддержки. Единственным основным браузером с недостаточной
поддержкой является Internet Explorer до в версии. В то же время, к примеру, Chrome
и Rrefox поддерживали префиксы для экспериментальных, еще не включенных
в стандарт CSS свойств, начиная с первых версий.

КОМБИНАЦИЯ «РЕЗИНОВОГО» И ЖЕСТКОГО МАКЕТОВ
61
Для начала заставим изображения заполнять весь боковой
элемент, задав параметр width:
aside img,
.main img,
.slats img {
width: 100%;
}
Важно помнить, что для элемента img в коде HTML нельзя за-
давать атрибуты height и width. Если это сделать, изображение
не будет масштабироваться пропорционально. Для получения
«резиновых» изображений.нужно контролировать их размеры
исключительно средствами CSS.
Затем нужно объявить свойство max-width. Присвоив ему
значение 100 %, мы укажем браузеру, что размер изображения
не должен превышать размера контейнера (в данном случае его
роль играет боковая панель). В этом случае при уменьшении
размеров экрана изображение не выйдет за границы контейнера
и не будет обрезано:
aside img,
.main img,
.slats img {
width: 100%;
max-width: 100%;
Итак, мы получили «резиновый» макет, доступный для про-
смотра с самых разных устройств (рис. 2.6). Можно еще пора-
ботать над изображениями, улучшив внешний вид, но об этом
мы поговорим в главе 4.
Комбинация «резинового»
и жесткого макетов
Статья выглядит прекрасно и обладает нужной нам гибкостью.
Но предположим, что мы хотели бы зафиксировать правый
столбец, сделав его ширину равной 300 пикселам. Это вовсе не
обязательное действие, но с учетом того, что в боковой панели
у нас располагается реклама, выглядеть конечный результат
будет лучше.
Совет
Посмотреть на
полученный ре-
зультат можно на
странице http://
implementing-
responsivedesign.
com/ex/ch2/
ch2.3.html.

62 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
РИС. 2.6. НОВЫЙ f^:^I,«-,..,, ;,, ,..;-.;,.7-w ."."Г" ,.„7
«резиновый» I""•'•"•"■"■"л"лл'-и
макет выглядит | Tfe»f S*F h*« the ball
вполне при-
емлемо, даже
когда размер
экрана отлича-
ется от запла-
нированного
d
# ■
1СЮ

КОМБИНАЦИЯ «РЕЗИНОВОГО» И ЖЕСТКОГО МАКЕТОВ 63
Но пока мы пользуемся свойством float, это практически невоз-
можно. Как говорилось ранее, ширина основного столбца подби-
рается в соответствии с разрешением экрана. И в результате, если
зафиксировать размер правой панели, а для основного столбца
сохранить нынешний размер 63,125 %, на экранах шириной менее
960 пикселов начнутся проблемы.
Поэтому нам потребуется другой способ. А именно CSS-таблицы.
Макеты на основе таблиц
Еще не так давно основой большинства сайтов являлись таблицы.
Это нарушало семантику, было не очень аккуратно, заставляло
пользователей страдать, но работало. Затем стандарты Сети из-
менились, появилась идея отделения контента от оформления
и возросла важность семантической разметки. После долгой
борьбы стандарты вышли на первый план.
Но есть один аспект, в котором макеты на основе таблиц превос-
ходят CSS-макеты. Они упрощают представление сайта в виде
набора столбцов. Вы можете без особых затруднений скомби-
нировать фиксированный и «резиновый» варианты, выровнять
столбцы и строки. Средствами CSS эта задача так просто не
решается.
Свойство display в языке CSS принимает ряд имеющих отноше-
ние к таблицам значений, что дает вам возможность контроля.
Фактически присвоение этих значений аналогично установке
определенных HTML-тегов (табл. 2.1).
Таблица 2.1 Связанные с таблицами значения свойства display
ЗНАМЕНИ!
table
table-row
table-row-group
table-header-group
table-footer-group
СООТВЕТСТВУЮЩИЙ
HTML-ТЕГ
TABLE
TR
TBODY
THEAD
TFOOT
ЗНАЧЕНИЕ
table-column
table-column-group
table-cell
table-caption
СООТВЕТСТВУЮЩИЙ
HTML-ТЕГ
COL
COLGROUP
TD,TH
CAPTION

64 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Если вам не нравится идея применения в CSS связанных с табли-
цами значений, вас вполне можно понять. Критиковали макеты
на основе таблиц вполне заслуженно. Но в отличие от таблиц
в HTML, табличные значения в CSS определяют не значение со-
держимого, а только его визуальное представление.
Впрочем, table-значения свойства display даже сейчас приме-
няются не очень широко. Вину за это вполне можно возложить
на Internet Explorer. Если Firefox, Safari и Opera поддерживали
возможность подобной имитации таблиц довольно давно, то
в Internet Explorer она появилась только в версии 8. На момент
написания данной книги совокупное использование браузеров
Internet Explorer 6 и 7 составляло менее 5 %, поэтому я думаю,
что пора отряхнуть пыль с макетов на основе CSS-таблиц. Тем
более что в мобильные браузеры в большинстве своем также
встроена поддержка данной функции.
Присвоив свойству display столбцов значение table-cell, мы
сможем без проблем скомбинировать столбцы фиксированной
и переменной ширины:
.main {
display:table-cell;
aside {
display:table-cell;
width: 300px;
Теперь при изменении размеров окна браузера правый столбец
сохранит ширину 300 пикселов, в то время как основной столбец
заполнит остальное пространство. При этом пропадает раздели-
тельная полоса между столбцами, но ее легко вернуть на место
при помощи небольших полей:
.main {
display:table-cell;
padding-right: 2.5316456 %; /* 24px / 948px */
Как видно на рис. 2.7, без малейшего труда мы скомбинировали
столбец фиксированной ширины с «резиновым» столбцом, из-
бежав хаоса, который возникает в гибридном макете, если ис-
пользуется свойство float. Основной столбец может выглядеть
не очень хорошо при высоких разрешениях, но эту проблему

КОМБИНАЦИЯ «РЕЗИНОВОГО» И ЖЕСТКОГО МАКЕТОВ 65
мы решим в следующей главе в процессе рассмотрения медиа-
запросов.
fiat guy Ьа* the ball
Я«Ымм1 ШшяЛшт
! That guy has the bai
(That gmy hae the m*»*t«4 ншЛ!»-
ball '..m.m
Related ЯввЛаж»
Рис. 2.7. Благо-
даря свойству
displayrtable-cell
размер боковой
панели теперь
всегда составляет
300 пикселов, в то
время как основ-
ная панель запол-
няет остальное
пространство
Тищж!
Шат^ё Шшш

бб ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
ПОДДЕРЖКА СТАРЫХ ВЕРСИЙ INTERNET EXPLORER
По большому счету, тут можно было бы и остановиться. Вер-
сии браузера Internet Explorer, предшествующие 8-й, быстро
выходят из обращения. Но заказчики и целевая аудитория
бывают самые разные, и позволять старым версиям браузера
Internet Explorer визуализировать страницу как получится —
не самая лучшая идея. Контент при этом никуда не денется,
а вот на состоянии дизайна это может сказаться не лучшим
образом. Для таких ситуаций нужно подготовить несколько
альтернативных стилей.
Это делается при помощи условных комментариев, которые за-
ставляют Internet Explorer использовать для определенных версий
другую таблицу стилей. Поэтому создадим таблицу стилей ie.css.
Для ее загрузки в Internet Explorer версии 8 и ниже воспользуемся
вот таким условным комментарием:
<!-[if It IE 8]>
<link rel="stylesheetM href="/css/ie.ess" media=Mall">
Теперь для всех ранних версий браузера Internet Explorer вплоть
до 8-й будет загружаться своя таблица стилей.
К сожалению, она же будет загружаться и для Windows Phone 7.
Учитывая, что стили для маленьких экранов мы будем редакти-
ровать при помощи медиазапросов в следующей главе, сейчас
нам не нужно переопределять их через привязанную к IE таблицу
стилей. К счастью, проблему можно решить, слегка изменив ус-
ловный комментарий (первым эту возможность документировал
Джереми Кейт1):
<!--[if (It IE 8) & (!IEMobile)]>
<link rel="stylesheet11 href ="/css/ie.ess" media=iiallll>
Теперь о наличии альтернативных стилей можно позаботиться, не
затрагивая сайт, созданный для мобильных телефонов. Поэтому
вернем в файле ie.css стили двум гибким плавающим столбцам:
Статья Windows mobile media queries на странице http://adactio.com/journal/4494/

КОМБИНАЦИЯ «РЕЗИНОВОГО» И ЖЕСТКОГО МАКЕТОВ 67
.main {
float: left;
width: 65.8227848%; /* 624/948 */
}
aside {
float: right;
width: 31.6455696%; /* 300/948 */
Предостережение по поводу
свойства displayrtable
Перед тем как вы начнете радостно использовать свойство display:table везде, где
только можно, хотелось бы обратить ваше внимание на несколько моментов.
Во-первых, абсолютное позиционирование содержимого внутри элемента, заданного
как display:table-cell, невозможно. Если оно вам требуется, придется вставить внутрь
еще один контейнер div или поискать альтернативный способ создания таблицы.
Во-вторых, таблица является довольно жесткой структурой. Иногда же требуется
гибкая природа плавающих элементов. Например, слишком длинный текст может
по контуру обтекать изображение. Я еще раз повторяю: в веб-дизайне не бывает
однозначных и простых решений. Перед выбором того или иного подхода следует
тщательно рассматривать все требования. Это касается и применения свойства
display :table.
Имеет смысл упомянуть и спецификации CSS Grid Layout и Flexbox, обеспечивающие
намного более полный контроль над макетом. Но их поддержка пока ограничена.
Собственно, поэтому в книге и рассматривается вариант с display:table.
Это не совсем тот макет, который увидят пользователи браузе-
ров с лучшей поддержкой стандартов, но полученный результат
к нему довольно близок. Впрочем, сайты и не обязаны выглядеть
совершенно идентично во всех браузерах и на всех устройствах.
Хотя бы потому, что это попросту невозможно. Поэтому пользо-
вателей старых версий Internet Explorer мы снабдили красивым
макетом, вполне подходящим для их браузера.
Совет
Посмотреть на
полученный ре-
зультат можно на
странице http://
implementing-
responsivedesign.
com/ex/ch2/
ch2.4.html.

68 ГЛАВА 2. «РЕЗИНОВЫЕ» МАКЕТЫ
Подводя итоги
В большинстве случаев для сайта лучше всего подходят «рези-
новые» макеты (подгоняющие свои размеры под размер экрана).
Но можно создать и эластичный макет, ширина которого будет
зависеть от размеров шрифта.
Гибкий выбор размера шрифта упрощает поддержку и увеличи-
вает доступность сайта. Эта задача решается указанием размера
в процентах или единицах em, хотя в будущем, возможно, в по-
всеместный обиход войдут и единицы rem.
Сетка делает сайт структурированным и согласованным. Лучше
не выбирать предустановленные варианты, а конструировать
собственную сетку, исходя из контента сайта. Фактически она
формируется в зависимости от длины строк, размера изображе-
ний, рекламных объявлений и ряда других критериев.
Вы можете легко перейти от фиксированных единиц измерения
к гибким, разделив размер, который нужно получить в итоге,
на текущий контекст. Эта формула работает как для размеров
шрифта, так и для ширины экрана.
Таблицы CSS дают вам возможность легко комбинировать
столбцы постоянной и переменной ширины. Их прекрасно
поддерживают множество современных браузеров, а для Internet
Explorer версии 8 и ниже можно создать альтернативную таблицу
стилей, подключив ее при ломощи условных комментариев.
Мы создали гибкий макет для страницы сайта Yet Another Sports
Site, имеющий приемлемый вид при большем количестве раз-
решений, чем аналогичный макет с фиксированной шириной.
Однако его пока нельзя считать по-настоящему адаптивным.
На слишком узких экранах возникают проблемы с формати-
рованием, а на слишком больших дизайн начинает выглядеть
неряшливо.
В следующей главе мы решим эти проблемы при помощи ме-
диазапросов. Ведь именно они позволяют выбирать стили в за-
висимости от свойств используемого устройства. Именно эта
мощная техника позволит нам сделать шаг по дороге к настоя-
щему адаптивному дизайну.

Глава 3
Медиазапросы
Стань аморфным, бесформенным, как вода.
Когда воду наливают в чашку, она становится
чашкой. Когда воду наливают в чайник, она
становится чайником. Когда воду наливают
в бутылку, она становится бутылкой.
Брюс Пи
w^^l

70 ГЛАВА 3. МЕДИАЗАПРОСЫ
Примечание
Текущую версию
страницы можно
посмотреть по
адресу http://
implementing-
responsivedesign.
com/ex/ch3/
ch3.1.html.
Вы когда-нибудь делали сэндвич с арахисовым маслом? Без джема.
Только арахисовое масло между двумя кусками булки.
Это вполне съедобно. Это определенно лучше, чем просто два
куска булки. Но все-таки чего-то не хватает. Вы просто знаете,
что нужен еще один ингредиент, чтобы намного улучшить вкус.
Разумеется, вам нужен джем.
В адаптивном дизайне роль джема играют медиазапросы.
«Резиновые» макеты являются прекрасным стартом. Они устра-
няют ограничения, которые подстерегают вас при работе с маке-
тами фиксированной ширины, и обеспечивают приемлемый вид
сайта на как можно большем количестве экранов. Но на этом их
возможности иссякают.
Медиазапросы указывают, какие стили следует применять в опре-
деленных обстоятельствах, позволяя ориентироваться на такие
параметры, как разрешение, глубина цвета, высота и ширина.
Правильно применяя медиазапросы, мы сможем устранить все
шероховатости нашего макета.
К концу этой главы вы научитесь:
• использовать на своих сайтах метатег viewport;
• настраивать дизайн сайтов с помощью медиазапросов;
• создавать и применять медиазапросы;
• определять места для точек перехода;
• улучшать систему навигации на маленьких экранах.
Итак, мы создали страницу со статьей, воспользовавшись для
этого «резиновым» макетом и свойствами display:table. Бо-
ковая панель имеет фиксированную ширину, в то время как
размеры основного столбца и внешнего контейнера заданы
в процентах и подстраиваются под размер экрана.
В начале этой главы у сайта магическим образом появились за-
головок и нижний колонтитул, придавая ему дополнительную
форму и структуру. Текущий вид страницы показан на рис. 3.1.
В определенном диапазоне размеров экрана все выглядит за-
мечательно. Но при ближайшем рассмотрении обнаруживается
ряд проблем.

МЕДИАЗАПРОСЫ 71
Yet Ешж Шт Шштж i тШШв
That guy has the ball
By Ridty Boucher | January i, aoia
TWGir/Knocked Out the Other Guy
Your Favorite Sport* Tern Loat AfaJn.
fta Yankee. Buy the Entire Leap*
tbe Moment
New Record Set «Neither Тейп 8oore.
и>гетф«ш1<Ь1ог*а1>*,ю1ж*е№а£!>1^
Nam pun* neque, tfoddunt ut ahqoarn dapibut, dictum a maaaa-CurabituraagittiiiDietanteatiquet
rrbtiquevitaenecjuito QnUqueWteBiMMqt^npharetniboteUnecidenMi Praaaent far mantum dm id
i dictum at art amet noBa. 8ed aed lao at ante
^
УеЛ1Ышп rate 1решпрг)ти^&1^ЬшогаЬегшЛи11гкя«power»с
-Guy with bigot
q/towtntht ganml Or at
pc«oeren»fMet»i
oinW,tempuevelulrnce»vel,vulpuUlei:
VbaniH ladaia metua at qoam poanare oondimamim. V«atMtmaifeipaiimprin»innm1>wordhictiM
at utrrioe* posuere eobffia Свгав, Bham ipaom maurSs, bdftri. ut pbretr. ut, Udnia vit« veHt Peaertesque
habitant тогЫ triatiqua Moaetua at netui at maleraada I
„mper maaoa ЬЯШрМо dapibu. Tel auctor o<ho i
m in adtp>ae>n« tioadtmt, я»Ю pun» toNiptt bbero, dictum iacuUa an»
t«1or,»edrurnimalridolor»«1»ие.Йшп.огпиеШ>его PufMi
venenerU пес вше Nen pahnwr iacubs li«ui« а 1ш*ш. Рике vulpatateodioidparat<£d>iffl
NuUam oondlmentum, ит ас nuttii oongue, mi enim interdum rirot,id Aoncuivelitnequee
РеПеме-jue vettibnhm) rfaoaeoe «olltarodm. Cna eartpw^v^t. Donee eto^iamelit.ie
Р)иее a dolor a eUt tindduat dictum et son ore. Inteeer iliquam TddcnUelitatvehiaiU.
Ubero Maec«iaiinrttitDT,h>rtor<(etoon«uelobon», dolor li(uU сипи. miDt, east hictn
Мою I» Football
ta on record 13 field goals YourfamitetaaeloaaatothattaamBOOBB TbaSoaracrawaWin^arO
Рис. 3.1 .Теперь
на странице
сайта Yet Another
Sports Site поя-
вились заголо-
вок и нижний
колонтитул

72 ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.2. Умень-
шение ширины
окна браузера
приводит к иска-
жению макета
На слишком широком экране увеличивается длина строки. Чем
шире экран, тем больше длина строки начинает отличаться от
идеальной. Но в остальном ситуация не так уж плоха — макет
выглядит вполне приемлемо.
Но как только мы попытаемся сузить окно, наш замечательный
макет приобретет такой вид, как будто по нему несколько раз
ударили тяжелым предметом. Довольно быстро первый нави-
гационный элемент окажется под остальными ссылками, как
показано на рис. 3.2. Выглядит это не очень элегантно, хотя
и вполне допустимо. Но также сокращается длина строки в ос-
новном столбце. Как вы помните, в идеале она должна содержать
от 45 до 70 символов. Все прочие показатели негативно влияют
на читабельность.
щттттттштяяттщщтшт
тшшттттттавшшшшшт
ЖШШШШШжжШШЖЖШШЖ
%' fiy§t МШ
That guy has the
That Guy Knocked Out the Other Qay
Your Favorite Sports Team Lost Again.
In what Ьш^оЫ considered a development of the Z!_ _Z!Z:_.
utmost importance, that man over tbcrc now has the "И» Yankee* Bay the Entire League
Ш- Guy S*y» Something Stupid in the He*t of
By Ш&9 Boucher) Jamiaryi.aoia the Moment
New Record Set as Neither Team Score*
Why Haven't You Oicked One of Our
Headlines Yet?
Lorem ipeum dolor ait amet, conMctetar
eliL Nulla а<титпмп felis quk nibh pretium tempus.
Nullam qma rhonau пшава. Yvmmn laoreet
convallie зет ас dapibos. Donee varitts oongue sera
ac molestie. Nam purua neque, dnddunat ut aBquam
dapibmTdictmnaniagna.Curabitureagitti*miet
antealiquettrietiquevitaenecjaeto.Quisqueid
telhis et quam pharetra ladnianeelderoe. Praeaent
fermentum did id tellus aliqaam tinddant.
SmpendUae ец ante aed eat veetibulum dictum at ait
Чем уже становится окно, тем серьезней проблемы. При ширине
около 360 пикселов панель навигации приходит в полный бес-

МЕДИАЗАПРОСЫ 73
порядок. В основном столбце на одной строчке едва помещаются
три слова, и даже боковой панели перестает хватать места. С этим
определенно нужно что-то делать.
Вы можете решить, что узкое окно дает картинку, которую на-
блюдают посетители, пользующиеся мобильными устройствами,
но ошибаетесь. На большинстве смартфонов страница со статьей
сохраняет исходный макет (рис. 3.3). Соответственно, проблем,
сопровождающих уменьшение окна браузера, просто не воз-
никает. Зато текст и все прочие элементы становятся слишком
маленькими. Чтобы понять, почему так происходит, нужно
внимательней рассмотреть маленькие квадратики на экране —
пикселы.
Рис. 3.3. На смарт-
фонах масштаб
страницы просто
уменьшается
Области просмотра
Концепция области просмотра является очень простой, когда
дело касается браузеров для настольных компьютеров: это та об-
ласть, в которой появляется содержимое страниц. Она так проста,
что по большому счету никто о ней не думает. Но все изменилось
с появлением телефонов. Их экраны очень маленькие, но при

74 ГЛАВА 3. МЕДИАЗАПРОСЫ
этом пытаются отобразить весь сайт, чтобы позволить полно-
ценно им пользоваться. То есть внезапно ситуация осложнилась.
Пиксел это пиксел. Но не всегда
Когда дело доходит до браузеров, пикселы делятся на два вида:
пикселы устройств и CSS-пикселы. Первые ведут себя именно
так, как вы этого ожидаете от пикселов. При наличии экрана
шириной 1024 пиксела на нем могут уместиться два элемента
шириной 512 пикселов.
CSS-пикселы несколько менее стабильны. Они имеют отно-
шение не к экрану, а к видимой области внутри окна браузера.
Это означает, что CSS-пикселы могут не совпадать с пикселами
устройств. Например, на экранах с высоким разрешением, таких
как Retina смартфона iPhone, один CSS-пиксел равен двум пик-
селам устройства. Но это еще не самое забавное обстоятельство!
Каждый раз, когда пользователь меняет масштаб страницы,
CSS-пикселы меняются. Например, при увеличении до 300 %
пиксел растягивается в три раза по ширине и по высоте. Если
же установить масштаб, равный 50 % от исходного, ширина
и высота пиксела уменьшатся в два раза. При этом количество
пикселов устройства не меняется, ведь ширина экрана является
константой. А вот количество CSS-пикселов, видимых в окне
браузера, варьируется.
Именно в этот момент на сцене появляется область просмотра.
При этом нужно рассмотреть два варианта: визуальную область
просмотра и область просмотра макета. Последняя аналогична
пикселам устройства в том плане, что ее размеры остаются кон-
стантой вне зависимости от ориентации и коэффициента мас-
штабирования. Визуальная же область просмотра представляет
собой фрагмент страницы, наблюдаемый на экране в данный
момент (рис. 3.4).
На мобильных устройствах это порой все сильно осложняет.
Для обеспечения работы с полноформатными сайтами многие
мобильные устройства используют большую область просмотра
макета. Например, у iPhone ее ширина составляет 980 пикселов,
у Opera Mobile — 850 пикселов, а у Android WebKit — 800 пиксе-
лов. Соответственно, элемент размером 320 пикселов на смарт-
фоне iPhone займет примерно треть пространства экрана.

ВИЗУАЛЬНАЯ ОБЛАСТЬ ПРОСМОТРА
(ШИРИНА УСТРОЙСТВА)
ОБЛАСТИ ПРОСМОТРА 75
Рис. 3.4. Мобиль-
ные устройства
имеют две отли-
чающиеся друг
от друга области
просмотра
^ ОБЛАСТЬ ПРОСМОТРА
МАКЕТА
Тег Viewport и его свойства
К счастью, движок WebKit дал нам возможность выйти из этой
ситуации, и многие другие браузерные движки последовали его
примеру. Метатег viewport задает масштаб и правила поведе-
ния области просмотра для множества мобильных устройств.
Он имеет очень простой формат: достаточно определить его как
метатег viewport и добавить набор управляющих атрибутов:
<meta name="viewport" content="directive,directive" />
Метатеги помещаются в заголовок документа HTML:
<head>
<meta name="viewport" content="directive,directive" />
</head>
А теперь подробно рассмотрим атрибуты метатега viewport.
WIDTH
Атрибут width позволяет задать ширину области просмотра
или сделать ее равной ширине экрана устройства:
<meta name="viewport" content="width=device-width" />
Браузерным движ-
ком (rendering
engine) называется
программа, преоб-
разующая разметку
(HTML,XML
и др.) и сведения
о форматировании
(CSS,XSLTnnp.)
в интерактивное
отображение от-
форматированного
контента на экране.

76 ГЛАВА 3. МЕДИАЗАПРОСЫ
Примечание
Обязательно нужно
использовать
кавычки и вложен-
ный знак =. Нельзя
записать
<meta name=
"viewport"
width="device-
width"/>. Вторую
часть следует
включить в атрибут
content="".
Лучше всего присвоить этому атрибуту значение device-width.
В этом случае область просмотра макета совпадет по размеру
с экраном, если измерять их в пикселах устройства.
Если же вы предпочтете другое значение, например 240 пиксе-
лов, большинство устройств слишком сильно увеличат масштаб
изображения. Скажем, если экран вашего устройства имеет
ширину 320 пикселов, все элементы страницы будут увеличены
в 1,33 раза (320/240) в попытке корректно отобразить эту стра-
ницу на экране (рис. 3.5).
По этой причине атрибуту width практически никогда не при-
сваивается абсолютное значение. Вместо этого фигурирует
значение device-width.
Рис. 3.5. После
присвоения
атрибуту width
значения device-
width страница
задействует все
предлагаемые
экраном iPhone
320 пикселов
(слева). Результат
присвоения этому
атрибуту значе-
ния, не совпадаю-
щего с шириной
устройства, что
привело к увели-
чению масштаба
страницы {справа)
HEIGHT
Эквивалентный атрибуту width атрибут height задает высоту
области просмотра:
<meta name="viewport" content="height=468px" />
Эта запись задает высоту области просмотра 468 пикселов. Но,
как и в описании атрибута width, надежней пользоваться зна-
чением device-height:
<meta name="viewport" content="height=device-height" />

ОБЛАСТИ ПРОСМОТРА 77
В результате высота области просмотра совпадает с высотой
экрана. Но на практике этот атрибут используется нечасто. Он
применяется, например, чтобы запретить вертикальную про-
крутку, но это довольно редкий случай.
USER-SCALABLE
Атрибут user-scalable отвечает за возможность пользователя
менять масштаб изображения на странице:
<meta name="viewport" content="user-scalable=no" />
Страницы, у которых атрибуту user-scalable присвоено зна-
чение по, встречаются довольно часто. Как правило, это дела-
ется для обеспечения идеального отображения дизайна. Но это
противоречит природе Сети и вредит пользователям с ограничен-
ными возможностями. Если не задать значение атрибута user-
scalable в явном виде, он по умолчанию получит значение yes.
Поэтому лучше просто не обращать на него внимания.
Проблема с ориентацией страницы в iOS
Разработчики пользуются атрибутами user-scalable или maximum-scale, в частности,
из-за наличия одной устойчивой проблемы с операционной системой iOS.
Если разрешить пользователям масштабировать страницу, изменение ориентации
экрана устройства приведет к тому, что часть контента выйдет за границы ото-
бражения. В результате, чтобы увидеть страницу целиком, придется прибегнуть
к дополнительному масштабированию.
Отключение масштабирования с помощью атрибутов user-scalable или maximum-scale
устраняет данную проблему. Но, к сожалению, при этом уменьшается доступность
страницы для лиц с ограниченными возможностями.
К счастью, проблема была окончательно решена в операционной системе iOS6. Для
пользователей более старых версий Скоттом Джелом (Scott Jehl) из компании Filament
Group было разработано исправление. При помощи датчика поворота устройства
масштабирование отключается в момент начала поворота и включается только после
завершения изменения ориентации. Исправление доступно на странице https://
github.com/scottjehl/iOS-Orientationchange-Fix сайта GitHub.

78
ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.6. Устрой-
ство с шириной
экрана 320 пик-
селов отобразит
страницу нор-
мально, если при-
своить атрибуту
initial-scale значе-
ние 1 (слева). При
значении этого
атрибута 0,5 мас-
штаб страницы
уменьшится в два
раза (справа)
INITIAL-SCALE
Принимающий значения от 0,1 (10 %) до 10,0 (1000 %) атрибут
initial-scale задает начальный масштаб страницы. Вот как
он объявляется:
<meta name="viewport" content="initial-scale=lj width=device-width" />
В результате, если ширина устройства составляет 320 пикселов,
ширина страницы также составит 320 пикселов.
А теперь рассмотрим другой пример:
<meta name="viewport" content="initial-scale=.5, width=device-width" />
При таких параметрах браузер будет отображать все в умень-
шенном масштабе. На устройстве шириной 320 пикселов ширина
страницы составит 640 пикселов (рис. 3.6).
MAXIMUM-SCALE
Атрибут maximum-scale задает максимально возможный масштаб
страницы. В мобильном браузере Safari он по умолчанию имеет
значение 1,6 (160 %), но ему можно присвоить любое число от
0,1 (10%) до 10,0 (1000%).
Он может функционировать аналогично атрибуту user-scalable.
Ведь присвоение ему значения 1,0 равносильно запрещению
масштабирования, что уменьшает доступность сайта.

ОБЛАСТИ ПРОСМОТРА 79
MINIMUM-SCALE
Атрибут minimum-scale задает минимально возможный масштаб
страницы. В мобильном браузере Safari он по умолчанию имеет
значение 0,25 (25 %). Но, как и в предыдущем случае с атрибутом
maximum-scale, вы можете присвоить любое число от 0,1 (10 %)
до 10,0 (1000%).
Присвоение атрибуту minimum-scale значения 1,0 (100 %) отклю-
чает возможность масштабирования. Я думаю, вы уже поняли,
почему этого желательно избегать.
РЕШЕНИЕ ПРОБЛЕМЫ С ОБЛАСТЬЮ ПРОСМОТРА
Теперь, вооружившись сведениями о метатеге viewport и его
атрибутах, вы можете легко избавиться от уменьшенного вида
страниц, заставив мобильные устройства использовать в ка-
честве ограничителя ширину собственных экранов. Для этого
достаточно присвоить атрибуту width значение device-width:
<meta name="viewport" content="width=device-width11 />
Адаптация CSS к устройствам
На самом деле метатег viewport является ненормативным. То есть пока он не является
стандартом. Изучение документации W3C показывает, что своим наличием в специфика-
ции он обязан исключительно необходимости предоставить браузерам доступ к новому
синтаксису (©viewport
Правило ©viewport позволяет задать любые атрибуты тега viewport (ширину, масштаб,
ориентацию, разрешение и т. п.) непосредственно в CSS. Например, чтобы сделать
размер видимой области равным ширине устройства, достаточно вставить в код CSS
следующий фрагмент:
^viewport {
width: device-width;
}
Поддержка этой возможности в настоящее время ограничена реализацией, включающей
вендорные префиксы в браузерах Opera и Internet Explorer 10. Но учитывая отношение
к метатегу viewport, можно ожидать, что после появления полноценной поддержки
правила @viewport поддержка самого метатега прекратится.

80
ГЛАВА 3. МЕДИАЗАПРОСЫ
Теперь загруженная на мобильное устройство страница будет
вести себя точно так же, как в случае, когда мы уменьшали размер
окна браузера на обычном компьютере. Это связано с тем, что
теперь мобильный телефон использует в качестве визуальной об-
ласти просмотра весь экран. Остальные атрибуты мы трогать не
будем, так как на данном этапе это не нужно. Кроме того, данные
попытки управления средой могут уменьшить доступность сайта.
Но если посмотреть на рис. 3.7, сразу бросается в глаза, что по-
сле введения тега viewport ситуация стала только хуже! Теперь
сайт деформирован не только на обычных компьютерах, но и на
мобильных устройствах. Пришло время позвать на помощь на-
ших друзей — медиазапросы.
Рис. 3.7. После
задания тега
viewport сайт
стал отобра-
жаться так же,
как на обычном
компьютере при
уменьшении окна
браузера
Структура медиазапроса
Медиазапрос позволяет спросить у браузера, верно ли опреде-
ленное выражение. При получении положительного ответа он
загружает блок стилей, в данной ситуации предназначенных для
корректировки отображения.

СТРУКТУРА МЕДИАЗАПРОСА 81
В общей форме медиазапрос выглядит так:
@media [not|only] type [and] (expr) {
rules
}
Его составляют четыре компонента:
• type — тип целевого устройства;
• ехрг — проверка на наличие определенной функции;
• логические операторы — ключевые слова (например, and,
or, not или only), позволяющие формировать более слож-
ные выражения;
• rules — базовые стили, корректирующие отображение.
Рассмотрим их более подробно.
Типы носителей
Сеть обладает удивительной способностью предоставлять
данные самым разным устройствам. Интернет простирается
далеко за границы экранов. Можно распечатать информацию
или получить к ней доступ через устройства с тактильной
обратной связью, синтезаторы речи, проекторы, телевизоры
и другие платформы.
Носители различных типов появились, чтобы превратить по-
рядок в хаос. Чаще всего их используют отдельно, без написания
полного медиазапроса. Если вы когда-нибудь создавали печат-
ный стиль (print stylesheet), значит уже сталкивались с этим
явлением.
Тип носителя указывает агенту пользователя (например, брау-
зеру), когда нужно загружать определенный стиль. Например,
для типа носителя screen агент пользователя загрузит указан-
ные вами стили, когда обнаружит экран компьютера или дру-
гого устройства. А если в качестве типа носителя фигурирует
print, эти стили загрузятся только при попытке распечатать
страницу или произвести ее предварительный просмотр перед
печатью.
В CSS определены десять типов носителей (табл. 3.1).

82 ГЛАВА 3. МЕДИАЗАПРОСЫ
Таблица 3.1 Типы носителей
ТИП
all
braille
embossed
handheld
print
projection
screen
speech
tty
tv
ЦЕЛЕВОЕ УСТРОЙСТВО
Все устройства (по умолчанию)
Устройства, основанные на системе Брайля, предназначенные для слепых
Устройства печати символов Брайля
Наладонные компьютеры (обычно они имеют маленький и, возможно,
монохромный экран)
Вывод на печать и предварительный просмотр печати
Демонстрация с помощью проекторов
Мониторы компьютеров
Синтезаторы речи
Носители с фиксированным расстоянием между символами (терминалы
и телетайпы)
Телевизоры
В таблице стилей запрос будет выглядеть так:
gmedia print {
}
или в полной форме, с применением атрибута media для эле-
мента link:
<link rel="stylesheet" href="print.ess" media^'print" />
В любом из этих случаев указанный стиль CSS будет применен
только при выводе страницы на печать или предпечатном про-
смотре.
Тип носителя должен быть указан в каждом медиазапросе. Если
он не указан в явном виде, по умолчанию этот параметр должен
принять значение all, но ситуация варьируется в зависимости
от браузера.
На практике вы, скорее всего, будете пользоваться в основном
вариантами all, screen и print. К сожалению, разработчики
долго использовали screen вместо, скажем, handheld или tv,
и в результате многие устройства поддерживают вместо соб-

СТРУКТУРА МЕДИАЗАПРОСА 83
ственного типа носителя вариант screen. Это не их вина — не
прими они этого решения, многие сайты на их устройствах даже
не отображались бы.
Сами по себе типы носителей всего лишь позволяют выбрать
устройство из широкого диапазона. Для улучшения вида стра-
ницы нужно указать, что с ней требуется сделать. И здесь на
сцену выходят медиафункции.
Медиафункции
Сила медиазапросов состоит в способности при помощи вы-
ражений проверять наличие у устройства различных функций.
В качестве простого примера попробуем определить, превосходит
ли ширина видимой области устройства размер 320 пикселов:
@media screen and (min-width: 320px) {
}
Здесь проверяются две вещи. Во-первых, есть ли у носителя
экран. Во-вторых, какова ширина видимой области. Именно из
этих условий составлено выражение. В частности, приставка
min- гарантирует, что ширина составит минимум 320 пикселов.
В табл. 3.2 перечислены функции, наличие которых вы можете
проверить. Там же указано, допустимо ли использовать в вы-
ражении приставки min- и max-.
В основном вам предстоит пользоваться функциями width,
height, orientation, resolution и, возможно, aspect-ratio.
В браузерах такие функции, как color, color-index и device-
aspect-ratio, пока не поддерживаются должным образом.
А функции monochrome, scan и grid уже не имеют отношения
к большинству современных устройств.
Логические операторы
Наряду с типами носителей и медиафункциями в медиазапрос
можно вставлять логические операторы.
AND
Позволяет проверить одновременно несколько условий:
gmedia screen and (color)
В этом примере проверяется наличие у устройства цветного
экрана.

84 ГЛАВА 3. МЕДИАЗАПРОСЫ
Таблица 3.2 Медиафункции
ФУНКЦИЯ
width
height
device-width
device-height
orientation
aspect-ratio
device-aspect-
ratio
color
color-index
monochrome
resolution
scan
grid
ОПРЕДЕЛЕНИЕ
Ширина отображаемой области
Высота отображаемой области
Доступная ширина экрана
устройства
Доступная высота экрана
устройства
Определяет, портретный или
альбомный режим задан на
устройстве
Отношение значения функции
width к значению функции height
Отношение значения функции
device-width к значению
функции device-height
Количество бит на канал цвета
(если устройство не цветное,
возвращает ноль)
Количество цветов,
поддерживаемое устройством
Количество бит на пиксел
на монохромных устройствах
(возвращает ноль, если
устройство не монохромное)
Разрешение устройства. Может
измеряться в точках на дюйм [dpi]
или в точках на сантиметр [dpcm]
Определяет тип развертки
телевизоров
Определяет устройства
с фиксированным размером
символов. Если устройство
таковым не является,
возвращается ноль
ЗНАЧЕНИЕ
<размер> (например, 320)
<размер> (например, 600)
<размер> (например, 320)
<размер> (например, 600)
портретная|альбомная
<дробь>
(например, 16/9)
<дробь>
(например, 16/9)
< целое число>
(например, 1)
<целое число>
(например, 256)
<целое число
(например, 8)
<разрешение>
(например, 118 dpcm)
прогрессивная|чересстрочная
<целое число>
(например, 1)
MIN/MAX
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Да
Нет
Нет

СТРУКТУРА МЕДИАЗАПРОСА 85
Медиазапросы нового поколения
Проводится работа по стандартизации дополнительных функций для медиазапросов.
На момент написаний данной книги были добавлены три функции: script pointer и hover.
Медиафункция script проверяет, поддерживается ли язык ECMAscrlpt и активна ли
его поддержка на данный момент (не была ли она отключена). Она принимает два
значения: 1, если язык поддерживается, и 0 — в противном случае.
Медиафункция pointer проверяет точность указательного устройства (например,
мыши или пальца). При натлчт нескольких методов ввода возвращается результат
для основного метода. Возвращаемые значения: попе (указательное устройство
не обнаружено), coarse (ограниченная точность — например, палец на сенсорных
экранах) и fine (в случае использования мыши или пера).
Ну и, наконец, медиафункция hover проверяет наличие указателя, который можно
навести на элемент без нажатия. При наличии нескольких методов наведения
результат возвращается для основного метода. Устройства с сенсорным экраном
возвращают для этой функции значение 0, сигнализируя о том, что наведение ука-
зателя на элемент невозможно. Причем это происходит даже после подсоединения
внешнего устройства (например, мыши), поддерживающего данную возможность.
Впрочем, ни одна из перечисленных функций еще не зафиксирована окончательно,
так что спецификация, возможно, со временем изменится. Тем не менее имеет смысл
обратить на них внимание.
NOT
Этот оператор отрицает результат всего выражения, а не только
его части. Рассмотрим следующий пример:
@media not screen and (color) {...} //отрицает условия (screen and
(color))
Этот запрос возвращает значение false для любого устройства
с цветным экраном. Следует также заметить, что оператор not
имеет низкий приоритет и оценивается в запросе последним.
Именно поэтому он должен предшествовать остальной части
запроса.
OR
Для медиазапросов данного оператора на самом деле не суще-
ствует, но с его ролью вполне справляется обычная запятая. Это

86 ГЛАВА 3. МЕДИАЗАПРОСЫ
позволяет загрузить таблицу стилей при соблюдении хотя бы
одного из перечисленных условий:
gmedia screen and (color), projection and (color)
Данное выражение возвращает значение true при обнаружении
устройства с цветным монитором или цветного проектора.
ONLY
Многие старые браузеры не поддерживают медиазапросы, но
умеют работать с различными типами носителей. Иногда это
приводит к попыткам скачать стили, которые вы не хотите по-
казывать пользователям. Данный оператор позволяет скрыть
медиазапросы от старых браузеров. В остальных случаях запрос
обрабатывается обычным образом. Например, запись
@media only screen and (color)
будет просто проигнорирована браузером, не поддерживающим
медиазапросы, в то время как остальные браузеры воспримут
ее как запись
gmedia screen and (color)
Стили
Последним кусочком в мозаике медиазапроса являются стили,
которые вы хотите применить. Они ничем не отличаются от
обычных стилей CSS, просто включены в медиазапрос:
@media only screen and (min-width: 320px) {
a{
color: blue;
Встроенные и внешние
медиазапросы
Медиазапрос можно встроить в основную таблицу стилей или
воспользоваться атрибутом media элемента link для ссылки на
внешнюю таблицу стилей.

ВСТРОЕННЫЕ И ВНЕШНИЕ МЕДИАЗАПРОСЫ 87
Вот пример встроенного запроса:
а{
text-decoration:none;
@media screen and (min-width: 1300px) {
a{
text-decoration: underline;
В этом случае ссылки будут подчеркиваться только на экранах
шириной более 1300 пикселов.
Внешние медиазапросы располагаются непосредственно вну-
три элемента link, загружающего пользовательскую таблицу
стилей. Соответственно, к элементу head вашего HTML-кода
нужно будет добавить строку
<link href="style.ess" media="only screen and (min-width: 1300px)"
Более предпочтительный способ выбирается в зависимости от
проекта; оба варианта имеют свои достоинства и недостатки.
В случае медиазапроса, встроенного в одну таблицу стилей,
скачиваться будут все стили вне зависимости от необходимости
в них. Но при этом вам достаточно сделать всего один HTTP-
запрос. С точки зрения производительности это немаловажно,
особенно при работе в мобильной сети. Мобильные сети имеют
длительное время задержки, то есть время, за которое сервер
получает и обрабатывает запрос от браузера. Каждый HTTP-
запрос в мобильной сети обрабатывается в четыре-пять раз
дольше, чем при обычном интернет-соединении. Но ситуация
имеет и свои минусы. В частности, этот единственный файл CSS
может стать слишком большим. Фактически, вы, экономя на
числе запросов, создаете чересчур тяжелый файл, поддержка
которого может оказаться непростым делом.
Вы можете удивиться, узнав, что внешние медиазапросы тоже
не избавляют вас от необходимости скачивать все стили вне
зависимости от того, нужны они или нет. Рациональное зерно
в этом есть. Если размер окна браузера или его ориентация из-
менятся, стили уже будут под рукой. К сожалению, при этом
Совет
Обойти пробле-
му с загрузкой
ненужных стилей
можно с помощью
служебной про-
граммы eCSSential,
созданной Скот-
том Джелом. Для
ее скачивания зай-
дите на страницу
https://github.
com/scottjehl/
eCSSential.

88 ГЛАВА 3. МЕДИАЗАПРОСЫ
приходится делать несколько HTTP-запросов вместо одного.
Исключением из этого правила являются устройства, которые
вообще не поддерживают медиазапросы. Если перед медиаза-
просами поместить оператор only, то эти устройства просто
проигнорируют дополнительные стили.
Преимущество внешних медиазапросов состоит в меньшем объ-
еме файлов, что упрощает их поддержку. Можно также обеспе-
чить набор упрощенных таблиц стилей для устройств, которые
не поддерживают медиазапросы, и благодаря оператору only вам
уже не нужно будет беспокоиться о скачивании ненужных стилей.
Разумеется, в конечном счете все определяется самим проектом,
но в общем случае я рекомендую использовать единую таблицу
стилей с встроенными медиазапросами. Дополнительные HTTP-
запросы могут значительно замедлить работу сайта, а произво-
дительность является слишком важной характеристикой, чтобы
рисковать ею понапрасну.
Порядок медиазапросов
Следующее, что нужно рассмотреть в процессе структуриро-
вания CSS-кода, — это способ построения адаптивного сайта.
Можно спускаться от версии для настольных компьютеров вниз
или подниматься от версии для мобильных устройств вверх.
От версии для настольных компьютеров
Изначально отправной точкой для адаптивного дизайна были
сайты для обычных компьютеров. Подобным образом он зача-
стую реализуется и сейчас. Берется исходный макет, то есть то,
что вы обычно видите в окне браузера на ноутбуке или настоль-
ном компьютере, и при помощи набора медиазапросов (обычно
это запросы max-width) упрощается и подгоняется для экранов
меньшего размера. Структурированные таким способом таблицы
стилей могут выглядеть следующим образом:
/* основные стили */
@media all and (max-width: 768px) {

ПОРЯДОК МЕДИАЗАПРОСОВ 89
@media all and (max-width: 320px) {
К сожалению, такой подход приводит к ряду серьезных проблем.
Поддержка медиазапросов мобильными устройствами несмо-
тря на ряд улучшений все еще остается весьма фрагментарной.
В операционных системах BlackBerry (предыдущая версия 6.0),
Windows Phone 7 и в браузере NetFront (работавшем на преды-
дущем, третьем поколении устройств Kindle) они вообще не
поддерживаются.
Можно представить себе идеальный мир, в котором все поль-
зуются самыми новыми технологиями на самых современных
устройствах, но в реальности дела обстоят далеко не так ра-
дужно. На момент написания данной книги Android 4 являлась
последней версией данной операционной системы, но до 92 %
устройств Android использовали операционную систему версии
2.3.x и младше1. Широко распространены и старые устройства
BlackBerry. В настоящее время 66 % их пользователей работают
под операционными системами, в которых отсутствует под-
держка медиазапросов2.
Реальность такова, что далеко не все имеют желание идти в ногу
с быстро развивающимися технологиями, а кто-то банально не
может себе этого позволить.
От версии для мобильных устройств
Если же перевернуть все с ног на голову и использовать в качестве
основы сайт для мобильных устройств, регулируя его макет по
мере расширения экрана при помощи медиазапросов, проблему
с поддержкой в основном удается обойти. Ведь при таком подходе
вы обеспечиваете корректным макетом сайта не поддерживаю-
щие медиазапросы мобильные устройства. Единственным брау-
зером, с которым придется повозиться, является Internet Explorer.
До версии 9 он не умел работать с медиазапросами, но, как вы
увидите чуть позже, это ограничение довольно легко обойти.
Информация о версиях платформ взята со страницы http://developer.android.com/resources/
dashboard/platform-versions.html
По информации по страницы http://us.blackberry.com/developers/choosingtargetos.jsp

90
ГЛАВА 3. МЕДИАЗАПРОСЫ
Эд Мерритт
МЕДИАЗАПРОС ВЕРТИКАЛЬНЫХ РАЗМЕРОВ
Эд Мерритт (Ed Merritt) — дизайнер, разработчик интерфейсов,
пекарь-любитель и большой поклонник эля, с 2001 года исполь-
зующий пикселы, шрифты, а порой и контейнеры для создания
веб-интерфейсов. Эд работает с замечательными талантли-
выми людьми в компании Headscapexo.uk и является основате-
лем TenByTwentyxom— небольшой студии, создающей шрифты,
графические символы и темы для Wordpress. Эд проживает в Борнмуте на южном побережье
Великобритании.
ПРОЕКТ
В середине 2010-х в процессе разработки
нового сайта для фонда защиты окружа-
ющей среды я прочел статью Итана Map-
котта (Ethan Marcotte) Responsive Web Design»
Идея адаптации макета к видимой среде
мне понравилась — она была очень све-
жей. Однако работа над дизайном уже шла
полным ходом, поэтому реализовать адап-
тивный подход целиком было невозможно.
Но я горел желанием применить хотя бы
некоторые элементы этого подхода.
ПРОБЛЕМА
На главной странице спереди и в цен-
тре использовался карусельный дизайн,
а остальная часть страницы располагалась
ниже. Это был очень эффективный вариант,
но внезапно оказалось, что при разрешении
1024x768 (согласно нашей статистике, это
второе по частоте использования разре-
шение экранов посетителей) и самых рас-
пространенных настройках (окно браузера
полностью открыто, дополнительные панели
инструментов отсутствуют) в видимой обла-
сти находится только карусель. Тестирова-
ние показало, что пользователи практически
не используют вертикальную прокрутку, так
как при подобном расположении элементов
страницы у них создается впечатление, что
ниже уже ничего нет.
В наши дни проблемы с разрывами стра-
ницы в основном остались позади, так как
пользователи без проблем задействуют про-
крутку. Но наш опыт показал, что в некото-
рых случаях компоновка элементов может
ввести в заблуждение, вызвав у человека
ощущение, что он уже достиг конца стра-
ницы. В окне его браузера присутствует
линия, ограничивающая видимую область,
и кажется, что дальше уже ничего нет, так
зачем пользоваться прокруткой? Впрочем,
вопрос был в том, как показать посетителю,
что ниже есть и другие материалы.
РЕШЕНИЕ
Мной уже были созданы два макета фик-
сированной ширины: полноразмерный
(для области видимости от 1024 пикселов)
и узкий (для ширины от 800 до 1024 пик-
селов). Такое решение ни в коей мере не
являлось адаптивным, но это был первый
шаг проекта в направлении применения
медиазапросов.

ПОРЯДОК МЕДИАЗАПРОСОВ 91
Медиазапрос к вертикальным размерам позволил расположить на более коротком экране большее
количество контента и дать понять, что внизу есть дополнительные материалы
Я понял, что медиазапрос к вертикальным
размерам позволит мне внести изменения
в макет для устройств, вертикальное раз-
решение которых составляет менее 768 пик-
селов. В узкой версии ширина страницы уже
уменьшена до трех четвертей от исходной,
пропорционально уменьшилась и высота
карусели. Мне оставалось только создать
такую версию для более коротких экранов,
как показано на рисунке.
Очевидно, что в окнах с короткой, но широ-
кой областью просмотра имелось горизон-
тальное пространство, которое мы соби-
рались удалить. К счастью, под каруселью
страница разделилась на основной столбец,
занимающий три четверти ширины экрана,
и правый столбец, на долю которого оста-
лась последняя четверть. Уменьшив ширину
карусели до трех четвертей ширины экрана,
мы сформировали сбоку пространство, кото-
рое и заполнил этот столбец.
КОНЕЧНЫЙ РЕЗУЛЬТАТ
Такой подход понравился клиенту и дал
пользователям понять, что на странице
есть дополнительные материалы. Также он
позволил более эффективно использовать
доступное пространство, что было приятным
бонусом. (Впрочем, мне никогда не нрави-
лась карусель, заполняющая всю видимую
область.) И все это было обеспечено добав-
лением медиазапроса к коротким, но широ-
ким областям просмотра.
Принцип решения данной проблемы можно
применять где угодно. Во время работы
над всеми следующими проектами я обяза-
тельно задавал себе вопросы: существуют
ли обстоятельства (они могут касаться как
высоты, так и ширины), при которых область
просмотра негативно влияет на представле-
ние контента, и как я могу с ними бороться?

92 ГЛАВА 3. МЕДИАЗАПРОСЫ
Таблица стилей, создаваемая на основе версии для мобильных
устройств, может выглядеть, например, так:
/* здесь идут базовые стили для маленьких экранов */
gmedia all and (min-width: 320px) {
}
gmedia all and (min-width: 768px) {
Поддержка является не единственным преимуществом данного
метода. Начало работы с версией для мобильного сайта позволяет
заодно уменьшить сложность кода CSS. Рассмотрим боковую па-
нель страницы нашего сайта Yet Another Sports Site. На большом
экране для нее заданы свойство display: table-cell и фиксиро-
ванная ширина 300 пикселов. На маленьком экране ее, вероятно,
имеет смысл отобразить линейно, расположив под статьей. При
построении страницы на основе версии для обычных компью-
теров стили могут выглядеть, например, вот так:
aside{
display:table-cell;
width: 300px;
}
gmedia all and (max-width: 320px) {
aside{
display:block;
width: 100%;
Если же за основу берется версия для мобильных устройств, код
будет выглядеть уже так:
gmedia all and (min-width: 320px) {
aside{
display:table-cell;
width: 300px;
Применение в начале более простого макета позволяет вос-
пользоваться параметрами браузера по умолчанию как основой,
на которой будет построено все остальное. В результате можно
обойтись более простым и чистым CSS-кодом.

ОСНОВНОЙ ИНТЕРФЕЙС
93
Основной интерфейс
В идеале каждый проект нужно начинать с основного интер-
фейса, простого, оптимизированного и работающего на как
можно большем количестве устройств. Широта охвата является
одной из сильных сторон Интернета, старайтесь увеличивать
ее по мере возможности.
Помня об этом, мы начнем создание основного интерфейса
с простого, состоящего из одного столбца, макета. Весь связан-
ный с макетом код CSS нужно поместить вниз таблицы стилей
и на время превратить его в комментарии.
После того как из таблицы стилей будут выбраны все от-
носящиеся к макету плавающие элементы или все свойства
display: table, набор комментариев в нижней части кода CSS
будет выглядеть следующим образом:
1. /*
2. .main {
3. display: table-cell;
4. padding-right: 2.5316456%;
5- }
6. aside {
7. display: table-cell;
8. width: 300px;
9. }
10. .slats li {
п. float: left;
12. margin-right: 2.5316456%;
13. width: 31.6455696%;
14. }
is. .slats li:last-child {
16. margin-right: 0;
17. }
18. nav[role="navigation"] li {
19. float: left;
29. }
21. nav[role="navigation"] a {
22. float: left;
23. }
24. footer[role="contentinfoH] .top {
25. float: right;
26. }
37. */
Примечание
Это не совсем
макет, но мы
удалим из него
строку, которая
задает ширину
баннеракак100%
от ширины экрана.
Иногда менять
размер рекламного
блока запрещает
сам рекламодатель.
Более подробно
мы поговорим об
этом в главе 4.
Вид страницы после этой операции показан на рис. 3.8.

94 ГЛАВА 3. МЕДИАЗАПРОСЫ
Сложных вещей тут нет, что прекрасно подходит для наших целей.
Ведь основа должна быть доступной для широкого диапазона
устройств. Хотя не мешало бы разграничить элементы навигации,
например как показано на рис. 3.9:
nav[role="navigation"] li {
padding: .625em 2em .625em 0;
border-top: lpx solid #333;
}
После создания такого нестандартного макета и внесения в него
небольших изменений наш основной интерфейс готов к работе.
Можно добавлять к нему медиазапросы, совершенствующие
макет по мере увеличения размеров экрана.
YJtat guy lias the bai
Рис. 3.8. После превращения стилей в ком-
ментарии макет страницы стал простым,
состоящим из одного столбца
Рис. 3.9. Навигационные элементы стали
более различимы после добавления к ним
свойства border со значением 1 пиксел

ТОЧКИ ПЕРЕХОДА 95
Точки перехода
Традиционно для определения точек перехода берутся стан-
дартные варианты ширины: 320 пикселов (в эту часть спектра
попадают iPhone и ряд других мобильных устройств), 768 пик-
селов (iPad) и 1024 пиксела. Но с этим подходом связана одна
проблема.
Ориентируясь только на разрешения распространенных
устройств, вы получите макеты для определенных значений
параметра width, проигнорировав промежуточные варианты.
А ведь, например, при повороте смартфона iPhone меняется
ориентация экрана и его ширина становится равна 480 пиксе-
лам. Кроме того, такой подход не очень хорош с точки зрения
перспективы. Популярное сегодня могут забыть уже завтра.
А значит, при появлении нового популярного устройства вам
придется добавлять еще одну точку перехода, просто чтобы
остаться на плаву. Это проигрышная стратегия.
Контент как точка отсчета
Пусть контент подскажет вам, где именно требуются точки
перехода и сколько их должно быть. Начните менять размер
окна браузера, и вы увидите, где именно нужно улучшить макет.
Такой подход способствует освобождению макета от при-
вязки к определенному разрешению. Расположение данных
на странице само должно подсказать, где именно требуется
отредактировать макет. И это будет мудрое и ориентированное
на будущее решение.
Для определения точек перехода следует уменьшить ширину
окна браузера примерно до 300 пикселов (конечно, если это
возможно), а затем начать понемногу ее увеличивать, пока не
выяснится, что в макет пора вносить исправления.
В нашем случае при ширине примерно 600 пикселов изображе-
ния в разделе More in Football начинают выглядеть некрасиво.
Вероятно, имеет смысл воспользоваться медиазапросом для
смещения их в сторону, в положение, в котором они распола-
гались в главе 2 (рис. 3.10).
Примечание
Если вы выпол-
няете все упраж-
нения по ходу
повествования,
то в настоящий
момент вы должны
работать с файлом,
расположенным на
странице http://
implementing-
responsivedesign.
com/ex/ch3/
ch3.1.html.

96 ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.10. При
ширине экрана
около 600 пиксе-
лов изображения
начинают зани-
мать слишком
много места
(слева), поэтому
имеет смысл
добавить точку
перехода
и исправить
дизайн (справа)
ШШШКШШ
Примечание
Инструмент
mediaQuery
bookmarklet;
который мож-
но скачать со
страницы http://
seesparkbox.
com/foundry/
media_query_
bookmarklet,
позволяет опре-
делить ширину
браузера и актив-
ные в этот момент
медиазапросы.
2.
3,
4.
5.
6.
7.
8.
9.
10.
gmedia all and (min-width: 600px) {
.slats li {
float: left;
margin-right: 2.5316456%; /* 24px / 948px */
width: 31.6455696%; /* 300 / 948 */
.slats li:last-child {
margin-right: 0;
При ширине окна примерно 860 пикселов содержимое бокового
столбца станет слишком растянутым. Но такой ширины пока
недостаточно для смещения этого столбца вправо, поэтому мы
сделаем отдельные элементы плавающими, расположив их в один
или два ряда (рис. 3.11):
1. @media all and (min-width: 860px) {
2. aside{
3. display: block;
4. margin-bottom: lem;
5. padding: 0 1%;
6. width: auto;
7. }
8. aside section{
9. float: left;

ТОЧКИ ПЕРЕХОДА 97
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
16.
margin-right: 2%;
width: 48%;
.article-tags{
clear: both;
.ad{
text-align: center;
padding-top: 2.5em;
В этой точке навигационные элементы уже можно снова сделать
плавающими (рис. 3.12), Нужные стили находятся в превра-
щенном в комментарии фрагменте CSS-кода, поэтому просто
скопируем их оттуда и вставим в медиазапрос. Попутно удалим
элемент border из нашей системы навигации:
1. gmedia all and (min-width: 860px) {
2.
3. nav[role="navigation"] li {
4. float: left;
s. border-top: 0;
6. }
7. nav[role="navigation"] a {
8. float: left;
9. }
10. footer[role="contentinfo"] .top {
11. float: right;
12. }
13. }
RalMad ШтлёШштв
elated Не*<Ша»««
юЬ
L
Рис. 3.11. Новая точка перехода позволяет
выровнять разделы бокового столбца друг
относительно друга, обеспечивая более
согласованный вид макета

98 ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.12. Теперь
места снова
достаточно для
плавающей нави-
гации и смещения
остального кон-
тента вверх
Наконец, при ширине примерно 940 пикселов появляется место
для возвращения боковой панели вправо. Ее разделы в этом
случае нужно превратить из плавающих в элементы с фиксиро-
ванной шириной:
1. gmedia all and (min-width: 940px) {
2. .main {
3. display: table-cell;
4. padding-right: 2.5316456%; /* 24px / 948px */
5. }
6. aside {
7. display: table-cell;
8. width: 300px;
9. }
10. aside img {
n. max-width: 100%;
12. }
13. aside section {
14. float: none;
15. width: 100%;
16. }
17. }
Макет, который мы имеем при ширине более 940 пикселов,
почти аналогичен макету, созданному к концу главы 2 (рис. 3.13).

ТОЧКИ ПЕРЕХОДА 99
Рис. 3.13. После
определения
новой точки
перехода при
ширине экрана
как минимум
940 пикселов мы
получили макет,
практически
аналогичный
исходному
Усовершенствование для больших экранов
Продолжив увеличивать размер окна браузера, мы быстро об-
наружим, что строки становятся слишком длинными и неудоб-
ными для чтения. Многие сайты на данном этапе пользуются
атрибутом max-width, чтобы ограничить максимальный размер
окна браузера, или увеличивают размер шрифта.
Но вместо задания предельной ширины окна мы воспользуемся
существующим в CSS3 макетом, состоящим из нескольких столб-
цов. Пример страницы, которая получается на основе такого
макета, показан на рис. 3.14. Макет хорошо поддерживается:
с ним работают Opera, Firefox и WebKit. А для браузеров Firefox,
Internet Explorer 10 и WebKit просто нужно указать правильные
префиксы. Поскольку эта замечательная функция не является
обязательной, для вышеупомянутых браузеров можно выполнить
прогрессивное улучшение:
1. gmedia all and (min-width: 1300px) {
2. .main section {
3. -moz-column-count: 2; /* Firefox */
4. -webkit-column-count: 2; /* Safari, Chrome */
5. column-count: 2;
6. -
moz-column-gap: 1.5em; /* Firefox */
продолжение

100 ГЛАВА 3. МЕДИ АЗАПРОСЫ
7. -
8,
9,
19.
11.
12. }
13. }
webkit-column-gap: 1.5em; /* Safari, Chrome */
column-gap: 1.5em;
-moz-column-rule: lpx dotted #ccc; /* Firefox */
-webkit-column-rule: lpx dotted #ccc; /* Safari, Chrome */
column-rule: lpx dotted #ccc;
^■}i^'^B4a^£&%^kt?M?^i^M^-
шшшшшшшшшшшш
Рис. 3.14. Ha
широких экранах
для сохранения
читабельности
строк статья раз-
бивается на два
столбца
Строчки 3-5 указывают браузеру, какое количество столбцов
требуется для отображения статьи. В строчках 6 и 7 между столб-
цами формируется разделительная полоса толщиной 1,5 em
(24 пиксела). Ну и, наконец, в строчках 9-11 в промежуток между
столбцами помещается светло-серая пунктирная линия толщиной
1 пиксел для дополнительного визуального разделения (рис. 3.15).
Рис. 3.15. Сво-
бодное простран-
ство и граничная
линия отделяют
изображение от
следующего за
ним текста
That guy has the ball
In what Ьм to be conridered a development of the utmost im^
By Ricky Boucher 1 January l.aoia ______„
Lorem ipram dolor «it «met, coneectetar adipisdng elit
NulkaccomMmSeliequism^pretiumterapuB.Nullam
qua rhoocus masaa. Vivamue laoreet oonvallis eem ас
dapsbus. Donee varius congue sem ac molestie. Nam pan»
Curabitur eagittis mi et ante aliquet tristique vitae nee
viverra non, eodales e^et augue. 1в Ьас habitaese piatea
i dictumrt.CSaeeapterttecitieociaequadlitotatorquentper
ooaiibia nostra, per inoeptoe himenaeos. Praeeent nee neque
; q^odiohendreritawtornecveleratlnullamoorperiMilla
«od ipeum eknwntum varius. МогЫ et sepien ас шя!
STBdpittinciduaLSedlacnam*l,tempusvelultriceeveU
vulpntate a ramc Snspeadssee in diam vitae xmlla temper
vulputate qsds ac mine.
Nam in dm «get augue malesuada adipisdng ac at maasa. In
sed auctor libexo. Qukque egeatas mollis lobortia Vivamus
ladnia metus at quam posuere aaxfimentum. VestibuJum
sxite ipeum рпхшв ш. шкзЬш ores, ractue et ultricm pcumerc
cubi]kCur»e;EtieBQipsmnmauris,fiK3lisisutph«retraut,
ladzda vitae velit Pellwrtesque habitant morbi tristique
aenectusetnetxtsetmaleeuadaftaneflacturpieegeetas.

ТОЧКИ ПЕРЕХОДА 101
Теперь строки имеют более приемлемую длину, но вид страницы
можно еще улучшить, отделив статью от сведений об авторе.
Заодно имеет смысл еще немного отодвинуть изображение от
текста:
1. @media all and (min-width: 1300px) {
2. .main section img{
3. margin-bottom: lem;
4. border: 3px solid #dbdbdb;
s. }
6. .main .articlelnfo{
7. border-bottom: 2px solid #dbdbdb;
8. }
9. ...
10. }
Теперь, после визуального разграничения изображения и преди-
словия, а также создания дополнительных полей, дизайн принял
более или менее подобающий вид.
Единицы em
Браузеры пользователей имеют разный коэффициент масштаби-
рования. Человек со слабым зрением, скорее всего, сочтет шрифт
на большинстве сайтов слишком мелким и будет бороздить
просторы Сети браузером, масштаб отображения в котором
увеличен по умолчанию.
Разумеется, все это влияет на размер шрифта. В браузерах
Firefox и Opera при этом проблем не возникает. Медиазапросы,
основанные на размере пикселов, заново обсчитывают стра-
ницу и применяют соответствующий коэффициент масштаби-
рования. Но в других браузерах тщательно выбранные точки
перехода, связанные с размером шрифта, обманывают наши
ожидания. Внезапно от идеальной длины строки не остается
и следа (рис. 3.16).
В главе 2 вы видели, что аналогичная проблема возникает, когда
устройство по умолчанию использует другой размер шрифта.
Например, шрифт размером 26 пикселов на устройствах Kindle
не даст корректно отработать нашим медиазапросам. Но с этим
легко справиться, если сделать сайт еще более гибким, перейдя
к единицам em.

102 ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.16. Пока
точки перехода
определяются для
сайта, элементы
которого изме-
ряются в пиксе-
лах, увеличение
масштаба будет
приводить к иска-
жению макета
That guy has the ball
In what has to be considered a development of the utmost importance,
that man over there now has the ball.
By Ricky Boucher j January l, 2012
erst. In ullamcorper nulla sed
ipsum elementum varius. Morbi
et sapien ac nisi suscipit tincidunt
Sedlacwsnisl,tempueveluitrices
vel, vulputate a nunc. Suspendisse
in diam vitae nulla tempor
Lorem ipsum dolor sit amet, vulputate quis ac nunc
consectetur adipiscmg elit. Nulla
accumsanfeHsquiembbpretJum Nam in dui eget augue malesuada
tempus. Nuuam quis rhoncus adipiscing ac at massa. In sed
~«~.., \я,«ч^.,«, u™«^ ^„„„nj, auctor libero. Quiscpie egestas
Related Headlines
That Guy Knocked Out the Other Guy
Your Favorite Sports Team Lost Again.
The Yankees Buy the Entire League
Guy Says Something Stupid in the Heat
of the Moment
New Record Set as Neither Team
Why Haven't You Clicked One of Our
Headlines Yet?
Также в главе 2 была приведена формула преобразования одних
единиц измерения в другие. Она применима и в данном случае.
Нужно разделить цель (ширину в точке перехода) на контекст
(в данном случае это 16 пикселов, размер шрифта основного текста):
1.
2.
3
4.
5
6
7.
/* 600рх/16рх = 37.5ет */
gmedia all and (min-width: 37.5em) {
}
/* 860px/16px = 53.75em */
@media all and (min-width: 53.75em) {
9. /♦ 940рх/16рх = 58.75em */
10. @media all and (min-width: 58.75em) {
u.
12. }
13. /* 1300px/16px = 81.25em */
14. @media all and (min-width: 81.25em) {
15.
16. }
Теперь, когда медиазапросы оперируют единицами em, даже
при значительном увеличении масштаба изображения все будет
работать должным образом и оптимизированный макет никуда
не денется (рис. 3.17).

НАВИГАЦИЯ 103
That guy has the ball
In what has to be considered a development of the utmost importance, that man over there now has the ball.
By Ricky Boucher | January l, 2012
Рис. 3.17. Ука-
зав параметр
точки перехода
в единицах em,
вы гарантируете
корректный
вид макета вне
зависимости от
коэффициента
масштабирования
Используя в медиазапросах единицы em, мы еще одним спосо-
бом подстраиваемся под гибкость и непредсказуемость Сети.
Это позволяет пользователю контролировать свою работу со
страницей, а контенту — определять вид макета.
Навигация
Остался последний момент, имеющий отношение к теме ме-
диазапросов: навигация сайта. Самый лучший в мире контент
не удержит посетителя на вашем сайте, если он не сможете
сообразить, как по нему перемещаться. Навигация должна
быть доступной и легкой в применении вне зависимости от
размеров экрана.
В нашем примере навигация оказывается неудобной при
просмотре сайта с мобильных устройств. Расположение
элементов друг над другом придает сайту аккуратный вид,
но, как показано на рис. 3.18, совершенно вытесняет из поля
зрения статью, за которой пользователи, собственно, и за-
ходят на сайт.
Примечание
Увеличение мас-
штаба страницы
после ее загрузки
иногда становится
заметным только
после обновления.
Впрочем, большин-
ство пользователей
выбирают масштаб
заблаговременно,
поэтому в данном
случае проблема
отсутствует.

104 ГЛАВА 3. МЕДИАЗАПРОСЫ
Рис. 3.18. При
просмотре
сайта с теле-
фона статьи
не видно из-за
длинного спи-
ска элементов
навигации
Примечание
Брэд Фрост (Brad
Frost) рассматри-
вает у себя в блоге
различные вариан-
ты адаптивной на-
вигации, перечис-
ляя достоинства и
недостатки каждо-
го изнихЬир://
bradfrostweb.
com/blog/
web/complex-
navigation-patterns-
for-responsive-
design/.
Навигационные элементы должны подчиняться следующим
критериям:
• занимать на экране немного места;
• быть интуитивно понятными;
• быть доступными на самых разных устройствах (хотя
конкретная реализация меню в разных условиях может
различаться).
У нас есть несколько вариантов действий.
• Ничего не делать и оставить страницу как есть. В конце
концов, существующая система меню является интуитивно
понятной и работает на разных устройствах, просто иногда
начинает занимать слишком много места.
• Перейти к выпадающему меню. Это сэкономит место на
экране, будет доступно для большинства устройств и об-
ратно совместимо с устройствами, которые не могут обра-
ботать необходимый код JavaScript. Но для пользователей
эти меню давно стали неотъемлемой частью различных
форм. Посетители могут растеряться, столкнувшись с ними в
качестве инструмента навигации. Кроме того, большинство
браузеров не позволяют менять их внешний вид.

НАВИГАЦИЯ 105
• Скрыть меню. На маленьких экранах можно полностью
спрятать меню при помощи JavaScript, оставив для поль-
зователей кнопку, щелчок на которой разворачивает си-
стему навигации. Этот метод соответствует всем нашим
требованиям. Он экономит место на экране, интуитивно
понятен пользователям и может быть реализован на
самых разных устройствах, обеспечивая обратную со-
вместимость там, где не поддерживается JavaScript.
Поскольку скрытое меню соответствует всем выдвинутым
нами условиям, именно оно и будет реализовано на сайте Yet
Another Sports Site.
Переключение
Реализовать простой переключатель можно всего несколькими
строками кода CSS и JavaScript.
Для начала добавим ссылку на HTML-код, который будет управ-
лять появлением меню. Ее можно поместить непосредственно
над списком навигационных элементов:
<а href="#nav" class="nav-collapse" id="nav-collapse">Menu</a>
<ul class="nav" id="nav">
КОД CSS
Теперь при помощи CSS создадим несколько правил, чтобы
придать кнопке свертки меню определенный стиль и изна-
чально скрыть ее.
1. #nav-collapse{
display: none;
color: #fff;
text-align: right;
width: 100%;
padding: .625em 0 .625em 0;
2.
3.
4.
5.
6.
7- }
8. #nav-collapse.active {
9. display: block;
10. }
Строки 1-7 задают основные стили кнопки свертки и делают
ее изначально скрытой. Как вы помните, если браузер не под-
держивает JavaScript, сразу же появляется обычная навигация
и кнопка становится просто ненужной.
Примечание
Усовершенствуем
решение, сгене-
рировав кнопку
свертки дина-
мически, сред-
ствами JavaScript.
Когда JavaScript
отключен, ее не
существует.

10б ГЛАВА 3. МЕДИАЗАПРОСЫ
Строки 8-10 отображают кнопку, если атрибут class получает
значение active. Это делается средствами JavaScript.
Эти стили ничего не меняют в браузере, пока на сцене не появ-
ляется JavaScript. Именно это нам и нужно. Даже без JavaScript
навигацией вполне можно пользоваться. Она будет выглядеть
неидеально, но сохранит всю функциональность.
КОД JAVASCRIPT
Код JavaScript в данном случае тоже очень простой. Создайте
файл с именем yass.js и вставьте сценарий в HTML перед закры-
вающим тегом body:
<script type="text/javascript" src="yass.js"x/script>
Теперь поместите в файл yass.js следующий код:
1. window.onload = function() {
2. var collapse = document.getElementByld('nav-collapse');
3. var nav ■ document.getElementByldCnav1);
4. //функция переключения класса
5. function classToggle( element, tclass ) {
6. var classes = element.className,
7. pattern = new RegExp( tclass );
8. var hasClass = pattern.test( classes );
9. //переключение класса
10. classes = hasClass ? classes.replace( pattern, '* ) :
classes + ' ' + tclass;
11. element.className = classes.trim();
12. };
13. classToggle(nav, 'hide');
14. classToggle(collapse, 'active1);
is. collapse.onclick = functionQ {
16. classToggle(nav, 'hide');
17. return false;
18. }
19. }
При загрузке страницы (строка 1) запускается представленный
ранее код JavaScript. Строки 2 и 3 захватывают навигационный
элемент и кнопку свертки, чтобы впоследствии сценарий мог
к ним обратиться.
В строках 5-12 создается простая функция toggleClass. Она
берет элемент и проверяет, был ли применен соответствующий
класс. В случае положительного результата проверки она удаляет
этот класс. Если же результат отрицательный, добавляет его.

НАВИГАЦИЯ 107
Строки 13 и 14 применяют к навигации класс hide, а к кнопке —
класс active.
Ну и, наконец, строки 15-18 определяют функцию, вызываемую
при каждом щелчке на кнопке свертки. После вызова эта функ-
ция переключает класс hide, примененный в настоящее время
к системе навигации. В результате кнопка будет управлять ото-
бражением навигационных элементов.
Сейчас этот код выполняется, невзирая на обстоятельства. Оче-
видно, это не то, что нам нужно. Он должен работать только
в случае, когда элементы навигации располагаются друг над
другом. Проще всего ориентироваться на ширину экрана, но
это означает вставку новой точки перехода, а соответственно,
усложнение как CSS, так и JavaScript-кода.
Если же сценарий будет проверять, являются ли элементы нави-
гации плавающими, и запускаться в зависимости от результатов
проверки, точка перехода останется на прежнем месте. Попутно
мы переместим функцию classToggle в служебный объект, ко-
торый будет создан чуть позже:
1. var Utils = {
2. classToggle : function(element, tclass) {
3.
4. }
5. }
6. window.onload = function() {
7. var nav = document.getElementById('nav');
8. var navltem = nav.getElementsByTagNameCli');
9.
16. //является ли объект плавающим?
ii. var floated = navltem[0].currentStyle ?
el.currentStyle['float1] :
document.defauItView.getComputedStyle(navItem[0],null).
getPropertyValue('float');
12.
13. if (floated != 'left1) {
14. var collapse = document.getElementByldCnav-collapse1);
15.
16. Utils.classToggle(nav, 'hide');
17. Utils.classToggle(collapse, 'active');
18.
19. collapse.onclick = functionQ {
20. Utils.classToggle(nav, 'hide');
21. return false;
22. }
23. }
24. }

108 ГЛАВА 3. МЕДИАЗАПРОСЫ
Примечание
Детальная инфор-
мация о JavaScript
выходит за рамки
данного издания,
но если вы хотите
подробнее по-
знакомиться с этим
языком, восполь-
зуйтесь, например,
книгой Джона Пол-
лока «JavaScript.
Руководство
разработчика»,
вышедшей в изда-
тельстве «Питер»
в 2011 году.
Давайте рассмотрим этот код более подробно.
Строки 8-11 проверяют, является ли элемент навигации плаваю-
щим. Строка 11 может выглядеть несколько пугающе, но на самом
деле она всего лишь проводит проверку, чтобы определить, каким
способом будет выполнен запрос информации о текущем стиле.
Браузер Internet Explorer не очень хорошо работает с подобным
кодом, поэтому в нем проверяется другое свойство.
После определения значения свойства float остальная часть
кода запускается, только если элементы навигации являются
плавающими. Если применить данный код и обновить страницу,
на большом экране ничего не произойдет. А вот на маленьком
экране в момент загрузки страницы появится кнопка свертки
(рис. 3.19).
Рис. 3.19. Благо-
даря функции
переключения
навигация не
появляется, пока
пользователю
это не нужно
Поддержка Internet Explorer
К сожалению, это еще не все. Источником головной боли для нас
является любимый многими браузер Internet Explorer.
Медиазапросы поддерживаются только версиями от 9 и выше.
Это означает, что если за основу дизайна была взята версия для

ПОДДЕРЖКА INTERNET EXPLORER 109
мобильных телефонов, пользователям более старых версий этого
браузера будет продемонстрирован макет, предназначенный для
маленьких экранов.
Впрочем, эта проблема легко решается при помощи условных
комментариев, которые позволяют отдельно загрузить стили
для Internet Explorer. Поскольку в предыдущей главе мы создали
таблицу стилей ie.css, сложностей возникнуть не должно.
Для начала создадим условный комментарий применимым ко
всем версиям Internet Explorer до версии 9. Это означает, что
поддерживающая свойство display: table 9-я версия тоже будет
отображать макет с плавающими элементами, но это не очень
большая плата за то, что мы избежим добавления еще одной
связанной с Internet Explorer таблицы стилей:
<!--[if (It IE 9) & (!IEMobile)]>
<link rel="stylesheet" href =IIIf/css/ie. ess" media-"all">
Теперь добавим стили, которые встречались только в медиаза-
просах, в таблицу стилей для браузера Internet Explorer:
1. .main {
2. float: left;
3. width: 65.8227848%; /* 624 / 948 */
4. }
5. .slats li {
6. float: left;
7. margin-right: 2.5316456%; /* 24px / 948px */
8. width: 31.6455696%; /* 300 / 948 */
9. }
10. .slats li:last-child {
и. margin-right: 0;
12. }
13. aside{
14. display: block;
is. margin-bottom: lem;
16. padding: 0 1%;
17. float: right;
18. width: 31.6455696%; /* 300 / 948 */
19. }
20. nav[role="navigation"] li {
21. float: left;
22. border-top: 0;
23. }
24. nav[role="navigation"] a {
25. float: left;
26. }
27. footer[role=Hcontentinfo"] .top {
28. float: right;
29 • } продолжение

110 ГЛАВА 3. МЕДИАЗАПРОСЫ
30. aside img {
31. max-width: 100%;
32. }
Теперь и в Internet Explorer страница начнет отображаться вполне
приемлемо. Она не является адаптивной, но по крайней мере
обладает «резиновым» макетом, который хорошо выглядит при
большинстве разрешений экрана.
Подводя итоги
«Резиновая» разметка является только началом пути. И неиз-
бежно наступает момент, когда нам требуется внести в макет
изменения, иногда кардинальные, для адаптации его к различным
устройствам.
Смартфоны пытаются обеспечить пользователей полными вер-
сиями сайтов. И без метатега viewport большинство смартфонов
отображают сильно уменьшенные версии сайтов.
Медиазапросы позволяют проверять значения таких параметров,
как, например, width и height, и в зависимости от результа-
тов проверки соответствующим образом редактировать CSS.
Вы можете как воспользоваться внешним медиазапросом, так
и встроить его в код. Оба эти варианта имеют свои преимущества
и ограничения, поэтому важно выбирать стратегию, исходя из
требований к проекту.
Общепринятой практикой является привязка точек перехода
к ширине экрана устройства, но лучше определять необходимость
медиазапроса, исходя из контента.
Адаптивные сайты можно сделать еще более гибкими и доступ-
ными, воспользовавшись для измерения параметров в медиаза-
просах единицами em вместо пикселов.
Обязательно тестируйте результаты своей работы на реальных
устройствах. Именно это позволяет понять, что некоторые эле-
менты сайта, например система навигации, требуют настройки
под различные экраны.
В следующей главе мы рассмотрим различные подходы к выбору
корректного размера изображений и значительно улучшим про-
изводительность вашего сайта.

ЩШШШШМШ
Глава 4
Адаптивные элементы
Слушайте! Мы рассмотрели семнадцать
способов, и ни один из них не подошел,
потому что как бы мы ни считали,
кому-то это не нравилось.
Бадди Хэккет в роли Бенджамина Бенджи,
«Этот безумный, безумный, безумный,
безумный мир»

112 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Отношение пользователей к внешнему виду страниц всегда
было неоднозначным. С одной стороны, красивые изображения
и интересные видео делают пребывание на сайте более прият-
ным. С другой — слишком большое их количество негативно
сказывается на времени загрузки, что изрядно действует на
нервы. Значит, вид страниц нужно тщательно планировать,
стараясь взять лучшее от каждого аспекта и получить красивые,
интересные и максимально быстро загружающиеся страницы.
При помощи изученных в первых трех главах методов мы соз-
дали адаптивный сайт. Он хорошо выглядит на настольных
компьютерах, планшетах и смартфонах. Пользователи могут по
своему желанию менять размер окна браузера, макет при этом
будет соответствующим образом подстраиваться. Но если бы все
было так просто, книга получилась бы совсем короткой. У нас
еще достаточно работы по приведению сайта в порядок. В част-
ности, нужно решить проблему с изображениями.
В этой главе мы обсудим:
• значение производительности;
• организацию условной загрузки изображений;
• доступные решения для получения адаптивных изобра-
жений и их пределы;
• возможность замены фоновых изображений без скачива-
ния многочисленных графических файлов; ,
• условную загрузку шрифтов;
• будущее адаптивных изображений;
• масштабирование встроенного видео с сохранением про-
порций;
• адаптивные баннеры.
Истоки проблемы
На момент достижения последней точки перехода (при ширине
1300 пикселов) связанные с разделом More in Football изображе-
ния выглядели не очень привлекательно. В остальных случаях
они были резкими и четкими.
В доработке, похоже, нуждается и вид основной фотографии
на маленьких экранах. При более плотном кадрировании изо-

ИСТОКИ ПРОБЛЕМЫ 113
бражение сохранило бы свое первоначальное воздействие даже
после уменьшения его размеров. А пока в результате масштаби-
рования присутствующие на снимке объекты становятся слабо
различимыми (рис. 4.1).
Рис. 4.1. На
маленьком экране
сложно понять,
что именно изо-
бражено на
фотографии
Но основной проблемой является не столько вид изображений,
сколько их размер и требования, предъявляемые ими к произ-
водительности. В настоящее время для всех устройств загру-
жаются одни и те же картинки. Это означает, что, к примеру,
главная фотография шириной 624 пиксела скачивается даже при
просмотре на маленьком экране, на котором было бы вполне
достаточно картинки шириной 350 пикселов. Производитель-
ность страницы уменьшается, а этот параметр крайне важен
для посетителей сайта.
Производительность
К сожалению, производительность во многих проектах рас-
сматривается как второстепенный аспект. При этом небольшой
анализ показывает, что такого подхода следует всеми силами
избегать.

114 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Большинство из нас имеет более быстрое соединение с Интерне-
том, чем среднестатистический пользователь. В результате наш
опыт работы различается. И именно пользователи на своей шкуре
ощущают все недостатки сайта с низкой производительностью.
В 2009 году сайт Shopzffla, предоставляющий услуги по сравнению
товаров, ускорил загрузку страниц. Если раньше она занимала
от 4 до 6 с, то после преобразования это время сократилось до
1,5 с. Результат был поразительным. Показатель эффективности
рекламы сайта увеличился с 7 до 12 %, а число просмотров стра-
ниц — на целых 25 %*.
Аналогичный результат получила организация Mozilla, уменьшив
время загрузки страницы до 2,2 с: количество переходов, завер-
шившееся скачиванием, возросло до 15,4 %, что соответствует
примерно 10,28 млн дополнительных скачивании браузера Firefox
в год2!
Ситуация становится еще более критической для мобильных
телефонов. Сети работают медленнее, возможности аппаратного
обеспечения меньше, кроме того, приходится иметь дело с за-
путанным миром ограниченного трафика и способов перекоди-
ровки. Но несмотря на все это ожидания пользователей остаются
теми же самыми. Оказалось, что 71 % мобильных пользователей
ожидает, что сайты начнут загружаться на телефон с той же ско-
ростью или даже быстрее, чем на обычный компьютер3.
Для нашего сайта в его современном состоянии это плохие
новости. Как логотип, так и основное фото имеют изрядный
размер. Основное фото при ширине 624 пиксела весит примерно
50 Кбайт. Для устройств с маленькими экранами вполне могло
бы сгодиться вполовину меньшее изображение (шириной при-
мерно 300 пикселов), но мы заставляем пользователей скачивать
графику, больше подходящую для настольных компьютеров. Воз-
можность уменьшить количество передаваемых данных слишком
важна, чтобы мы могли ее игнорировать.
Данные со страницы www.saibd.com/doc/16877317/Shopzillas-Site-Redo-You-Get-What-You-Measure
Данные со страницы http://blog.mozilia.org/metriG/2010/04/05/firefox-page-load-speed—part-ii/
Данные со страницы www.gomez.com/resources/whitepapers/survey-report-what-users-want-from-
mobile/

ИСТОКИ ПРОБЛЕМЫ 115
Быстрая оценка страницы показывает, что оптимизировать
можно следующие изображения.
• Картинки в разделе More in Football. Ширина каждой
из них составляет всего 300 пикселов, но на маленьком
экране без них вполне можно обойтись. По большому
счету, они занимают довольно много места и нарушают
пропорциональность контента (рис. 4.2). На маленьком
экране имеет смысл отображать не изображения, а только
заголовки.
• Основное изображение в статье. Его ширина составляет
624 пиксела, а размер — около 50 Кбайт. На маленьких
экранах также хорошо будет смотреться изображение
вполовину меньшего размера. Кроме того, если путем ка-
дрирования создать версию снимка для маленьких экранов,
сохранится визуальная фокусировка на флаге.
• Логотип. Он весит 10 Кбайт, выигрывая в этом отношении
у основного изображения. Что не мешает ему быть в два
раза больше, чем нужно.
Рис. 4.2. На устрой-
ствах с маленьким
экраном изобра-
жения из раздела
More Football
занимают слишком
много места

116 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Пользователь-
ские атрибуты
data
Атрибуты с при-
ставкой data- со-
храняют данные
пользователя пря-
мо на странице,
что часто требует-
ся для различных
сценариев.
Изображения для
мобильной версии
Для начала удалим картинки из раздела More in Football базовой
версии сайта. Очень соблазнительно воспользоваться свойством
display: none и считать дело законченным, но это просто убирает
проблему с глаз долой, а не решает ее.
Изображение, в свойствах которого прописано display:none,
все равно запрашивается и скачивается браузером. То есть оно
просто перестает отображаться, а проблема с лишним запро-
сом и его размером никуда не девается. Поэтому правильным
будет начать с мобильной версии и выполнить прогрессивное
улучшение вида страницы.
Сначала полностью уберем из HTML-кода картинки:
г.
з.
4.
s.
6.
7.
8.
9.
10.
п.
12.
13.
14.
15.
16.
17.
class="slats">
li class=Hgroup">
<а href="#">
<h3>Kicker connects on record 13 field goals</h3>
class="group">
<a href=H#">
<h3>Your favorite team loses to that team no one Iikes</h3>
<a href="#">
<h3>The Scarecrows Win 42-0</h3>
Очевидно, что при реализации этого кода, изображения за-
гружаться не будут. Именно в таком виде мы оставим сайт для
устройств с маленькими экранами. Для экранов большего раз-
мера небольшой сценарий JavaScript вернет графику назад. Мы
пойдем на небольшую хитрость и воспользуемся атрибутами
data-* из языка HTML5, так как они позволяют объяснить сце-
нарию JavaScript, какие именно изображения следует загружать:
2,
class="slats">
li data-src="images/ball.jpg" class="group">

ИЗОБРАЖЕНИЯ ДЛЯ МОБИЛЬНОЙ ВЕРСИИ 117
3. <а href="#M>
4. <h3>Kicker connects on record 13 field goals</h3>
6,
7. <li data-src="images/goal_post.jpg" class="group">
8. <a href="#">
9. <h3>Your favorite team loses to that team no one Iikes</h3>
18.
11.
12. <li data-src="images/ball_field.jpg" class="group">
о. <a href="#">
14. <h3>The Scarecrows Win 42-0</h3>
15.
16.
17.
JavaScript
Первым делом добавим небольшую служебную функцию, кото-
рая поможет при выборе элементов. Это необязательный шаг, но
наличие этой функции нам явно не помешает:
1. q : function(query) {
2. if (document.querySelectorAll) {
3. var res ■ document.querySelectorAll(query);
4. } else {
s. var d = document,
6. a = d.stylesheets[0] || d.createStyleSheetQ;
7. a.addRule(query,'f:b');
8. for(var l=d.all,b=0,c=[]if=l.length;b<f;b++) {
9. l[b].currentStyle.f && c.push(l[b]);
10. a.removeRule(O);
п. var res = c;
12. }
13. return res;
14. }
15. }
Если вы не очень хорошо знакомы с кодом JavaScript, этот фраг-
мент может показаться слегка запутанным. Но это нестрашно.
Функция всего лишь рассматривает некоторое условие и воз-
вращает элемент, который ему соответствует. Здорово, если вы
в состоянии разобраться в представленном коде. Но по большому
счету, для наших целей достаточно, чтобы вы понимали, что
именно делает код.
Благодаря данной функции значительно упрощается фрагмент,
непосредственно отвечающий за загрузку изображений:

118 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
1. //получение информации об изображениях
2. var lazy = Utils.qC [data-src]1);
3. for (var i = 9; i < lazy.length; i++) {
4. var source = lazy[i].getAttribute('data-src1);
5. //создание изображения
6. var img = new ImageQ;
i. img.src = source;
8. IУ вставка изображений в ссылку
9. lazy[i].insertBefore(img, lazy[i].firstChild);
10. };
Строка 2 выбирает все элементы с атрибутами data-src. А в
строке 3 осуществляется их циклический просмотр. В строках 4-7
сценарий создает новое изображение для каждого элемента на
основе значения атрибута data-src. Затем новое изображение
вставляется (строка 9) в ссылку как первый элемент.
Благодаря этому коду JavaScript изображения не запрашива-
ются в первый же момент. Их загрузка начинается только после
окончания загрузки страницы, что нам и требуется. После этого
остается только объяснить сценарию, что для устройств с ма-
ленькими экранами изображения скачивать не нужно.
Примечание
Сценарий Айри-
ша можно скачать
со страницы
https://github.
com/paulirish/
matchMedia.js
сайта GitHub или
найти в примерах
кода на сайте
данной книги
http://www.
implementing-
responsivedesign.
com.
Introducing matchMedia
Созданный нами в главе 3 сценарий, отображающий систему
навигации на устройствах с маленьким экраном, проверял, яв-
ляются ли элементы навигации плавающими. В случае положи-
тельного результата проверки создавалась функция свертки. Но
на этом раз мы воспользуемся методом matchMedia().
Это собственный метод JavaScript, позволяющий передавать
в CSS медиазапрос и получать информацию о его результатах.
Функция возвращает объект MediaQueryList, обладающий двумя
свойствами: matches и media. Свойство matches возвращает
значение true, если запрос из списка соответствует состоянию
текущего окна, и false — в противном случае. Свойство media
возвращает только что переданный вами медиазапрос. Например,
свойство media для запроса window.matchMedia("(min-width:
200рх)") вернет результат " (min-width: 200рх)".
Метод matchMedia() поддерживается в браузерах Chrome,
Safari 5.1+, Firefox 9, Android 3+ и iOS5+. Пол Айриш (Paul Irish)
создал практичный сценарий для браузеров, которые не под-
держивают данный метод.

ИЗОБРАЖЕНИЯ ДЛЯ МОБИЛЬНОЙ ВЕРСИИ 119
При наличии этого сценария для объяснения браузеру того
факта, что изображения должны вставляться только после пер-
вой точки перехода, достаточно вставить код внутрь первой
проверки matchMedia:
1. if (window.matchMedia("(min-width: 37.5em)").matches) {
2< //получение информации об изображениях
3. var lazy = Utils.q('[data-src]');
4. for (var i = 0; i < lazy.length; i++) {
5. var source = lazy[i].getAttribute('data-src');
6. //создание изображения
7. var img = new Image();
8. img.src = source;
9. //вставка изображений в ссылку
16. lazy[i].insertBefore(img, lazy[i].firstChild);
и. };
12. }
Теперь при загрузке страницы на телефон или уменьшении раз-
меров экрана изображения не запрашиваются (рис. 4.3). Это
большая победа на ниве производительности. Теперь у нас на
три HTTP-запроса меньше, а размер страницы уменьшился
примерно на 60 Кбайт (суммарный вес трех изображений). Но
при этом никуда не исчезли заголовки и полностью сохрани-
лась функциональность ссылок. Пользователь спокойно может
работать с сайтом.
Рис. 4.3. На устрой-
ствах с маленькими
экранами изображе-
ния раздела More in
Football скачиваться
не будут, что зна-
чительно увеличит
производительность
страницы

120 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Гай Поджарны
АДАПТИВНЫЙ ДИЗАЙН И ПРОИЗВОДИТЕЛЬНОСТЬ
Гай Поджарны (Guy Podjarny), или виуро, является специалистом по
тестированию производительности и миссионером, постоянно
фиксирующим меняющуюся на глазах Сеть. В основном его интересует
производительность мобильного Интернета, и поэтому он регулярно
копается в потрохах мобильных браузеров. Также он является авто-
ром сервиса Mobitest, тестирующего производительность сайтов
на мобильных платформах. Свой вклад он внес в создание различных
инструментов с открытым исходным кодом. Поджарны был одним из создателей, а затем и глав-
ным техническим директором компании Blaze.io, позднее приобретенной провайдером Akamai.
Сейчас он является одним из ведущих разработчиков Akamai.
Адаптивный дизайн решает множество про-
блем, и легко потерять голову, пытаясь опре-
делить, насколько поддерживаемым, ориенти-
рованным на будущее или крутым будем ваш
сайт» Но за всей этой суетой важно не упустить
из виду такой аспект, как скорость его работы.
Производительность является важной состав-
ляющей пользовательского опыта, и многочис-
ленные исследования доказывают ее влияние
на удовлетворение пользователей и вашу ито-
говую прибыль.
В настоящее время браузеры смартфонов часто
перенаправляют на специально созданные
мобильные сайты, которые имеют намного
меньший вес и меньшее количество визуаль-
ных эффектов, чем их аналоги для настольных
компьютеров. С такого сайта приходится скачи-
вать намного меньше изображений, сценариев
и таблиц стилей, что значительно ускоряет
его загрузку. Принцип очень простой: чем
меньшее количество байт скачивается и чем
меньше запросов производится, тем быстрее
все работает.
Но в случае адаптивных сайтов этот принцип
не действует. Недавно я проверил произво-
дительность 347 таких сайтов (все они пере-
числены в издании http://mediaqueri.es/ за
март 2012 года). Я загружал главную страницу
каждого из них в браузер Google Chrome
с четырьмя разными размерами окна в диа-
пазоне от 320x480 до 1600x1200 пикселов.
Каждая страница загружалась несколько раз
в инструмент с сайта www.webpagetest.org.
Результаты были удручающими. Несмотря на
изменение внешнего вида сайтов в зависимо-
сти от размера окна, их вес и скорость загрузки
практически не менялись.
86 % сайтов при загрузке в браузер с минималь-
ным размером окна весили столько же, сколько
и обычно. Другими словами, хотя сайты каза-
лись мобильными, они все равно скачивали все
свое содержимое и поэтому были ужасающе
медленными.
Все сайты разные, но практически у всех них
существуют три причины избыточного ска-
чивания:
• скрытые элементы;
• сжатые элемейты;
• избыточный DOM.
Одной из самых распространенных причин ска-
чивания избыточного количества данных явля-
ются скрытые элементы. Адаптивные сайты
обычно возвращают всем клиентам один и тот
же HTML-код. Даже у сайтов, проектирование
которых начиналось с версии для мобильных
устройств, этот код содержит все необходи-
мое для обеспечения максимально насыщен-
ных страниц на самых широких мониторах.
На маленьких экранах не предназначенные
для демонстрации разделы скрываются при
помощи свойства displaymone. К сожалению,

ИЗОБРАЖЕНИЯ ДЛЯ МОБИЛЬНОЙ ВЕРСИИ 121
это никак не увеличивает производительность,
так как скрытые ресурсы все равно продол-
жают скачиваться, сценарии из скрытых раз-
делов — работают, а элементы DOM — созда-
ются. В результате, даже если скрыть большую
часть контента страницы, браузер все равно
будет скачивать все ресурсы, которые сможет
обнаружить.
Концептуально схожа с вышеизложенным
проблема сжатия скачанных элементов» Адап-
тивные сайты пользуются «резиновыми» изо-
бражениями для лучшей совместимости с экра-
нами разных размеров. При всей визуальной
привлекательности этого подхода он означает
скачивание изображения, предназначенного
для настольных компьютеров, даже если сайт
просматривается через устройство с малень-
ким экраном. Но пользователи последних не
в состоянии оценить высокое качество кар-
тинки, так что никакой пользы избыточное
скачивание данных не несет.
Третьей причиной является избыточный DOM.
Браузеры анализируют и обрабатывают скры-
тые области DOM, в результате получается, что
устройства с маленьким экраном получают
намного более сложный программный интер-
фейс, чем им требуется. Усложнение интер-
фейса вызывает большее потребление памяти,
требующее ресурсов переформатирования, и в
общем случае медленную работу сайта.
Решить эти проблемы не так уж просто, потому
что они проистекают из современного спо-
соба функционирования адаптивных сайтов
и браузеров. Но можно порекомендовать ряд
методов контроля производительности:
пользуйтесь адаптивными изображе-
ниями;
начинайте проектирование с версии
для мобильных устройств;
• измеряйте производительность.
Адаптивные изображения подробно рассма-
триваются в этой книге и помогают бороться
с проблемой номер два. Так как изображения
вносят изрядный вклад в вес каждой стра-
ницы, это самый простой способ значительно
уменьшить данную характеристику. Имейте
в виду, что CSS-изображения также должны
быть адаптивными. Кроме того, их можно заме-
нить с помощью медиазапросов.
Что касается второй рекомендации, то вам
нужно не просто спроектировать версию для
мобильных устройств, но и написать отдельный
код для самого низкого из возможных разре-
шений. Полученный сайт должен функциониро-
вать так же хорошо, как и остальные версии для
мобильных устройств, и иметь разумно низкий
вес. Совершенствовать такую страницу нужно
только средствами JavaScript или CSS, чтобы
избежать избыточного скачивания. В резуль-
тате клиенты, устройства которых не поддер-
живают JavaScript, получат базовую, но при
этом функциональную версию. Имейте в виду,
что при доработке сайта при помощи JavaScript
сохранить высокую производительность не так
уж просто, более того, наработанные практики
в этой области отсутствуют, что приводит меня
к третьему пункту программы — необходимо-
сти измерений.
Считайте производительность ключевым
аспектом качества вашего сайта и не считайте
свою работу выполненной, пока не добьетесь
удовлетворительных показателей. Если соз-
данная вами мобильная версия сайта весит
свыше 1 Мбайт, ее запуск имеет смысл отло-
жить до тех пор, пока вы не примете нужные
меры. Существуют различные инструменты для
измерения производительности, но я бы поре-
комендовал вам Mobitest для тестирования на
мобильных устройствах (http://akamai.com/
mobitest) и WebPageTest для тестирования на
настольных компьютерах (www.webpagetest.
org). В последнем случае для изменения раз-
меров окна браузера пользуйтесь командой
setviewportsize.
В заключение хотелось бы сказать, что адаптив-
ный дизайн является мощной и прогрессивной
техникой, но оказывает значительное влия-
ние на производительность. Убедитесь, что вы
понимаете источник проблем и конструируете
сайт таким образом, чтобы их избежать, чтобы
посетители не уходили с вашего сайта до про-
смотра замечательных визуальных эффектов
и контента.

122 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Теперь можно сфокусироваться на основном изображении и ло-
готипе. Они должны отображаться вне зависимости от разре-
шения экрана. Поэтому для них требуется не условная загрузка,
а корректное масштабирование. Вот тут-то все становится куда
сложнее.
Создание адаптивных
изображений
Говорят, что в мире существует всего семь сюжетов, просто их
пересказывают по-разному. По аналогии можно сказать, что
существует только три стратегии работы с адаптивными изо-
бражениями: борьба с браузером, отказ от борьбы и обращение
к серверу.
Борьба с браузером
Большинство интерфейсных решений пытаются бороться с бра-
узером. Они хотят указать, какое изображение требуется скачать,
до того как браузер примет неверное решение. Это очень сложная
задача. Браузеры хотят, чтобы страницы загружались быстро,
и потому идут на крайние меры в том, что касается скорости
скачивания изображений. Это совпадает с вашими собствен-
ными стремлениями, но очень раздражает, когда вы пытаетесь
соревноваться с браузером.
Отказ от борьбы
В основе некоторых стратегий лежит идея, что браузер все равно
не победить. В этом случае обычно по умолчанию первым делом
загружаются изображения для маленьких экранов. Затем при
необходимости подгружается графика для больших экранов.
Очевидно, что это не идеальный выход. Устройства с большими
экранами вынуждены делать два запроса вместо одного. А этого
по возможности следует избегать, ведь производительность
важна для устройств всех видов.

ВАРИАНТЫ АДАПТИВНЫХ ИЗОБРАЖЕНИЙ 123
Обращение к серверу
Ну и, наконец, в некоторых случаях выбор изображений для за-
грузки осуществляется непосредственно на сервере. В этом слу-
чае никакой конкуренции с браузером не возникает. Логические
операции выполняются до того, как браузер увидит HTML-код.
Но этот подход нельзя отнести к числу ориентированных на буду-
щее. Хранить информацию обо всех устройствах, которые могут
запросить контент вашего сайта, становится все труднее, так
как их количество быстро увеличивается (за это нужно сказать
спасибо уменьшению стоимости производства вычислительной
техники). А по мере того как во все большем количестве устройств
будут обеспечены различные способы просмотра (проекции,
встроенные виджеты webview или дополнительный экран), ин-
формация о них будет становиться все менее достоверной.
Варианты адаптивных
изображений
В настоящее время все подходы к созданию адаптивных изо-
бражений имеют ограничения. Для иллюстрации сказанного
рассмотрим пару техник и оценим, подходят ли они для нашей
страницы Yet Another Sports Site.
Сервис Sencha.io Src
Созданный Джеймсом Пирсом (James Pearce) сервис Sencha.
io Src максимально соответствует нашим представлениям
о готовом решении для получения адаптивных изображений.
Он берет переданное вами изображение и возвращает его по-
сле изменения размеров. Для этого достаточно указать перед
адресом изображения адрес сайта Sencha.io Src, например:
http://src.sencha.io/http://mysite.com/images/football.jpg
Сервис использует строку агента пользователя производящего
запрос устройства, чтобы определить размер экрана и со-
ответствующим образом масштабировать изображения. По
умолчанию его размер подгоняется под 100 % ширины экрана.
Примечание
Детальное опи-
сание сервиса
Sencha.io Src
находится по
адресу http://docs.
sencha.io/0.3.3/
index.html#!/
guide/src.

124 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Примечание
Код для исполь-
зования сервиса
Adaptive Images
находится на
странице http://
adaptive-images.
Возможно также задать пользовательские настройки. Например,
чтобы получить изображение определенной ширины, можно
передать этот размер в виде параметра. Вот эта строчка позволяет
получить изображение шириной 320 пикселов:
http://src.sencha.io/320/http://mysite.com/images/football.jpg
Сервис умеет даже кэшировать запросы, поэтому отпадает не-
обходимость генерировать изображение при каждой загрузке
страницы.
К сожалению, это решение не очень подходит для нашего сайта
Yet Another Sports Site. Как вы помните, при увеличении разме-
ров экрана статья начинает отображаться в виде двух столбцов,
изображение же будет масштабироваться до 100 % размера
экрана, так как сервис Sencha.io Src ориентируется на параметры
устройства, а не на величину контейнера. Разумеется, можно
заставить сервис использовать ширину столбца, но для этого
потребуется задействовать экспериментальную функцию изме-
рений на стороне клиента и прибегнуть к некоторой доработке
сценария JavaScript.
Для мобильной версии сайта такой проблемы не существует,
но сервис Senchaio Src не сможет вам помочь в ситуации, когда
нужно не только изменить размер изображения, но и выполнить
его кадрирование. А ведь возможно, картинки из раздела More in
Football на каком-то этапе нужно будет превратить в квадратные
миниатюры. Здесь простое изменение размеров уже не поможет.
Требуется некая возможность художественной обработки, недо-
ступная на сайте Sencha.io Src.
Кроме того, использование сторонних решений всегда связано
с некоторым риском. Если компания изменит политику или
решит прекратить свою работу, срочно понадобится искать
какой-то альтернативный вариант.
Сервис Adaptive Images
Другим практически автоматическим решением является сервис
Adaptive Images, созданный Мэттом Уилкоксом (Matt Wilcox). Он
определяет размер экрана, после чего создает, кэширует и мас-
штабирует версию вашего изображения.

ВАРИАНТЫ АДАПТИВНЫХ ИЗОБРАЖЕНИЙ 125
Это прекрасное решение для уже готового сайта в случае, если
у вас нет времени менять структуру разметки или кода. Его при-
менение представляет собой простой, трехступенчатый процесс:
1. Скопируйте файлы .htaccess и adaptive-images.php в корневой
каталог вашего сайта.
2. Создайте папку ai-cache и установите для нее право на запись.
3. Добавьте в заголовок вашего документа следующую строку
JavaScript:
<script>document.cookie='resolution»'+Math.max(screen.width,
screen.height)+'; path=/';</script>
Этот код сохраняет в куки информацию о разрешении экрана.
Существует много способов конфигурации файла adaptive-images.php,
но в большинстве случаев вполне достаточно присвоить пере-
менной $resolutions значения, которые будут соответствовать
точкам перехода:
$resolutions = array(860, 600, 320); // разрешения в точках
перехода
// (ширина экрана в пикселах)
Возможно, вы обратили внимание на то, что эти точки пере-
хода немного отличаются от указанных в CSS-коде страницы
Yet Another Sports Site. В этом коде отсутствует точка перехода
при 320 пикселах, зато есть две точки при максимальных раз-
решениях 1300 пикселов и 940 пикселов, которые не включены
в массив $resolutions. Все дело в способе работы сценария.
Минимальное значение (в нашем случае 320 пикселов) — это
размер изображения, которое будет создаваться для всех экранов
меньшей ширины. Например, для экрана шириной 300 пикселов
будет получено изображение шириной 320 пикселов, так как это
минимальный размер, заданный в массиве $resolutions. При
ширине экрана 321 пиксел, которое превосходит указанное в мас-
сиве значение 320 пикселов, сайтом будет получено следующее
изображение — в данном случае шириной 600 пикселов. Если
оставить это значение в качестве первой точки перехода, все
устройства с шириной экрана менее 600 пикселов будут полу-
чать изображения, горизонтальный размер которых составляет
600 пикселов.

126 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Художественная обработка
и адаптивные изображения
В основном обсуждения адаптивных изображений вращаются вокруг размеров файла.
Это очень важный, но далеко не единственный параметр. Иногда масштабирование
фотографии для маленьких экранов уменьшает ее воздействие. Рассмотрим для при-
мера фотографию шлема футболиста.
В исходном размере снимок выглядит хорошо сбалансиро-
ванным. Но при его уменьшении шлем оказывается слишком
маленьким, чтобы с первого взгляда можно было распознать,
что это такое.
Именно на этом этапе требуется художественная обработка*
Простое масштабирование нивелирует воздействие фотогра-
фии и затрудняет распознавание представленных на ней объ-
ектов. Кадрирование же позволяет сохранить в фокусе шлем,
несмотря на маленький размер конечного изображения.

ВАРИАНТЫ АДАПТИВНЫХ ИЗОБРАЖЕНИЙ 127
Две верхние точки перехода при этом просто не требуются,
так как сценарий попытается масштабировать изображение до
указанного размера. Но при этом он никогда не сделает графи-
ческий фрагмент большим, чем он есть, поэтому все значения,
превышающие 624 пиксела (физический размер изображения),
не имеют смысла.
Готовые изображения сохраняются в папку ai-cache (ее имя можно
при желании изменить), поэтому их повторной генерации не
требуется. При этом вы можете контролировать длительность
кэширования изображения браузером.
Как видите, все очень просто. Еще раз упомяну, что это за-
мечательное решение для сайтов, которым требуется готовый
вариант. Тем не менее оно не лишено недостатков. К сожалению,
из-за динамического изменения размеров изображения отсут-
ствует возможность художественной доработки последнего.
Сценарий не поможет и в случае, когда при большом раз-
решении требуется небольшое изображение. Для страницы
Yet Another Sports Site это проблема. При разрешениях экрана,
превышающих 1300 пикселов, статья разбивается на два столбца,
а изображение уменьшенного размера помещается в один из
них. Если же воспользоваться сценарием Adaptive Images, будет
скачиваться самая большая версия картинки.
Другим тонким моментом является адрес URL, не зависящий
от размера запрошенного изображения. Это может стать при-
чиной проблем с сетями доставки контента (Content Delivery
Networks (CDN)). При первом запросе данного URL-адреса CDN
может кэшировать его, чтобы увеличить скорость следующего
запроса к данному ресурсу. Соответственно, при множественных
запросах к одному URL через одну сеть CDN вы можете полу-
чить изображение вовсе не того размера, который вам требуется.
И что же делать?
В настоящее время однозначного решения для работы с адап-
тивными изображениями не существует. Каждый метод имеет
свои достоинства и недостатки. И выбирать только вам, исходя
из нюансов конкретного проекта.
Сетью доставки
контента на-
зывается геогра-
фически распре-
деленная сетевая
инфраструктура,
позволяющая
оптимизировать
доставку данных
конечным пользо-
вателям.

128 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Из двух предложенных вариантов, вероятно, лучшим является
Adaptive Images, так как он не ставит вас в зависимость от сто-
ронних ресурсов.
Будущее адаптивных изображений
Сразу уточню, что симбиоз распознавания на стороне сервера и JavaScript-куки —
исключительно временная мера. Если бы в наличии имелся какой-то более долго-
вечный метод, я сразу стал бы его приверженцем* К сожалению, все доступные на
сегодня возможности работы с адаптивными изображениями представляют собой
некие трюки, временные способы закрыть проблему.
Обсуждались возможности и таких решений, как новый элемент, новый атрибут или
новый формат изображений. Более того, если вы чувствуете в себе склонность к экс-
периментам, то вот ссылка на полностью функционирующий код одного из таких еще
не существующих элементов: https^/github.com/scottjehl/picturefill. К сожалению,
проблема далека от своего решения, потому что требуется не просто нечто «удобное
для применения разработчиками».
При обсуждении мнений по поводу двух популярных решений Джейсон Григсби (Jason
Grigsby) нащупал корень проблемы1. Для улучшения производительности браузеры
стараются максимально быстро скачать изображения, не будучи осведомленными
о компоновке страницы. Разработчики же считают, что сведения о макете помогут
правильно выбрать изображение для скачивания. Примирить эти противоречия не
так-то просто.
Я уверен, что со временем обязательно появится подходящее решение. Кроме того,
как я уже говорил, оптимальный подход будет зависеть от особенностей реализуе-
мого проекта,
Узнать подробности конфликта между <picture> и <a>srcset можно на странице http://blog.doudfour.
comAhe-real-conflict-behind-picture-and-srcset/
Фоновые изображения
Ребята, заказавшие нам сайт Yet Another Sports Site, весьма до-
вольны нашей работой, но хотели бы еще видеть в заголовке ви-
зуальный индикатор, позволяющий посетителю понять, в каком
разделе сайта он находится.

ФОНОВЫЕ ИЗОБРАЖЕНИЯ 129
Через 30 секунд изматывающей работы в Photoshop мы добавили
два силуэта футбольных мячей (рис. 4.4).
Им понравилось, как это выглядит на большом экране, но после
точки перехода на отметке 53,75 em, в которой логотип начинает
перекрываться текстом, фоновое изображение имеет смысл убрать.
Это еще один случай, когда проектирование нужно начинать
с мобильной версии. Давайте посмотрим, что произойдет, если
мы начнем ухудшать версию сайта для настольных компьютеров
при помощи медиазапросов.
Базовые стили, включающие в себя фоновое изображение, никуда
не денутся, поэтому их придется переопределить при помощи
медиазапроса. Это будет выглядеть примерно так:
1. /* базовые стили */
2. header[role="banner"] .inner{
3. background: url('../images/footballjjg.png1) bottom right
no-repeat;
4. }
5
6. gmedia all and (max-width: 53.75em) {
7. header[role="banner"] .inner {
8. background-image: none;
*. }
10. }
На бумаге все выглядит хорошо. Но в реальности многие бра-
узеры даже для устройств с маленьким экраном станут ска-
чивать изображение, хотя оно никак не будет использоваться.
Самым примечательным из них является встроенный браузер
Android 2.x. Как вы помните, хотя на момент написания данной
книги уже появилась версия 4, около 95 % устройств Android
работали с ее предшественницей. Это означает, что практически
весь трафик для мобильных устройств Android будет включать
в себя совершенно ненужное изображение.
Чтобы избежать этой напасти, лучше объявить фоновое изо-
бражение в самом медиазапросе, например:
Рис. 4.4. Заголо-
вок украсило эле-
гантное фоновое
изображение

130 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Примечание
Чтобы более
полно ознако-
миться с различ-
ными методами
замены и скрытия
фоновых изобра-
жений, смотрите
результаты про-
веденных мной те-
стов на странице
http://timkadlec.
com/2012/04/
media-query-asset-
downloading-
results/.
Примечание
Зачем скачивать
такое количество
разных файлов?
За это можно
поблагодарить
разные браузеры.
При наличии
вполне адекватной
поддержки они
не могут прийти
к согласию по
поводу единого
формата текста.
1. /* базовые стили */
г. 0nedia all and (min-width: 53.75em) {
3. header[role=tIbannerlf] .inner{
4. background: url('../images/football_bg.png') bottom
right no-repeat;
5. }
6. }
7
8. gmedia all and (max-width: 53.75em) {
9. header[role="banner"] .inner {
10. background-image: none;
11. }
12. }
Этого вполне достаточно для исправления ситуации на устрой-
ствах Android.
Поскольку в данном случае за основу берется мобильная версия,
весь процесс изрядно упрощается. Базовый макет не нуждается
в фоновом изображении, поэтому мы позднее вставим его внутри
медиазапроса:
1. /* базовые стили ♦/
2. gmedia all and (min-width: 53.75em) {
3. header[role=banner] .inner{
4. background: url('../images/football_bg.png') bottom
right no-repeat;
5. }
6. }
Такой подход означает, что запрашивать фоновое изображение
будут только те браузеры, в которых оно отображается, то есть
проблему с производительностью мы решили!
Разумеется, в данном случае построение сайта на основе мо-
бильной версии также означает, что в Internet Explorer версии 8
и ниже фонового изображения по умолчанию видно не будет.
Но благодаря условным комментариям уже подключена пред-
назначенная для IE таблица стилей. Достаточно добавить в нее
данное объявление, и эта проблема будет решена.
Раз уж мы об этом заговорили
В настоящее время мы загружаем шрифт ChunkFive, используе-
мый в элементах header. Объявление стиля выглядит так:
1. @font-face {
2. font-family: 'ChunkFiveRegular';

ФОНОВЫЕ ИЗОБРАЖЕНИЯ 131
3. src: urlCChunkfive-webfont.eof);
4. src: url('Chunkfive-webfont.eot?#iefix') format
('embedded-opentype'),
s. url('Chunkfive-webfont.woff') format ('woff),
6. url('Chunkfive-webfont.ttf') format('truetype'),
7. url('Chunkfive-webfont.svgttChunkFiveRegular1) format('svg1);
8. font-weight: normal;
9. font-style: normal;
10. }
Представленный код прекрасно работает. Браузер берет нужный
файл и визуализирует указанный шрифт. И даже с размерами
файлов все не так уж плохо. Но в ситуации есть небольшая не-
доработка. В настоящее время браузеры на базе WebKit не ото-
бражают текст с бесплатными шрифтами из Интернета, пока не
будет скачан соответствующий шрифт. Это означает, что у поль-
зователей Android, BlackBerry и iPhone с небольшой скоростью
соединения (или у тех, кто использует ноутбук в качестве точки
доступа) заголовки будут отображаться не сразу. Такая ситуация
сбивает пользователей с толку, поэтому ее нужно избегать.
Мы не можем определить полосу пропускания конкретного поль-
зователя (по крайней мере, в настоящий момент — в главе 9 вы
прочитаете прогнозы на будущее), но известно, что вероятность
столкнуться с медленным соединением выше всего у мобильных
устройств. Поэтому имеет смысл загружать шрифты только на
экраны большего размера.
Условная загрузка, которой мы пользовались для фоновых изо-
бражений, вполне годится и для шрифтов. Поэтому переместим
в медиазапрос объявление @font-f асе. В результате до точки
перехода устройства не будут даже пытаться скачивать файлы
со шрифтами:
1. 0media all and (min-width: 37.5em) {
2.
3. gfont-face {
4. font-family: 'ChunkFiveRegular1;
s. src: url('Chunkfive-webfont.eot');
6. src: url('Chunkfive-webfont.eot?#iefix')
format('embedded-opentype'),
7. url('Chunkfive-webfont.woff) format('woff■),
8. url('Chunkfive-webfont.ttf1) formatCtruetype1),
9. url('Chunkfive-webfont.svg#ChunkFiveRegular')
formate svg1);
18. font-weight: normal;
11. font-style: normal; продолжение &

132 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
12. }
13. }
Благодаря этой маленькой доработке бесплатные шрифты бу-
дут скачиваться только для экранов шириной более 37,5 em
(-600 пикселов) (рис. 4.5). Разумеется, пользователи с медлен-
ной связью все еще могут столкнуться с присущим WebKit за-
медлением загрузки заголовков, но, убрав шрифты с маленьких
экранов, мы обезопасили наиболее вероятную жертву — поль-
зователей мобильных устройств.
Рис. 4.5. С целью
повышения про-
изводительности
на устройства
с маленькими
экранами больше
не будут скачи-
ваться бесплат-
ные шрифты из
Интернета
ball
Плотностью
пикселов (pixel
density) называ-
ется количество
пикселов на ука-
занном простран-
стве. Например,
запись 326 ppi
означает, что на
дюйм приходится
326 пикселов.
Экраны с высоким разрешением
На случай, если вы решили, что замена изображений в зависи-
мости от размера экрана является совсем не сложным делом,
рассмотрим ситуацию, которая требует другого подхода: экраны
с высоким разрешением. Проблема возникала с появлением дис-
плеев Retina у смартфонов iPhone 4, а тот факт, что их поддержи-
вают iPad 3 и последние версии MacBook Pro, усугубляет ситуацию.
Дисплей Retina может похвастаться колоссальной плотностью
пикселов — 326 ppi (пикселов на дюйм). Для сравнения: у iPhone 3
этот параметр составляет всего 163 ppi. Такая плотность позво-
ляет получить удивительно детализированные и четкие изо-

ЭКРАНЫ С ВЫСОКИМ РАЗРЕШЕНИЕМ 133
бражения — если, конечно, они оптимизированы для данных
дисплеев. Без оптимизации они будут выглядеть зернистыми
и размытыми.
Изображения для устройств с высоким разрешением экрана
должны иметь большой размер, а значит, увеличатся и размеры
файлов. Именно тут и начинаются проблемы. Мы не хотим пере-
давать такие изображения на устройства, для которых они не
требуются. Но в настоящее время нет хорошего способа работы
с графикой, являющейся частью контента страницы. Этого мо-
мента мы уже касались при обсуждении загрузки изображений
в соответствии с шириной экрана.
В случае изображений CSS для всех браузеров, кроме работаю-
щих на движке WebKit, можно воспользоваться медиазапросом
min-resolution. А для браузеров WebKit нужно пользоваться
медиазапросом -webkit-min-device- pixel- ratio.
Медиазапрос -webkit-min-device-pixel-ratio принимает
десятичное значение, устанавливающее соотношение между
физическими и CSS-пикселами. Чтобы подготовить изображения
для iPhone, iPad или нового MacBook Pro, понадобится значение,
равное хотя бы 2.
Медиазапрос min-resolution принимает одно из двух значе-
ний — разрешение экрана в формате точек на дюйм или точек на
сантиметр. Для этого требуется немного математики, поэтому не-
которые из ранних реализаций получались несколько неаккурат-
ными. В результате я бы порекомендовал пользоваться новыми
единицами dppx, то есть количеством точек на пиксел. При этом
вы не только обойдетесь без дополнительных вычислений (все
автоматически подгоняется под соотношение, принимаемое ме-
диазапросом -webkit-min-device-pixel-ratio), но и избежите
старых неправильных реализаций. Поддерживаются эти новые
единицы измерения в настоящее время далеко не везде, но так
как отображение графики с качеством, приемлемым для дисплеев
Retina, является приятным усовершенствованием, а не жизненно
необходимой функцией, на это можно не обращать внимания:
1. header[role="bannerH] .inner {
2. background: url('../images/football_bg_lowres.png')
bottom right no-repeat;
3. } продолжение &

134 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
4. gmedia only screen and (-webkit-min-device-pixel-ratio: 2),
s. only screen and (min-resolution: 2dppx) {
6. header[го1е="Ьаппеги] .inner {
7. background: url('../images/football_bgjiighres.png')
bottom right no-repeat;
8. }
Этот медиазапрос отсылает нас к устройствам, соотношение
пикселов на которых составляет по крайней мере 2. Строки 1-3
задают фоновое изображение для низких разрешений. Строки 4
и 5 указывают, что нашей целью являются устройства с указан-
ным соотношением пикселов. Для них в строках 8-10 назначается
фоновое изображение с более высоким разрешением.
Язык SVG
Одним из вариантов решения, подходящего как к ситуации
с дисплеями высокого разрешения, так и к масштабированию
изображений в зависимости от размеров экрана, является язык
разметки SVG (от Scalable Vector Graphics — масштабируемая
векторная графика). Изображения SVG векторные, а их поведение
определяется кодом XML. Это дает возможность масштабировать
их, не увеличивая при этом размер файла. Кроме того, такие изо-
бражения допускают программное редактирование.
Замечательным примером улучшения внешнего вида при по-
мощи SVG является работа мобильной компании Yiibu из Эдин-
бурга, выполненная для Гринвичской королевской обсерватории.
Компания работала над адаптивным сайтом, частью которого
были изображения созвездий. И их требовалось уменьшить. Мас-
штабирование обычных изображений приводило к потере дета-
лизации на маленьких экранах. Воспользовавшись форматом SVG
и специальным алгоритмом масштабирования, специалисты из
Yiibu смогли подготовить детализированные изображения для
маленьких экранов (рис. 4.6).
На пути повсеместного применения формата SVG стоят две про-
блемы: его поддерживают не все браузеры и наблюдается недо-
статок инструментов. Explorer версии 8 и ниже этого формата не
понимает. Но, что куда важнее, его не распознает и встроенный
браузер Android 2.x — самая популярная версия для данной плат-
формы. Поддержка же формата в тех браузерах, которые могут
с ним работать, очень сильно различается по уровню и качеству.

ДРУГИЕ ЭЛЕМЕНТЫ ФИКСИРОВАННОЙ ШИРИНЫ 135
Рис. 4.6. Простое изменение размеров изображения
приводит к потере детализации {справа сверху); фор-
мат SVG и специальный алгоритм масштабирования
позволяют отредактировать изображения с сохране-
нием детализации. Особенно это касается читабель-
ности текста (справа снизу)
Самые популярные приложения для работы с графикой, та-
кие как Photoshop, не понимают формата SVG. Поэтому для
создания SVG-изображений вам придется поискать другой
инструмент.
Но со временем при условии развития соответствующих инстру-
ментов и браузеров изображения в формате SVG могут стать
обыденной частью инструментария веб-разработчика.
Другие элементы
фиксированной ширины
Изображения являются не единственными элементами, пред-
ставляющими проблему для адаптивных сайтов. Рассмотрим
еще два элемента — видеоклипы и баннеры.

136 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Рис. 4.7. К сожа-
лению, при атри-
бутах max-width:
100% и height: •
auto искажаются
пропорции встро-
енного видео
Видео
Вставка видео на страницу адаптивного сайта является несколько
более сложной процедурой, чем кажется на первый взгляд. Она
проста только для элемента HTML5 video. В этом случае можно
воспользоваться атрибутом max-width, при помощи которого
мы получали «резиновые» изображения:
1. video{
2. max-width: 100%;
3. height: auto;
4. }
Но большинство сайтов содержат видео со сторонних ресурсов
(например, YouTube или Vimeo), встраиваемое при помощи
контейнера iFrame. Результатом работы представленного ранее
фрагмента кода будет изменение ширины с сохранением высоты,
что приведет к искажению геометрических пропорций (рис. 4.7).
That guy has the ball
Ы what has to be considered a development of the utmost importance, that man over there
now has the ball.
By Ricfcy Boucher] January 1,2012
Lorem ipeum dolor sit amet, consectetur arHpiscing elit. Nullam tristique elit eget erat
placerat nonsasttis augue piharetra* Cras quam arcu» elementum <|uls tinddont $ed» interdum
Id elit Aenean ullamcorper bibendum odio a rutrum. Vestibuium ante ipsum primis in
faucibus ora luctus et ultrices posuere cubilia Curae; Donee at ullamcorper neque. Proin
Поэтому нам потребуется то, что Терри Кобленц (Thierry Koblentz)
назвал внутренними пропорциями1. Основная идея состоит в со-
хранении корректных пропорций контейнера, содержащего видео
Соответствующая статья находится на странице www.alistapart.com/articles/creating-
intrinsic-ratios-for-video/

ДРУГИЕ ЭЛЕМЕНТЫ ФИКСИРОВАННОЙ ШИРИНЫ 137
(4:3,16:9 и т. п.). После чего нужно сделать так, чтобы размер видео
совпал с размером контейнера. В этом случае изменение ширины
контейнера будет сопровождаться изменением пропорций видео.
Начнем мы с создания контейнера:
1. <div class="vid-wrapper">
2. <iframex/iframe>
з.
Затем нужно обеспечить ему корректное соотношение ши-
рины и высоты. В нашем случае оно составляет 16:9. Поскольку
для видео у нас применяется абсолютное позиционирование,
контейнеру требуются поля. Именно они позволят управлять
геометрическими размерами. Для поддержки пропорции 16:9
разделим 9 на 16 и получим 56,25 %:
1. .vid-wrapper{
2. width: 100%;
3. position: relative;
4. padding-bottom: 56.25%';
5. height: 0;
6. }
7. .vid-wrapper iframe{
8. position: absolute;
9. top: 0;
10. left: 0;
u. width: 100%;
12. height: 100%;
13. }
Эти стили обеспечивают абсолютное позиционирование видеоро-
лика внутри контейнера и задают высоту и ширину последнего как
100 %, что дает возможность его растяжения для заполнения всей
выделенной области (строки 11 и 12). При этом ширина самого
контейнера указывается как 100 % от ширины статьи (строка 2),
в результате он меняется при изменении размеров экрана.
Благодаря этим стилям мы получили видео, размеры которого
варьируются в зависимости от ширины экрана с сохранением
геометрических пропорций.
Улучшение интерфейса
На этом этапе, как обычно, имеет смысл оглянуться назад и по-
думать: нельзя ли внести какие-либо улучшения в интерфейс?

138 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
В настоящее время видео скачивается для всех устройств. Для
базового интерфейса это может быть не лучший вариант. Можно
увеличить скорость его загрузки, предоставив только ссылку на
видео. Встроенный же ролик будет появляться только на устрой-
ствах с более широкими экранами.
Начнем мы с простой ссылки:
<а id="video" href="http://www.youtube.com/watchPvsHwbE3bPvzr411>
Video highlights</a>
Можно добавить к ней набор стилей, чтобы гарантировать, что
ссылка не будет выделяться из остального контента:
1.
2.
3.
4.
5.
6.
7.
8.
9.
.vid{
display: block;
padding: .3em;
margin-bottom: lem;
background: url(../images/video.
padding-left: 35px;
border: lpx solid rgb(175,175,
color: #333;
>
png) 5px center no-repeat #e3e0d9;
175);
Мы не сделали ничего выдающегося. К ссылке были добавлены
поля и отступ, который выделяет ее из остального контента, а по-
том ей был сопоставлен фоновый рисунок со значком камеры
(рис. 4.8).
Рис. 4.8. Благо-
даря стилям
ссылка на видео
хорошо гармо-
нирует с осталь-
ным контентом
страницы
Теперь воспользуемся JavaScript для преобразования ссылки
в код для вставки.
Добавим к объекту Utils в файле yass.js следующую функцию:
1. getEmbed : function(url){
2, var output = '';
3, var youtubeUrl = url.match(/watch\?v=([a-zA-Z0-9\-J+)/);
4. var vimeoUrl = url.match(/Ahttp:\/\/(www\.)?vimeo\.com\/
(clip\:)?(\d+).*$/);

ДРУГИЕ ЭЛЕМЕНТЫ ФИКСИРОВАННОЙ ШИРИНЫ 139
5. if(youtubeUrl){
6. output = '<div class="vid-wrapper">
<ifrarne src="http://www.youtube.com/
embed/'+youtubeUrl[1]+'?rel=0M
f rameborder»"©11 allowf ullscreenx/if ramex/div>';
7. return output;
8. } else if(vimeoUrl){
9. output = '<div class="vid-wrapper">
<iframe src=tlhttp://player.vimeo.com/video/l+vimeoUrl[3]+IM
f rameborder=ll0" x/if ramex/div>';
10. return output;
n. }
12. }
Рассмотрим ее более подробно.
В качестве единственного параметра функция принимает
адрес URL видеоролика. Затем при помощи регулярных выраже-
ний в строках 4 и 5 она определяет, где именно находится ролик —
на YouTube или на Vimeo. В зависимости от типа адреса URL
создается разметка для встраивания, включающая контейнер,
которую функция и возвращает (строки 5-11).
Функция get Embed позволяет легко преобразовать ссылку на
видеоролик во встроенный видеофрагмент. Добавьте следующий
элемент JavaScript в проверку matchMedia (" (min-width: 37. 5em)"):
1. //загрузка встроенного видео
2. var videoLink = document.getElementById('video');
3. if (videoLink) {
4. var linkHref = videoLink.getAttribute('href');
5. var result = Utils.getEmbed(linkHref);
6. var parent = videoLink.parentNode;
7. parent.innerHTML ■ result + videoLink.parentNode.innerHTML;
8. parent.removeChild(document.getElementByld('video'));
9. }
Первые две строки берут ссылку на видео и ее атрибут href.
В строке 5 ссылка передается созданной нами функции getEmbed.
Результат ее выполнения в строках 6-8 вставляется в статью,
откуда убирается текстовая ссылка (рис. 4.9).
Теперь наше видео адаптивно и встраивается в страницу только
при ширине экрана, превышающей 37,5 em, гарантируя, что базо-
вому интерфейсу не придется прибегать к требующим изрядных
ресурсов HTTP-запросам.

140 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Рис. 4.9. На
больших экранах
(справа) видео
будет встраи-
ваться в страницу,
в то время как на
маленьких экра-
нах (слева) вместо
этого будет ото-
бражаться только
ссылка на ролик
Баннеры
Еще одним элементом фиксированного размера, с которым при-
ходится повозиться, являются баннеры. Нравится нам это или
нет, но для многих сетевых бизнесов это основной источник
дохода. Мы не будем сейчас сравнивать уровень прибыли от
баннерной и текстовой рекламы. Реальность в том, что для мно-
гих предприятий данная статья дохода имеет большое значение.
С технической точки зрения добавить баннер на адаптивный сайт
не особо сложно. Можно воспользоваться сценарием JavaScript
для условной загрузки рекламного баннера в зависимости от
размеров экрана. Разработчик из Нью-Йорка Роб Флаэрти (Rob
Flaherty) предложил базовый метод1:
1. // Конфигурация объявления
2. var ads = {
3. leaderboard: {
4. width: 728,
5. height: 90,
6. breakpoint: false,
1 Код со страницы www.ravelrumba.com/blog/responsive-dd-demos/

ДРУГИЕ ЭЛЕМЕНТЫ ФИКСИРОВАННОЙ ШИРИНЫ 141
7. url: '728x90.png1
8. Ь
9. rectangle: {
10. width: 300,
11. height: 250,
12. breakpoint: 728,
13. url: '300x250.png1
14. },
15. mobile: {
16. width: 300,
17. height: 50,
is. breakpoint: 500 ,
19. url: '300x50.png1
20. }
21. };
Здесь задаются три варианта баннеров (горизонтальный длин-
ный, прямоугольник средней величины и мобильный). Каждый
из них имеет ширину (строки 4, 10 и 16), высоту (строки 5, 11
и 17), адрес URL (строки 7, 13 и 19) и точку перехода, после
которой начинает загружаться (строки 6, 12 и 18). Определить,
какой баннер следует использовать в конкретной точке перехода,
поможет функция matchMedia.
Но лучше всего то, что мы можем сделать адаптивным сам баннер.
Код HTML и CSS позволят регулировать его параметры в зави-
симости от размеров экрана. При этом мы перестанем зависеть
от сценариев JavaScript и получим возможность воспользоваться
интерактивной природой баннера.
С технической точки зрения реализовать все перечисленное
несложно. Но проблема в том, что создание и отображение
баннера является сложным процессом. Большинство баннеров
поставляются сторонними сетями и отображаются в соответ-
ствии со спецификациями сайта. И в настоящее время ни одна
из рекламных сетей не работает с баннерами, размер которых
меняется в зависимости от размера экрана.
Размещение баннера непосредственно на сайте дает чуть боль-
шую свободу действий, но если он создан третьими лицами,
скорее всего, вам нужно быть готовым к объяснению своей
позиции. Авторы рекламных материалов могут не до конца по-
нимать, в чем, собственно, дело.
Кроме того, сейчас продажи баннеров во многом напоминают
работу с печатными материалами: оплата зависит от размера

142 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
и размещения объявления. Соответственно, непонятно, как
определить цену, если размер и положение баннера будут ме-
няться?
Можно продавать не одно объявление, а целую группу. Напри-
мер, вместо баннера формата «небоскреб» можно продавать
«основную группу» объявлений (можете придумать какое угодно
название). В группу могут входить «небоскреб» для экранов,
ширина которых превышает 900 пикселов, длинный баннер для
экранов шириной от 600 до 900 пикселов и маленький баннер
для экранов меньших размеров.
Очевидно, переход будет нелегким делом. Вам придется объяс-
нить рабочей группе, специалисту, ответственному за принятие
решений, и менеджеру по продажам, почему предложенный вами
подход является более осмысленным, чем покупка фиксирован-
ной рекламной площади. Разумеется, со временем решение этой
задачи упростится.
Также следует учесть наличие компаний, предпочитающих еди-
ный форм-фактор. Например, их работа может быть связана
только с мобильными устройствами, и поэтому рекламу они
готовят только для маленьких экранов. В этом случае от идеи
продажи группы баннеров придется отказаться.
В конечном счете мне бы хотелось, чтобы обсуждения адаптив-
ной рекламы привели к уменьшению ее количества и большей
цене одного баннера. Сайты, основой дохода которых является
баннерная реклама, зачастую перенасыщают свои страницы
объявлениями. Это сильно усложняет создание интерфейса для
маленьких экранов. Если вы их скроете, для рекламодателей
уменьшится количество просмотров. В противном случае по-
сетители сайта могут столкнуться со сплошной стеной баннеров.
Вместо загрузки страниц со все новыми и новыми баннерами
желательно уменьшать количество рекламы. Вместо десяти
рекламных мест стоимостью $1000 в месяц лучше предложить
три по цене $4000 за каждое. Рекламное место нужно превратить
в ценный ресурс. Выиграют от этого и рекламодатели, поскольку
при меньшем количестве объявлений проще привлечь внимание
к каждому из них, и посетители, процесс пребывания которых
на сайте станет более приятным.

подводя итоги 143
К сожалению, это проблема курицы и яйца. Цены на рекламу
в настоящее время стремительно уменьшаются. Объявления
конкурируют за количество щелчков по ним, поэтому выигры-
вает тот, кто может предложить самую низкую цену. И нужна
изрядная смелость, чтобы попытаться выйти из этого заколдо-
ванного круга.
Подводя итоги
Производительность является важной характеристикой лю-
бого сайта. Скачивание ненужных или слишком больших
изображений может негативно сказаться на времени загрузки
страницы.
Предлагаемое в качестве решения CSS-свойство display:none
в данном случае не помогает. Изображения перестают отобра-
жаться, но не перестают запрашиваться и скачиваться. Чтобы
графические фрагменты появлялись только после определенной
точки перехода, лучше воспользоваться условной загрузкой,
которая выполняется после загрузки страницы.
Проблема адаптивных изображений до сих пор не решена. Все
предлагаемые сейчас варианты имеют свои недостатки. Выбрать
оптимальный подход можно только в результате тщательного
рассмотрения требований конкретного проекта.
Чтобы изображения не просто перестали отображаться, но еще
и не скачивались, их следует вставить в медиазапрос. Если по-
местить его в базовые стили и затем попытаться скрыть, в боль-
шинстве случаев изображение будет скачиваться.
Дисплеи с высоким разрешением, такие как Retina у послед-
них версий iPhone, iPad и MacBook Pro, ставят вас перед оче-
редной проблемой. Решение существует для изображений на
основе CSS, для которых может применяться медиазапрос
min-resolution.
Беспокойство причиняют также видеоролики и баннерная ре-
клама. Внутренние пропорции дают возможность корректно
масштабировать видео на экранах различных размеров. В дан-
ном случае, как всегда, нужно следить за производительностью.

144 ГЛАВА 4. АДАПТИВНЫЕ ЭЛЕМЕНТЫ
Для пользователей лучше всего, если на маленьких экранах
вместо встроенного видеоролика будет только ведущая на него
ссылка.
В случае баннерной рекламы решить технические проблемы
совсем несложно. При загрузке объявлений из собственной си-
стемы сценарии JavaScript, а также адаптивный HTML и CSS-код
помогут адаптировать баннеры к различным разрешениям. На-
много сложнее переубедить отделы продаж сторонних рекламных
сетей в необходимости нового подхода.

Глава 5
Планирование
Подготовка — это ключ к успеху.
Александр Грэхем Белл

146 ГЛАВА 5. ПЛАНИРОВАНИЕ
Теперь, когда вы познакомились с основными аспектами «рези-
новых» макетов, медиазапросов и адаптивных элементов, можно
оглянуться назад и посмотреть, как адаптивность дизайна влияет
на остальные процессы, начиная с планирования. Подготови-
тельный этап крайне важен вне зависимости от того, чем вы
собираетесь заняться — вступить в бой, пробежать марафон или
создать адаптивный сайт. Последнее означает, что вам придется
принять во внимание целую экосистему устройств. Без должной
подготовки вы многое упустите из виду, и итоговое качество ва-
шего сайта оставит желать лучшего. Вам требуется четкий план.
Это вовсе не означает, что вы будете его придерживаться от
начала до конца. В столь стремительно меняющейся среде, как
Интернет, вам обязательно придется столкнуться с множеством
препятствий. Это и появление новых платформ и устройств,
и изменение сроков сдачи проекта, и пересмотр приоритетов.
Поэтому важно не только наличие плана, но и умение быть
гибким и подстраиваться под конкретную ситуацию. Готовьтесь
к любым неожиданностям.
Выбор в пользу адаптивности
В 1997 году в процессе первого пузыря доткомов фирма IBM вы-
пустила рекламный ролик, в котором два бизнесмена сидели за
столом для совещаний. Один читал газету, а второй работал на
компьютере. Первый заметил: «Тут написано, что за Интернетом
будущее в деле бизнеса. Мы должны выйти в Интернет».
Второй оторвался от компьютера и спросил: «Зачем?»
После короткой паузы первый ответил: «Здесь не написано».
Эта юмористическая реклама хорошо демонстрирует ситуацию
с множеством веб-проектов: технология опережает стратегию.
Фирмы слепо цепляются за модные слова, сходят с ума по со-
циальным сетям или недавно появившимся платформам, не
задумываясь, зачем им это нужно.
Приступая к реализации любого адаптивного проекта, первым
делом следует понять, имеет ли вообще смысл ваше начинание.
Или вы просто решили, что это модно и круто?

ФАКТОРЫ, КОТОРЫЕ НУЖНО УЧЕСТЬ 147
Факторы, которые
нужно учесть
Итак, нужен ли вам адаптивный сайт? На этот вопрос существует
короткий и скучный ответ: зависит от обстоятельств. Перед тем
как принять окончательное решение, рассмотрите следующие
факторы:
• производительность;
• контекст;
• контент сайта;
• временные рамки;
• поддержку;
• рекламу.
Если какой-то из этих факторов является для вас преградой,
имеет смысл сделать выбор в пользу обычного, неадаптивного
сайта. Посмотрим на каждый из них более внимательно.
Производительность
Производительность является важной частью пользовательского
опыта. И то, что имеет смысл с точки зрения производитель-
ности на одном устройстве или в одной сети, может оказаться
совершенно неприемлемым в других условиях.
Рассмотрим, к примеру, процедуру оптимизации производитель-
ности для мобильных сетей. В случае проводного соединения
стили и сценарии имеет смысл хранить в отдельных файлах. Это
позволяет кэшировать их, а значит, пользователь избавляется
от необходимости скачивать их снова и снова. Но для устройств,
работающих в мобильных сетях, такой подход может стать при-
чиной резкого падения производительности. Мобильные сети,
в отличие от обычных, имеют большую задержку и урезанную
полосу пропускания. А значит, для создания мобильного сайта
желательно встраивать стили и сценарии в страницу, чтобы
уменьшить количество запросов.
Некоторые механизмы замены изображений на странице в за-
висимости от параметров просмотра заставляют пользователей
Примечание
Если сайт создает-
ся целенаправлен-
но для мобильных
устройств, это не
означает, что лая
него невозможен
и не требует-
ся адаптивный
дизайн. Можно
и нужно пользо-
ваться гибкостью,
которую дают ме-
диазапросы. Более
подробно об этом
пишет Том Маслен
в соответствую-
щем разделе этой

148 ГЛАВА 5. ПЛАНИРОВАНИЕ
скачивать несколько версий картинки, несмотря на то что ему
требуется всего одна. Если вы решите скрыть часть контента от
пользователей, просматривающих сайт с устройства с небольшим
экраном, браузер все равно скачает для него соответствующие
разметку и CSS. Недостаток аккуратности при проектировании
сайта увеличивает его размер и замедляет его работу. Избежать
этих скользких моментов вполне реально путем тщательного
планирования, но это непростая задача, поэтому многие ею
пренебрегают.
Контекст
Интерфейс сайта нужно выбирать в зависимости от контекста.
Для разных задач и разных сред используются разные устройства.
И реализация, к примеру, для смартфона будет отличаться от
реализации для настольного компьютера.
Скажем, социальная сеть с геопозиционированием Foursquare
может взаимодействовать с пользователем в зависимости от того,
с какого устройства он в нее зашел. В то же время новостной
сайт всегда выглядит одинаково, так как его интерфейс никак
не связан с контекстом.
Сайт, рекламирующий различные мероприятия, может восполь-
зоваться сведениями о местоположении пользователя. Если вы
обнаружите, что пользователь в день концерта зашел на сайт,
находясь неподалеку от места проведения мероприятия, вы
можете оптимизировать контент, предоставив уточняющую
информацию, неактуальную для тех, кто просто раздумывает,
не посетить ли ему этот концерт.
Контент сайта
Имеет смысл реконструировать некоторые сайты и изменить
их структуру. Предположим, страница состоит из большого
основного столбца и боковой панели. При уменьшении ширины
экрана боковой столбец опустится вниз, а это далеко не всегда
именно то, что вам нужно. Зачастую его содержимое важнее
расположенного в нижней части основного раздела. Без пере-
планировки иерархия информации будет потеряна (рис. 5.1).

ФАКТОРЫ, КОТОРЫЕ НУЖНО УЧЕСТЬ 149
Рис. 5.1. На больших экранах кнопка скачивания фреймворка
YAML отображается сверху справа, в то время как при уменьше-
нии ширины экрана она уходит вниз и исчезает из видимости
Временные рамки
Адаптивный подход, как правило, требует больших времен-
ных затрат, и это неудивительно. Ведь приходится учиты-
вать множество устройств с разными характеристиками, что
занимает изрядное время. Нужно оценить существующие
устройства, понять, какие стандарты они поддерживают
и каким образом их пользователи могут взаимодействовать
с контентом вашего сайта. Все это добавляет переменных
в уравнение, которое вам требуется решить.
Но потраченное на этом этапе время позволит сократить
временные затраты в будущем, ведь вам придется зани-
маться поддержкой всего одного сайта, а не целого набора.
Таким образом, потери на этапе конструирования компен-
сируются уменьшением затрат на поддержку.
Разумеется, если пуск сайта должен состояться через месяц,
вряд ли имеет смысл включать в план адаптивный подход.

150 ГЛАВА 5. ПЛАНИРОВАНИЕ
На спокойное обдумывание и проектирование качественного
сайта требуется немалое время.
Поддержка
Построение адаптивного сайта на основе версии для обычных
компьютеров до сих пор встречается довольно часто и становится
причиной проблем при просмотре сайта с мобильных устройств.
Современные браузеры WebKit поддерживают медиазапросы,
чем многие другие популярные браузеры похвастаться не могут.
В итоге мобильные устройства отображают сайты, сконструиро-
ванные «сверху вниз», в виде версии для настольных компьюте-
ров, если, конечно, вообще в состоянии что-то отобразить.
Если же вы проштудировали материалы, посвященные про-
грессивному улучшению, и предпочли подход, диаметрально
противоположный описанному ранее, подобных проблем можно
избежать. Начинайте с написания кода для обладающего мини-
мальными возможностями браузера и постепенно совершен-
ствуйте его при помощи медиазапросов.
Именно этот подход позволяет обратить себе на пользу обще-
доступность Интернета. Кроме того, нет никаких гарантий, что
новые популярные у пользователей устройства будут обладать
большими возможностями, чем аппаратура, массово использу-
ющаяся сейчас.
Реклама
Проблема вставки рекламных материалов на адаптивные сайты
выходит за рамки чисто технических ограничений. Существует
огромный разрыв между тем, как устроена современная реклам-
ная индустрия, и тем, что может потребоваться в этой области
завтра. Приходится объяснять как клиентам, так и агентствам,
каким образом создаются объявления, размер которых подстра-
ивается под параметры устройства.
С технической точки зрения важно также предоставить рекламо-
дателям возможность не отображать их баннеры при некоторых
разрешениях. К примеру, рекламодатель может решить, что его
продукт лучше всего продается при размещении баннеров ис-

СТАТИСТИЧЕСКИЕ ДАННЫЕ 151
ключительно на сайтах для мобильных устройств. В обсужде-
нии этой темы Джейсон Григсби (Jason Grigsby)1 выразился так:
«Выбор сегмента рынка является частью рекламной политики».
Решение проблем, связанных с продажей и производством ре-
кламы для адаптивных сайтов, является очень важным шагом,
так как рекламодатели могут получить существенную выгоду от
размещения правильно подобранных баннеров на таких ресурсах.
Ведь большой баннер на обычной, неадаптивной странице просто
потеряется при ее просмотре на маленьком экране. Адаптивный
подход гарантирует оптимизацию баннеров для всех возможных
разрешений.
Заключение
Несмотря на ограничения современного инструментария и мен-
талитета, не следует игнорировать потенциал адаптивного ди-
зайна. При тщательной проработке в сочетании с корректными
методами он может стать отправной точкой для множества сай-
тов. Просто помните, что сама по себе адаптивность не должна
становиться целью. Адаптивный подход является большим
фрагментом мозаики, но это только фрагмент.
Если же вы решили, что именно адаптивный дизайн лучше всего
подходит для вашего проекта, следует понять, каким способом
вы будете его реализовывать. Это не элемент декора, который
можно добавить в самом конце. Продумать придется весь про-
цесс конструирования сайта.
Статистические данные
35 миллионов устройств, позволяющих выйти в Интернет, ис-
ключают возможность индивидуальной оптимизации. Поэтому
первым делом нужно определить наиболее важные устройства
в контексте вашего проекта. С расчетом на них будет конструи-
роваться сайт, но при этом желательно оптимизировать его и для
максимального количества остальных устройств.
www.cloudfour.com

152 ГЛАВА 5. ПЛАНИРОВАНИЕ
Рис. 5.2. Устрой-
ства обладают
самыми разными
размерами
и формами, что
влияет на способ
конструирования
сайта
Одним из преимуществ адаптивного дизайна является незави-
симость компоновки от устройства, но это не означает, что при
этом на устройство можно не обращать внимания, — все ровно
наоборот. Ведь существует разница в возможностях, ограни-
чениях и потенциальном применении устройств. Поддержка
зависит от платформы. Существуют различные типы сетей, что
влияет на производительность. Интерфейс пользователя прихо-
дится регулировать в зависимости от типа устройства (рис. 5.2).
Определить, под какие устройства и форм-факторы следует оп-
тимизировать сайт, можно только при наличии сведений о том,
какие устройства чаще всего применяются для просмотра вашего
сайта и каковы их возможности. Именно на этой информации
базируется выбор устройств для тестирования и функций, ко-
торые будут разрабатываться для различных платформ.
Тщательно проанализируйте собранные сведения и обратите
внимание на то, какими устройствами пользуются посетители.
Оцените поведение посетителей. Например, может оказаться,
что определенные устройства фигурируют в статистике как наи-
более часто используемые, но при этом их владельцы проводят
на сайте совсем мало времени. Возможно, для них требуется
доработка интерфейса.

СТАТИСТИЧЕСКИЕ ДАННЫЕ 153
Затем сравните эту информацию с данными об удельном весе
товара в обороте рынка. И если трафик для какого-либо попу-
лярного у пользователей устройства окажется крайне низким,
возможно, в интерфейсе вашего сайта чего-то не хватает.
Хотелось бы вас предостеречь. Делая заключения на основе ста-
тистических данных, нужно учитывать все возможные факторы.
Восприятие разных устройств программами для сбора стати-
стики может очень сильно различаться, что вызовет перекосы
в ту или иную сторону.
Перекос в статистических данных
Многие сервисы сбора статистики, в том числе популярный
Google Analytics, используют в качестве средства слежения код
JavaScript, который передает данные о посетителях и использу-
емых ими устройствах для дальнейшей обработки. Но, к сожа-
лению, при этом можно упустить изрядный сегмент аудитории
сайта.
Многие мобильные устройства не имеют поддержки JavaScript.
В основном это относится к обычным мобильным телефонам, но
и более продвинутые смартфоны тоже частенько попадают в эту
категорию. Например, в ряде устройств BlackBerry поддержка
JavaScript по умолчанию отключена. Зачастую пользователи даже
не догадываются, что ее можно включить, а значит, они будут
заходить на ваш сайт, никак не отображаясь в статистике.
Кроме того, различается и уровень поддержки JavaScript на
разных устройствах. Неполная поддержка означает, что вы не
можете гарантировать ни попадания данных о пользователе
в статистику, ни полной корректности этих данных.
Альтернативой JavaScript являются внедряемые в страницу изо-
бражения. Используются они и сервисом Google Analytics и пред-
ставляют собой фрагменты кода на стороне сервера, создающие
на странице элемент img. Его атрибут src отправляет в Google
данные о посетителе и используемом им устройстве.
Но использование кода на стороне сервера имеет ряд серьезных
минусов. Без настройки предоставляемого по умолчанию фраг-
мента кода вы теряете вспомогательную информацию о версии

154 ГЛАВА 5. ПЛАНИРОВАНИЕ
Примечание
Хотите получить
лучшее от обоих
вариантов сбора
статистики? Поду-
майте о возможно-
сти переключения
между ними на
стороне сервера.
Более подробно
мы поговорим
об этом в главе 8
при обсуждении
технологии RESS.
установленного у посетителя проигрывателя Flash, разрешении
экрана и уровне поддержки JavaScript. Исчезает возможность
отслеживания событий и наблюдения за исходящими ссылками.
Зато вы получаете более полную картину относительно устройств
и браузеров, используемых для доступа к вашему сайту. Данные
о самых популярных устройствах и браузерах, скорее всего, не
будут особо отличаться от информации, полученной анализа-
тором на базе JavaScript, а вот расхождения в других элементах
списков могут оказаться весьма значительными. Многочислен-
ность способов доступа к сайту может вас изрядно удивить.
Ну и, наконец, опасайтесь сбывшихся прогнозов. Если оптими-
зация сайта под различные платформы и браузеры не была вы-
полнена, не стоит удивляться тому, что часть трафика окажется
крайне низкой. Растение, которое не поливают, засыхает.
Какая статистика имеет значение
После рассмотрения статистических данных, касающихся вашего
сайта, важно изучить общие тенденции рынка. Если окажется,
что довольно популярные платформа или браузер в ваших
данных практически не появляются, вполне может оказаться,
что интерфейс сайта для них неудобен и просто отпугивает
посетителей.
Чтобы понять, на какие устройства вам следует в первую очередь
ориентироваться, рассмотрим различные системы показателей.
Не существует ни одной системы сбора статистики, позволяю-
щей управлять ими одновременно и связать их друг с другом.
В блоге Джейсона Григсби есть прекрасная статья1 для всех, кто
хочет понять, какую статистику имеет смысл принимать в рас-
чет. В статье говорится о мобильной статистике, но эти советы
хорошо подходят и к планированию адаптивного сайта. Веб-
разработчикам Григсби рекомендует обратить особое внимание
на три вида показателей:
• сведениях о мобильных устройствах. Эта статистика по-
казывает, какие устройства и браузеры используются для
1 www.cloudfour.com/a-comprehensive-guide-to-mobile-statistics/

СТАТИСТИЧЕСКИЕ ДАННЫЕ 155
доступа к Интернету. Ее важность трудно переоценить.
Если 5 млн человек приобрели устройство определенного
типа, но не пользуются им для доступа в Интернет, вряд
ли имеет смысл оптимизировать сайт под это устройство,
несмотря на всю его популярность;
• демографических исследованиях. Данная информа-
ция помогает определить, каким образом используются
устройства. Люди различного возраста, с разным обра-
зованием и уровнем дохода могут пользоваться устрой-
ствами по-разному. Понимание их поведения гарантирует
не только функционирование вашего сайта на конкретном
устройстве, но и его соответствие нуждам целевой ауди-
тории;
• статистике использования устройств. Эти данные по-
казывают, какое количество проданных устройств при-
меняется по назначению. Важно использовать их в ком-
плексе с двумя упомянутыми ранее типами показателей.
Попытайтесь определить, какие устройства из целевого
сегмента вашего рынка применяются по назначению чаще
всего.
Поскольку адаптивный подход не ограничивается удовлетво-
рением нужд мобильных пользователей, эти показатели нужно
рассматривать для самого широкого спектра оснащенных брау-
зером устройств. Конкретные цифры можно найти на различных
сайтах.
Данные о доле на рынке
Данные о доле товара на рынке по ряду причин также могут быть
не совсем точными. Это может быть связано как со способом
сбора информации, так и с поведением определенных платформ.
В качестве примера можно рассмотреть устройства BlackBerry.
Их интернет-трафик идет через прокси-серверы RIM, находя-
щиеся в Канаде. В результате при просмотре IP-адресов все
пользующиеся этими устройствами посетители отображаются
как пребывающие на территории Канады. Это часто приводит
к занижению доли устройств BlackBerry на рынке американского
трафика.

156 ГЛАВА 5. ПЛАНИРОВАНИЕ
Том Маслен
БОЛЬШИЕ ОЖИДАНИЯ МАЛЕНЬКИХ СМАРТФОНОВ
Том Маслен (Тот Maslen) является старшим разработчиком из команды
ВВС News и отвечает за разработку клиентской стороны новостной
страницы rn.bbcco.uk/news. После создания мобильной версии ново-
стей ВВС с интерфейсом, адаптированным под все типы мобильных
телефонов и планшетов, его команда приступила к работе над
адаптивной версией уже для обычных компьютеров. Маслен специ-
ализируется на JavaScript, уделяя большое внимание производитель-
ности браузеров и доступности соответствующих стандартам
веб-страниц. В свободное время он разводит морских свинок, является
большим поклонником компьютерной игры Skyrim и многолетним фанатом футбольного клуба
«Тоттенхэм Хотспур».
Мобильные телефоны давно стали неотъем-
лемой частью нашей жизни, а увеличение
количества смартфонов влияет на способ
доступа пользователей к интернет-версии
новостей ВВС. Раньше у нас существовали
довольно примитивный мобильный сайт для
устройств с ограниченными возможностями
и полная версия для настольных компьютеров.
Но оказалось, что все большее количество
пользователей используют смартфоны для
доступа к полной версии. Это однозначно ука-
зывало на неудовлетворенность посетителей
мобильной версией сайта.
Также стало ясно, что мобильные пользова-
тели хотели видеть больше информации и, что
самое главное, получали ее, хотя навигация по
полной версии сайта требовала от владельцев
устройств с сенсорными экранами множества
действий по масштабированию и прокрутке.
Сначала нам казалось, что для удовлетворе-
ния нужд пользователей имеет смысл созда-
вать уникальные веб-приложения для каждой
комбинации ширины экрана устройства, типа
взаимодействия, скорости соединения и мощ-
ности процессора. Якоб Нильсен (Jakob Nielsen)
совершенно правильно указал на различие
в нуждах пользователей разных устройств1.
Но реализация такой стратегии на практике
требовала слишком больших средств: даже
компания Google была вынуждена признать,
что не может себе этого позволить2.
Поэтому постулат Нильсена о необходимости
разработки отдельных вариантов дизайна для
мобильной и обычной версий сайта был отвер-
гнут. Мы знали, что адаптивный дизайн позво-
лит нам получить решение, включающее в себя
как базовый интерфейс для недостаточно функ-
циональных браузеров, так и усовершенство-
ванные версии, сложность которых зависит от
возможностей устройства и размеров экрана.
Адаптивный интерфейс должен был быть по
крайней мере сравнимым по качеству с тем,
который получали пользователи обычных ком-
пьютеров. Это означало и быструю загрузку
страниц, и возможность применения жестов,
и современную айимацию. Первый прототип
такого сайта появился весной 2011 года.
Но в дополнение к созданию современного
интерфейса для пользователей смартфонов
хотелось сохранить также аудиторию, заходя-
щую на сайт с обычных телефонов. Ведь в мире
существует немало рынков, на которых послед-
ние все еще занимают лидирующие позиции.
Наш прототип показал, что адаптивный под-
ход позволяет как эффективно предоставить
упрощенную версию для телефонов с огра-
www.useit.com/alertbox/fnobile-vs-lull-sites.htm!
2 Слайд 35 презентации со страницы www.slideshare.
net/commuter|oy/responsive-design-bbccouk-8687366

СТАТИСТИЧЕСКИЕ ДАННЫЕ 157
ничейными возможностями, так и усовершен-
ствовать базовый интерфейс для смартфонов.
Для этого широко применяют тестирование
возможностей клиентского устройства и уже
по его результатам решают, нужно ли загружать
интерфейс, отличный от базового.
АДАПТИВНЫЕ МОБИЛЬНЫЕ ВЕРСИИ
В марте 2012 года мы возобновили работу
над интерфейсом для мобильных телефонов.
В процессе построения нового сайта в соот-
ветствии с принципами адаптивного дизайна
стало понятно, что базовым кодом можно
воспользоваться для доставки новостей всем
пользователям мобильных устройств, планше-
тов и обычных компьютеров1.
Наличие двух базовых кодов — одного для
обычных компьютеров, второго для всего
остального — не очень соответствовало идее
адаптивного подхода, да и, по сути, не имело
к ней отношения. К сожалению, большая часть
контента сайта ВВС News не отображается на
маленьких экранах. Команда разработчиков
потратила весь следующий год на внесение
в рабочий процесс изменений, которые позво-
лили бы преобразовать различные типы кон-
тента в функционирующий в рамках адаптив-
ного дизайна формат.
Например, результаты работы команды ВВС
News Specials рассчитаны на использование
графики. Интерактивные дизайнеры сотруд-
ничают с журналистами для создания таких
замечательных материалов, как, скажем, «Сап
you build a human body?»2. Но на маленьких
экранах все это великолепие просто не ото-
бражается.
Мы активно работаем над решением подобных
задач, но до завершения этой работы вам при-
дется пользоваться старыми добрыми браузе-
рами для настольных компьютеров.
1 ВВС News, раздел Mobile site на странице http://
rn.bbcco.uk/news
2 Его можно посмотреть на странице www.bbc.co.uk/
news/health-17235058
РЕАКЦИЯ НА ОБРАТНУЮ СВЯЗЬ
Мнения аудитории по поводу новой версии
мобильного сайта вполне ожидаемо оказались
полярными. Пользователи смартфонов поло-
жительно отреагировали на новый дизайн, в то
время как владельцам более старых устройств
новая компоновка по большей части не понра-
вилась.
Интересны были и данные анализа посещае-
мости. Количество посетителей радикально не
изменилось, а вот число просмотров страниц
поползло вниз, то есть пользователь за один
визит заходил на меньшее количество стра-
ниц. В определенном смысле именно этого
и ожидали. Главная страница новой версии
предлагала намного больше информации, чем
раньше. Именно поэтому при практически не
изменившемся трафике посетителей на сайт
сократилось количество просмотров других
разделов. Мы поставили своей приоритет-
ной задачей усовершенствование системы
навигации, что и было сделано спустя месяц
после запуска проекта, и количество заходов
в такие разделы, как, к примеру, Technology and
Business, снова возросло.
Пользователи устройств с горизонтальной
ориентацией экранов жаловались на слишком
громоздкие графические элементы, которые
в верхней части страницы разворачивались на
весь экран. За две недели мы добавили в макет
еще одну точку перехода. Это был медиазапрос
для устройств с шириной экрана от 480 до
640 пикселов, проверяющий наличие горизон-
тальной ориентации. В результате изображения
стали масштабироваться до 50 % от ширины
экрана и прижиматься клевому краю, а сопро-
водительный текст оказывался справа от них.
Поскольку все больше материалов нашего
сайта выходит на базе адаптивного дизайна,
ожидается, что скоро новая версия сайта
сможет конкурировать с традиционной. По
мере появления все новых и новых устройств
доступа в Интернет постепенно начнет раз-
мываться разница между «мобильным Интер-
нетом» и «Интернетом», а адаптивный дизайн
станет промышленным стандартом.

158 ГЛАВА 5. ПЛАНИРОВАНИЕ
Контент сайта
Мы все попадали в подобную ситуацию: поступает заказ на ди-
зайн или, что еще хуже, просят написать разметку и код CSS, не
давая никакой информации о наполнении сайта. А ведь именно
содержимое является основой большинства сайтов. Именно ради
него люди в первый раз оказываются на сайте. И совершенно
непонятно, почему контент долго считался второстепенным
аспектом большинства проектов.
С точки зрения дизайнера, работа над сайтом без знакомства
с его контентом невозможна. Ведь создание дизайна не сводится
к выбору симпатичной цветовой гаммы и скругленных уголков.
Дизайн добавляет смысловую нагрузку. Он помогает рассказать
историю представляемых с его помощью данных. А как расска-
зать историю, которой ты еще не знаешь?
Разумеется, иногда тянет начать работу над макетом и сопут-
ствующими задачами до окончательной подготовки контента.
Но такой подход заранее обречен на провал. Контент текущего
проекта следует самым тщательным образом учитывать с са-
мого начала работы. Поэтому, если он еще не полностью готов,
попытайтесь понять, какие типы контента вам предстоит под-
держивать и каким образом их следует распределить.
Дизайнеры и разработчики должны получать информацию на
всем протяжении проекта, чтобы не возникало ситуаций, когда
в последний момент нужно срочно менять структуру разметки
или переделывать дизайн для вставки неожиданно появившегося
дополнительного контента.
Для адаптивных сайтов понимание структуры и иерархии кон-
тента становится задачей первостепенной важности. В процессе
настройки дизайна под различные разрешения недостаточно
просто уменьшать количество столбцов для просмотра на ма-
леньких экранах. Часто приходится решать, не поменять ли сам
способ отображения контента.
Скажем, при отображении на большом экране новостного сайта
имеет смысл показывать заголовки, описания и иллюстрации
к 10 последним статьям. При уменьшении экрана желательно
сократить их количество, например, до пяти. Для совсем ма-

КОНТЕНТ САЙТА 159
леньких экранов лучше всего, наверное, оставить только список,
состоящий из пяти заголовков.
Знание типов и структуры контента, который будет отображаться
на странице, облегчает принятие подобных решений. В процессе
корректировки дизайна вы сможете определить, что нужно
оставить, что допустимо выкинуть, а чему поставить высокий
приоритет.
На этой стадии вы уже должны знать ответы на следующие во-
просы.
• Какова целевая аудитория проекта?
• Какой контент доступен на данный момент?
• Как упростить имеющийся контент и уменьшить его
объем?
• Какова основная идея проекта?
• Имеется ли контент, диссонирующий с основной идеей?
• Какую иерархию имеет контент?
Ответить на эти вопросы помогут такие отчетные материалы,
как аудит контента и таблицы страниц.
Аудит контента
В конце концов вы должны получить представление обо всем
имеющемся контенте. Это делается путем аудита контента, то есть
его оценки или инвентаризации. Данная операция преследует
множество целей. Во-первых, появляется информация о струк-
туре, расположении и поддержке каждой страницы сайта. Во-
вторых, обнаруживаются проблемы: вы видите, чего не хватает
и что следует добавить по мере развития проекта. Ну и, наконец,
аудит является прекрасным помощником при переносе контента.
Он дает вам карту движения со старого сайта на новый, избавляя
от необходимости действовать наугад, которая часто возникает
в процессе перехода к новому дизайну или другой CMS.
В процессе аудита нужно просмотреть весь сайт, страница за
страницей, записывая данные о каждом фрагменте контента
в электронную таблицу. Именно к ней можно обратиться в бу-
дущем, если возникнет необходимость вспомнить, кто поддер-

160 ГЛАВА 5. ПЛАНИРОВАНИЕ
живает определенную страницу или где должен располагаться
определенный контент.
'""*Г™/'' 1'
Рис. 5.3. Аудит
контента уточняет
структуру и рас-
положение стра-
ниц сайта, а также
соображения
касательно их
поддержки. Коли-
чество столб-
цов в таблице
варьируется
в зависимости
от потребностей
конкретного
проекта
Существует множество шаблонов для аудита, но мне больше всего
нравится вариант, предложенный в 2002 году Джефри Вином
(Jeffrey Veen)1. Таблица (рис. 5.3) очень проста и не имеет ничего
лишнего. Она содержит следующие столбцы:
• Page ID — уникальный идентификатор страницы;
• Page Name — заголовок страницы;
• Link — адрес URL страницы;
• Document type — шаблоны, которые используются на
странице;
• Topics, keywords — тема страницы и связанные с ней клю-
чевые слова;
• Owner/Maintainer — лицо, ответственное за наполнение
страницы;
• ROT — обозначение избыточного, устаревшего или ни-
чтожного контента. Используется для страниц, которые
не следует переносить на новый сайт;
• Notes — любые дополнительные комментарии по поводу
страницы. Они могут указывать на битые ссылки или
проблемы с HTML-кодом, а также просто содержать на-
поминания на будущее.
Подобная тщательная ревизия позволяет составить впечатление
о качестве содержания сайта. Это облегчает расстановку при-
оритетов и в некоторых случаях органично приводит к решению
о сжатии или полном удалении страницы. Если ее контент не
вносит вклада в основное сообщение и не представляет ценности
для посетителей, зачем он вообще оказался на сайте?
www.adaptivepath.comAideas/doing-content-inventory.

КОНТЕНТ САЙТА 161
Хэни Свои
АДАПТИВНЫЙ ДИЗАЙН И ДОСТУПНОСТЬ
Хэни Свои (Непу Swan) — специалист по доступности данных
и занимается в основном видео по запросу и мобильными систе-
мами. В настоящее время работает в ВВС над проектом iPlayer
и занимается написанием стандартов и руководст в по мобильной
доступности. С ее деятельностью можно ознакомиться в Твиттере @iheni и в блоге www.
iheni.com.
Адаптивный сайт является, наверное, одним
из самых эффективных способов увеличения
доступности контента для самых разных
пользователей. Единый базовый код с хоро-
шей структурой, альтернативами, метками
и редакторскими правками, построенный
в соответствии с принципом прогрессив-
ного улучшения, является большим шагом
в сторону совместимости с любыми устрой-
ствами. Но это далеко не универсальное
решение. Хорошо функционирующие на
обычных компьютерах вещи могут потре-
бовать доработки при попытке отобразить
их на планшете или мобильном устройстве.
А значит, важно понимать, где располага-
ются точки перехода, то есть в какой момент
(в зависимости от устройства) доступность
пропадает.
важным компонентом доступных сайтов
является их структура. Правильное приме-
нение заголовков, меток WAI-ARIA (стандарта
доступности активных интернет-приложе-
ний), разбиения текста на абзацы и списков,
во-первых, позволяет сгруппировать реле-
вантную информацию способом, понятным
для сопутствующих технологий, таких как
программы чтения с экрана и голосового
ввода, во-вторых, обеспечивает навига-
цию по странице. Контент, состоящий из
пяти заголовков Н2 с абзацем текста под
каждым из них, для мобильных устройств
имеет смысл трансформировать в список из
пяти ссылок. Навигация из шести элементов
для обычных компьютеров при переходе
к мобильной версии может превратиться
в выпадающее меню. Также мобильные
устройства избавились от необходимости
навигационных пометок. Более того, сохра-
нив заголовки Н2 и пометки, вы перегру-
зите экраны пользователей, прибегающих
к устройствам для чтения, избыточными
деталями.
Мы часто интересуемся качеством под-
держки WAI-ARIA или HTML5 на различных
устройствах, в то время как на НТМ 4 также
следует обратить пристальное внимание.
Привычные нам методы написания кода
могут не поддерживаться мобильными
устройствами. Запись tabindex^-Г пре-
красно работает на обычных компьютерах,
но ее не поддерживают мобильные брау-
зеры. Не распознаются и псевдокласс hover,
теги title, abbr и span.
Но несмотря на эти ограничения, адаптив-
ный дизайн остается самым эффективным
способом предоставления информации
самым широким категориям пользователей.
Корректное применение медиазапросов
позволяет отрегулировать контент таким
образом, что способ доступа к нему или
метод просмотра перестают иметь значение.

162 ГЛАВА 5. ПЛАНИРОВАНИЕ
В случае создания адаптивных проектов аудит контента позво-
ляет выделить одинаковые черты страниц, а значит, определить
типы контента и правила его редактирования при изменении
разрешения.
Таблицы страниц
После знакомства с контентом приходит время тщательно изу-
чить его структуру. До некоторой степени с этим могут помочь
структурные схемы, но они обычно показывают небольшой на-
бор страниц сайта. Также по ним нельзя понять, каким способом
будет поддерживаться контент и в чем состоит основная идея
каждой страницы. Устранить эти пробелы поможет таблица
страницы.
Эти таблицы, которые иногда называют шаблонами контента,
предлагают детальное исследование данных на постраничной
основе. Они содержат сведения о контенте страницы, ее клю-
чевом посыле и способе поддержки. Пример такой таблицы
показан на рис. 5.4.
Обратите внимание на невысокую точность такой таблицы. Это
сделано, чтобы не возникало заблуждений по поводу ее неизмен-
ности. Такие таблицы создаются и редактируются буквально на
коленке.
С их помощью упрощается процедура получения данных от
других участников проекта и клиентов, так как таблица точно
показывает, какой контент требуется и какой посыл он должен
нести. Подобный способ представления информации позволяет
сфокусировать общее внимание на одной странице и обозначить
зону ответственности каждого участника рабочего процесса.
Наличие данных об иерархии контента страницы крайне важно,
особенно в адаптивном дизайне. Ведь в процессе подгонки макета
под параметры различных устройств нужно все время держать
в уме данный аспект.
Существует еще ряд мер, гарантирующих качество контента. Мы
еще вернемся к данной теме в главе 7, но для получения более
подробной информации желательно обратиться к специализи-
рованным изданиям, например «Контентная стратегия управ-

ВЫБОР УСТРОЙСТВ 163
ления сайтом» Кристины Халворсон или «Основы контентной
стратегии» Эрин Киссейн.
About Yet Another Sports Site
Pag» otfactlv»: Provide Information about who, and what, Yet Another Sports
«to is.
Scop»: И scope
Pageftte
About Yet Another Sport» S*e
Msssaoe: We «re your one stop
destination for «portt related new»
Provide some pjenoral Information about
what information teavefebie on Yet
Another Sport* Ste. at wel м whet
sports ere covered.
Let of sports covered Includes:
Provide some general information «bout
what formation is avatebte on Yet
Another Sports Sfte, as we! as what
«ports are covered.
Unk» to etfitoria) staff member bin».
information about advert»*? wMh Yet
Another Sport» Sfte.
Footer and standard Inks.
from to current print-ba
Maintenance! Should be reviewed every 8 months to make sure ttiat the Infbrniation Is
up to date
Неявнее on IWrd part**: None.
Рис. 5.4.
Таблицы страниц
дают информа-
цию о структуре
и предназна-
чении каждой
страницы, помо-
гая выбрать
способы компо-
новки контента
при разных
разрешениях
Выбор устройств
Вооруженные информацией о наполнении будущего сайта и его
целевой аудитории, мы можем приступить к выбору средств его
представления. Разумеется, имеет смысл сделать сайт как можно
более доступным, но все-таки нужно решить, для каких плат-
форм, устройств и возможностей мы будем его оптимизировать.
В этом нам поможет статистика сайта.
Это вовсе не значит, что мы должны стремиться к наименьшему
общему знаменателю или работать только с наиболее функцио-

164 ГЛАВА 5. ПЛАНИРОВАНИЕ
нальными устройствами. Нет, наша задача — создать сайт, ко-
торый будет работать с широким спектром устройств наиболее
подходящим для их возможностей и форм-факторов образом.
Оптимизирован для некоторых,
доступен для многих
Определить чаще всего используемые для доступа на наш сайт
устройства и платформы крайне важно, но еще важнее помнить,
что мы не сможем учесть все фигурирующие в этом списке вари-
анты. Невозможно оптимизировать сайт для всех устройств, но
нужно стремиться к созданию максимально доступного контента.
Брэд Фрост (Brad Frost), разработчик из нью-йоркского реклам-
ного агентства R/GA, рассматривает эту разницу в своем блоге1:
Просто требуется быть более внимательным и предоставить
людям, которые хотят воспользоваться вашим сайтом, функци-
ональный интерфейс. Для этого нужно отказаться от привычных
представлений о поддержке и принятии во внимание различных
вариантов работы с сайтом. Существуют способы поддержки
меньшего числа платформ с одновременной оптимизацией для
лучших из лучших.
Для этого вам нужно очень тщательно подойти к использованию
особенностей обработки контента браузерами, все время помня о
прогрессивном улучшении. От вас никто не требует одного и того
же макета и интерфейса для всех браузеров и устройств, да это и
невозможно. Ничего страшного, если интерфейс на более старых
устройствах будет иметь ряд недостатков. Главное, чтобы он со-
хранил свою функциональность. Именно в этом состоит разница
между оптимизацией под устройство и поддержкой устройства.
Интерфейс для
различных устройств
Сколько устройств в день вы используете? Большинство даст
один и тот же ответ: несколько. И часто для решения одной
http://bradfrostweb.com/blog/mobHe/support-vs-optimization/

ИНТЕРФЕЙС ДЛЯ РАЗЛИЧНЫХ УСТРОЙСТВ 165
и той же задачи. Согласно опубликованным компанией Yahoo!
результатам исследования, 59 % пользователей заходят на сайт
сначала с мобильного устройства, а потом с обычного ком-
пьютера. Обратный порядок действий демонстрировали 34 %
пользователей1. По мере появления у человека дополнительной
аппаратуры для выхода в Интернет переход от одного устройства
к другому становится реальностью, отмахнуться от которой уже
вряд ли получится.
Когда Мадхаву Энроса (Madhava Enros) из компании Mozilla
спросили, какой интерфейс ему нравится, он сказал, что мобиль-
ных устройств слишком много для однозначного ответа (рис. 5.5):
Одним из моих любимых устройств является Kindle. Мне нра-
вится его аппаратная часть, но Amazon, кажется, пока не по-
нимает функционального многообразия мобильных устройств.
Арсенал одного пользователя не ограничивается телефоном.
Дома он читает с электронной книги, а в поезде применяет для
этой цели смартфон Android или достает планшет iPad. Поэтому
большим шагом вперед будет согласованное представление дан-
ных на разных устройствах.
Эту идею можно преподнести и в другом ключе: работа с Сетью
представляет собой совокупность пользовательских опытов.
Отдельный опыт работы пользователя с вашим сайтом должен
быть обособлен, но набор таких опытов обязан нести единые
черты для формирования некоего общего знаменателя.
Отсюда следует множество требований, но элементарным явля-
ется требование единообразия: интерфейс одного устройства
должен быть знаком всем, кто изначально попал на ваш сайт
при помощи любого другого устройства. Пользователь должен
обнаружить знакомую навигацию и не ощущать нехватки от-
дельных фрагментов контента.
Идею согласованного интерфейса следует держать в уме с самого
начала. Продумайте, каким образом он может меняться в зави-
симости от размеров и функциональности устройств, и что вы
можете сделать, чтобы гарантировать его единообразие.
Данные со страницы http://advertising.yahoo.com/article/the-role-of-mobile-devices-in-shopping-
process.html

166 ГЛАВА 5. ПЛАНИРОВАНИЕ
Рис. 5.5. Устрой-
ства Kindle
синхронизируют
ваши заметки,
выделенные
фрагменты
и закладки,
поэтому на
любом из них
вы можете
вернуться
к прерванному
занятию
Ipmg was
gey with bunting, and everybody wss m gala
diifsv. Whit Monday had beets looked forward to
for a month ot more. By the afternoon ewr» those
who bfhnved in the Dnwen w«e b«gmumg to
fashion on tiif, кищчмАюг. that he had quite gurii*
ewe'/, «nd wrth ihe srepttcs he was already a jest
Hut р€ч»рк«,, sceptics and bdwwrs alike, wetc
retnarfcabt? soaablt» чИ that day.
Haysmaii's roeadow was gay with a tent, in
wbi>"h Mn*- Bunting And other ladies were
piepwrmg tea, white, without, the Sufitky-sch&oi
пишу guidance of dw curate and fte Misses Cus^
an»i Sackbyf. No Uotibt Ihcrt- wns. a slight
!Ш«здШ1С'нн at the шг, buf ррцЛ* foi №t* hi^b! pai?
had tbfc «■?««■ tci n.inr«a! whalfv^r imagsnafiv*1
qualms they experienced. On the village gteen aa
a p«lk«y-swuftg handle, orw couid be hurlt-d
I()«M* " UfMt «id ttfdiqgK ftw ft*
«:rL:;^;:;:,;:Lu:t:;
(h 4 oil ii, whin, M i- tt.i.mm,
tit 1 , » II, >W » « <• < *
and bars <»f bis own hmty;, >m«i
Jailers w;n ivirtg к1ш!«'нл1 in
thf js;irl«Hir of tht> ''CiMi'h iiwA
зш! woif»n ilwn snwller, nvwt
was tfav 'AJih hnnttne,, .did
<ЛЧМ\1инК «4,4 ii) Й-()Д dfCS.S
Whit Moiidav Idh! Ihw1, luukvi
lorward to lor ;i immtl* uf
теку Ih (Jir jil'fei'au'Hi «'\nt
thus** who be*!!tivi><} iti the
Постепенно все четче вырисовывается бессмысленность разде-
ления Сети на мобильный Интернет, Интернет для настольных
компьютеров и т. п. Следует понять и принять, что это единая
среда, различаться может только способ и контекст доступа
к ней. В результате может варьироваться как дизайн, так и до
определенной степени контент. Но пользователи ожидают, что
взаимодействие с этой средой будет организовано единообразно

ИСПЫТАТЕЛЬНЫЙ СТЕНД 167
вне зависимости от того, каким устройством они пользуются
в конкретный момент.
Испытательный стенд
Разумеется, вы должны тестировать результаты своего нелегкого
труда, начиная с момента получения задания (на эту тему мы под-
робно поговорим в следующей главе). Именно тут начинаются
основные сложности. Как получить нужное количество устройств
и браузеров, не попав в долговую яму?
В первую очередь давайте вспомним о разнице между оптими-
зацией и поддержкой. Невозможно протестировать сайт на всех
существующих в природе устройствах. Поэтому следует выбрать
основные варианты и сфокусироваться на них.
Существуют разные возможности тестирования:
• реальные устройства;
• эмуляторы;
• сторонние сервисы.
Реальные устройства
Проще всего протестировать свой сайт в реальном браузере,
запущенном на реальном устройстве. В этом случае вы сможете
получить однозначное представление о том, как ваш сайт зависит
от таких факторов, как производительность, сеть, форм-фактор
и функциональность. Это невозможно узнать, просто поменяв
размер окна браузера или прибегнув к эмулятору. Чтобы по-
чувствовать все нюансы пользования вашим сайтом, нужно
оказаться на месте реального пользователя.
Выйдите из офиса с его высокоскоростным Интернетом. Вос-
пользуйтесь более медленным Wi-Fi-соединением. Подсоедини-
тесь к мобильной сети. Попробуйте зайти на свой сайт, стоя на
шумной автобусной остановке. Ведь далеко не все пользователи
бродят по Интернету, сидя в удобном кресле и пользуясь широ-
кополосным доступом.
Тестирование с максимальным приближением к реальным усло-
виям является самым лучшим методом. К сожалению, устройств
для доступа в Интернет великое множество, и далеко не все они

168 ГЛАВА 5. ПЛАНИРОВАНИЕ
стоят дешево. Приобретать их, конечно, нужно, но не проделы-
вая дыру в собственном кармане. Как же выбрать устройства,
которые имеет смысл покупать?
Ответ зависит от конкретной ситуации. В своей статье «Стратегия
выбора тестовых устройств»1 Стефани Ригер (Stephanie Rieger)
выделяет пять критериев:
• существующий трафик;
• региональный трафик и рынок;
• факторы, связанные с устройствами;
• факторы, связанные с проектом;
• бюджет.
Имеет смысл подробно рассмотреть каждый из них и его влияние
на ваше решение.
СУЩЕСТВУЮЩИЙ ТРАФИК
Здесь мы снова осознаем ценность статистики сайта. Чтобы
определить, какие устройства вам нужно приобрести, для начала
имеет смысл просмотреть список устройств, используемых для
доступа к вашему сайту. Обращайте внимание также на плат-
форму и версии устройств. В итоге вы легко составите список
возможных приобретений.
РЕГИОНАЛЬНЫЙ ТРАФИК И РЫНОК
Принимая решение о группах устройств и точках перехода,
нельзя полагаться только на статистические данные. Нужно
учесть и такой фактор, как доминирующие в вашем регионе
устройства и платформы. Сравните их список с имеющейся у вас
статистикой и обратите внимание на то, в каких местах списки
перекрываются, а где есть пробелы.
ФАКТОРЫ, СВЯЗАННЫЕ С УСТРОЙСТВАМИ
Наличие у экспериментального стенда различных платформ
является важным, но не достаточным условием успешного тести-
рования. Рассматривать нужно также различные форм-факторы,
размеры и функциональность. Одна и та же платформа будет
по-разному работать на высокотехнологичных устройствах,
http://stephanierieger.com/strategies-for-choosing-test-devices/

ИСПЫТАТЕЛЬНЫЙ СТЕНД 169
устройствах среднего звена и устройствах с ограниченными
возможностями. Проектирование сайта зависит также от до-
ступных методов ввода (рис. 5.6). Убедитесь в наличии всех
перечисленных факторов.
Рис. 5.6. Несмо-
тря на воз-
растающую
популярность
сенсорных
экранов, многие
устройства, в том
числе теле-
фоны BlackBerry,
используют для
ввода данных
шаровой манипу-
лятор или обыч-
ную клавиатуру
ФАКТОРЫ, СВЯЗАННЫЕ С ПРОЕКТОМ
Рассмотрите функции, требуемые проектом или способные при-
нести выгоду. В своей статье Ригер использует в качестве примера
геопозиционирование. Наличие на сайте многочисленных служб,
связанных с местоположением пользователя, требует устройств
с поддержкой данной функции. Кроме того, тестирование нужно
будет выполнить и на более примитивных, не поддерживающих
геопозиционирование устройствах, чтобы проработать резервные
варианты.
БЮДЖЕТ
Если вы не миллионер, бюджет на покупку устройств для тести-
рования у вас, скорее всего, ограничен. Просматривайте предло-
жения на распродажах. Нет ничего страшного в покупке устрой-
ства, уже побывавшего в чьем-то пользовании, или более старой
модели. Большинство пользователей вряд ли будут владельцами
последних технических новинок. Зачастую как раз старые модели
более реалистично воспроизводят аудиторию вашего сайта.
Не забывайте сравнивать цены. Телефоны и планшеты стоят
недешево, но регулярно просматривая предложения на таких
сайтах, как Avito.ru или eBay, можно совершить совершенно

170 ГЛАВА 5. ПЛАНИРОВАНИЕ
фантастические покупки, пополнив свою коллекцию тестовых
устройств замечательными экземплярами. Но слишком эко-
номить тоже не следует. Здброво иметь под рукой множество
дешевых не новых устройств с ограниченными возможностями,
но в вашем арсенале должны быть не только они.
Попробуйте зайти в компьютерный магазин и объяснить, что вам
нужно. Вполне возможно, вам предоставят устройства, на кото-
рых вы за несколько минут сможете протестировать свой сайт.
Опросите коллег в офисе. Проведенный среди 30 сотрудников
нашей компании опрос выявил поразительное разнообразие
имеющихся в наличии устройств. Возможно, источник аппара-
туры для экспериментального стенда находится у вас под носом.
ПРОВЕРКА В БРАУЗЕРАХ
Следующим шагом после получения доступа к набору устройств
будет поиск всех возможных браузеров для них. Многие устрой-
ства умеют работать с несколькими браузерами. Установите их все.
Это касается и настольного компьютера. Скачайте Safari, Chrome,
Firefox, Internet Explorer и Opera и установите их. По возможности
используйте различные версии, чтобы тестирование не огра-
ничивалось самыми новыми и функциональными браузерами.
Примечание
Более подробно
познакомиться
с различными
эмуляторами
можно на стра-
нице http://www.
mobilexweb.com/
emulators или
в книге Максими-
лиано Фиртмана
«Mobile Emulators
& Simulators: The
Ultimate Guide».
Эмуляторы
Эмуляторы далеко не совершенны. Обычно они требуют мно-
жества средств разработки, а значит, для их хранения нужно
много места. Эмуляторы не позволяют почувствовать, как будет
взаимодействовать с сайтом реальное устройство. По сути это
порты ввода-вывода браузера или операционной системы.
Впрочем, тестирование при помощи эмулятора лучше, чем
полное отсутствие тестирования. При отсутствии под рукой
реальных устройств это вполне приемлемый вариант.
Сторонние сервисы
Такие сторонние сервисы, как PerfectoMobile (www.perfectomobile.
com) и DeviceAnywhere (www.keynotedeviceanywhere.com), обладают
множеством доступных устройств, и вы можете посмотреть, как

ИСПЫТАТЕЛЬНЫЙ СТЕНД 171
Adobe Shadow
Большое количество устройств для тестирования—это замеча-
тельно, но вам предстоит вручную загружать свой сайт на каждое
из них, чтобы понять, как он отображается и как себя ведет. Это
уже менее заманчивая перспектива, поэтому предлагаю вам
воспользоваться инструментом Adobe Shadow.
Этот инструмент позволяет оптимизировать процедуру тестиро-
вания на реальных устройствах. Скачайте его на свой компью-
тер и установите в виде дополнения к браузеру Chrome. Затем
установите соответствующий инструмент Adobe Shadow на все
свои устройства (на момент написания книги поддерживались
только Android и iOS).
После этого останется воспользоваться приложением Adobe
Shadow для соединения устройств с компьютером (провода
в данном случае не требуются). В результате страница, открытая
в браузере Chrome, будет отображаться на всех присоединенных
устройствах.
А теперь предположим, что у вас есть десять различных устройств,
соединенных с основным компьютером через приложение Adobe
Shadow. При переходе в браузере Chrome на следующую стра-
ницу сайта все присоединенные устройства также перейдут по
указанному адресу URL В результате вы сэкономите довольно
много времени, так как теперь достаточно просмотреть все
страницы сайта на настольном компьютере.
Данный инструмент также умеет:
• делать снимки экрана любого из присоединенных устройств;
• делать снимки экрана одновременно всех устройств через
расширение Chrome;
• удаленно исследовать структуру HTML, CSS и DOM на при-
соединенных устройствах;
• контролировать кэш любого из присоединенных устройств.
Кажется, приложение Shadow скоро обречено стать незамени-
мым инструментом для веб-разработчиков.

172 ГЛАВА 5. ПЛАНИРОВАНИЕ
на них будет визуализироваться ваш сайт. Но стоимость их услуг
может оказаться изрядной, поэтому пользуйтесь ими аккуратно.
Несмотря на более точные по сравнению с полученными на
эмуляторах результаты тестирования, из-за своей цены эти
сервисы становятся крайним средством. Если бюджет позволяет,
начните с тестов на реальных устройствах, пробелы в результатах
заполните при помощи эмуляторов, а к сторонним сервисам об-
ращайтесь только в случае крайней необходимости.
Подводя итоги
Адаптивный дизайн является мощной техникой, в этом нет ника-
ких сомнений. Но, к сожалению, это не панацея. Выжать из своего
сайта максимум можно только путем больших временных затрат
и тщательного планирования. А значит, проектирование адап-
тивного дизайна должно начинаться уже на стадии подготовки.
Изучайте статистические данные, но помните, что они могут
оказаться не совсем достоверными. Внимательно отнеситесь
к контенту сайта. Даже если к моменту начала проектирования
и разработки он не совсем готов, вы должны полностью пред-
ставлять себе его структуру.
Продумайте интерфейс для различных устройств. Ведь пользова-
тели будут заходить на ваш сайт разными способами. При этом
они захотят увидеть знакомый интерфейс, оптимизированный
под их нужды.
Ну и, наконец, по возможности тестируйте свой сайт на реаль-
ных устройствах. Эта идея может показаться слегка пугающей,
но создание тестового комплекса не должно ввести вас в зна-
чительные расходы. Потратьте время, чтобы определить, какие
устройства приносят максимальную выгоду вашему проекту,
следите за предложениями о продаже, и постепенно у вас со-
берется замечательный набор для тестирования.
В следующей главе мы поговорим о том, как адаптивность
проекта влияет на весь рабочий процесс — от способа функ-
ционирования рабочей группы до методов конструирования
и построения сайтов.

ftteг
Ж*»^i ir/1 * ч Ш!.-Иф'ЩШШЩ
:~ at., -•
*"V
Глава б
Процесс
проектирования
Наша «эпоха постоянных тревог» по большей
части возникла из-за попыток решать
современные задачи при помощи устаревших
инструментов и устаревших концепций.
Маршалл Маклюэн

174 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Когда бросаешь камень в воду, раздается плеск, а потом по воде
идут круги. Небольшая точка приложения силы приводит к да-
леко идущим последствиям. Если представить современный
рабочий процесс как воду, адаптивный дизайн будет играть в нем
роль камня. Единственное изменение вызывает волны, влияющие
на способ нашей работы с Интернетом.
Технология меняется. Она развивается и взрослеет. Появляются
возможности решения новых задач. При этом мы тоже должны
меняться. Наши инструменты и техники и даже процесс мышле-
ния — все должно развиваться, чтобы идти в ногу со временем.
Влияние новых технологий на процесс проектирования огромно.
Оно может выбить нас из колеи, так как приходится смиряться
с фактом несовершенства многих привычных практик. Рабочий
процесс нужно сделать более гибким. Следует отбросить старые
способы работы и поискать более совершенные способы управ-
ления этой невероятной средой.
В этой главе мы обсудим следующие темы.
• Интерактивная природа Сети и ее влияние на рабочий
процесс.
• Почему проектирование нужно начинать с версии для
мобильных устройств.
• Преимущества разработки в браузере.
• Инструменты и техники, в частности каркасы, эскизы
и руководства стилей.
На вкус и цвет
Дэн Браун в своей книге «Communicating Design»1 написал заме-
чательные строки: «Тот, кто говорит об однозначности процедуры
создания дизайна, никогда не пытался зарабатывать этим себе на
жизнь». Процесс конструирования не наука, а искусство. Правил
в нем не так уж и много. Различаются требования клиентов, рамки
проектов, работа команд. И оптимальный метод работы каждый
ищет для себя в рамках конкретного проекта.
1 Второе издание, выпущено издательством New Riders в 2010 году.

НА ВКУС И ЦВЕТ 175
Результаты работы и этапы проекта определяются такими фак-
торами, как размер команды, бюджет, квалификация дизайнеров
и разработчиков, сроки сдачи.
Помните, что отдельные этапы процесса не так важны, как со-
блюдение следующих ключевых концепций.
• Сеть интерактивна. Это должно отражаться на выборе
инструментов и конечном результате.
• Работа должна быть совместной.
• Сайт рассматривается как система, а не как совокупность
страниц.
Интерактивная среда
Пора прекращать работать с Интернетом как со статичной средой.
Он таковым не является. Он гибок. Он непредсказуем. Попытка
загнать его в жесткие рамки с фиксированным конечным резуль-
татом не даст максимально раскрыть его потенциал. В итоге нам
ставятся различные ограничения там, где их на самом деле нет.
Современный подход к сетевому дизайну родственен подходу
к дизайну полиграфических материалов. При разработке сайта
используются в основном те же самые инструменты, что и при
разработке плаката. Но печатная продукция не интерактивна,
в отличие от сайтов в Сети. Посетители не просто рассматривают
сайт, а взаимодействуют с ним. Они щелкают на ссылках. Наво-
дят указатель мыши на разные элементы. Касаются сенсорного
экрана пальцем. Интернет представляет собой живой, дышащий
холст, которым они могут манипулировать по своему желанию.
Сайт в Интернете намного ближе к программе, чем к печатной
продукции. А значит, наши инструменты, техники и полученные
с их помощью результаты должны лучше отражать динамическую
природу Сети.
Сотрудничество
Долгое время рабочий процесс создания сайтов был по большей
части линейным. Дизайнер создавал дизайн и после одобрения
пересылал один или два макета разработчику. К сожалению, при

176 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
этом порой терялось изрядное количество информации. Такие
компоненты, как сообщения об ошибке, состояния при наведении
указателя мыши, открывающиеся и закрывающиеся элементы
навигации, при передаче проекта из рук в руки могут остаться
вне фокуса внимания.
При разработке адаптивного проекта фокусироваться прихо-
дится на огромном количестве разных устройств, а значит, рабо-
чий процесс в обязательном порядке становится намного более
опосредованным. Вы должны не только быть осведомленными
о способах возможного взаимодействия пользователей с сайтом,
но и предугадывать его реакцию на различные размеры, функ-
циональность устройств и методы ввода. Невозможно ожидать,
что дизайнер предвосхитит все тонкости, а разработчик под-
строится под все варианты взаимодействий способом, на 100 %
совпадающим с оригинальным видением дизайнера. А значит,
требуется более тесное сотрудничество.
Итан Маркотт (Ethan Marcotte) обсуждает это в своей книге
«Responsive Web Design»1:
Адаптивные проекты, в которых мне приходилось принимать
участие, достигали больших успехов благодаря объединению
стадий дизайна и разработки в одну большую стадию и превра-
щению двух рабочих групп в один коллектив.
Такой гибридный подход имеет смысл. Разработчики и дизайнеры
получают возможность обсуждать поведение страниц при их раз-
личных размерах и в процессе взаимодействия. Вместе они могут
выявить неочевидные варианты взаимодействия и компоненты,
а также принять решение о способах подстройки под различные
устройства и методы ввода.
Сотрудничество позволяет снизить количество неучтенных
аспектов. При создании дизайна в статистических программах
обычно рассматривается некий идеальный сценарий, а рабочий
процесс предполагает организацию в его рамках наилучшей
поддержки и функциональности. В случае сотрудничества раз-
работчик может указать на другие вероятные сценарии. Что
произойдет при поддержке сенсорных экранов? Как действовать
при отсутствии геопозиционирования? Именно совместная ра-
1 Маркотт И. «Отзывчивый веб-дизайн» (Манн, Иванов и Фербер, 2012).

НА ВКУС И ЦВЕТ 177
бота увеличивает вероятность появления дизайна и для таких
сценариев тоже.
Аналогичные преимущества получает разработчик. Ведь из-
начально он, как правило, не имеет полного представления
о видении дизайнера и может не понимать, почему был выбран
тот или иной вариант визуальной эстетики. Именно тесное со-
трудничество с дизайнером позволяет сохранить исходную идею.
Когда в сценарии возникает нечто не укладывающееся в рамки
первоначального дизайна, дизайнер с разработчиком могут найти
решение, не нарушающее целостности.
Совместный рабочий процесс порой приводит к инновациям.
Как при ударе камнем о камень, столкновение двух различных
точек зрения может зажечь искру идеи. Мы решаем проблемы,
исходя из предшествующего опыта, а значит, решения ограни-
чены известными нам вещами. Объединяя людей в команду, вы
расширяете доступный диапазон опыта, а значит, увеличиваете
вероятность качественного решения возникающих в процессе
работы проблем.
Успешное внедрение совместной работы требует взаимодействия,
периодического повторения некоторых этапов и уважения к ре-
зультатам чужой деятельности.
ВЗАИМОДЕЙСТВИЕ
Дизайнеры и разработчики должны присутствовать уже на самых
первых рабочих совещаниях. Именно это дает возможность полу-
чить от их деятельности максимум. Дизайнеры при этом могут
убедиться, что их исходное видение остается согласованным
на всех страницах и во время всех итераций. Разработчикам
же становятся видны потенциальные слабые места до момента
возникновения серьезных проблем.
Вместо простой раздачи заданий при этом вырабатывается
стратегия сотрудничества.
На собраниях с участием как дизайнеров, так и разработчиков
сайт рассматривается с точки зрения приложения к максимально
возможному количеству устройств. Это привлечет внимание
к возможным недостаткам дизайна и даст ключ к дополнительной
оптимизации интерфейса под конкретные устройства.

178 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Во время этих собраний имеет смысл рассматривать следующие
вопросы.
• Достаточен ли размер активных точек для сенсорного
экрана?
• При каких размерах экрана появляются признаки растя-
жения макета?
• Насколько удобным является взаимодействие с динами-
ческими элементами страницы?
• Улучшит ли дизайн добавление очередной точки перехода?
• Можно ли улучшить интерфейс для конкретного устрой-
ства?
• Какие небольшие усовершенствования могут обеспечить
поддержку более широкого диапазона устройств?
ПОВТОРЕНИЕ
Ответив на данные вопросы, вы начинаете цикл итераций. Вы
корректируете дизайн, подстраиваясь под изменения, а затем оце-
ниваете результат и повторяете эту процедуру. В идеале двигаться
вперед нужно маленькими шажками. Коренным образом что-то
менять не следует. Это упростит тонкую настройку интерфейса
и позволит избежать слишком общего, доминирующего взгляда
на этот аспект.
Может показаться, что такой подход требует изрядного времени.
И это действительно так. Но именно он позволяет гарантировать
на выходе качественный продукт, доставляющий удовольствие
пользователям.
Вам нужно погрузиться в среду, для которой вы создаете сайт.
Наше знание характеристик и особенностей доступных устройств
ограничено. Попытки предугадать проблемы с макетом при
масштабировании сайта и его взаимодействии с конкретным
устройством являются проигрышной стратегией.
УВАЖЕНИЕ
Разумеется, сотрудничество будет обречено на провал при недо-
статке взаимоуважения работающих над проектом дизайнеров
и разработчиков.

НА ВКУС И ЦВЕТ 179
Брэд Фрост
ПРОДВИЖЕНИЕ АДАПТИВНОГО ДИЗАЙНА
Брэд Фрост (Brad Frost) является разработчиком мобильных стра-
тегий и дизайнером интерфейсов в нью-йоркском рекламном агент-
стве R/GA. Он основал сайт Mobile Web Best Practices, направленный на
помощь в создании интерфейсов мобильных и адаптивных сайтов.
Также он является куратором проекта WTF Mobile Web, который на
примерах учит, как не нужно работать с мобильным Интернетом.
Как страстный поклонник мобильного Интернета, Брэд обожает писать об этом в Твиттере
и в блоге и вести обсуждения на данную тему.
Клиента нужно заранее приучать к особенно-
стям адаптивного дизайна, так как реализация
адаптивности влияет на процесс работы, вре-
менные рамки, бюджет и в итоге на конечный
продукт. Важно быть честным и показывать
как проблемы, так и возможности адаптивного
дизайна. После подобных объяснений клиенты
охотнее осуществляют инвестиции в проект
и гарантируют, что все будет сделано корректно.
Стоит убедить того, кто на самом деле прини-
мает решение, как остальной процесс проходит
практически гладко.
Я обнаружил, что самых лучших результатов
достигают путем демонстрации. Всего несколько
иллюстраций позволяют мне показать возрас-
тающую сложность Сети, с которой невозможно
не считаться. Примеры описывают адаптив-
ный дизайн намного доходчивей любых слов.
Одним из моих любимых приемов является
превращение пары страниц уже имеющегося у
клиента сайта в адаптивные. Разумеется, это не
тот способ, которым нужно пользоваться при
создании новых сайтов, но понять концепцию
адаптивного макета он помогает очень хорошо.
Клиентам часто бывает сложно отойти от сте-
реотипного мышления («но ведь сайт нашей
фирмы не газета!»), и это простенькое упражне-
ние помогает сфокусироваться на возможностях
адаптивного дизайна.
На выбор страниц для преобразования влияет
ряд факторов, и одним из них является простота
реализации. Разумеется, никто не будет выби-
рать самую сложно организованную страницу
сайта для иллюстрации концепции адаптивно-
сти. Наиболее подходящими для этого являются
страницы с высокими показателями посещения
с мобильных устройств. Также мне нравится
показывать, что адаптивность не ограничи-
вается одной только настройкой интерфейса,
поэтому я задействую страницы, на которые
можно вставить карусельный дизайн, чтобы
сделать их более привлекательными. При этом
многое сводится к искусству презентации, что
означает демонстрацию сайта на реальных
устройствах, но я обнаружил, что начинать
имеет смысл с обычного изменения размеров
окна браузера, чтобы клиент понял концепцию
уже на этом этапе.
Иногда адаптивный подход не является опти-
мальным. Некоторым проектам нужнее доступ
к API камеры. Некоторые маленькие сайты
создаются всего на пару недель. А некоторые
клиенты предоставляют свою продукцию мил-
лионерам и поэтому могут позволить написание
специализированного приложения для iPhone.
Но даже если проект не является адаптивным,
я всегда задаю важные вопросы о мобильной
совместимости. Каким образом видеоклипы
будут обрабатываться мобильными устрой-
ствами? Какой размер должны иметь страницы?
Что, если устройство не поддерживает данный
шрифт?
Наличие мобильных устройств следует как
минимум принять во внимание, а лучше всего
создать для них полностью оптимизированный
и адаптивный интерфейс.

180 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Устойчивый информационный обмен до определенного предела
спасает ситуацию. Работая бок о бок, дизайнеры и разработчики
смогут лучше понять проблемы, которые приходится решать
другой стороне.
Данной осведомленности оказывается более чем достаточно. Как
оказалось, сложно относиться с уважением к вещам, которых не
понимаешь. Если вы дизайнер, время, потраченное на получение
представлений об основах программирования, позволит вам
лучше понять суть деятельности разработчика. А разработчи-
ков знакомство с основами дизайна избавляет от иллюзии, что
дизайн сводится к подбору симпатичных цветов и шрифтов.
СОТРУДНИЧЕСТВО С КЛИЕНТОМ
Сотрудничество не должно ограничиваться рамками коллек-
тива — его нужно распространить и на взаимодействие с кли-
ентами. Клиента нужно вовлечь в работу на ранних стадиях
и сделать частью общего процесса. Типичная при линейной
разработке ситуация, когда дизайнеры и разработчики представ-
ляют клиенту на одобрение созданное ими решение, а дальше
в игру вступает менталитет «мы против них». Клиент требует
изменений, обозначая таким образом свое участие в проекте,
а дизайнеры и разработчики хотят всеми силами отстоять ре-
зультаты своего труда и начинают сопротивляться поступившим
предложениям.
В то же время с самого начала вовлеченный в рабочий процесс
клиент чувствует себя членом команды. Обе стороны имеют
шанс услышать друг друга, а принятые решения содержат вклад
каждой из сторон.
Сотрудничество разработчиков с клиентом дает обеим сторонам
также фантастический учебно-педагогический опыт. Команда
дизайнеров знакомится с уникальными требованиями и огра-
ничениями, с которыми приходится иметь дело клиенту. Они
могут быть связаны, например, с особенностями унаследованных
систем или с политикой компании. Клиент же узнает, каким об-
разом принимаются решения по поводу дизайна и поддержки.
Участвуя в планерках, он имеет шанс понять, почему дизайн сайта
меняется в зависимости от устройства и браузера.

СНАЧАЛА МОБИЛЬНЫЕ 181
Системное мышление
Вспомним материал из предыдущей главы, касающийся интер-
фейса, работающего на различных устройствах. Во главу угла
при этом ставился принцип согласованности. Согласованными
должны быть не только все страницы сайта, но и его вид на раз-
личных устройствах.
Для обеспечения подобной согласованности следует отойти от
восприятия сайта как совокупности страниц. Теперь его нужно
воспринимать в терминах систем и их компонентов: заголовков,
нижних колонтитулов, навигации и т. п. Это позволит нам от-
делить компоненты от страниц и рассмотреть их работу с точки
зрения общего интерфейса сайта.
Данный подход никогда не был так важен, как сейчас. Сайты
должны работать в большем количестве браузеров и на большем
количестве устройств, чем когда бы то ни было. Рассмотрение
того, как отдельные компоненты функционируют в различных
средах и как они объединяются друг с другом в общий интерфейс,
является существенным компонентом успеха любого адаптив-
ного проекта.
Кроме того, такой подход к производству дизайна помогает
увеличить согласованность и производительность. Исчезает
необходимость снова и снова изобретать велосипед: постепенно
у вас накопится целая библиотека дизайнерских приемов, до-
ступных для повторного применения в аналогичных ситуациях.
Сначала мобильные
Как уже упоминалось, увеличивающаяся фрагментация перевер-
нула рабочий процесс с ног на голову. И теперь мы призываем
начинать работу с проектирования для мобильных устройств.
Родоначальником данной концепции является Люк Вроблевски
(Luke Wroblewski). В первой записи на эту тему он приводит три
причины, по которым сначала должен создаваться мобильный
интерфейс1.
www.lukew.com/ff/entry.asp7933

182 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
• Мобильный Интернет бурно развивается. «Начиная ра-
боту с версии для мобильных устройств, вы гарантируете
сайту компании интерфейс, доступный для постоянно
растущей пользовательской базы, которая со временем
превратится в отдельную большую платформу».
• Мобильный Интернет заставляет сконцентрироваться.
«Мобильные устройства требуют от разработчиков про-
граммного обеспечения фокусировки на наиболее важных
данных и действиях. На экране размером 320x480 пикселов
просто нет места для лишних, второстепенных элементов.
Поэтому приходится расставлять приоритеты».
• Мобильный Интернет увеличивает ваши возможности.
«Начиная работу с мобильной версии, команда получает
возможность задействовать всю палитру функций для
создания богатых, контекстно-зависимых приложений,
не ограничиваясь набором непрерывно устаревающих
решений».
Рассмотрим каждый из этих пунктов более подробно.
Развитие мобильного Интернета
В настоящее время мы наблюдаем непрерывный рост как ко-
личества, так и качества мобильных устройств. По оценкам,
к 2020 году ожидается примерно 12 млн мобильных подписок1.
По мере распространения мобильных устройств все больше
увеличивается число пользователей, выходящих в Интернет
исключительно с их помощью. Они не пользуются ноутбуками
и компьютерами, единственным средством выхода в Сеть яв-
ляется маленькое устройство, которое помещается в кармане.
В США 25 % мобильных пользователей выходят в Интернет
только с мобильных устройств. В Великобритании их количество
составляет 22 %2.
И эти показатели невысоки, если сравнить их с данными других
стран (рис. 6.1). Лидирует в этом списке Египет с его 70 % чисто
1 http://www.mobileworldlive.com/proliferation-of4onnected-devices-will-create-a-12tr-revenue-opportunity-
for-operators-by-2020
2 http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats

СНАЧАЛА МОБИЛЬНЫЕ 183
мобильных пользователей. Страны Африки в принципе являются
регионом, в котором мобильные телефоны у людей встречаются
чаще доступа к электричеству1. Их заряжают, например, при по-
мощи автомобильных аккумуляторов.
Процент пользователей мобильного Интернета, Рис. 6.1. Коли-
которые никогда или редко используют для доступа чество чисто
80 г- в Интернет обычные компьютеры мобильных поль-
зователей в раз-
70
60
50
40
30
20
10
0
ных странах
В этой статистике интересно восприятие Интернета в различ-
ных странах. Сложно представить себе жизнь в стране, где до-
ступ к электричеству встречается реже доступа к мобильным
устройствам. Тем не менее попытайтесь представить восприятие
Интернета в ситуации, когда вы и 7 из 10 ваших друзей видите
сайты исключительно на маленьком экране своего телефона.
Количество устройств и количество их пользователей будет
быстро расти. И имеет смысл учесть, что в некоторых странах
мобильная платформа уже сейчас является доминирующей.
Необходимость концентрации
Необходимость первой создавать мобильную версию помогает
сконцентрироваться на по-настоящему важных аспектах. Многим
при работе в компании или при выполнении заказа частного
клиента приходилось сталкиваться с разнообразием мнений по
поводу материала для главной страницы. Разумеется, все хотят,
http://www.wfs.org/content/significance-mobile-web-africa-and-its-future

184 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Рис. 6.2.
По-настоящему
интересна посе-
тителям только
статья (выделена
на рисунке),
но страница
перенасыщена
отвлекающими
элементами
чтобы на первый план была выдвинута именно их информация.
И это приводит к перегруженным вариантам дизайна. На одну
страницу втискивается множество вкладок и сворачиваемых
элементов, так что свободного пространства практически не
остается (рис. 6.2).
В случае создания сайтов для мобильных устройств ситуация еще
больше осложняется, так как обычно их просматривают на очень
маленьком экране. И места для огромныхобъемов информации
просто не остается. В результате на первый план приходится вы-
двигать самые важные для посетителей элементы. Какие функции
жизненно важны для вашего сайта? Что присутствует в качестве
приятного дополнения? А что лучше вообще убрать со страницы?
Дискуссии о приоритетности содержимого возникают и вне зави-
симости от разрешения экрана. В конце концов, если вы решили,
что вот этот конкретный фрагмент контента недостаточно важен
для того, чтобы оказаться на первой странице мобильной версии
сайта, то ему в принципе незачем там находиться, а значит, его
можно без проблем убрать и из полноформатной версии.

СНАЧАЛА МОБИЛЬНЫЕ 185
Увеличение ваших возможностей
В настоящее время мобильные версии зачастую воспринимают
как усеченные варианты обычных сайтов. Это может быть свя-
зано с ограниченными возможностями, которые мы исторически
связываем со словом «мобильный». Или мы просто не в состоя-
нии признать, что маленькая по размеру вещь может быть очень
функциональной. Впрочем, вне зависимости от причин, многие
упрощают мобильный интерфейс до такой степени, что он начи-
нает выглядеть калекой по сравнению с сайтами для настольных
компьютеров, которые часто называют полной версией.
Это изначально неверное мышление с практической точки
зрения не имеет никакого смысла. Как сказал мобильный кон-
сультант Джош Кларк (Josh Clark): «Считать мобильный дизайн
по умолчанию менее функциональным, все равно что требовать
выкинуть часть глав из книг в мягкой обложке, потому что они
имеют меньший размер страниц»1.
Мобильные устройства не являются функционально усеченной
версией своих более крупных братьев — часто они даже превос-
ходят их по функциональности. Например, они позволяют опти-
мизировать интерфейс сайта при помощи геопозиционирования.
Они переходят от одного макета к другому в зависимости от того,
как их держат в руках. Многие из них поддерживают мультисен-
сорный интерфейс. Мобильные устройства зачастую способны
предоставить больше возможностей, чем настольный компьютер.
Также устройства оснащают все большим количеством датчиков.
Хотя многие из них пока недоступны в браузере, следует думать
о будущем и планировать варианты их применения. Нельзя
создавать для мобильных устройств усеченные версии сайтов,
ведь именно они открывают нам путь к максимально персона-
лизированному интерфейсу.
Я думаю, вы уже убедились, что начинать разработку новых
сайтов следует именно с интерфейсов для мобильных устройств.
Разумеется, к такому подходу нужно привыкнуть, но вы очень
быстро обнаружите, что именно он позволяет сфокусироваться
на ключевых компонентах сайта и экономит ваше время.
http://thenextweb.com/dd/2011/11/07/josh-clark-debunks-the-7-myths-of-mobile-web-design/

186 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Инструментарий
В этом разделе перечислены инструменты, которыми я чаще всего
пользуюсь для работы. Разумеется, для каких-то проектов вам
потребуется меньше, чем указано в этом списке, а где-то будет не
обойтись без дополнительных, тут не упомянутых инструмен-
тов. В список я включил то, что чаще всего требуется в работе.
Но, как я уже упомянул, ваши вкусы могут отличаться от моих
и варьироваться от проекта к проекту. Строгих критериев тут
нет, нужно просто выбирать наиболее подходящий к решению
конкретных задач инструментарий.
Каркасы
На начальных стадиях работы над дизайном не следует увле-
каться детализацией. Если с самого начала создать высококаче-
ственный макет или прототип, разглядеть цвета и шрифты на
фоне общей структуры будет непросто.
Поэтому начинать работу лучше всего с примерного каркаса.
Такой каркас представляет собой диаграмму, демонстрирующую,
какой именно контент должен появиться на странице. Сюда не
входят ни цвета, ни шрифты, ни изображения. Каркас не пред-
назначен для отображения макета сайта, он помогает определить
структуру страницы, типы контента, который предполагается на
ней разместить, и приоритетность этого контента.
Каркасы должны быть максимально простыми. Чем выше точ-
ность макета, тем большие препятствия потом придется пре-
одолевать. Слишком высокая детализация отвлекает. На этой
стадии следует концентрироваться не на цветах и шрифтах, а на
элементах страницы и их структуре. А это проще всего сделать
при невысокой точности каркаса.
Стивен Хей (Stephen Hay) любит пользоваться, как он их называет,
каркасами с отсылкой к контенту. Это набросок, демонстрирую-
щий, где на странице должны располагаться данные различных
типов. Благодаря аудиту контента и таблицам страниц (о них мы
говорили в главе 5) вы знаете и каково помещаемое на страницу
содержимое, и какова его общая иерархия. Этих сведений доста-
точно для построения каркаса с отсылкой к контенту (рис. 6.3).

1. НАВИГАЦИЯ
2. ЛОГОТИП
3. СТАТЬЯ
ИНСТРУМЕНТАРИЙ 187
Рис. 6.3. Кар-
кас с отсылкой
к контенту демон-
стрирует, где на
странице дол-
жен находиться
каждый фрагмент
данных
4. ОТНОСЯЩИЕСЯ К
СТАТЬЕ ЗАГОЛОВКИ
5. ОБЪЯВЛЕНИЯ
6. ТЕГИ
7. ЗВУКОВЫЕ ЦИТАТЫ
8. РАЗДЕЛ
ДОПОЛНИТЕЛЬНЫХ
МАТЕРИАЛОВ
9. НИЖНИЙ
КОЛОНТИТУЛ
(ПОВТОРЯЕТ
НАВИГАЦИЮ)
Поскольку такие каркасы не требуют особой точности, создать
их можно буквально на коленке. За несколько минут рисуются
каркасы страниц для различных базовых размеров экрана. Так
же легко будет вносить в проект изменения при поступлении от
клиента предложений или замечаний.
НАЧИНАЙТЕ С ЭСКИЗА
Какой бы формат представления каркаса вы ни выбрали, на-
чинать всегда следует с эскиза. В основе эффективности этого
средства лежит не качество, а количество. Эскизы создаются
очень быстро, давая возможность оперативно оценить различ-
ные параметры и размеры (рис. 6.4). Для адаптивных проектов,
в которых требуется просмотреть макеты для набора различных
разрешений, это особенно важно.
Эскизы тоже не требуют точности. При виде набросков на листе
бумаги каждому становится понятно, что это приблизительная
идея. Эскиз выполняется в произвольной форме: его небрежные
линии однозначно указывают, что перед нами творческая мысль

188 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
в своем развитии, а не отработанная, доведенная до совершенства
идея. Это вдохновляет на обсуждение, ведь сразу видно, что про-
ект все еще разрабатывается. Недостаток детализации помогает
избежать предвзятости и увидеть картину в целом.
Рис. 6.4. Эскизы
позволяют
быстро оценить
множество идей
и сценариев
После просмотра готовых эскизов некоторые дизайнеры пере-
ходят к имеющим более высокую точность каркасам. Следующий
распространенный шаг Джейсон Санта Мария (Jason Santa Maria)
называет методом серого ящика1.
Как легко понять по названию метода, вам предстоит создать
каркас, состоящий из серых ящиков, которые представляют раз-
личные разделы контента. Данная операция обычно осуществ-
ляется в таких программах, как Adobe Illustrator и Photoshop, или
любом другом графическом редакторе.
Состоящие из серых ящиков каркасы стали настолько рас-
пространенным явлением, что многие заказчики просят их
предоставить. Однако в этот момент мы рассмотрим отход от
стандартного подхода. Каркасы позволяют быстро дать пред-
ставление о структуре страницы, но не более того. Даже если
потратить массу усилий на создание каркаса высокой точности,
сделать его более наглядным не получится. Любую задачу нужно
решать при помощи подходящего для этого инструмента.
1 http://v3.jasonsantamaria.com/archive/2004/05/24/grey_box_method.php

ИНСТРУМЕНТАРИЙ 189
Поэтому мы не будем останавливаться на серых ящиках, а перей-
дем к более интерактивным методам.
Прототипы
Умение отпускать является частью взросления. Скорее всего, у вас
в детстве была любимая плюшевая игрушка, но в какой-то момент
необходимость в ней отпала. А сейчас пришло время перерасти
свое желание контролировать все с точностью до пиксела.
Чтобы поддерживать максимальное количество пользователей,
порой приходится жертвовать придуманным идеальным образом.
У вас есть выбор — пытаться создать совершенный дизайн для
некоторой части потенциальной аудитории или примириться
с некоторыми недостатками. Допуская последнее, мы даем доступ
к сайту намного большему числу пользователей.
Несовершенство полезно. Оно закаляет наш характер и делает
нас более гибкими. Более того, несовершенный, но гибкий сайт
почти всегда оказывается лучше совершенного, но негибкого.
Людям нравятся вещи, которые, подобно пластилину в руках,
допускают настройку под их нужды.
В нашей отрасли долгие годы муссируется вопрос: «Должен ли
сайт выглядеть одинаково во всех браузерах?» И многие аргу-
ментированно доказывают, что не должен.
Представьте огромную работу, которая была проделана для того,
чтобы сайт начал выглядеть практически одинаково во всех бра-
узерах. Большинство из нас создавали дизайны со скругленными
углами еще до того, как вендорные префиксы дали возможность
отображать их в большинстве современных браузеров. Для этого
в общем случае требуются несколько дополнительных контей-
неров div и наборы изображений.
Долго проблемой была прозрачность изображений формата PNG,
так как она не поддерживалась браузером Internet Explorer. Для
их корректного отображения требовались сторонние сценарии.
Но за подобные решения приходилось платить увеличением
времени разработки и утяжелением страниц. Они добавляли
в проекты ненужную сложность.
Идея создания идеально подогнанного дизайна очень соблазни-
тельна. Именно поэтому многих так вдохновляют возможности

190 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
встроенных приложений iOS. Они обеспечивают абсолютный кон-
троль над способами конструирования и разработки приложений.
Но в Интернете подобная точность отсутствует. Здесь приходится
учитывать слишком большое количество факторов. Пользователь
может поменять масштаб страницы, не разворачивать на полный
экран окно браузера, кроме того, невозможно предугадать, каким
браузером он воспользуется и каковы будут функциональность
и уровень поддержки этого браузера.
В итоге получается, что идея идентичного во всех браузерах
дизайна не только неверна, но и потенциально вредоносна.
Часто громче всех возмущаются разным видом сайта в IE б и в
последней версии Google Chrome заказчики и другие заинтере-
сованные лица. С другой стороны, если копнуть поглубже, может
оказаться, что причиной проблем является наша собственная
недоработка: статические прототипы.
ПРОБЛЕМА СО СТАТИЧЕСКИМИ ПРОТОТИПАМИ
Традиционно прототипы дизайна создавались в таких графиче-
ских редакторах, как Adobe Photoshop или Fireworks. Вы штам-
повали статические прототипы, возможно, распечатывали их
и предъявляли клиентам. Они делали замечания и высказывали
пожелания, после чего вы возвращались к приложению Photoshop.
Получив окончательную, полностью одобренную клиентом
версию прототипа, вы передавали ее разработчикам для после-
дующего воплощения средствами HTML и CSS.
Это было удобно. Такова традиция. Но этот подход имеет суще-
ственные недостатки.
Сложно сомневаться в мощности графических редакторов. Они
предоставляют нам удивительный по разнообразию инструмен-
тарий и потрясающую точность управления. Можно виртуозно
подбирать шрифты, цвета, рамки, компоновку и многое другое.
Поэтому графические редакторы идеально подходят для ре-
дактирования изображений, создания значков или подготовки
печатной продукции. Но для такой изменчивой среды, как Ин-
тернет, они не подходят.
При создании в приложении Photoshop нового документа первым
делом нужно указать его размер. Уже в этот момент вы разрыва-

ИНСТРУМЕНТАРИЙ 191
ете связь со средой, для которой предназначен конечный продукт.
Неудивительно, что из ваших рук выходит такое количество
сайтов фиксированной ширины.
Существует множество проблем со статическими макетами. Они
позволяют оценить вид конечного результата с крайне ограни-
ченным числом позиций. Они не в состоянии продемонстриро-
вать дизайн при различных размерах экрана. И не показывают,
что произойдет, например, при наведении указателя мыши на
определенный объект. Они не дают представления о несоответ-
ствиях, которые неизбежно проявятся при визуализации сайта
в различных браузерах.
Когда дело доходит до обмена информацией с потенциальным
клиентом или менеджером, это становится проблемой. Вы
представляете прототип с идеально подобранными цветами
и шрифтами, а они потом высказывают претензии к внешнему
виду сайта в различных браузерах.
Возможность полного управления видом статичного прототипа
создает иллюзию, что аналогичным образом вы управляете по-
ведением сайта в Интернете, в разных браузерах и на разных
устройствах. Также это разобщает дизайнеров и разработчиков.
Последним просто передается одобренный прототип, но часто
это означает, например, отсутствие объяснений, что делать с ви-
зуальными стилями при взаимодействии с объектом.
Благодаря графическим редакторам дизайнеры полагают, что
полностью контролируют точность макета сайта. В то же время
все разработчики, с которыми мне доводилось разговаривать,
жаловались на порой совершенно нереалистичные или ужасно
неэффективные прототипы. В случае же с адаптивным дизайном
получается, что от дизайнера требуется целая стопка статических
прототипов. Как определить, сколько прототипов нужно соз-
давать? Что будет, если руководитель отдела купит устройство
с нестандартным размером экрана и потребует очередного прото-
типа? Как видите, такой подход не очень хорошо масштабируется.
КОНСТРУИРОВАНИЕ В БРАУЗЕРЕ
Альтернативным подходом является конструирование непо-
средственно в той среде, в которой затем будет находиться
сайт, — в браузере. Это позволяет решить множество проблем.

192 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Живой, управляемый кодом HTML прототип продемонстрирует
процессы взаимодействия пользователя с элементами страницы.
Всегда можно показать, какие изменения требуются в зависи-
мости от возможности устройства или браузера, и оценить вид
дизайна на экранах разных размеров.
Кроме того, разработка в браузере смещает фокус внимания на
контент и его структуру. Учет вида разметки на самой ранней
стадии работы над сайтом в дальнейшем пойдет только на пользу.
И помните, что в большинстве случаев посетители приходят на
сайты благодаря их наполнению.
Хотя написанное ранее верно не для всех. Создание дизайна от-
носится к творческой деятельности, которая невозможна, если
вы не до конца знакомы с инструментарием. А большинству
дизайнеров удобней и привычней работать с графическими
редакторами. Аналогичной привычки к конструированию в бра-
узере при этом может и не быть. Но в данном случае проблема
состоит не в особенностях подхода, а в нашем инструментарии
и наших привычках.
ПРИВЫЧКИ
Дебаты о том, должен дизайнер знать, как пишется код, или нет,
возникают с удивительной периодичностью. Это очень старая
тема. В 1990 году Митчелл Кэпор (Mitchell Kapor) привел до-
воды в пользу того, что дизайнеры должны иметь представление
о программировании1:
Дизайнерам требуется твердое знание хотя бы одного совре-
менного языка программирования (С или Pascal) в дополнение
к представлениям о самых разных языках и инструментах, в том
числе о Forth и Lisp.
Столь радикальная позиция мне не близка. Я не считаю, что
дизайнер должен уметь программировать (хотя это, конечно,
большой плюс), но навыки написания кода HTML и CSS ему
явно не помешают.
Интернет является интерактивной средой, во многом более
близкой к программному обеспечению, чем к полиграфической
продукции. Но исторически мы не привыкли смотреть на него
Из книги Winograd T. Bringing Design to Software (Addison-Wesley, 1996).

ИНСТРУМЕНТАРИЙ 193
с этой точки зрения. Возможно, все дело в том, что изначально
в основе рабочего процесса лежал именно подход, основанный
на документах. В результате в соответствии с теорией Маршалла
Маклюэна (Marshall McLuhan) мы сталкиваемся с вполне пред-
сказуемыми ограничениями и недостатками (рис. 6.5).
Рис. 6.5. «Мы
смотрим на сегод-
няшний день
через зеркало
заднего вида. Мы
пятимся назад
в будущее». Мар-
шалл Маклюэн
Те, кто считает, что дизайнеры не должны уметь программировать,
часто приводят такой аргумент: «Вы же не хотите, чтобы архи-
тектор строил ваш дом». И это действительно так. Но я не буду
обращаться и к архитектору, который не имеет представления
о строительстве. От архитектора я буду требовать полной осве-
домленности. Он должен разбираться в свойствах строительных
материалов и знать достоинства и недостатки каждого из них. Он
обязан точно знать, как создать прочный фундамент и как ком-
пенсировать воздействующие на здание естественные нагрузки.
То же самое можно сказать о веб-дизайнере. От него не требуется
умение создавать сайты своими силами, но хорошо разбираться
в свойствах среды он обязан. Для этого следует знать используе-
мые в Интернете языки, то есть как минимум HTML и CSS. Ди-
зайнер должен знать ограничения, уникальные характеристики
и возможности среды.
Взрослеть тяжело — спросите любого прыщавого юнца. Но без
этого никак. Чтобы в какой-то момент научиться пользоваться
всем потенциалом Сети, нужно снова и снова выходить из зоны
комфорта.

194 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Интернет является интерактивной средой: в его основе лежат дви-
жение и взаимодействие, им управляют капризы пользователей.
Имеет смысл понять и принять это уже на ранних стадиях проекта.
ИНСТРУМЕНТАРИЙ
Графические редакторы слишком ограниченны и не отражают
природу Сети. К сожалению, многие дизайнеры не могут творить
и экспериментировать в коде. Нужно сформировать умение рабо-
тать в интерактивной среде, а для этого можно воспользоваться
помощью инструментов.
В презентации «Inventing on Principle» Брэт Виктор (Bret Victor)
обсуждает влияние немедленной реакции инструмента на наши
действия и развитие творческих способностей1:
Создателю нужна мгновенная связь с его творением. Я имею
в виду немедленную реакцию на внесение изменений или при-
нятые решения. Не должно быть никакой задержки или неявных
результатов. Творец должен видеть, что он делает.
Именно отсутствие немедленной реакции на действия мешает
многим дизайнерам работать непосредственно в браузере. И со-
временные инструменты пока не позволяют устранить этот
психологический дискомфорт.
Статические прототипы все еще в ходу
Вряд ли графические редакторы когда-то полностью исчезнут из рабочего процесса.
Впрочем, к этому не нужно стремиться. Просто следует помнить, что этот инструмент
имеет серьезные ограничения»
Не стоит постоянно представлять клиентам дизайн в виде статических прототипов,
но иногда это вполне допустимое решение. Бывают ситуации, когда для наглядности
восприятия дизайна имеет смысл быстро создать прототип и представить его на
обсуждение.
Просто старайтесь сразу же после завершения такого обсуждения вернуться к работе
в браузере.
https://vimeo.com/36579366

ИНСТРУМЕНТАРИЙ 195
До появления новых чудесных инструментов важно работать
в направлении ослабления зависимости от любимой графиче-
ской программы. Не отказывайтесь от нее сразу, просто начните
постепенно реализовывать более гибкий подход. Создавайте
визуальные элементы по мере написания кода. Старайтесь, чтобы
эти два процесса шли рука об руку, и вы улучшите свои способ-
ности к работе в Сети.
Руководства по стилям
В качестве вспомогательных материалов следует создать руковод-
ства по стилям и библиотеку шаблонов. Руководства по стилям
некоторое время были очень популярны у крупных торговых
марок. Следовало пользоваться чисто визуальным руководством,
которое позволяло бы людям при взгляде на шрифты, изображе-
ния и логотипы сразу распознать марку. Это гарантировало, что
даже в случае, когда дизайнер не принимает непосредственного
участия в создании материалов, финальный продукт все равно
будет ассоциироваться с торговой маркой.
Применив аналогичную концепцию к разработке, мы получим
руководство по стилю интерфейса. Такое руководство демон-
стрирует принципы отображения различных компонентов сайта.
В него можно включить таблицы, кнопки, сообщения об ошибках,
шрифты, изображения и т. п.
Также руководство предоставляет шаблоны разметки. Например,
демонстрируя внешний вид таблицы, следует показать способ
ее написания, включая структуру и атрибуты. Таким способом
гарантируется не только визуальная согласованность страниц
сайта, но согласованная форма кода, значительно упрощающая
поддержку.
Поскольку руководства по стилям создаются в виде кода HTML
и CSS, их поведение можно замечательно протестировать в
различных браузерах и при различной ширине экрана. Доста-
точно поместить все компоненты на одну страницу, загрузить
ее в разные браузеры или на разные устройства и посмотреть на
поведение элементов в такой среде. Можно менять размер окна
или масштабировать текст, одновременно наблюдая за тем, как
это влияет на отдельные компоненты.

196 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Рис. б.б. Руковод-
ства по стилям
Starbucks (слева)
и Twitter Bootstrap
(справа) наглядно
демонстрируют
свою полезность
Если вы решите поменять несколько стилей, просто отредакти-
руйте руководство и снова протестируйте страницы. Если браузер
не поддерживает определенную функцию, сохранят ли элементы
согласованность с внешним видом страницы? Будут ли шрифты
читаться при просмотре руководства на маленьком экране?
Нужно ли увеличивать размер шрифта на большом экране?
Руководства по стилям становятся все более распространен-
ными. Одним из самых известных является руководство Twitter
Bootstrap (рис. 6.6). Оно демонстрирует, как должны быть на-
писаны и какой внешний вид должны иметь все элементы — от
медиаблоков до шрифтов и модальных окон диалога. Благодаря
этому ресурсу новые разработчики могут быстро приступить
к выполнению своих обязанностей.
«* с ,'.: «wv
; Oops, something was mtesed!
Примечание
Скачать Barebones
можно на стра-
нице http://
github.com/
paulrobertlloyd/
barebones.
СОЗДАНИЕ РУКОВОДСТВА ПО СТИЛЯМ
Единственно правильного способа создания руководства по сти-
лям не существует. Если выбранная вами процедура позволяет
создать руководство, которое легко поддерживать, тестировать
и пересматривать, значит вы на верном пути.
Имеет смысл рассмотреть такой инструмент, как творение Пола
Роберта Ллойда (Paul Robert Lloyd) под названием Barebones. Это
бесплатный, многоцелевой фреймворк, содержащий механизм
начальной настройки папок, руководство по стилям и библио-
теку шаблонов.

ИНСТРУМЕНТАРИЙ 197
Настройка этого фреймворка очень проста: скачайте код в вы-
бранную вами папку, и он создаст следующую структуру папок:
• _assets — пустая папка, предназначенная для изображений
и шрифтов сайта;
• _css — папка для хранения CSS;
• jnc — пустая папка, предназначенная для фрагментов РНР;
• Js — пустая папка для файлов JavaScript;
• „patterns — папка для хранения шаблонов из библиотеки;
• _patterns.php — страница, которая будет отображать библи-
отеку шаблонов;
• __styleguide.php — страница, которая будет отображать руко-
водство стилей.
Нас в основном интересуют файлы _patterns.php и _styleguide.php.
Руководство по стилям (рис. 6.7) показывает отображение базо-
вой разметки (то есть списков, элементов заголовков и горизон-
тальных разделителей) в стилях сайта. Это статическая страница.
Для добавления в руководство нового элемента требуется отре-
дактировать непосредственно файл _styleguide.php, а затем добавить
стили в файл _pattems.css, расположенный в папке _css.
Style Guide
A guide to the base markup styles used throughout the site
Sections Unked
The main page header of this guide Is an hi element Any header elements may Include links, as depleted In the example
The secondary header above is an h2 element which may be used tor any form of importer)! page-level header More than one may
beusedperpage Consider using an h2 unless you need a header level of teas Importance, or as a sub-header to an existing h2
element
Third-Level Header Linked
The header above la an h3 element which may be used for any torn» of page-level header which falls bel
Fourth-Level Header Unked
The header above la ал M element which may be used tor any form of p*ge4evel header which tails bel
document hierarchy
FMfvUvel Header Linked
The header above is an h5 element, which may be used for any form of page-tevel header which falls bel
document hierarchy
SIXTH-LEVEL HEADER LINKED
The header above la an h6 element which may be used tor any torn» of page-level header which faUs bel
document hierarchy
Grouping content
Paragraphs
All paragraphs are wrapped In p tags. Additionally, p elements can be wrapped with a blockquote eter
indeed a quote Historically, blockquote has been used purely to force indents, but this is now achievei
blockquote tor quote*
ow the h2 header in a
ow the h3 header In a
ow the h4 header In a
ow the h5 header in a
nent if the p element is
d using CSS Reserve
Рис. 6.7. Входя-
щее в фрейм-
ворк Barebones
руководство по
стилям демон-
стрирует вид
базовой разметки

198 ГЛАВА б. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Руководство по стилям не только позволяет посмотреть, как
элементы будут выглядеть на странице, но и содержит сведения
о том, когда и как их следует применять.
Библиотека шаблонов (рис. 6.8) демонстрирует внешний вид раз-
личных фрагментов кода (таких как всплывающая при наведении
указателя мыши на объект подсказка или сообщение об ошибке).
Сбоку находятся сами фрагменты кода HTML.
Рис. 6.8. Библи-
отека шабло-
нов Barebones
демонстрирует
внешний вид и
код разметки рас-
пространенных
элементов
Pattern Primer
ЯЦНШМЙЙИВВНИВт'юп snippets of та.^к. ip
1
| Hiis i« s notification of a failed action or event
| • Date ill Otrtft
1
used tnrot
jgnout the f«fo.
a>p hini
1
1
Все представленные на странице фрагменты хранятся в отдель-
ных файлах HTML в папке _patterns. Страница проводит поиск
по этой папке и отображает каждый фрагмент и его разметку.
Для добавления нового шаблона следует создать новый файл
с фрагментом кода и вставить нужные стили в файл _patterns.css.
Посмотрим на код РНР, чтобы понять, что там происходит. Не
волнуйтесь, это очень простой код:
1. $files = аггау();
2. $patterns_dir = "_patterns";
3. $handle = opendir($patterns_dir);
4. while (false !== ($file = readdir($handle))):
5. if(stristr($file/.htmr)):

подводя итоги 199
6. $files[] = $file;
7. endif;
8. endwhile;
9. sort($files);
Эта часть кода открывает папку patterns (строка 3), читает содер-
жимое всех файлов (строки 4-8) и помещает их в массив. Затем
происходит сортировка имен их файлов в алфавитном порядке
(строка 9).
После того как в папке patterns появился отсортированный массив
фрагментов кода, он циклически просматривается и содержимое
файлов помещается в руководство по стилям:
1. foreach ($files as $file):
2. echo '<div class="patternll>1;
3. echo '<div class="displayn>>;
4. include($patterns_dir.V.$file);
5. echo '</div>';
6. echo '<div class^'source'V;
7. echo '<textarea rows^'ie" cols»"30">1;
8. echo htmlspecialchars
(file_get_contents($patterns_dir.'/'.$file));
9. echo '</textarea>';
10. echo '<pxa href="' .$patterns_dir. V .$file. lll>1 .$file.'
11. echo '
12. echo '
13. endforeach;
В процессе циклического просмотра фрагментов кода они встав-
ляются в контейнер div (строки 3-5) и в текстовую область
исходного кода HTML (строки 6-11), что позволяет вам видеть
разметку каждого фрагмента.
Этот обманчиво простой инструмент заметно упрощает ре-
дактирование руководства по стилям. Для добавления нового
элемента достаточно вставить его код в библиотеку шаблонов,
и он автоматически появится в руководстве. В результате вы
легко можете просмотреть все свои стили и фрагменты кода на
одной странице.
Подводя итоги
Адаптивный дизайн — это больше чем просто стратегия, это
пусковой механизм нового подхода к проектам и нового рабо-

200 ГЛАВА 6. ПРОЦЕСС ПРОЕКТИРОВАНИЯ
чего процесса, лучше подходящего к уникальным особенностям
среды, с которой вам приходится иметь дело.
Новый рабочий процесс должен быть динамичным и гибким.
Природа нового подхода такова, что в обязательном порядке
требует сотрудничества, постепенного внесения изменений и вза-
имного уважения всех членов команды друг к другу. Дизайнеры
и разработчики в каждом проекте должны работать рука об руку.
Разработка, начатая с версии для мобильных устройств, помогает
сконцентрироваться и познакомиться с новыми интересными
методами улучшения интерфейса. Мобильные устройства ста-
новятся все более распространенными и все более функцио-
нальными, открывая двери для новых методов взаимодействия
и познания.
Совершенствовать нужно и результаты вашего труда. Каркасы
помогут избежать чрезмерной детализации на ранних стадиях
проекта. Старайтесь делать их как можно более небрежными,
подчеркивая, что эскиз находится в стадии редактирования.
Примите идею об интерактивной природе Сети и начните соз-
давать прототипы непосредственно в браузере. Статичное изо-
бражение демонстрирует только внешний вид сайта. А передача
проекта в руки разработчиков сильно затрудняется, если вы не
в состоянии продемонстрировать поведение дизайна при взаи-
модействии пользователей с отдельными элементами.
Разработка в браузере означает для дизайнера необходимость
вспомнить все, что он знает о HTML и CSS. Это может быть не-
просто, но совершенно необходимо. Разумеется, все сказанное
вовсе не означает полного отказа от графических редакторов.
Они всего лишь перестают быть инструментом, с которого мы
по умолчанию начинаем работу.
Системное мышление помогает найти верное направление в раз-
нообразии браузеров и устройств. Представления сайта в виде
совокупности страниц для этого мало. Руководства стилей по-
могают нам увидеть отдельные компоненты сайта и их сочетание
друг с другом.
В следующей главе мы рассмотрим процесс создания контента,
который может использоваться на различных платформах. Также
вы узнаете, как и когда он редактируется.

Глава 7
Адаптивный контент
Технология будет меняться. Стандарты
будут развиваться. Но никуда не денется
необходимость понимать назначение, смысл,
структуру, соотношения и ценность контента
Как только мы сможем осознать эту мысль,
создаваемый нами контент станет свободным
и уверенно продолжит жизнь в направлении
пока не известного нам будущего.
Сара Вахтер-Беттхер

202 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Представьте, что вы хотите купить дом. Вы находите в Интернете
подходящий вариант с потрясающими фотографиями! В доме
прекрасные деревянные полы и много места. Кухня явно недавно
ремонтировалась: новые шкафчики и блестящие столешницы.
Есть лоджия и огромная гостиная. Есть даже бассейн с подогре-
вом. Кажется, что найти лучший вариант просто невозможно!
Вы едете посмотреть все на месте и, к своему изумлению, обнару-
живаете, что дом поврежден. Фундамент покосился и покрылся
трещинами. Удивительно, что все не рухнуло.
Качество дома определяется качеством его фундамента. Можно
потратить время и деньги на укладку паркета, покупку гранит-
ных столешниц и элегантных светильников, но без крепкого
фундамента дом долго не простоит.
Создание сайта без учета контента и, что самое главное, смысла,
который несет этот контент, подобно укладке паркета на утрам-
бованную землю. Для успеха любого проекта жизненно важно
ознакомиться с контентом и понять его назначение.
В этой главе вы узнаете следующее:
• Почему учитывать контент нужно с самого начала.
• Как определяется структура контента и почему она имеет
значение.
• Какой контент и когда следует отображать и чем плохи
ссылки на полную версию.
• Как оптимизировать содержимое для разных устройств.
• Когда нужно менять порядок содержимого.
• Как запланировать и структурировать содержимое с при-
целом на будущее.
Начиная с контента
Как уже было сказано в главе 5, учитывать контент важно с са-
мого начала работы над проектом. Ведь именно он составляет
основу большинства сайтов. Не уделяя должного внимания
этому аспекту, мы недооцениваем основную причину захода
пользователей на сайт.

ТИПЫ КОНТЕНТА 203
Многие работали под лозунгом «Первым делом контент!» В об-
щем случае это правильно. Но как это обычно бывает, некоторые
понимают призыв чересчур буквально и считают, что работу над
дизайном не следует начинать, пока не будет готов весь контент.
Это совершенно нереальный и неправильный сценарий. Контент
непрерывно обсуждается как в процессе работы над дизайном,
так и долгое время после ее завершения. Как сказал дизайнер
Сеннид Боулс (Cennydd Bowles), дизайн и наполнение должны
идти рука об руку1:
Стиль и контент, прочно связаны. Это как пространство и время,
которые различны по своей природе, но немыслимы одно без
другого. Между ними не существует иерархии, нельзя сказать,
что какой-то из членов этой пары является главным. Они до-
полняют друг друга.
Более реалистична стратегия «первым делом структура контента».
Да, вы не можете ждать, пока будет готов весь контент, но должны
хорошо разбираться в его типах, способах создания и предна-
значении каждого из них, а также в их структуре.
Разумеется, не помешает и образец контента, с которым вы
будете работать. Наличие примера новостной статьи, рецепта,
биографии — контента любого типа — будет направлять рабочий
процесс, подтверждая правильность выбранного курса.
Хотя на самом деле в первую очередь нужно понять, что сайт
пытается сообщить миру. Только в этом случае вы сможете опре-
делить структуру контента, не говоря уж о дизайне.
Типы контента
Важно знать, контент каких типов вам предстоит отобразить на
сайте. Например, на новостном сайте, скорее всего, будут рас-
полагаться статьи, блоги, записи и комментарии. Большинство
новостных сайтов еще более детализированы. Вместо типа article
(статья), могут фигурировать типы interview (интервью), review
(обзор) и editorial (редакционная колонка).
1 www.cennydd.co.uk/2011 /what-bugs-me-about-content-out/

204 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Кулинарный сайт в дополнение к записям в блоги и статьям мо-
жет включать такие типы контента, как recipes (рецепты) и chef
bios (биографии кулинаров). Разбиение содержимого на типы
является важным этапом в создании сайта: контент любых сайтов
может и должен быть систематизирован.
Сведения о типах контента позволяют установить рамки об-
суждения его структуры, создания и предназначения. Именно
возникшие во время данных обсуждений соображения служат
основой решения об изменении иерархии контента при адап-
тации сайта к различным разрешениям и функциональным
возможностям.
Предназначение
Вы должны понимать, зачем нужен каждый тип контента. Без
этой информации вы не сможете принимать решения о роли
контента в различных сценариях.
Адаптивный дизайн в обязательном порядке требует изменения
положения контента на странице. Именно детальное понимание
назначения контента позволяет реорганизовать структуру стра-
ниц с сохранением иерархии.
Создание
Нужно понять, каким образом создается контент каждого типа.
Кто за это отвечает? Кто редактирует и поддерживает напол-
нение? Как выглядит процедура получения, например, новой
статьи для сайта? Должен ли контент для этого проходить через
руки редакторов? Кто одобряет публикацию? Кто принимает
окончательное решение?
Ответы на эти и подобные вопросы играют важную роль при
выборе способа построения сайта или приложения.
Структура
Создание дизайна для различных устройств и платформ означает,
что для перехода от одного контекста к другому контент должен
эволюционировать. Каждое изменение контекста потенциально
способно повлиять на приоритет контента.

ТИПЫ КОНТЕНТА 205
Говоря о структурированном контенте в этом смысле, я не имею
в виду семантическую разметку HTML, хотя это, конечно, очень
важная и имеющая отношение к делу тема. Но в данный мо-
мент речь идет о структурированном контенте на уровне базы
данных или модели. Любой тип состоит из набора фрагментов
контента. Скажем, статья должна состоять из заголовка, соб-
ственно текста, имени автора и даты создания. Эти фрагменты
создаются в процессе так называемого моделирования контента.
МОДЕЛИРОВАНИЕ КОНТЕНТА
Моделированием контента называется процедура определения
и документирования структуры этого контента. Каждый фраг-
мент должен иметь определенные смысл и назначение. Именно
это помогает принять решение о том, как он будет использо-
ваться на различных платформах и устройствах.
Эти фрагменты контента хранятся в виде отдельных сущностей
(например, элементов базы данных), что позволяет при необхо-
димости легко найти и использовать нужный. Будь все свалено
в одну большую кучу, без метаданных, изменение приоритетов
контента стало бы попросту невозможным.
Замечательным примером является любая страница с инфор-
мацией о неком продукте. Как правило, она включает фото-
графию и название продукта, его описание, отзывы о нем, цену
и предложения дополнительных товаров. Все это независимые
сущности, которые хранятся отдельно друг от друга. Помещая,
к примеру, описание и цену в одно поле, вы практически теряете
возможность редактировать эти компоненты, подстраивая их
под различные разрешения. Они слишком тесно связаны, чтобы
можно было управлять методом и порядком их отображения.
Аналогично, отсутствие метаданных, связанных с самим про-
дуктом или потенциальными дополнительными предложени-
ями, лишает нас возможности максимально корректно выбрать
отображаемые дополнительные продукты.
Если же, наоборот, все компоненты хранятся по отдельности
и снабжены подходящими метаданными, их порядок можно
менять произвольным образом, гарантируя при этом сохране-
ние исходной иерархии.
Метаданными
{metadata) на-
зываются данные,
придающие фраг-
ментам контента
определенный
контекст. Напри-
мер, присвоение
тега travel указы-
вает, что фрагмент
контента включает
информацию о пу-
тешествиях.

206 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Моделирование контента возможно только после его глубокого
анализа. Насколько модульным оно должно быть? Какие типы
контента будут использоваться в разных местах? Нужно ли ме-
нять способ отображения какого-либо контента в зависимости
от его положения на странице? Потребуется ли сортировать или
фильтровать этот контент? Ограничены ли во времени созда-
тели наполнения? Без ответов на эти и многие другие вопросы
невозможно построить точную и успешно функционирующую
модель контента.
Не стоит приступать к моделированию, пока вы не поймете его
предназначение: кто будет его потребителем и какую информацию
следует до этого потребителя донести. Без понимания того, зачем
нужен контент, вряд ли реально структурировать его, гарантиро-
вав возможность повторного применения и модификации.
Поскольку в данном случае требуется глубокий анализ, проце-
дура моделирования не только помогает определить необходимые
вам типы контента, но и позволяет принимать фундаментальные
решения о поведении этого контента на адаптивном сайте.
В частности, вы определяете:
• какой контент и когда следует отображать;
• будет ли порядок и приоритетность контента меняться
в зависимости от обстоятельств.
Выбор контента
для отображения
Вооружившись информацией о структуре и иерархии контента,
можно принять решение о том, каким образом оно будет ото-
бражаться при изменении размеров экрана и контекста. Если
вы потратили время на то, чтобы понять назначение контента
и правильно его структурировать, ничто не помешает сделать
его адаптивным.
В своей книге, посвященной управлению контентом, Энн Рокли
(Ann Rockley) называет адаптивным контент, который «может
6ыт1> отображен в любом желаемом порядке, реагирует на опре-
деленные воздействия пользователя, меняет свой вид в зависи-

ВЫБОР КОНТЕНТА ДЛЯ ОТОБРАЖЕНИЯ 207
мости от местоположения и способен объединяться с контентом
из других источников»1.
Достичь подобного результата позволяют две основные стра-
тегии:
• удаление контента;
• совершенствование контента.
Удаление контента
С полным удалением части контента следует быть крайне осто-
рожным. Особо хотелось бы предостеречь любителей скрывать
часть контента в версиях для мобильных устройств, оставляя
ссылку для перехода к полной версии сайта (рис. 7.1).
Mobile | Full Site
NEWS & ANALYSIS
Рис. 7.1. Сегодня широко рас-
пространена практика уреза-
ния контента для мобильной
версии сайта с предоставле-
нием ссылки на полную версию
ССЫЛКА НА ПОЛНУЮ ВЕРСИЮ
Давайте представим такую ситуацию. Вы являетесь постоянным
читателем местной газеты. И будучи противником напрасной
траты бумаги, подписались на электронную версию. Все заме-
чательно. Качество информации вас устраивает, и вы научились
перемещаться по сайту в поисках наиболее интересных статей.
Но однажды вы решили просмотреть сайт через телефон. И об-
наружили, что от газеты остались всего лишь пять наиболее
популярных за эту неделю статей и несколько ссылок на самые
популярные разделы. Все остальное пропало.
Скрепя сердце вы переходите по ссылке View Desktop, чтобы по-
смотреть версию для устройств с большим размером экранов.
В конце концов, вы же помните, как найти то, что обычно пред-
почитаете читать, даже если на вашем малюсеньком экране
форматирование страницы далеко от идеального.
Рокли Э. и Купер Ч. Managing Enterprise Content: A Unified Content Strategy (New
Riders, 2012).

208 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
В современном Интернете этот сценарий реализуется, пожалуй,
даже слишком часто. Ответственные лица — это могут быть раз-
работчики, дизайнеры или те, кто спонсирует издание, — решили,
что мобильным пользователям полной версии сайта не требуется.
Им достаточно будет упрощенной версии с наиболее популярным
контентом. Если же посетитель хочет получить больше, вот ему
ссылка на версию для настольных компьютеров.
Проблема в том, что подобные предположения о желаниях
мобильных пользователей появились на основе устаревшей
информации о способах взаимодействия этих пользователей
с Интернетом.
Традиционно мобильного пользователя представляли примерно
так. Он все время торопится, и если выходит в Интернет, значит,
ему требуется определенная информация и он не хочет терять на
ее поиск слишком мно^о времени. Речи о простом времяпрепро-
вождении не идет — мобильные пользователи ориентированы
на решение конкретной задачи.
Но в настоящее время ситуация изменилась. Возможности
смартфонов сделали просмотр веб-страниц вполне тривиальным
делом. Более того, от этого процесса на правильном устройстве
можно даже получить удовольствие. К тому же с появлением
планшетов изменилось само определение мобильного устройства,
что привело к еще большей путанице.
Разумеется, иногда мобильные пользователи ищут строго опре-
деленную информацию, но намного чаще они занимаются ба-
нальным просмотром различных страниц. Устройство может
использоваться дома, в приемной стоматолога или в машине
в процессе ожидания ребенка из школы. И в этом случае тради-
ционный сценарий уже не срабатывает, речь идет о просмотре
страниц для развлечения.
И пользователю уже требуется не усеченный, а полноформат-
ный сайт. Он хочет, чтобы дизайн был оптимизирован под его
устройство, но контент и навигация остались без изменений.
И обнаружив, что доступная в версии для настольных компью-
теров информация отсутствует, он начинает искать ссылку для
перехода к этой версии.
Но не стоит идти на компромисс, просто предоставляя эту ссылку.
Ведь переходящий по ней пользователь, возможно, даже получит

ВЫБОР КОНТЕНТА ДЛЯ ОТОБРАЖЕНИЯ 209
доступ к интересующей его информации, но процедура доступа
к ней вряд ли доставит ему удовольствие.
Сайты, просматриваемые при помощи мобильных устройств,
должны быть простыми и легкими в использовании, но не упро-
щенными до абсурда.
ДОВЕРИЕ
В итоге все сводится к проблеме доверия. Сейчас люди перестали
доверять мобильным версиям сайтов, особенно тем, на которых
красуется ссылка на версию для настольных компьютеров или,
что еще хуже, на полную версию сайта.
Они слишком часто обжигались на этом. Контент исчезал, на-
вигация неузнаваемо изменялась. С подобными проблемами
приходилось бороться так часто, что пользователи перестали
доверять дизайну для мобильных версий, как бы симпатично
он не выглядел.
Невозможно корректно выбрать, какой контент будет отобра-
жаться, а что следует скрыть, на основе только используемого
для просмотра устройства.
Совершенствование контента
Вместо полного удаления содержимого имеет смысл сконстру-
ировать набор интерфейсов и затем оптимизировать контент
в соответствии со своими планами.
Разумеется, вполне возможна ситуация, когда данные, отобража-
емые в одной версии дизайна, не требуется отображать в другой.
Скажем, в полноформатной версии страницы магазина, продаю-
щего платья, можно поместить 10 связанных друг с другом вари-
антов товара, а для версии для маленьких экранов сократить их
количество до двух-трех. Более того, в базовой версии интерфейса
вместо демонстрации дополнительных вариантов имеет смысл
ограничиться ссылкой Related Items (Дополнительные сведения).
Аналогично обстоит дело с сокращением выдержек из текста.
Например, на больших экранах ничто не мешает опубликовать
в качестве рекламы целый абзац текста, снабдив его ссылкой Read
More (Читать дальше), но в версии для мобильных устройств

210 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Примечание
Посмотреть на на-
писанный Джелом
шаблон и узнать
о технике его при-
менения можно на
странице http://fi-
lamentgroup.com/
lab/ajax_includes_
modular content/.
для экономии места имеет смысл сократить эту выдержку до
одной строчки.
Рассмотрим простой пример условной загрузки контента при
помощи JavaScript.
В нашей статье для сайта Yet Another Sports Site мы увидим за-
головки дополнительных материалов в боковой панели (рис. 7.2).
Но для экономии места на маленьком экране не стоит отображать
их по умолчанию. Вполне достаточно ссылки на них.
Примечание
Модуль Reqwest
включен в файлы
с примерами.
Кроме того, его
можно скачать на
странице https://
github.com/ded/
reqwest.
Рис. 7.2. Сейчас
заголовки послед-
них новостей запол-
няют почти весь
экран
Для улучшения интерфейса воспользуемся механизмом, ко-
торый Скотт Джел (Scott Jehl) назвал шаблоном, содержащим
привязку (anchor-include pattern). Это шаблон, преобразующий
в процессе прогрессивного улучшения функциональную ссылку
во вложение на стороне клиента. Предложенный Джелом фраг-
мент написан на jQuery, но мы для демонстрации создадим его
версию на JavaScript.
Впрочем, мы пойдем на небольшую хитрость. Дело в том, что
процедура настройки объекта XMLHttpRequest, обеспечивающая
его корректную работу во всех браузерах, выходит за рамки
данной книги. Поэтому для части функций, основой которых
является Ajax, мы воспользуемся модулем Reqwest. js. Именно

ВЫБОР КОНТЕНТА ДЛЯ ОТОБРАЖЕНИЯ 211
он обеспечит нам Ajax-функциональность. Если предложенный
нами вариант вам по каким-то причинам не нравится, вос-
пользуйтесь любой другой вспомогательной функцией Ajax
по своему выбору.
Начнем с рассмотрения базового интерфейса. При отключенном
JavaScript или слишком маленьком размере экрана должна по-
являться только ссылка:
1. <section class="related">
2. <а href«"headlines.html" id="lazy">View the latest headlines</a>
3. </section>
Атрибут id в данном случае обеспечивает хук (то есть способ
идентифицировать ссылку в сценарии) для JavaScript. Также нам
нужно знать, в какой элемент будет вставлено итоговое наполне-
ние. В этом нам поможет новый атрибут data-* из языка HTML5.
Он позволяет вместо перезагрузки атрибутов создать ваши соб-
ственные атрибуты для вставки данных. Им можно присвоить
любые имена при условии, что они начинаются с приставки
data-. В нашем примере данный атрибут указывает сценарию
на целевой объект, поэтому мы назовем его data-target:
1. <section id="related" class="related">
2. <a href="headlines.html" data-target="related" id="lazy">
View the latest headlines</a>
3. </section>
Мы просто воспользовались атрибутом data-target для иденти-
фикации элемента, в который будет помещено взятое наполнение.
Но перед написанием кода JavaScript посмотрим на страницу
headlines.html:
1. <h2>Related Headllnes</h2>
2.
з.
4.
5.
6.
7.
8.
9.
<lixa href="#">That Guy Knocked Out the Other Guy</ax/li>
<lixa href="#">Your Favorite Sports Team Lost. Again.
<lixa href="#">The Yankees Buy the Entire League</ax/li>
<lixa href="#">Guy Says Something Stupid in the Heat of the
Moment</ax/li>
<lixa href="#">New Record Set as Neither Team Scores
<lixa href="#">Why Haven't You Clicked One of Our
Headlines Yet?</ax/li>
Примечание
В рабочей вер-
сии сайта этот
фрагмент имеет
смысл извлечь из
страницы. В этом
случае, даже
если поддержка
JavaScript отклю-
чена, посетитель,
перейдя по ссылке,
все равно получит
полную версию
страницы. Но для
демонстрацион-
ных целей этого
фрагмента вполне
достаточно.

212 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Как видите, тут ничего особенного не происходит. Это всего
лишь фрагмент, который по умолчанию был страницей статьи.
Теперь добавим к объекту Utils (в первый раз он использовался
в главе 3) функцию anchorlnclude.
1. //функция anchorlnclude превращает ссылку во включение
на стороне клиента
2. anchorlnclude : function ( elem ) {
3. //берем ссылку на адрес URL
4. var url = elem.getAttributeChref);
5. //берем элемент, в котором будет отображаться результат
6. //задаем ссылку при помощи атрибута data-target
7. var target = document.getElementById(elem.getAttribute(
'data-target'));
8. //выполняем запрос ajax
9. //используем для демонстрационных целей объект reqwest.js
10. reqwest(url, function (resp) {
11. //помещаем результат в целевой элемент
12. target.innerHTML = resp;
13. });
14. }
Функция anchorlnclude берет функциональную ссылку (elem)
в качестве параметра (строка 2). Получив ссылку, сценарий
методом getAttribute извлекает ее адрес URL (строка 4). Этот
же метод применяется для поиска целевого элемента (строка 7).
Затем сценарий выполняет Ajax-запрос (строки 10-13). Еще раз
отмечу, что в этом месте я иду на небольшую хитрость и при-
меняю вспомогательную функцию Reqwest, но вы можете вос-
пользоваться любой другой вспомогательной функцией Ajax.
Запрашивается адрес URL, уже полученный из ссылки. Затем
ответ вставляется в целевой элемент при помощи свойства
innerHTML (строка 12).
Теперь у нас есть функция anchorlnclude. Передав ей загрузоч-
ную ссылку lazy, вы увидите, как вместо ссылки на странице
появляются заголовки:
var lazyLink = document.getElementById('lazy');
anchorlnclude(lazyLink);
Осталось только указать функции, в каких случаях она должна
срабатывать. Поскольку вы уже пользуетесь медиазапросом
matchMedia, проверяя точку перехода для загрузки изображений
по ссылке lazy, ничто не мешает вставить туда еще и функцию
anchorlnclude:

ВЫБОР КОНТЕНТА ДЛЯ ОТОБРАЖЕНИЯ 213
if (window.matchMediaC'Cmin-width: 37.5em)").matches) {
Utils.anchorlnclude(lazyLink);
Если устройство соответствует условию, обозначенному в медиа-
запросе, загружается указанный контент. В противном случае на
странице появляется только базовая ссылка.
Улучшение посредством усечения
Другим способом оптимизации интерфейса на маленьких экранах является усече-
ние текста. Предположим, что на странице находится анонс статьи — целый абзац,
завершающийся ссылкой на саму статью. Можно оставить вместо него только ссылку
на материал или маленький кусочек для привлечения читателей.
Наличие в базе данных поля teaser позволяет сократить рекламный анонс, например,
до пары предложений. При этом не важно, полный или усеченный вариант анонса
отображается на странице, посетитель все равно в состоянии уловить суть статьи.
Главное, постараться не отсечь ключевой контент. Рекламный анонс является хоро-
шим примером информации, для которой данная операция осмысленна. Но при этом
вряд ли вы захотите усечь саму статью или другой материал, который после этого
потеряет смысл. Тут очень легко увлечься и удалить контент, доступ к которому обе-
спечивает согласованность материалов. Усечением нужно пользоваться с большой
осторожностью.
Возможны и дальнейшие улучшения. Сейчас на устройствах
с маленьким экраном щелчок на ссылке перемещает вас на соот-
ветствующую страницу. Для пользователей, у которых включена
поддержка JavaScript, можно загрузить условленный контент.
Для этого к оператору if достаточно добавить оператор else:
1. //функция запускается только при ширине экрана не менее 600 рх
2. if (window.matchMedia("(min-width: 37.5em)M).matches) {
3. Utils.anchorlnclude(lazyLink);
4. ...
5. } else {
6. //если ширина экрана меньше 600 рх,
7. //при щелчке на ссылке загружаются только заголовки
8. lazyLink.onclick = function() {
9. Utils.anchorlnclude(this);
10. return false; продолжение

214 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Рис. 7.3. При
включенной
поддержке
JavaScript на
больших экранах
будет появляться
список заголов-
ков (слева), а на
маленьких экра-
нах для экономии
места он будет
заменен ссылкой
п. }
12. }
В результате (рис. 7.3) при соблюдении условия (если включена
поддержка JavaScript) контент будет загружаться всегда — это
всего лишь вопрос времени. Именно это является прогрессивным
улучшением во всей своей красе. Даже при отсутствии поддержки
JavaScript посетитель получит полностью функциональный сайт
со всем его наполнением. При этом поддержка JavaScript означает
улучшение интерфейса вне зависимости от размеров экрана.
That guy has the ball
In what has to be considered n development of the utmost importance, that man over there now hu the ball
By Ricky Boucher | January t, s
Lorem ipsum dolor sit amet, confecteiur adipisctBg elit Nullam tnsbque ebt eget erat placerat ran sagittis
augue pharetra. Qras quam ami, elementum quiz tinrfdunt sed, interdum id elit Aeneaa ullamcorper
bibendum odfo a rulrum Vestibulum ante ipsum pnmw in faucibus ord lurtus et ultnces posuere ajbilia
Сотое, Donee at иНатсо^рег neque Prom tinddunt leo eget lorem tempor pulvinar Ut non purus justo, nee
Hoochmt Hgula. Etiam ports mass» mauns Pellentesque habitant morbi tnstique senectus et netus et
Примечание
В главе 8 вы позна-
комитесь с функ-
цией распознава-
ния устройств на
стороне сервера.
Ее комбинация
с адаптивным ди-
зайном позволяет
согласовать поря-
док отображения
контента.
Изменение порядка
отображения контента
Как я уже упоминал, оптимизация макета для различных
устройств и разрешений требует принятия решения по поводу
порядка отображения контента на экранах различных размеров.
Невозможность согласовать этот порядок сейчас является одним
из самых больших ограничений адаптивного подхода на основе
редактирования интерфейса.

ИЗМЕНЕНИЕ ПОРЯДКА ОТОБРАЖЕНИЯ КОНТЕНТА 215
Снова рассмотрим страницу сайта Yet Another Sports Site. Пред-
ставим, что в боковой панели находится связанный со статьей
контент, например дополняющие материал фотографии или
видеофрагменты.
На большом экране подобная компоновка имеет смысл. Со-
держимое боковой панели будет отображаться сбоку от статьи,
предоставляя пользователям быстрый доступ к дополнительным
материалам.
Но что произойдет, когда на маленьком экране вместо двух
столбцов останется один (рис. 7.4)? А это неизбежно, так как сам
способ написания данного HTML-кода предполагает смещение
содержимого боковой панели вниз. Но разве это правильно?
Разве содержимое боковой панели не так же важно, как содер-
жимое основного столбца?
Более того, имеет смысл в зависимости от типа устройства выде-
лять определенные фрагменты контента. К примеру, при входе на
сайт ресторана со смартфона основной акцент следует сделать на
контактную информацию и данные о местоположении заведения.
И снова структура
Подобные сценарии развития события наглядно демонстрируют
важность структуры. Если контент представляет собой один
большой фрагмент, сгенерированный WYSIWYG-редактором,
исправить ситуацию уже не получится. По сути, вы можете
сделать всего две вещи: отображать массив текста или не ото-
бражать его.
Если же контент аккуратно разбит на фрагменты и хранится
в таком виде, а также снабжен корректными метаданными, про-
странство для маневра становится куда обширнее. Манипуляции
контентом перестают быть сложной задачей. Структурирован-
ность дает множество вариантов. И появляется возможность
выбирать поведение контента на более тонком уровне.
ПОМОЩЬ УЖЕ БЛИЗКА
К сожалению, в настоящий момент при решении проблемы с по-
рядком отображения контента невозможно обойтись без кое-
каких согласований на стороне сервера или сценариев JavaScript
«UU Сяпг. ГгаиШ от р«Мтг
More in Football
y<rarbvoritete«m!oM«totJutt«*moc
от Ufa»
TheSe«>oro««Wla4to
View related headlines »
iab.
Рис. 7.4. Все
содержимое
боковой панели
оказалось внизу
статьи, что
далеко не всегда
правильно
Аббревиатура
WYSIWYG рас-
шифровывается
как What You
See Is What You
Get (что видишь,
то и получишь).
WYSIWYG-
редактор позволя-
ет менять оформ-
ление контента
непосредственно
в процессе редак-
тирования при
помощи набора
кнопок.

216 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
(более подробно об этом написано далее во врезке «Смещение
контента»). Существуют и методы компоновки при помощи CSS:
модули Flexible Box Layout (или коротко Flexbox) и Grid Layout.
Модель Flexbox позволяет задать внешний вид контейнеров
с сохранением возможности менять их положение и размер для
заполнения доступного пространства. Кроме того, в этом случае
ничто не мешает менять порядок отображения контента. В резуль-
тате, например, элементы навигации, которые в коде фигурируют
первыми, могут появиться на странице в последнюю очередь.
Модуль Grid Layout также дает способ менять порядок отобра-
жения контента. С его помощью вы можете создавать столбцы
и строки и указывать, какие элементы должны отображаться
в каждой из ячеек.
Смещение контента
Чтобы поменять местами несколько фрагментов контента на странице, возможно, вам
будет достаточно сценария AppendAround (его можно скачать со страницы https://
github.com/filamentgroup/AppenclAround) от Скотта Джела и компании Filament Group.
Этот шаблон вставляет в страницу пустые элементы div, которые используются в каче-
стве контейнеров для вставки контента. Каждому элементу div присваивается один и
тот же атрибут data-set, чтобы показать, что все они связаны друг с другом. Например:
1. <div class*"foo" data - set» wfoobarbaz"x/div>
3.
4. /
s. <div classe"barM data-set="foobarbaz">
6. <img src="ad.png" />
7.
В этом случае оба элемента div имеют одно и то же значение атрибута data-set. Один
контейнер пуст, второй содержит объявление. Средствами CSS вы обеспечиваете
видимость только одного из контейнеров. Например, для маленьких экранов можно
скрыть контейнер с классом bar, а для больших — контейнер с классом foo.
При загрузке страницы сценарий AppendAround определяет, какой из элементов
отображается, и помещает объявление именно в него.
Впрочем, для радикального изменения порядка следования контента этим сценарием
пользоваться не рекомендуется. Но он замечательно подходит для ситуации, когда
нужно сместить в сторону объявление или любой другой фрагмент контента.

НАПРАВЛЕНИЕ РАЗВИТИЯ 217
К сожалению, на момент написания данной книги обе специ-
фикации находились в состоянии постоянной доработки и,
следовательно, поддерживались более чем ограниченно. Тем не
менее советую потратить время на знакомство с ними. Лишним
оно явно не будет.
Направление развития
Дела обстоят так: решения проблемы платформ и фрагментации
устройств в ближайшем будущем не ожидается. Скорее всего,
ситуация только усугубится. И для выживания в этой постоянно
усложняющейся экосистеме следует изменить способы хранения
контента и доступа к нему.
Трудная ситуация с кодом
В основе множества современных сайтов лежит одна из систем
управления контентом (CMS). За счет простого метода ввода
эти системы упрощают поддержку и обновление контента. В из-
рядной степени простота ввода обеспечивается WYSIWYG-
редакторами.
Эти редакторы содержат примерно такой же набор элементов
управления, как приложения для редактирования документов,
такие как Microsoft Word (рис. 7.5). Для работы с ними не требу-
ется знать HTML. Достаточно выделить текст, нажать несколько
кнопок — и как по мановению волшебной палочки буквы при-
обретут размер 18 рх, ярко-розовый цвет и станут отображаться
шрифтом Comic Sans!
! * У'
Path.: p
Word count: 0
HT^Ji7~| Рис. 7.5. WYSIWYG-
редакторы предо-
ставляют тот же
самый набор эле-
ментов управления,
что и приложения
для редактирова-
ния текстов

218 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
Примечание
К сожалению,
книга «Nimble
Report» пока не
переведена на
русский язык,
но оригинальная
версия доступна
в Интернете
по адресу http://
nimble.razorfish.
com/publication/
?m=11968&l=l.
Но за этот уровень абстракции приходится дорого платить. Сге-
нерированный таким редактором конечный продукт представ-
ляет собой мешанину контента и разметки, причем последняя
часто включает излишние и неверно используемые фрагменты.
А затем мы все это сохраняем в базу данных.
Отвлечемся на минуту от вопроса хранения. Если посмотреть
на контент с точки зрения его отображения на определенном
устройстве, ничего страшного в WYSIWYG-редакторах нет. Про-
блема в том, что в Сети контент не ограничивается только одним
представлением, его могут попытаться отобразить где угодно.
В замечательной книге «Nimble Report» Рэйчел Лавингер (Rachel
Lovinger) обсуждается необходимость вывода контента за гра-
ницы единственной страницы:
Это именно то, что нужно контенту для выживания. Свобода
оказываться там, где он больше всего требуется людям.
Его должно быть легко читать и просматривать на самых разных
портативных и настольных устройствах. Он должен свободно
интегрироваться с различными службами, социальными сетями,
приложениями и содержимым из других источников. В мире
устойчивых связей содержимое, занимающее узкую нишу, прак-
тически невидимо. А это все равно что его не существует.
Контент может оказаться где угодно — в разных контекстах, на
разных устройствах и даже в разных стилях. И контролировать
его на уровне WYSIWYG-редакторов невозможно.
Я думаю, теперь очевидно, почему не будет работать мешанина
из разметки. Сохранив ее в базе данных, мы свяжем контент
с крайне специфическим форматом отображения. И если возник-
нет необходимость поменять монитор, разметку или иерархию,
сделать это будет крайне сложно.
Этот вопрос выходит за рамки адаптивного дизайна. Контент,
управляемый из базы данных, потенциально способен отобра-
жаться на любых устройствах. В теории одной базы с контентом
вполне достаточно для реализации чего угодно — сайта, прило-
жения, коллекции электронных книг и даже печатной продукции.
Но мешанина контента и разметки этот потенциал сильно со-
кращает. В результате повторно использовать фрагменты данных
становится намного сложнее.

НАПРАВЛЕНИЕ РАЗВИТИЯ 219
Первые шаги
К сожалению, невозможно просто отобрать у всех WYSIWYG-
редакторы (хотя, признаюсь, мне хотелось бы это сделать). Нужно
просто перерасти укоренившиеся модели создания контента.
WYSIWYG-редакторы привычны и удобны многим, и переход
к новым инструментам является довольно болезненным. Но
делать это нужно. Чтобы обратить себе на пользу уникальные
характеристики Сети и выжить в мире постоянно растущего
многообразия устройств для выхода в Интернет, нужно всерьез
подойти к вопросу создания контента.
Мы должны понимать сложившуюся ситуацию и взаимодей-
ствовать с лицами, отвечающими за контент. Не лениться де-
монстрировать им, насколько WYSIWYG-редакторы снижают
уровень контроля над происходящим.
Если без присущих WYSIWYG-редакторам элементов управления
не обойтись, старайтесь максимально сократить их количество.
Например, вместо кнопок выбора цвета, размера и шрифта
оставьте только кнопки базового форматирования, скажем,
дающие возможность делать текст жирным или превращать его
в курсив. Это снизит количество проблемных мест, присущих
коду, сгенерированному редактором WYSIWYG.
В конце концов, создатели контента тоже хотят делать свою
работу качественно. Если потратить время на объяснения, как
этого добиться, в перспективе вы получите замечательные ре-
зультаты.
Создание API
Одним из способов получить гарантированно универсальный
контент является создание внутреннего API. Сначала создается
API для контента. А затем оно применяется для всех цифровых
представлений.
Именно так поступила крупнейшая радиостанция США NPR
(National Public Radio — Национальное общественное радио).
Был разработан крайне логичный и рациональный принцип, ко-
торый получил название СОРЕ (Create Once Publish Everywhere —-
создаешь однажды, публикуешь везде). Вместо ненужной траты

220 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
времени и сил они решили сделать движущей силой своих про-
ектов базу данных.
В итоге они создали собственную CMS. Весь контент хранится
в отдельных полях, гарантируя монолитность структуры. Перед
сохранением контента в базу разметка отфильтровывается.
Местоположение и тип разметки помещаются в одну таблицу,
а чистый контент — в другую. Затем при помощи API нужные
фрагменты контента извлекаются из базы и вставляются в при-
ложения или на сайт — словом, куда угодно.
Именно на подобной структуре и принципах базируется бу-
дущее. Нам нужны три основных уровня: хранения, передачи
и просмотра.
УРОВЕНЬ ХРАНЕНИЯ
Контент следует хранить в виде отдельных фрагментов, снабжен-
ных значимыми метаданными, позволяющими в любой момент
сделать запрос и воспользоваться нужными данными.
УРОВЕНЬ ПЕРЕДАЧИ, ИЛИ УРОВЕНЬ API
Итак, вы сохранили контент своего сайта, а этот слой перево-
дит его в пригодную для применения форму. Именно здесь осу-
ществляются запросы определенных фрагментов контента для
определенных устройства, сайта, приложения или платформы.
УРОВЕНЬ ПРОСМОТРА
После преобразования контента в пригодную для использования
форму следует определить, как оно будет отображаться, задав
порядок его вывода, взаимодействия и прочие аспекты. При
этом просмотр контента становится очень гибкой процедурой.
Можно запросить только реально необходимый контент и от-
форматировать его разными способами. Именно это называется
истинной адаптивностью.
При этом человек может сфокусироваться на той части задачи,
которую он выполняет лучше всего. Писатель в состоянии со-
средоточиться на смысловом наполнении текста, в то время как
лица, умеющие работать с сайтом или используемым для доступа

подводя итоги 221
устройством, стараются представить контент в виде, подчерки-
вающем смысловое наполнение.
Подводя итоги
Хотя контент и нужно принимать во внимание с самого начала
работы над проектом, работу следует начинать, не дожидаясь
окончательной готовности всех материалов. Первым делом
постарайтесь определить, какую идею несет сайт, какие типы
контента будут отображаться, каким способом они создаются,
для чего предназначены и как структурированы. Для принятия
решений, касающихся дизайна, вполне достаточно нескольких
образцов контента.
Иногда на маленьких экранах имеет смысл прибегнуть к усече-
нию контента. Но не стоит предполагать, что ссылка на полную
версию сайта дает вам индульгенцию на удаление большей части
данных из мобильной версии. Люди пользуются для доступа
в Интернет самыми разными устройствами, и изменившийся
до неузнаваемости интерфейс часто становится причиной по-
тери доверия к сайту. Поэтому предпочтительней не скрывать,
а улучшать контент. Продумайте, каким образом вид контента
может зависеть от среды, и выберите корректную технику для
реализации этой идеи. Правильно написанный код и тщательное
планирование позволяют получить мощную основу для построе-
ния под конкретный размер экрана. Разумеется, при этом порой
приходится менять порядок следования контента. Как следует
продумайте метаданные и убедитесь в том, что иерархия остается
согласованной на всех видах устройств.
Отношение к контенту должно стать более серьезным. Продол-
жая работать с WYSIWYG-редакторами, мы только создаем новые
проблемы. На самом же деле нам нужен структурированный кон-
тент, который будет обслуживаться при помощи API. Впрочем,
даже если вы не хотите пользоваться API, продумывание под-
ходящей для этого случая структуры помогает принять решение
о способах создания и хранения контента.

222 ГЛАВА 7. АДАПТИВНЫЙ КОНТЕНТ
А теперь пришло время улучшить наш адаптивный сайт при
помощи распознавания. В общем случае контент и интерфейс
только выиграют от более точной настройки под конкретное
устройство.
В следующей главе мы поговорим о том, как функция распознава-
ния и распознавание на стороне сервера помогают в оптимизации
пользовательского интерфейса.

Технология
плохого плотника всегда виноват топор
Махатма Ганди

224 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Я не плотник. Если мне выдать молоток, гвозди и несколько до-
щечек, вы получите кучку погнутых гвоздей, дощечки (со следами
молотка) и бесплатную возможность посмеяться. Это не означает,
что инструменты плохого качества. Дайте этот же набор плотнику,
и вы получите прочную скамейку, которая прослужит много лет.
Адаптивный дизайн и распознавание на стороне сервера уже
давно являются предметом споров. Многие разработчики счи-
тают последнее неверным по своей сути. Их противники говорят
то же самое про адаптивный дизайн на стороне клиента.
Ни один из подходов сам по себе не является решением — это
всего лишь хорошие инструменты. Мы уже довольно долго об-
суждаем адаптивный дизайн на стороне клиента и его возмож-
ности. Перечислим вещи, которые он делает не очень хорошо.
• Адаптация контента. Оптимизация разметки под уни-
кальные характеристики устройств практически не осу-
ществляется. Решение на стороне клиента может работать
только с имеющимся материалом.
• Учет производительности. Мы уже обсуждали сложно-
сти подготовки изображений корректного размера путем
адаптации на стороне клиента. Адаптивный дизайн также
не умеет оптимизировать разметку, сценарии JavaScript
и CSS, чтобы избежать скачивания ненужных данных.
• Совместимость с более ранними техническими решени-
ями. Тщательно построенный адаптивный сайт работает
на удивительно большом количестве устройств. Но вам по-
требуется еще немного поработать, чтобы его можно было
просматривать с более старых, имеющих ограниченные
возможности аппаратов. Многие из них поддерживают
только подмножество стандартов HTML, которое назы-
вается XHTML-MP.
• Совместимость с телевизорами. Телевизионные устрой-
ства пока только набирают силу, но можете быть уве-
ренными в том, что скоро они внесут дополнительный
хаос в мир веб-разработчиков. Распознавание на стороне
клиента в этом случае является бесполезной функцией. Их
разрешение совпадает с разрешением многих мониторов,
при этом тип среды TV ими не поддерживается (об этом
шла речь в главе 3).

РАСПОЗНАВАНИЕ АГЕНТА ПОЛЬЗОВАТЕЛЯ 225
Эти проблемы сложно, точнее, практически невозможно решить
только силами адаптивного дизайна на стороне клиента. Здесь
требуется уже распознавание на стороне сервера. Именно тут
нам на помощь приходит технология RESS, разработанная Люком
Вроблевски (Luke Wroblewski)1.
В этой главе вы узнаете следующее:
• Как распознать агент пользователя.
• Как распознать отдельные функции.
• Как скомбинировать распознавания агента пользователя
и функций.
• Как реализовать подход RESS.
• Как установить и настроить библиотеку WURFL.
• Как использовать эту библиотеку для оптимизации под
телефоны и устройства с сенсорными экранами.
Начнем с рассмотрения двух основных методов распознавания:
агента пользователя и функций.
Распознавание агента
пользователя
Распознавание агента пользователя представляет собой просмотр
соответствующей строки браузера и выбор на основании этой
информации способа работы с сайтом. Все это осуществляется
на стороне сервера.
Эта практика вполне заслуженно имеет плохую репутацию. Она
долго использовалась странным образом. Распознавание агента
пользователя применялось для того, чтобы предоставить одну
версию сайта, к примеру, для Internet Explorer, а вторую — для
Netscape. Из-за разного уровня поддержки браузеров разработ-
чики предпочитали создавать для них отдельные версии, причем
часть браузеров просто игнорировалась.
В результате большинство реализаций этого подхода отсекали
часть посетителей сайта (рис. 8.1). Фундаментальное решение
www.lukew.com/ff/entry.asp71392

226 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
о том, кто и что сможет увидеть, принималось на основании всего
одной строки. Поэтому постепенно вошла в моду небольшая
хитрость. Непопулярные браузеры подделывали строку агента
пользователя таким образом, чтобы их распознавали как более
популярные.
Рис 8.1. Распоз-
навание агента
пользователя
часто лишало
некоторых
пользователей
доступа к сайту
WB AR1ЯОЛЯУ, А РвОШМ НА» OCCURR1D «IHVAUP BUOWtg*
■• и Qpam v9 BQ which to а
• Оом your Ьгамяаг (tfyou have more than ом oaanplaaaadaaa them al)
• Open a brewer and atartf^ your atnirt horn* pa«a and navfgata to tfia
SUPPORTED MACINTOSH
BROWSERS
Last Name: Г
Which Store? Г
Etna» Address: П
Phone Number: Г
Description of Problem:
Connection Type? OOiaNip modem OCabte modem eNetwork GDSL OOther
Поэтому слишком базовый метод распознавания может ока-
заться опасным и ненадежным. Строки агентов пользователей
намеренно содержат неверные сведения.
Но прежде чем обвинять в этом бардаке браузеры, вспомните,
что за ним стоят разработчики. Если бы технология с самого
начала использовалась корректно, подобной путаницы просто
не возникало бы.
Я вовсе не имею в виду, что строки агента пользователя бес-
полезны: разработчики тщательно проверяют базы данных
устройств, что гарантирует достаточный уровень точности.
Просто нужно правильно ими пользоваться. Не пользуйтесь
распознаванием агента пользователя, чтобы что-то исключить,
как это делалось раньше. Наоборот, совершенствуйте интерфейс,
взяв за основу результат распознавания там, где это имеет смысл.

РАСПОЗНАВАНИЕ АГЕНТА ПОЛЬЗОВАТЕЛЯ 227
Анатомия строки агента пользователя
Строка агента пользователя является одним из HTTP-заголовков,
отправляемых браузером при запросе страницы или ресурса.
Она предназначена для идентификации используемого клиента
(браузера). К сожалению, стандартов написания этой строки
не существует, поэтому там содержится много бесполезной ин-
формации. Рассмотрим в качестве примера строку смартфона
Samsung Acclaim:
Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; SCH-R880 Build/FROYO)
AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
Значимой тут является только следующая информация:
• Android 2.2.1 — телефон использует операционную си-
стему Android OS, версии 2.2.1;
• AppleWebKit/533.1 — а это движок браузера и номер
сборки.
Фрагмент SCH-R880 указывает, что это смартфон Samsung Acclaim.
Эта информация также потенциально значима — тут все зависит
от того, что вы собираетесь делать.
Если вы пока не умеете анализировать строки агента пользова-
теля, ничего страшного: существует множество служб, которые
сделают это за вас. Знание же общей структуры этих строк по-
могает понять, каким образом службы собирают необходимую
им информацию.
Зачем нужно распознавание
агента пользователя?
Информацию об агенте пользователя можно использовать раз-
личными способами. Существуют сценарии, анализирующие
такие строки и сообщающие, является ли устройство мобильным
и прочее в этом роде.
На другом конце спектра находятся библиотеки устройств (device
detection repositories (DDR)), такие как WURFL и DeviceAtlas. Они
способны предоставить нам подробные сведения об устройстве,
браузере, операционной системе и том, что именно поддерживается.
WURFL — одна
из самых старых
и шире всего
реализованных
библиотек
распознавания
устройств.

228 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Возьмем для примера WURFL. Передав туда строку агента
пользователя устройства Samsung Acclaim, вы получите в от-
вет список из 500 различных функций: от проверки поддержки
CSS-градиентов до проверки возможности совершать телефон-
ные звонки. На основе этой информации вы можете настроить
интерфейс, перекроив разметку, CSS и JavaScript таким образом,
чтобы устройству была послана только та информация, которая
ему требуется.
Достоинства распознавания агента пользователя:
• вы получаете подробную информацию;
• поскольку оно происходит на стороне сервера, ненужные
ресурсы устройству не отправляются.
Недостатки распознавания агента пользователя:
• недостаточно аккуратное применение делает этот подход
ненадежным из-за долго практиковавшегося мошенниче-
ства;
• получение подробной информации связано с использо-
ванием стороннего сервиса, что удорожает стоимость
проекта.
Распознавание функций
Другим популярным подходом является распознавание функций,
которое обычно осуществляется на стороне клиента. При этом
вам не требуется иметь дело со строкой агента пользователя.
Вместо этого сценарий JavaScript проверяет наличие поддержки
различных функций. Например, можно проверить, имеется ли
в браузере встроенная поддержка формата JSON (JavaScript Object
Notation). Вот как выглядит подобный запрос:
return !!window.3SON;
Получив ответ на данный запрос, уже можно использовать
JavaScript для управления поведением страницы.
Считаю своим долгом вас предостеречь. Браузеры своим по-
ведением напоминают рыбаков. Они имеют склонность к не-
которым преувеличениям. Поддержка не является бинарным

РАСПОЗНАВАНИЕ ФУНКЦИЙ 229
аспектом, она имеет разные уровни. И хотя браузер в ответ
на запрос может утверждать, что функция поддерживается,
качество этой поддержки заранее предсказать невозможно.
Поэтому, как и при распознавании агента пользователя, для
корректного распознавания функций к делу следует подходить
очень аккуратно.
Modernizr
Существует множество сценариев распознавания функций,
и одним из самых популярных является Modernizr. Он тестирует
свыше 40 функций и помогает в разработке следующим образом.
• Создает объект JavaScript с результатами тестирования.
• Добавляет классы к элементу HTML, указывая, какие
функции поддерживаются, а какие — нет.
• Предоставляет загрузчик сценария, что дает возможность
выполнять условную загрузку сценариев с эмуляторами
различных спецификаций.
Сорок тестов — это очень много. Для большинства сайтов даже
чрезмерно. Поэтому сценарий Modernizr позволяет создавать
пользовательские наборы, включающие только тесты, необхо-
димые для конкретного проекта.
Такой сценарий следует поместить в заголовок документа. Также
имеет смысл добавить класс nojs к элементу html:
<html lang="en" class="nojs">
Когда пользователь запросит эту страницу, если сценарий
Modernizr сможет запуститься, nojs будет заменен на js, ука-
зывая на наличие поддержки JavaScript. Добавив nojs в качестве
значения по умолчанию, вы обеспечиваете приличный внешний
вид элементов страницы в отсутствии поддержки JavaScript.
К примеру, следующее объявление позволит вам применить
свойство overflow:hidden к элементу body, если JavaScript не
поддерживается:
Примечание
Скачать послед-
нюю версию сце-
нария Modernizr
можно на
странице http://
modernizr.com.
body.nojs {
overflowchidden;

230 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Кроме того, сценарий Modernizr добавляет к элементу html на-
бор классов, указывая, какие именно функции поддерживаются.
К примеру, если вы решили проверить только поддержку растро-
вого холста, геопозиционирования, модели RGBA и сенсорных
экранов, элемент HTML будет выглядеть примерно так:
<html lang="en" class="js canvas gelocation rgba touch">
Для того чтобы разобраться со стилями, в дополнение к классам
вы получаете доступ к результатам тестирования. Они содер-
жатся в объекте Modernizr.
Когда вам может потребоваться эта информация? Для примера
рассмотрим устройство с сенсорным экраном. Такие устройства
преобразуют события click в события touch, обеспечивая со-
гласованность поведения сайта. Однако это преобразование
приводит к задержке передачи информации на 300-500 мс. Вос-
пользовавшись результатами теста Modernizr.touch, можно
заменить события click событиями touch:
1. if (Modernizr.touch) {
2. //использовать события touch
3. } else {
4. //использовать события click
5. }
Примечание
Скачать библио-
теку modernizr-
server можно на
странице https://
github.com/
jamesgpearce/
modernizr-server.
Переход на сервер
Распознавание функций может быть крайне полезным, но его
выполнение на стороне клиента ограничивает вашу возмож-
ность сокращать количество скачиваемых данных и настраивать
интерфейс. Для внесения структурных изменений сервер должен
знать всю эту информацию перед отправкой страницы в браузер.
Осознав это, Джеймс Пирс (James Реагсе) создал библиотеку
modernizr-server, которая позволяет поместить результаты ра-
боты сценария Modernizr в код на стороне сервера. В результате
вы получаете возможность внести структурные изменения и из-
бавиться от скачивания ненужных ресурсов.
Работа с modernizr-server не составит проблем для тех, кто уже
пользовался библиотекой на стороне клиента. Для начала ска-
чайте как modernizr-server, так и последнюю версию библиотеки

РАСПОЗНАВАНИЕ ФУНКЦИЙ 231
JavaScript. Поместите последнюю в файл с именем modernizes,
расположенный в папке modernizr-server/modernizr.js/. Затем вставьте
в вашу страницу следующий файл РНР:
<?php
include('modernizr-server.php1);
?>
Это даст вам доступ к результатам работы теста Modernizr:
1. if ($modernizr-touch) {
2. //поддержка сенсорного экрана
3. } else {
4. //сенсорный экран не работает
5. }
При первом посещении страницы библиотека выполнит файл
JavaScript и получит результаты тестирования. Они будут до-
бавлены в куки, и страница немедленно перезагрузится.
При следующей загрузке страницы библиотека воспользуется
сведениями из куки и по возможности поместит их в переменную
сеанса для быстрого поиска в будущем.
Важно понимать, как все это работает, потому что здесь есть под-
водный камень: для первого запуска теста страница загружается
дважды. То есть вы создаете дополнительный HTTP-запрос. Это
происходит несмотря на то, что в первый раз контент не загру-
жается, так как немедленно выполняется сценарий JavaScript.
В зависимости от свойств сети, в которой находится пользователь,
подобное поведение может как создавать небольшое неудобство,
так и стать значительной помехой.
Достоинства распознавания функций:
• оно не основано на строке агента пользователя;
• оно позволяет оптимизировать функциональность
JavaScript в зависимости от поддержки функций.
Недостатки распознавания функций:
• JavaScript может быть отключен или вообще не поддержи-
ваться;
• браузеры преувеличивают свои возможности. Ответ на
вопрос о наличии поддержки зачастую нельзя свести
к бинарному «есть» или «нет»;

232 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
при выполнении на стороне клиента невозможно как сле-
дует адаптировать контент. При выполнении на стороне
сервера требуется дополнительная загрузка страницы.
Объединение
распознавания агента
пользователя и функций
Распознавание агента пользователя и функций обеспечивают нас
различной информацией и имеют собственный набор ограниче-
ний. Сами по себе они вполне подходят для большинства сайтов.
Но иногда возникают ситуации, когда требуется нечто более
мощное. И тогда имеет смысл скомбинировать эти два метода.
При комбинированном подходе вы в течение некоторого времени
собираете профили устройства. Для этого нужно сохранить
результаты тестирования и связать их с используемой строкой
агента пользователя.
Библиотека Detector
Вспомогательным инструментом для заполнения пространства между распознава-
нием функций на стороне клиента и на стороне сервера является созданная Дэйвом
Олсеном (Dave Olsen) библиотека Detector, скачать которую можно на сайте http://
detector.dmolsen.com.
Ее основой послужили библиотека modernizr-server и популярный сценарий рас-
познавания браузеров ua-parser.php, собирающий общие сведения об устройствах,
такие как установленная там операционная система или имя устройства. Благодаря
этой информации библиотека Detector динамически создает профили для каждой
строки агента пользователя, использовавшегося для доступа к странице.
В нее не включены мощные библиотеки WURFL или DeviceAtlas, но в то же время
она не зависит от тяжелой базы данных со сведениями об устройствах. В результате
получилось намного более быстрое решение. Для многих проектов обеспечиваемая
WURFL детализация не требуется, а значит, прекрасно подойдет оперативно функци-
онирующая библиотека Detector.

RESS: ЛУЧШЕЕ ИЗ ОБОИХ МИРОВ 233
Предположим, для доступа на сайт применяется все тот же
смартфон Samsung Acclaim. Вы берете строку агента пользова-
теля и отправляете запрос в библиотеку WURFL для получения
полной информации. Результаты этого запроса сохраняются
в базу данных.
При загрузке страницы вы проверяете наличие функций. Ре-
зультат этого тестирования также возвращается на сервер и со-
храняется в эту же базу.
Когда в следующий раз кто-то воспользуется устройством
Samsung Acclaim, з базе данных будут обнаружены результаты,
связанные с данной строкой агента пользователя. Имеет смысл
провести повторную проверку данных, запустив тестирование
функций при следующем появлении этой строки. Ведь в первый
раз на сайт вполне мог зайти пользователь настольного ком-
пьютера, браузер которого посылает фальшивую строку агента.
Поэтому дополнительная проверка никогда не помешает.
RESS: лучшее из обоих миров
Распознавание на стороне сервера имеет ряд существенных
недостатков. Если попытаться использовать его независимо от
адаптивного дизайна, исчезает возможность масштабирования.
По мере увеличения количества разнообразных устройств про-
цедуре распознавания на стороне сервера становится все труд-
нее удержаться на плаву (по крайней мере, это касается самых
распространенных реализаций, основанных на распознавании
агента пользователя). Это заметно уже сейчас.
Надежней всего скомбинировать распознавание на стороне
сервера с адаптивным дизайном. Этот подход, названный RESS,
сочетает лучшее из двух описанных ранее. Он предоставляет
всем устройствам один основной сайт (единый набор базовых
шаблонов), позволяя визуализировать на стороне сервера отдель-
ные компоненты в соответствии с требованиями конкретного
устройства.
К примеру, если к статье прилагается фотогалерея, общий вид
страницы может определяться единым для всех устройств шабло-

234 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
ном. При этом будут различаться реализации галереи, например,
для обычных компьютеров и устройств с сенсорным экраном.
Комбинация адаптивного дизайна с распознаванием на стороне
сервера эффективно устраняет большую часть проблем, прису-
щих каждому из подходов.
• Благодаря адаптивному дизайну макет становится не-
зависимым от устройства. Это позволяет создать сайт,
функционирующий на большем количестве устройств.
• Распознавание на стороне сервера позволяет уменьшить
количество скачиваемых данных, уменьшая тем самым
время загрузки страниц.
• Выгрузка компонентов позволяет оптимизировать интер-
фейс под конкретное устройство.
Сложное положение
До сих пор мы облегчали себе жизнь, проводя тесты в опера-
ционных системах iOS, Android и в браузерах для настольных
компьютеров. Но вкусы и предпочтения пользователей не огра-
ничиваются этим набором.
Что касается мобильных устройств, самую большую долю на ми-
ровом рынке занимают браузеры Opera Mini и Opera Mobile. Эту
часть трафика нельзя игнорировать. Согласно отчетам, в марте
2012 года количество пользователей браузера Opera Mini соста-
вило 168 млн и ими было скачано 117 млрд страниц1. От таких
цифр трудно отмахнуться.
Владельцы iPhone или Android могут установить на свое устрой-
ство браузер Opera Mini и спокойно заниматься тестированием.
В противном случае остается воспользоваться симулятором по
адресу http://implementingresponsivedesign.com/ex/ch8/ch8-1 .html.
Впрочем, сайт Yet Another Sports Site вполне приемлемо выглядит
в браузере Opera Mobile, чего не скажешь о браузере Opera Mini.
Дело в том, что последний сконструирован таким образом, чтобы
минимизировать использование данных и любой ценой ускорить
http://business.opera.com/smw/2012/03/

СЛОЖНОЕ ПОЛОЖЕНИЕ 235
свою работу. Поэтому специальный механизм сжимает страницу
на сервере еще до передачи ее на устройство.
Браузер Opera Mini поддерживает JavaScript, но запускает
сценарии только на стороне сервера. Это значительно огра-
ничивает количество доступных пользователю JavaScript-
взаимодействий.
Давайте запустим этот браузер и оценим, насколько все плохо.
К счастью, благодаря тому что страница конструировалась по
принципу прогрессивного улучшения, сайт выглядит довольно
прилично.
Результатом ограниченной поддержки JavaScript стала развер-
нутая по умолчанию навигация (рис. 8.2). Выглядит это ужасно,
тем не менее функциональность сохранена.
Рис. 8.2. В брау-
зере Opera
Mini система
навигации раз-
ворачивается
на весь экран
практически не
оставляя места
для контента
Честно говоря, данная проблема не является критической. Вид
страницы, конечно, далек от идеала, но контент доступен, а все
остальное вполне функционально. Поэтому нужно просто ре-
шить, как далеко вы готовы пойти в деле оптимизации. Ответ
зависит от таких факторов, как требования к проекту, трафик
сайта и бюджет.

236 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Эрик Раньон
ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ТЕХНОЛОГИИ RESS
Эрик Раньон (Erik Runyon) проживает в Мичигане и с 1995 года зани-
мается созданием сайтов. Он является убежденным сторонником
веб-стандартов, семантической разметки, мобильных интерфей-
сов и переносимости данных. С ним можно пообщаться в Твиттере
(@египуоп) и в его персональном блоге (weedygarden.net).
С самого начала работы над сайтом ND.edu
мы знали, что будем пользоваться техноло-
гией RESS, пытаясь по возможности сохранить
скоростей небольшой вес мобильного интер-
фейса. Нам хотелось познакомить пользова-
телей с университетом Нотр-Дам при помощи
изображений и тщательно подобранного
контента сайта. Для настольных компьютеров
и планшетов предназначались полноформат-
ные фотографии, занимающие большую часть
экрана, плюс вывод на главную страницу
ряда страниц верхнего уровня. Мы исполь-
зовали этот полноформатный стиль контента
для ряда очерков из предыдущей версии
сайта ND.edu. Но при таком объеме контента
и ресурсов мобильный интерфейс получился
далеким от идеала. Именно тут на помощь
пришла технология RESS.
При помощи простой библиотеки агентов
пользователя мы разбили все устройства на
две категории: мобильные и не мобильные.

СЛОЖНОЕ ПОЛОЖЕНИЕ 237
Это позволило корректно компилировать
контент на сервере, поставляя только нужные
компоненты. Необходимость определялась
рамками реализации интерфейса. Так как
полная версия сайта представляла собой
комбинацию страниц верхнего уровня, этот
контент без проблем можно пропустить, пре-
доставив мобильным пользователям систему
навигации для перемещения по этим стра-
ницам. Это значительно уменьшало размер
страниц, не лишая пользователей доступа
к нужному контенту.
Затем была рассмотрена система навигации,
оформленная в виде раскрывающихся спи-
сков, содержащих ссылки на внешние и вну-
тренние ресурсы. В мобильном варианте это
выглядело не очень хорошо, а так как все
ссылки были доступны через альтернативную
навигацию, было решено совсем отказаться
от этого меню.
Последним и наиболее критичным с точки
зрения равноправности контента были
сопроводительные иллюстрации и относя-
щиеся к ним материалы. Нам хотелось пока-
зать красоту университетского городка Нотр-
Дам, предоставив дополнительные сведения
к каждой фотографии на выдвигающейся
боковой панели. Решение убрать данную
функцию базировалось на двух соображе-
ниях. Во-первых, впечатление от большой
фотографии невозможно воспроизвести на
маленьком экране. Во-вторых, для описа-
ния каждого места требовалось множество
информации, что могло сказаться на общей
мобильности интерфейса. Поэтому мы пред-
почли включить аналогичный контент, но
оптимизированный под мобильные устрой-
ства. В результате путешествие по универ-
ситету было представлено как материалы,
раскрывающиеся при выборе определен-
ного места на карте. Такой подход имел ряд
преимуществ. Определив, что устройство
пользователя снабжено функцией геопози-
ционирования, мы предлагали ему указать
местоположение. И если оказывалось, что он
находится в нашем университетском городке,
ему предлагались для просмотра материалы,
относящиеся к ближайшим к нему местам.
Можно предоставить даже такую функцию,
как указание направления движения.
Таким способом мы научились учитывать
сильные и слабые стороны каждой класси-
фикации устройств и при помощи технологии
RESS выбирать интерфейс и контент, обе-
спечивающие оптимальный результат. Для
больших экранов мы смогли создать богатый,
насыщенный интерфейс весом 3 Мбайт, тре-
бующий 136 запросов. Мобильная же вер-
сия обходилась всего 23 запросами и весила
292 Кбайт. При этом контент был сохранен
практически полностью. Так что преимуще-
ства технологии RESS в веб-дизайне и раз-
работке не требуют доказательств.

238 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Совет
Библиотека
WURFL также
предлагает облач-
ный сервис (www.
scientiamobile.
com/cloud), более
простой в уста-
новке и эксплуа-
тации. В данной
книге он рассма-
триваться не будет,
так как для работы
с ним требуется
платная регистра-
ция. Тем не менее
иметь его в виду
стоит.
Впрочем, в качестве демонстрации решим данную проблему.
Ориентироваться тут следует на разрешение устройства. В следу-
ющем разделе мы воспользуемся данными из библиотеки WURFL
и внесем в интерфейс необходимые изменения.
Кроме того, узнать разрешение позволяет подход, аналогичный
библиотеке modernizr-server. Впрочем, этот пример тоже будет
рассмотрен далее, и вы поймете, почему в данном случае разум-
нее воспользоваться библиотекой WURFL.
Установка WURFL
Первым делом нужно установить PHP-библиотеку WURFL. Ее
можно найти или на сопроводительном сайте книги, или на сайте
SourceForge (http://wurfl.sourceforge.net).
После скачивания и распаковки основная папка получит имя
wurfl-php-номер-версии. Переместите ее в рабочую папку для рас-
сматриваемых примеров.
В папку wurfl-php-номер-версии вложена папка examples/resources. Ско-
пируйте папку resources в основную рабочую папку После этого
можно будет без проблем удалить папку examples.
Лицензирование WURFL
WURFL API распространяется под лицензией Affero General Public License v3 (AGPL).
Это означает бесплатность приложения для лиц, согласных с налагаемыми лицензией
ограничениями.
Ситуация в данном случае получается неоднозначной. К примеру, запуск WURFL API
на сервере приравнивается к распространению. Это означает, что все созданные
с помощью данного API приложения должны быть лицензированы как имеющие
открытый исходный код. Если для вашего проекта данные условия не подходят, можно
купить коммерческую лицензию WURFL.
База данных WURFL XML имеет отдельную лицензию и может использоваться только
совместно с WURFL API.

УСТАНОВКА WURFL 239
Папка resources содержит две вложенные папки: cache и persistence.
Обе они должны предоставить серверу доступ на запись.
Также в папке resources находится архив wurfLzip. Именно это и есть
центр действия. В архиве содержится файл wurfLxml со всей ин-
формацией об устройстве. Этот файл доступен для скачивания
и сам по себе. Это позволяет периодически обновлять его.
Конфигурация
В основной рабочей папке создадим файл wurfl_config.php и поме-
стим в него следующий код:
1. <?php
2. II Включить протоколирование ошибок во время разработки
3. ini_set('display_errors', 'on');
4. error_reporting(E_ALL);
5.
6. $wurflDir = dirname(__FILE__) . ,/wurfl-php-1.4.1/WURFL';
7. $resourcesDir = dirname( FILE ) . '/wurfl-php-1.4.1/resources';
8.
9. require_once $wurflDir.'/Application.php1;
10.
u. $persistenceDir ■ $resourcesDir.'/storage/persistence1;
12. $cacheDir = $resourcesDir.'/storage/cache1;
13.
14. // Создать объект WURFL Configuration
is. $wurflConfig = new WURFL_Configuration_InMemoryConfig();
16.
17. // Задать положение объекта WURFL File
18. $wurflConfig->wurflFile($resourcesDir.'/wurfl.zip');
19.
20. // Задать для API режим совпадений ('производительность1 или
'точность')
21. $wurfIConfig- xnatchMode('performance');
22.
23. // Задать сохранение WURFL
24. $wurflConfig->persistence('file', array('dir' =>
$persistenceDir));
25.
26. // Настройка кэширования
27. $wurflConfig->cache('file', array('dir' => $cacheDir,
'expiration' => 36000));
28.
29. // Создать объект WURFL Manager Factory из WURFL Configuration
зе. $wurflManagerFactory = new
WURFL_WURFLManagerFactory($wurflConfig);
31.
32. // Создать объект WURFL Manager
33. /♦ gvar $wurflManager WURFL_WURFLManager */
34. $wurflManager = $wurflManagerFactory->create();

240 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
DeviceAtlas
Библиотека WURFL—не единственное возможное решение Существуют и альтерна-
тивные варианты, самым примечательным из которых является DeviceAtlas.
Она появилась в 2008 году как коммерческая база данных устройств* Информацию
для нее получали от производителей и даже из библиотеки WURFL Но в отличие от
последней, DeviceAtlas в основном сфокусирована на аспектах, связанных с мобиль-
ным Интернетом. Разумеется, где-то возможности этих библиотек пересекаются, тем
не менее между ними есть и существенная разница.
К примеру, WURFL обладает целой категорией функций, имеющих отношение к скачи-
ваемым объектам, таким как обои, рингтоны и заставки для мониторов. В библиотеке
DeviceAtlas ничего подобного нет. Зато она имеет категорию, посвященную функциям,
связанным с HTML5, таким как canvas и application cache.
Обе библиотеки соответствуют высоким стандартам качества и часто обновляются,
поэтому выбор между ними в конечном счете делается в зависимости от требований
к проекту и персональных предпочтений.
Рассмотрим этот конфигурационный файл подробнее.
Строки 3 и 4 включают сообщения об ошибках в РНР. Для работы
WURFL это не является обязательным, но журнал ошибок может
пригодиться на стадии разработки сайта. Обязательно перенесите
эти строки на рабочую версию сайта.
Строки 6 и 7 указывают на папку WURFL и только что настроенную
папку resources.
Строка 9 включает основной файл приложения WURFL.
Строки 11 и 12 указывают путь к папкам persistence и cache. Папка
cache хранит данные об агентах пользователей, которые были за-
фиксированы для ускорения повторяющихся запросов.
Строка 15 создает экземпляр конфигурационного объекта, и мы
получаем возможность указать ему, где все находится.
Строка 18 указывает конфигурационному объекту положение
базы данных WURFL.
Строка 21 задает метод matchMode. Они имеет два параметра:
performance и accuracy. В первом случае браузеры для на-
стольных компьютеров начинают рассматриваться как некий

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 241
обобщенный браузер, их не пытаются точно идентифицировать.
В большинстве случаев этого достаточно.
Строки 24 и 27 задают методы persistence и cache. В этом случае
они заставляют библиотеку WURFL пользоваться хранилищем
файлов, в котором находится папка, а для папки cache указывается
еще и время жизни кэша.
В строках 30 и 34 конфигурационный файл создает объект
WURFL manager, позволяющий идентифицировать устрой
и возвращать сведения об их возможностях.
[ства
Возможности распознавания
Теперь, когда все переменные заданы, ничто не мешает вставить
библиотеку WURFL в страницу Yet Another Sports Site.
Добавьте в верхнюю часть страницы следующий код:
1. <?php
2. // Вставка конфигурационного файла
3. inclyde_once './wurfl_config.php';
4. // Эта строка распознает устройство, с которого просматривается
страница,
просматривая его HTTP-запрос ($_SERVER)
6. $device = $wurflManager->getDeviceForHttpRequest($_SERVER);
7. ?>
Этот фрагмент кода включает и запускает конфигурационный
файл и передает в библиотеку WURFL серверные переменные.
Библиотека идентифицирует устройство и возвращает сведения
о его возможностях.
Теперь можно сделать запрос к WURFL, чтобы понять, исполь-
. зуют ли устройства с маленьким экраном функцию resolution_
width:
1. if ($device->getCapability(iresolution_widthl) <= 480) {
2. $smallScreen = true;
3. } else {
4. $sma!lScreen = false;
5. }
Этот фрагмент кода проверяет, не превышает ли ширина
устройства 480 пикселов. В первой строчке используется метод
Серверные пере-
менные
РНР сохраняет
информацию о за-
головках (в том
числе строку аген-
та пользователя),
маршруте и рас-
положении в мас-
сив $ SERVER.

242 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
getCapability, позволяющий получить от WURFL значение
определенной функции. В данном случае WURFL возвращает
ширину устройства. Если она меньше или равна 480 пикселам,
созданная вами переменная $smallScreen получает значение
true. В противном случае ей присваивается значение false.
Теперь, имея переменную $smallScreen, мы можем отредакти-
ровать передаваемые браузеру элементы навигации:
1. <?php if ($smallScreen) { ?>
2. <а hrefs'^bottom" class="nav-collapse active"
id="nav-collapse">Menu</a>
3. <?php } else { ?>
4. <a href="#nav" class="nav-collapse" id="nav-collapse">Menu</a>
5. <ul class="nav" id«"navll>
6. <li class^'active-xa href-"*">Football</a></ll>
7. <lixa href=fl#fl>Baseball</a></li>
8. <lixa href«n#">Soccer</a></li>
9. <lixa href=tl#If>Tennis</ax/li>
19. <lixa href=n#">Ice Soccer</ax/li>
п. <lixa href=lf#ll>Basketball</ax/li>
12. </ul>
13. <?php } ?>
Если переменная $smallScreen имеет значение true, устройство
получит ссылку Menu, отправляющую к навигации в нижнем
колонтитуле. В противном случае будет передан весь набор на-
вигационных элементов.
Это решает проблему с навигацией в браузере Opera Mini. Теперь
на устройствах с маленьким экраном кнопка Menu (рис. 8.3) будет
отправлять пользователя в нижнюю часть экрана к навигацион-
ным элементам.
В данном случае распознавание агента пользователя применяется
не для исключения данных, а для улучшения. Теперь при ширине
экрана менее 480 пикселов все функции будут работать, просто
немного другим способом. Негативного влияния на пользова-
тельский интерфейс удалось избежать. Поскольку страница соз-
давалась в соответствии с принципом прогрессивного улучшения,
она будет функционировать, даже если устройства с большим
размером экрана не смогут свернуть меню. Вне зависимости от
ситуации навигация сохранит работоспособность, не заполняя
при этом маленькие экраны целиком.
Этот пример прекрасно демонстрирует, зачем иногда требуется
распознавание на стороне сервера. Вы улучшаете интерфейс

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 243
устройств, не поддерживающих выпадающие навигационные
меню. И что самое важное, при этом вы никого не лишаете
доступа к сайту. Распознавание на стороне сервера не должно
обозначать ограничения доступа.
Рис. 8.3. Благо-
даря простому
распознаванию
на стороне
сервера сред-
ства навигации
можно сместить
в нижнюю часть
экрана, освобо-
That £u> ims iU В див место для
ball I контента
РАСПОЗНАВАНИЕ ФУНКЦИЙ
Для увеличения надежности данного подхода добавим распоз-
навание ряда функций. Предоставленные библиотекой WURFL
данные о разрешении не раскрывают всей полноты картины.
Пользователь настольного компьютера может изменить размер
окна браузера по своему вкусу, но об этом WURFL уже не сообщит.
В главе 5 упоминалось, что ряд новых устройств умеет проециро-
вать изображение. Аналогичным образом можно присоединить
к смартфону Android внешний монитор, воспользовавшись
ОС, предоставленной Ubuntu. В подобных ситуациях данные
о разрешении от WURFL менее точны, чем распознанные при
помощи сценария JavaScript. Распознавание на стороне сервера
имеет смысл перед загрузкой первой страницы, а затем следует
получать данные о ширине при помощи JavaScript и использовать
их при загрузке остальных страниц.

244 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Примечание
Изначально эти
функции были
созданы Питером-
Полем Кохом
(Peter-Paul Koch)
и находятся на его
сайте (http://www.
quirksmode.org/js/
cookies.html).
Начнем с создания функций для чтения и записи куки в JavaScript.
Их мы добавим в объект Utils.
1. var Utils = {
2. createCookie : function(name, value, days) {
3. if (days) {
4. var date = new DateQ;
5. date.setTime(date.getTimeQ + (days*24*60*60*1000));
6. var expires = "; expires»"+date.toGMTString();
7. }
8. else var expires - "";
9. document.cookie = name + "=" + value + expires + ";
path=/";
readCookie : function(name) {
var nameEQ = name + "+";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var с = ca[i];
while (c.charAt(0)==* ') с = c.substring(l, c.length);
if (сindexOf(nameEQ) == 0) {
return c.substring(nameEQ.length, c.length);
}
};
return null;
li.
12.
13.
14.
is.
16.
17.
18.
19.
26.
21.
22. L
23. ...
24. }
Теперь, когда у нас есть служебные функции, пришло время соз-
дать объект Utils.tests, который будет содержать созданные
вами тесты функций. В настоящее время нас интересует только
проверка ширины, но построенный таким образом объект легко
масштабируется по мере возникновения необходимости в до-
полнительных тестах.
l. var Utils
2.
3.
4.
5.
6.
7.
8, }
tests : {
getWidth: function(){
return (window.innerWidth >
0) ?
window.innerWidth :screen.width;
В этом фрагменте создается функция getWidth, которая до-
бавляется в объект Utils .test. В строке 5 она возвращает или
свойство window. innerWidth, или, если оно недействительно,
свойство screen.width.

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 245
Теперь можно добавить в функцию window, onload код, запуска-
ющий тестирование и сохраняющий его результаты в куки для
ТТЛ TTKWPUTTTРГП ТТПМА/ГРНРТИЛСТ'
дальнейшего применения:
1. var features = {};
2. //проверка куки
3. if (Utils.readCookie('features')) {
4. features = Utils.readCookie('features');
5. features = 3SON.parse(features);
6. } else {
7. //проверка ширины
8. features ['width'] = Utils. tests. getWidthQ;
9. //сохранение функций
10. Utils.createCookie('features', JSON.stringifу(features));
u. }
Строка 1 создает объект features для хранения результатов
тестирования любых функций.
Строка 3 проверяет наличие куки. При положительном ре-
зультате проверки значение сохраняется в объекте features,
а JavaScript-функция JSON.parseQ преобразует это значение
в объект.
Если же куки не существует, строка 8 проверяет ширину и зна-
чение в виде строки сохраняется в куки с именем ' features'.
Ну и, наконец, остается объяснить коду на стороне сервера, что
нужно взять значение ширины из куки features:
1. if (isset($_COOKIE['features'])) {
2. $feature = json_decode($_COOKIE['features']);
3. }
4. if ($feature->width) {
5. $width = $feature->width;
6. } else {
7. $width = $device->getCapability('resolution_width');
8. }
Строка 1 проверяет, был ли задан куки. В случае положительного
результата проверки его значение сохраняется в переменную
$f eature (строка 2). Затем в строке 4 значение переменной
$width передается в функцию проверки ширины, а если ее не
существует, то в библиотеку WURFL.
Теперь можно объяснить коду, что значение переменной
$width позволяет идентифицировать устройства с маленьким
экраном:

246 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
1. if ($width <= 480) {
2. $smallScreen = true;
3. } else {
4. $smallScreen = false;
5. }
Теперь при первой загрузке страницы ширина экрана будет
определяться по данным о разрешении из библиотеки WURFL
При последующих загрузках, если включена поддержка JavaScript,
станет использоваться уже проверка функции.
Телефонные звонки
Владельцы сайта Yet Another Sports Site решили сделать шоу,
в процессе которого верные слушатели и читатели смогут звонить
и задавать вопросы. Поэтому на боковую панель нужно добавить
телефонный номер, начинающийся на 800.
Умный разработчик сразу сообразит: поскольку многие поль-
зователи просматривают сайт с телефона, неплохо бы сделать
так, чтобы для совершения звонка было достаточно щелчка на
номере. (Я не шучу. Эти мини-компьютеры действительно умеют
выполнять телефонные звонки! А вы не знали?)
Многие устройства пытаются определить номер телефона через
распознавание образов, но это далеко не лучший вариант. Суще-
ствует специальная ссылка tel:, поддерживаемая множеством
устройств. Именно она позволяет обозначить ссылку как номер
телефона:
<а href="tel:+18005555555li>l-800-555-5555</a>
Это прекрасно работает на поддерживающих данный формат
мобильных устройствах, но, как это обычно бывает, в целом
ситуация вовсе не так проста. Браузеры настольных компью-
теров подобной ссылки не понимают. В некоторых из них текст
отображается как ссылка, но при этом она не несет никакой
функциональной нагрузки. Другие, например Safari, пытаются
открыть ее как обычный адрес URL. Часть мобильных браузеров
вместо этого формата поддерживают более старый формат WTAI
Wireless Telephony Applications Interface:
<a href=Ilwtai://wp/mc;+18005555555">l-800-555-5555</a>

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 247
Впрочем, в этом случае решить проблему снова поможет рас-
познавание на стороне сервера.
Для начала поместим анонс шоу над разделом Related Headlines.
1. <aside>
2. <section class="talkshow">
3. <h2>We're talking sports!</h2>
4. <pxa href=iitel:+18005555555ll>l-800-555-5555</ax/p>
5. </section>
6. <section class=Mrelated">
7. ....
Теперь добавим несколько стилей, чтобы номер телефона сразу
бросался в глаза и без проблем реагировал на касание (класс call
будет использован чуть позже, если не будет включена ссылка):
1. .talkshow a, .call{
2. font-size: 1.5em; /* 24рх/1брх */
3. padding: .416666667em 0 ,416666667em 50px; /* 10px/24px */
4. background: url(../images/phone.png) left center no-repeat;
5. }
Теперь нужно прибегнуть к помощи WURFL, чтобы решить,
в каких ситуациях тут станет появляться ссылка, а в каких —
обычный номер. Здесь нам будут особенно полезны две функции:
has_cellular_radio и xhtml_make_phone_call_string.
Функция has_cellular_radio позволяет распознать наличие
у устройства возможности пользоваться сотовой связью. При
этом устройство может отличаться от телефона. Например,
электронные книги Kindle пользуются сотовой связью для пере-
дачи данных. Впрочем, функция has_cellular_radio дает более
или менее точный прогноз. А функция xhtml_make_phone_call_
string возвращает метод совершения телефонных вызовов.
Комбинация этих двух свойств позволяет распознать, способно
ли устройство совершать телефонные звонки. Добавьте в верх-
нюю часть страницы следующий код РНР:
1. if ($device->getCapability('has_cellular_radiol) === 'true') {
2. if ($device->getCapability( 'xhtmljnakejjhone^calLstring1) !■■
•none1) {
3. $wireless = true;
4. $method = $device->getCapability('xhtml jnake_phone_call_
string1);
5- > else < продолжение #

248 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
6.
7. }
8. } else {
9. $wireless
10. }
$wireless = false;
false;
Первая строка проверяет способность устройств пользоваться
сотовой связью. В случае отрицательного результата переменная
$wireless получает значение false и дальше ничего не проис-
ходит. В противном случае проверяется, не равна ли функция
xhtml_makejDhone_call_string значению попе. Это значение
указывает, что вставлять ссылку на телефонный звонок беспо-
лезно, поэтому переменной $wireless можно легко присвоить
значение false. В противном случае переменной $wireless
присваивается значение true, а строка xhtml_make_phone_call_
string передается в переменную $method, которая впоследствии
будет использоваться на странице.
Затем ссылку, которая в настоящий момент содержится
в коде HTML, следует вставить в PHP-оператор if /else:
1. <?php if ($wireless) { ?>
2. <pxa href=H<?php echo $method; ?>+18005555555">
l-800-555-5555</ax/p>
3. <?php } else { ?>
4. <p с1а55=нса11и>1-800-555-5555</р>
5. <?php } ?>
Рис. 8.4. Ha
устройствах,
умеющих делать
телефонные
вызовы, номер
превратится в
ссылку, упроща-
ющую процедуру
звонка (слева).
При этом в брау-
зерах настольных
компьютеров
он будет ото-
бражаться как
простой текст
(справа)
We're talking sports!
1-800-555-5555
We're talking «porM
1-800-555-5555!
Если переменная $wireless имеет значение true, ссылка встав-
ляется в страницу. Переменная $method отображается на экране,
гарантируя правильность используемого синтаксиса. Если пере-
менная $wireless имеет значение false, номер будет отобра-
жаться, но уже без ссылки (рис. 8.4). Это гарантирует отсутствие
странных проблем, которые могут возникнуть при попытке
воспользоваться ссылкой tel: на обычном компьютере.

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 249
Оптимизация для сенсорных экранов
Итак, правильно настроенное распознавание на стороне сервера
позволило улучшить интерфейс для еще более широкого спектра
устройств. Пойдем дальше и позаботимся об устройствах с сен-
сорным экраном. Начнем со слишком маленьких ссылок на до-
полнительные материалы в боковой панели. В Apple установили,
что цель касания должна иметь высоту по меньшей мере 44 пик-
села, поэтому нашим ссылкам не помешают небольшие поля.
Распознавание функций для устройств с сенсорными экранами
является популярной манипуляцией, но тут есть один тонкий
момент: распознается поддержка события касания, а не наличие
у устройства сенсорного экрана. К примеру, телефоны WebOS
имеют сенсорные экраны, но не поддерживают событие касания.
А значит, функция распознавания даст отрицательный результат
и устройство не получит соответствующих стилей.
В библиотеке WURFL есть функция pointingjnethod, при на-
личии сенсорного экрана возвращающая значение touchscreen.
К сожалению, тут тоже не все гладко: далеко не все сенсорные
экраны поддерживают событие касания.
Собственно, вопрос в том, как найти наиболее подходящий для
ваших целей инструмент. Если вы хотите отредактировать стили
для устройств с сенсорным экраном, пользуйтесь распознава-
нием на стороне сервера. Если же изменения требуется внести
в JavaScript, нужно прибегнуть к распознаванию функций.
Чтобы получить хук для изменения стилей на устройствах с сен-
сорным экраном, просто превратите функцию pointingjnethod
в класс элемента body:
<body id="top" class="<?php echo $device->getCapability
(•pointingjnethod1); ?>">
Теперь у устройств с сенсорным экраном в теге body появится
класс touchscreen. Наконец, осталось оптимизировать ссылки на
дополнительные материалы. Как вы помните, их высота должна
составлять по меньшей мере 44 пиксела. В настоящее время раз-
мер шрифта равен 16 пикселам, а высота строки — 24 пикселам.
Поэтому нам нужно добавить еще 20 пикселов. Это реализуется,

250 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
Примечание
Свойство
display.-block
гарантирует по-
явление полей
вокруг ссылки.
например, при помощи полей шириной 10 пикселов сверху
и снизу от ссылки. Формула
Цель/Контекст = Результат,
впервые появившаяся в главе 2, дает нам значение в единицах em:
1. .touchscreen .related a{
2. display:block;
3. padding: .625em 0;
4. }
Применим те же самые стили к ссылкам More in Football:
1. .touchscreen .more-stories a{
2. display:block;
3. padding: .625em 0;
4. border-bottom: lpx dotted #999;
5. }
Изображения для раздела More Stories загружаются после точки
перехода при 37,5 em (600 пикселах), поэтому в настоящее время
нижняя граница не нужна и выглядит несколько неуместно
(рис. 8.5). Поэтому данное свойство нужно переопределить, до-
бавив в медиазапрос следующие стили:
.touchscreen .more-stories a{
border-bottom: 0;
Рис. 8.5. На
устройствах
с сенсорным
экраном {справа)
вокруг ссылок
появились поля
Related Headlines
That Guy Knocked Out the Other Guy
Your Favorite Sports Team Lost.
Again.
The Yankees Buy the Entire League
Guy Says Something Stupid in the
Heat of the Moment
New Record Set as Neither Team
Scores
Why Haven't You Clicked One of Our
Headlines Yet?
Related Headlines
That Guy Knocked Out the Other Guy
Your Favorite Sports Team Lost.
Again.
The Yankees Buy the Entire League
Guy Says Something Stupid in the
Heat of the Moment
New Record Set as Neither Team
Scores
Why Haven't You Clicked One of Our
Headlines Yet?

ВОЗМОЖНОСТИ РАСПОЗНАВАНИЯ 251
Теперь если вы загрузите страницу на устройство с сенсорным
экраном, то обнаружите, что точки контакта в местах располо-
жения ссылок стали более удобными. При этом на устройствах
без сенсорного экрана размер ссылок не изменился.
ОПТИМИЗИРОВАННЫЙ ПОД КАСАНИЯ JAVASCRIPT
Визуально сайт готов работать на устройствах с сенсорным
экраном. Но осталось скорректировать еще один аспект.
В настоящее время, если устройство с разрешением более 480 пик-
селов по ширине имеет сенсорный экран, раскрывающееся меню
начинает реагировать только на события щелчка. Данные устрой-
ства достаточно интеллектуальны для обработки этого события,
но это будет стоить вам ожидания в течение 300-500 мс. Может
показаться, что это немного, тем не менее данный аспект значи-
тельно влияет на восприятие сайта пользователями.
Многочисленные исследования, проводимые с 1960-х годов, по-
казали, что задержка в 100 мс является пределом, при котором
пользователь считает систему мгновенно реагирующей на его
действия1. В остальных случаях возникает ощущение прерыва-
ния связи.
Если устройство поддерживает события касания, имеет смысл
пользоваться именно ими, обеспечив мгновенный отклик. И пом-
ните, на данные WURFL в этом случае полагаться нельзя. Функ-
ция pointing_method дает вам сведения о наличии сенсорного
экрана, но не о поддержке касаний. Для ее распознавания по-
требуется дополнительная функция.
Тут все довольно просто:
hasTouch = 'ontouchstart* in window || 'createTouch1 in document;
Здесь проверяются два свойства, связанных с событием касания.
Если существует хотя бы одно из них, скорее всего, поддержка
касаний включена и ими можно без проблем пользоваться.
К сожалению, поскольку событие касания позволяет выполнять
довольно сложные жесты, простой встроенной замены для ис-
www.useit.com/papers/responsetime.html

252 ГЛАВА 8. ТЕХНОЛОГИЯ RESS
пользуемого в данный момент события onclick не существует.
К счастью, над этим аспектом уже поработали.
Для страницы Yet Another Sports Site можно воспользоваться
модулем Алекса Гибсона (Alex Gibson) Tap.js, который можно
бесплатно скачать со страницы https://github.com/alexgibson/tap.js. Чтобы
избавиться от дополнительного HTTP-запроса, возьмите код из
файла tap.js и поместите его в верхнюю часть файла yassjs.
В модуле Tap.js распознавание функций проверяет наличие под-
держки события касания. В случае положительного результата
они будут применяться, в противном же случае мы вернемся
к событию щелчка.
Чтобы воспользоваться этим модулем, замените функцию
collapse.onclick:
1. collapse.onclick = functionQ {
2. Utils.classToggle(nav, 'hide');
3. return false;
4. };
следующим кодом:
1. myTap = new Tap(collapse);
2. collapse.addEventListener('tap', function(){
3. Utils.classToggle(nav, 'hide');
4. return false;
5. }, false);
Строка 1 создает новый объект Тар с именем ту Та р. Строки 2-5
заставляют браузер ожидать событие касания на кнопке свертки.
Как только оно произойдет, сработает функция classToggle
(строки 3 и 4).
Подводя итоги
Адаптивный дизайн и распознавание на стороне сервера часто
противопоставляют друг другу, но на самом деле ни одно из этих
решений не является самодостаточным. Только их совместное
аккуратное применение позволяет оптимизировать сайт под
максимальное количество устройств.

подводя итоги 253
Распознавание агента пользователя представляет собой очень
мощную технику, но применять его нужно с осторожностью.
Ваша задача — улучшить интерфейс для посетителей, а не за-
блокировать от них сайт.
Распознавание функций весьма популярно среди разработчиков
и допускает реализацию как на стороне клиента, так и с помощью
небольших хитростей на стороне сервера. Но это не очень на-
дежное решение. Иногда возможны фальшивые срабатывания,
а для запуска процедуры на сервере требуется дополнительная
загрузка страницы.
Библиотека WURFL представляет собой удивительно мощный
инструмент для распознавания устройств. Благодаря более чем
500 функциям, находящимся в ее распоряжении, она предостав-
ляет большую власть над пользовательским интерфейсом.
Тщательно учитывайте возможности устройств и способы оп-
тимизации под них интерфейса. Заменой компонентов и сти-
лей можно получить интерфейсы для устройств с сенсорными
экранами, старых устройств с ограниченными возможностями
и устройств, умеющих работать в режиме телефона.
В следующей главе на основе данного материала мы попробуем
выйти за границы адаптивных макетов и построить адаптивный
интерфейс.

Глава 9
Адаптивные
интерфейсы
Будущее в движении всегда.
Йода, «Звездные войны V:
Империя наносит ответный удар»

256 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Люди талантливы во многих областях, но плохо предсказывают
будущее. Наше видение грядущего омрачено прошлым опытом.
Поэтому при появлении новой среды так сложно забыть огра-
ничения сред, в которых мы работали ранее.
Найти подтверждающий эти слова пример несложно. Когда по-
явилось телевидение, изначально там транслировались радиошоу.
Содержание не изменилось, люди читали в микрофоны текст,
просто теперь их было еще и видно. И только некоторое время
спустя стал появляться новый, уже более привлекательный в ви-
зуальном плане контент.
Даже названия показывают, как сложно нам отделить себя от
прошлого. Слово «кинематограф» составлено из двух греческих
слов — «движение» и «рисовать». Это привычное нам, но не-
точное описание.
То же самое происходит в Интернете. Веб-дизайн по большей
части представляет собой преобразованные печатные варианты.
Мы даже позаимствовали термины «страница» и «сгиб». Но на-
вязчивая привязанность к компоновке приводит к неспособности
оценить потенциальные возможности среды. Интернет инте-
рактивен. И для максимального использования его потенциала
следует обращать внимание не только на внешний вид.
В этой главе вы узнаете, как же выглядит построение адаптив-
ного интерфейса.
• Как представить адаптивный дизайн в виде набора датчи-
ков.
• Как оптимизировать сайт с учетом скорости Сети и огра-
ниченности данных.
• Почему важен контекст.
• Как создать насыщенный персонифицированный интер-
фейс при помощи API.
Система датчиков
Итан Маркотт (Ethan Marcotte) считает тенденцию разработки
отзывчивой архитектуры источником вдохновения для адаптив-

СИСТЕМА ДАТЧИКОВ 257
ного дизайна1. При отзывчивой архитектуре стены могут изги-
баться и деформироваться при приближении людей. Это макет.
Но отзывчивая архитектура не была бы столь интересной, если
бы на этом все и остановилось. Комнаты также могут менять
свой вид в зависимости от освещенности и температуры. Стекла
можно делать менее прозрачными для сохранения личного про-
странства. На жильцов реагируют не только макет комнаты, но
и окружающая среда и атмосфера.
Если умение адаптироваться эквивалентно умению пользоваться
потенциалом Сети, то мы не можем останавливаться только на
рассмотрении макетов. Нужно создать персональный адаптив-
ный интерфейс, который подстраивается как под нужды и среду
пользователя, так и под возможности и ограничения устройства.
Да, сайты подстраиваются под ширину экрана устройств, но есть
и другие, не менее интересные аспекты, на которые мы можем
обратить внимание.
В своем блоге Марк Бултон (Mark Boulton) упоминает три суще-
ственные для адаптивного дизайна вещи2:
• Датчики. Элементы, умеющие чувствовать среду (не по-
году, а аспекты окружения, какими бы они ни были).
• Системы. Механизмы, получающие информацию от дат-
чиков и определяющие порядок дальнейших действий.
• Исполнительные устройства. То, что выполняет действия.
Двигатели, CSS, кабели.
Если посмотреть на адаптивный дизайн под таким углом, возни-
кает вопрос: какие «датчики» нам доступны? И сразу становится
понятно, что обсуждение должно выйти за пределы адаптации к
размеру экрана. По-настоящему адаптивный интерфейс должен
принимать во внимание еще и такие элементы:
• сеть;
• контекст;
• функциональные возможности.
1 Маркотт И. Отзывчивый веб-дизайн (Манн, Иванов и Фербер, 2012).
2 www.markboulton.co.uk/journal/comments/a-responsive-experience

258 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Интерфейсы устройств
Люк Вроблевски (Luke Wroblewski) предложил в своем блоге другой взгляд на интер-
фейсы для различных устройств.
Он предлагает создавать интерфейсы для каждой классификации устройств. Особое
внимание следует обращать на следующие категории:
• использование/стратегия;
• методы ввода;
• вывод/экран.
Эти категории хорошо вписываются в три аспекта, которые мы будем обсуждать чуть
позже (сеть, контекст и функциональные возможности). Но какой бы способ распре-
деления устройств по категориям вы ни выбрали, вывод всегда будет один: разные
устройства требуют разных требований к компоновке, взаимодействиям и иерархии
контента. Медиазапросы, «резиновая» разметка и «резиновые» изображения — это
только начальная адаптация, которой совершенно недостаточно.
Сеть
Пользовательский опыт сильно зависит от качества и скорости
работы сети. Как обсуждалось в главе 4, производительность
сайта в значительной степени влияет на выбираемые пользова-
телями способы взаимодействия.
К сожалению, характеристики сетей крайне неодинаковы. Су-
ществует огромная разница между высокоскоростным провод-
ным соединением и медленной мобильной сетью. Кроме того,
на производительность влияют местоположение, количество
пользующихся сетью людей, погода, связь — словом, ни о какой
согласованности не может быть и речи.
Возможны также ограничения на передачу данных. По мере
увеличения трафика в мобильных сетях все большее количе-
ство поставщиков предлагают ограниченные тарифные планы
и штрафуют пользователей, потребляющих больше установлен-
ного лимита.

сеть 259
Делать предположения о производительности сети на основе ис-
пользуемого устройства неправомерно. Разумеется, мобильные
устройства по большей части используют медленное соединение
и имеют меньшую по сравнению с настольными коллегами мощ-
ность. Но ничто не мешает подсоединить мобильное устройство
к высокоскоростной беспроводной сети, в то время как портатив-
ный компьютер может быть подключен к медленной мобильной
сети в качестве точки доступа. Поэтому информации о типе
устройства для идентификации свойств сети недостаточно.
По-настоящему адаптивный сайт подстраивается под более
медленные сети или под ограниченный трафик.
Что можно сделать
Изначально нужно стремиться к обеспечению максимальной
производительности вне зависимости от типа соединения или
устройства. По утверждениям пользователей, высокая произво-
дительность — это не дополнительная функция, а обязательное
требование. Вы можете попробовать еще сильнее оптимизиро-
вать интерфейс, собрав информацию о сети. Это можно сделать
двумя способами.
ТЕСТОВАЯ ЗАГРУЗКА ИЗОБРАЖЕНИЯ
Одним из способов проверки скорости сети являются запрос
небольшого изображения и фиксация времени, которое уходит
на выполнение этого запроса.
Вот примитивный вариант подобного теста:
1. van testlmg = document.сгeateElement('img');
2. testlmg.onload = function() {
3. endTime = ( new DateQ ).getTime();
4. var duration = (endTime - startTime) / 1000;
5. //если время превосходит заданное,
загружаем маленькие изображения
6. //в противном случае загружаем большие изображения
7- }
8. startTime = ( new DateQ ).getTime();
9. testlmg.srс = 'http://mysite.com/myimage.gif1;
Это крайне упрощенный пример, но он хорошо иллюстрирует
суть происходящего. Вы создаете изображение при помощи
JavaScript и перед заданием параметра src фиксируете время.

260 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Сразу после задания параметра src автоматически начинается
скачивание изображения.
Как только изображение загружено, вызывается функция onload.
Фиксируется конечное время — и продолжительность загрузки
определена. На основе этой информации можно решить, доста-
точна ли скорость сети для скачивания более тяжелых ресурсов,
например изображений с высоким разрешением. Точность дан-
ного метода невелика, но он вполне подходит для быстрой про-
верки того, высокоскоростная сеть или нет. В большинстве же
случаев потребуются более надежные и точные способы.
NETWORK INFORMATION API
Альтернативным способом проверки типа соединения является
интерфейс Network Information API, предоставляющий информа-
цию о соединениях устройства. Операционная система Android
в настоящее время поддерживает только более старую, ограни-
ченную версию этой спецификации, позволяющую определять
лишь тип используемой сети. Доступ к данной информации
осуществляется крайне просто:
var connection = navigator.connection;
Объект connection в Android реализован, начиная с версии 2.2.
В настоящее время он обладает следующими свойствами:
1. {
2. "type": "1",
3. "UNKNOWN": "0",
4. "ETHERNET" : "1",
5. "WIFI": "2",
7. "CELL_2G": "3",
8. "CELL_3G": "4"
9. }
Свойство type указывает, соединение какого типа используется
устройством в конкретный момент. В данном случае это тип 1
(строка 2). Посмотрев на остальные свойства, мы обнаруживаем,
что 1 означает соединение по технологии Ethernet (строка 4).
Эта информация позволяет, например, выбрать разрешение
предоставляемых для скачивания изображений. Скажем, для
сетей CELL_2G или CELL_3G явно требуются изображения
с низким разрешением.

СЕТЬ 261
Но и эта реализация оставляет место для ошибок. Сеть 3G вполне
может быть быстрой, а сеть Wi-Fi — медленной. Поэтому нам
больше пригодилась бы информация о реальной полосе про-
пускания.
К счастью, существует альтернативная версия данной специ-
фикации, предоставляющая больше сведений. Но реализует ее
в настоящее время только Firefox 12+. Впрочем, также она поддер-
живается ночными сборками WebKit, поэтому со временем можно
ожидать появления версий для Safari, Chrome, iOS и Android.
Для учета различных уровней поддержки нужно проверить еще
несколько значений с префиксами. В остальном применение
интерфейса не должно вызвать затруднений:
1. var connection = navigator.connection || navigator.mozConnection ||
navigator.webkitConnection;
2. //проверка полосы пропускания
3. alert(navigator.connection.bandwidth);
4. //является ли она ограниченной
5. alert(navigator.connection.metered);
Новая версия спецификации уже не содержит свойства type, зато
там появились более полезные свойства bandwidth и metered.
Свойство bandwidth возвращает одно из трех значений:
• 0, если устройство отключено от сети;
• Infinity, если полоса пропускания неизвестна;
• примерное значение полосы пропускания в мегабайтах
в секунду.
Свойство metered возвращает значение true в случае огра-
ниченного доступа (ограничение установлено провайдером)
и false — в противном случае.
Эта информация значительно более полезна. Примерная оценка
ширины полосы пропускания позволяет намного точнее оценить
скорость работы сети, чем информация о ее типе. А сведения об
ограничениях скорости передачи данных или трафика позволяют
принимать решения о реализации операций, требующих пере-
качки больших объемов данных.
Новая спецификация также позволяет задать функцию, которая
будет следить за изменением состояния сети:

262 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
1. function changed(){
2. alert('The bandwidth is now: ' +
navigator.connection.bandwidth);
3. }
4. navigator.connection.addEventListener('change'^ changed, false);
Как только информация о соединении меняется (строка 4), вы-
зывается функция changed(), оповещающая о новой пропускной
способности.
По мере улучшения поддержки данного API разработчики смогут
все более обоснованно принимать решения, касающиеся коррект-
ной загрузки изображений, и запускать процедуры с большим
количеством данных, например опросы, только если соединение
пользователя позволяет с ними работать.
Контекстом
(context) называ-
ются обстоятель-
ства (физические,
обусловленные
окружающими
условиями, по-
веденческие,
социальные и пр.),
в которых исполь-
зуется устройство.
Контекст
Контекст, особенно в отношении мобильных пользователей,
является крайне непонятной темой и порождает множество спо-
ров. К сожалению, многие слишком узко трактуют это понятие,
относя его только к технологиям.
Наиболее явно это проявляется на примере мобильных устройств.
Слово «мобильный» используется удручающе часто. Оно несет
на себе отголосок сложившихся за долгие годы представлений,
что совершенно неправильно. Под контекстом использования
мобильного устройства прежде всего подразумевается поль-
зователь, который делает что-то на ходу. Он никогда не будет
тратить время на бесцельный просмотр страниц — он ищет
строго определенную информацию. При этом у него не очень
много времени, поэтому он хочет найти все как можно быстрее.
Какое-то время данная интерпретация казалась вполне допусти-
мой. Одно слово включало в себя контекст применения и контекст
технологии. Мы представляли себе контекст, обусловленный
окружающими обстоятельствами, и задачи, обусловленные
устройством, находящимся в руках у пользователя.
Это представление базировалось на том, что изначально поль-
зование мобильным Интернетом было крайне неудобным, если
не сказать больше. Медленное соединение, неудобные и ограни-

КОНТЕКСТ 263
ченные методы ввода и устройства, которые могли отображать
только монохромную текстовую версию сайта.
Но времена изменились. Увеличивающаяся популярность смарт-
фонов — в частности, устройств iPhone и Android — показала,
что мобильным Интернетом пользоваться удобно и приятно. Эти
устройства способны предоставить доступ к полному интерфейсу.
И в итоге понятие контекста становится более многогранным.
Люди пользуются мобильными устройствами дома, сидя в лю-
бимом кресле (рис. 9.1). Они берут их в путешествие, где в их
распоряжении остаются только медленные мобильные сети.
Контекст применения становится расплывчатым.
Рис. 9.1. Теле-
фоны перестали
использоваться
исключительно
на ходу, поэтому
определить
контекст
мобильности
уже не так про-
сто, как раньше
Квартальный отчет для журнала Compete в 2010 году показал,
как сильно различается контекст применения смартфонов1:
• 84 % пользуются телефонами дома;
• 80 % — в свободное время;
• 76 % — стоя в очередях;
• 69 % — в процессе совершения покупок;
• 64 % — на работе;
• 62 % — во время просмотра телевизора;
• 47 % — по дороге на работу.
1 http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience

264 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Другое исследование, предпринятое в 2011 году компанией
Google, показало, что статистика может пойти и дальше, потому
что оказалось, что 39 % опрошенных пользуются мобильными
устройствами в ванной!1 Это может означать две вещи. Во-
первых, 61 % опрошенных лжет, во-вторых, данные устройства
можно использовать где угодно.
Проблема с большинством «контекстно» оптимизированных
интерфейсов заключается в отсутствии возможности собрать
информацию, иллюстрирующую истинные намерения поль-
зователей. Обнаружить контекст трудно, а выявить намерения
трудно до смешного. Для более точной оценки следует учитывать
следующие критерии:
• историю поведения;
• местоположение;
• время;
• погоду;
• расположенные рядом объекты;
• близость друзей, толпы, врагов;
• перемещения пользователя.
Марк Кирби (Mark Kirby) из компании Ribot писал: «Фундамен-
тальные решения по поводу контента нельзя принимать, пытаясь
читать мысли»2. И он совершенно прав. Трудно тщательно анали-
зировать, насколько мы готовы оптимизировать интерфейс, взяв
за основу пока крайне ограниченное знание контекста. Помните,
что этот аспект мы не в состоянии контролировать, его опреде-
ляет только сам пользователь. Как говорит Жиль Колборн (Giles
Colborne): «Вы не можете выбирать обстановку, в которой люди
будут пользоваться вашим программным обеспечением. Но вы
должны оптимизировать свое детище под нее»3.
При всей своей расплывчатости контекст имеет значение и при
наличии надежной информации превращается в весьма мощный
инструмент. Рассмотрим классический пример с сайтом музея.
1 http://www.google.com/think/research-studies/the-mobile-movement.html
2 http://mark-kirby.co.uk/2011/the-mobile-context/
3 Colborne G. Simple and Usable Web, Mobile, and Interaction Design (New Riders,
2010).

КОНТЕКСТ 265
Если вы сможете точно определить, что человек, зашедший на
сайт, уже находится в музее, ему будет предоставлен оптимизиро-
ванный для этого случая интерфейс. Основной упор будет сделан
на такой информации, как карта экспозиций, вместо сведений
о билетах и прочих аспектах, необходимых на этапе, когда визит
только планируется.
Как любитель научной фантастики, я считаю разговоры о кон-
тексте крайне важными. В подобных книгах часто упоминается
некая повсеместно распространенная технология. Она адапти-
руется в зависимости от контекста, обеспечивая пользователей
по-настоящему отзывчивым к их нуждам интерфейсом, причем
в любой ситуации. Портативные устройства, в частности мо-
бильные телефоны, обладают подобным потенциалом. Если мы
не продолжим экспериментировать с контекстом, мы предадим
технологию.
Классификация контекстов
Для начала расширим наше восприятие контекста. Перестаньте
определять его как мобильный (тем более что это бесполезно),
а представьте в виде комбинированного изображения или при-
вяжите к положению пользователя.
КОМБИНИРОВАННОЕ ИЗОБРАЖЕНИЕ
В своей презентации 2007 года Ник Финк (Nick Finck) предложил
рассматривать контекст как совокупность четырех аспектов1.
• Пользователь. Кто ваш пользователь? Каковы его нужды?
• Задача. Какую задачу пользователь пытается решить?
• Окружение. В каком окружении находится пользователь
как с физической, так и с социальной точек зрения?
• Технология. Какая технология предоставлена пользова-
телю и что она умеет?
Рассмотрение контекста как совокупности этих аспектов создает
более точное представление о том, какими способами будет ис-
пользоваться ваш сайт. Также сразу становится понятно, каким
сложным может быть контекст и почему он не может сводиться
www.slideshare.net/nickf/contextual-web

266 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
к тривиальным «мобильный» и «для настольных компьютеров».
Он определяется не одним критерием, а их совокупностью.
ПОЛОЖЕНИЕ ПОЛЬЗОВАТЕЛЯ
Полезно также попытаться учесть положение пользователя.
Например, американская компания Netflix при выборе спосо-
бов оптимизации интерфейса предпочитает учитывать, сидит
пользователь или находится на ногах, развалился в кресле или
делится опытом с друзьями.
Еще раз напомню, что попытки представить контекст использо-
вания помогают точнее разработать пользовательский интерфейс.
Разумеется, вы не сможете предугадать позу пользователя, но
имеет смысл учитывать этот аспект при разработке.
Наблюдайте и исследуйте
Говоря о контекстах, люди концентрируются на небольшом
количестве легко доступных данных, пытаясь определить кон-
текст программно. Это здорово и подчеркивает ценность сбора
контекстуальных ключей при помощи различных датчиков. Но
ничто не способно заменить наблюдений.
Как писал в своей книге Адам Гринфилд (Adam Greenfield)1:
Мы должны помнить, что несмотря на цифровую природу инфор-
мационных технологий взаимодействия пользователей с устрой-
ствами останутся раздражающе и прекрасно аналоговыми.
Для полноты и точности исследований они должны сочетать
в себе количественные (такие как анализ) и качественные (такие
как интервью) методы.
Следите за статистическими данными, чтобы понять, как ведут
себя люди. Какие страницы они посещают и какие устройства
при этом применяют? Не являются ли некоторые страницы более
популярными у пользователей определенных устройств (напри-
мер, планшетов по сравнению с настольными компьютерами)?
Зависят ли количество посещенных страниц и продолжитель-
ность их просмотра от устройства или местоположения? Все эти
1 Greenfield A. Everyware: The Dawning Age of Ubiquitous Computing (New Riders,
2006).

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 267
вещи позволяют понять, каким образом пользователи взаимо-
действуют с вашим сайтом.
Проводите опросы среди пользователей, чтобы определить их
цели и зависимость этих целей от контекста доступа к сайту. Но
помните о недостаточной точности полученных таким способом
данных: интервьюируемые имеют склонность к преувеличению
тем или иным способом.
Имеет смысл также понаблюдать за поведением пользователей.
Можно поставить перед опрашиваемыми определенную задачу
и смотреть, как именно они ее выполняют, или пойти в ближай-
ший магазин и наблюдать, как люди взаимодействуют со своими
устройствами.
Функциональные
возможности
Разные устройства обладают разными функциональными воз-
можностями. Прогрессивное улучшение позволяет восполь-
зоваться преимуществом более продвинутых в техническом
отношении аппаратов, создав для них более мощный интерфейс.
Типы ввода в HTML5
Вероятно, самым простым способом оптимизации является
применение типов ввода данных из HTML5 везде, где это обо-
сновано. Исторически существовало ограниченное количество
вариантов полей ввода, и чаще всего ввести в них можно было
только обычный текст.
С появлением HTML5 количество дополнительных вариантов
расширилось. В частности, для мобильных устройств появились
следующие поля ввода:
• email — для адресов электронной почты;
• tel — для телефонных номеров;
• number — для ввода чисел;
• url — для адресов URL.

268 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Сохранение статей
Замечательным примером извлеченной из более
совершенных технических возможностей выгоды явля-
ется адаптивный сайт газеты Boston Globe. Понимая,
что у читателей может возникнуть желание вернуться
к некоторым материалам позже, они реализовали
функцию My Saved. Она позволяет сохранить статью.
И доступ к этой функции сейчас есть у всех пользо-
вателей независимо от имеющихся у них устройств.
Затем был сделан еще один шаг. Многие устройства
позволяют сохранять контент для локального исполь-
зования. Благодаря этому посетители получили воз*
можность читать статьи в любое время вне зависимо-
сти от наличия интернет-соединения.
Это замечательный способ извлечения выгоды из
функциональности современных устройств. Плоды
тщательного анализа ситуации позволили кардинально
улучшить интерфейс.
Все это помогает браузеру понять, данные какого типа ожидаются
в конкретном случае, и соответствующим образом оптимизи-
ровать интерфейс. Типы ввода просты в применении, а если
устройство их не поддерживает, всегда остается возможность
ввести обычный текст.
Представим, что данное поле формы предназначено для ввода
адресов электронной почты:
<input type="text" name="email" id="email" />
При просмотре страницы с мобильного устройства вы увидите
обычную клавиатуру. А теперь укажем в качестве типа email.
<input type="email" name="email" id=IIemail" />
После этого на устройствах с iOS вы увидите рядом с клавишей
пробела знак @ (рис. 9.2). Это сделано для упрощения набора
адреса. Маленький, но полезный вариант оптимизации.

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 269
Рис. 9.2. Когда
операционная
система видит
тип ввода email,
раскладка кла-
виатуры слегка
меняется (справа)
Операционная система Android никак не оптимизирует процесс
ввода адреса электронной почты, зато Android и iOS меняют
клавиатурную раскладку для полей других типов (рис. 9.3).
Рис. 9.3. Ука-
зание типов
ввода из языка
HTML5, таких как
url (слева) и tel
(справа), застав-
ляют устройство
оптимизировать
вид клавиатуры

270 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Люк Вроблевски
ЗА ПРЕДЕЛАМИ МАКЕТА
Люк Вроблевски (Luke Wroblewski) является лидером в производ-
стве цифровой продукции. Он разработал или принял участие
в разработке программного обеспечения, которое используется
более чем 700 млн людей по всему миру. Также Люк написал три
популярные книги о веб-дизайне (книга Mobile First переведена на
русский и названа «Сначала мобильные»).
Экраны для ввода личных данных не функ-
ционируют. Почти 82 % пользователей
забывали свои пароли, и самым распро-
страненным запросом к службам техниче-
ской поддержки является именно запрос
на восстановление пароля1. Это добавляет
работы, увеличивает затраты и расстраивает
клиентов.
До настоящего момента при рассмотрении
такого важного взаимодействия, как авто-
ризация, на различных устройствах учи-
тывали в основном вид макета. Важен был
«правильный» вид интерфейса на малень-
ких, средних и больших экранах (в качестве
примера можете посмотреть на страницу
авторизации Windows Live). Несмотря на
замечательный внешний вид, эти решения
несут в себе все существующие проблемы
страниц авторизации, не задействуя много-
численные возможности оптимизации.
Страница авторизации сайта Windows Live
в браузере для настольного компьютера и для
мобильного устройства
navigator_sertdMessage( •.>■■•);• u:r\r
boncli.messaging.sybsciibeToSMSC.
wvMltAew.com/ff/entry.asp?1487
Вариант страницы авторизации, на которой для
идентификации пользователя применяются
фоновые SMS-сообщения

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 271
В Windows 8 для
авторизации исполь-
зуются личные фото-
графии и заранее
заданные жесты
Представив, каким образом уникальные
функции различных устройств могут при-
меняться в процедуре авторизации, мы
сможем найти решение за пределами адап-
тивного макета. Например, мобильные
устройства умеют отправлять и получать
текстовые сообщения. Вместо того чтобы
заставлять людей вводить имя пользова-
теля/адрес электронной почты и пароль
в поля формы при помощи маленькой
неудобной клавиатуры, можно ограничить
всю операцию нажатием одной кнопки для
отправки SMS, подтверждающего их права
доступа. И ничего печатать не нужно!
Разумеется, SMS — не единственная функ-
ция, которую мы можем задействовать.
Устройства с сенсорными экранами могут
применять для авторизации уникальные
жесты. В операционной системе Windows 8
эта процедура реализована именно так:
человек выбирает изображение и задает
графический пароль при помощи набора
линий, окружностей или касаний. Для авто-
ризации достаточно воссоздать данный жест
на выбранной картинке.
Как видите, мы уже вышли за пределы реше-
ния, ограниченного адаптивным макетом.
Более того, предложенный фирмой Microsoft
новый вариант авторизации по своей форме
более предпочтителен. В конце концов, что
для вас проще, нарисовать несколько линий
на фотографии вашей семьи или ввести
строку требуемой длины из букв верхнего
и нижнего регистра и цифр в маленькое поле,
в котором в ответ появляется только •♦••••?
Без попыток отстраниться от идеи адапта-
ции макетов и задействовать новые функ-
циональные возможности устройств мы
надолго застряли бы на этапе ••••••, упустив
замечательный шанс сделать лучше своим
клиентам и себе.

272 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
API
Поля ввода в формах — это только начало. Одним из самых
привлекательных способов извлечь выгоду из уникальных ха-
рактеристик устройств является использование API.
Устройства оснащают все большим числом самых разных дат-
чиков, позволяющих определять местоположение, ориентацию
и другие условия эксплуатации. Все эти сведения дают удиви-
тельную возможность создать по-настоящему персональный
и оптимизированный под пользователя интерфейс.
GEOLOCATION API
Рассмотрим страницу, на которой можно найти магазин. Шире
всего распространена реализация, основанная на указании место-
положения. Вы выбираете район или индекс, а сайт возвращает
адреса ближайших к вам магазинов. Но есть и лучший способ.
Одним из наиболее хорошо поддерживаемых интерфейсов для
устройств является Geolocation API. Он позволяет создать на-
много лучшие значения по умолчанию для пользователей сайта.
Чтобы познакомиться с этим API, давайте попробуем определить,
как далеко вы находитесь от известной гостиницы Lambeau Field
в городе Грин-Бей, штат Висконсин.
Структура HTML в данном случае очень простая:
i. <html>
г. <head>
3. <title>6eolocation</title>
4. <meta name="viewport" content=Hwidth=device-width" />
s. </head>
6. <body>
7. <p>Testing the Geolocation API.</p>
8. <div id="results"x/div>
9. </body>
le. </html>
Сценарий JavaScript вставляется перед закрывающим тегом body.
Первым делом нужно убедиться в том, что устройство поддер-
живает Geolocation API. В реальности на этом этапе правильно
было бы озаботиться предоставлением резервного способа по-
лучения информации (например, обеспечением возможности
ввода индекса). Выбор такого варианта полностью зависит от

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 273
того, каким образом осуществляется работа с сайтом. Но так
как мы рассматриваем демонстрационный пример, ограничимся
выводом текстового сообщения об отсутствии поддержки API:
1. <script type="text/javascript">
2. var results ■ document.getElementById('results');
3. //проверка наличия поддержки
4. if (navigator.geolocation) {
5. // ура! Геопозиционирование поддерживается
6. } else {
7. results.innerHTML = 'Увы, геопозиционирование
не поддерживается.';
8. }
9. </script>
Строка 1 берет элемент, в который вставляются результаты про-
верки местоположения.
В строке 4 сценарий проверяет наличие свойства geolocation.
Положительный результат означает, что вам повезло и устрой-
ство поддерживает геопозиционирование. В противном случае
на экране появится информационный текст.
При наличии поддержки геопозиционирования вы можете
получить доступ к местоположению пользователя при помощи
метода getCurrentPosition:
1. if (navigator.geolocation) {
2. navigator.geolocation.getCurrentPosition(function(pos) {
3. alert(pos.coords.latitude);
4. alert(pos.coords.longitude);
5. }, function(error) {
6. //увы!
7. alert('Проблема! Код ошибки: ' + error.code);
8. });
9. }
Строки 2-5 проверяют текущее местоположение пользователя
и сообщают ему его координаты: широту (строка 3) и долготу
(строка 4).
Строки 5-8 задают функцию, которая при отсутствии доступа
к местоположению пользователя будет вызывать сообщение об
ошибке.
Рис. 9.4. При
попытке
доступа
к Geolocation
API появится
сообщение,
спрашиваю-
щее вашего
разрешения
на доступ
к координатам

274 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
При открытии этой страницы в браузере будет появляться при-
глашение с вопросом, хотите ли вы сообщить сайту свое местопо-
ложение (рис. 9.4). Это важный для безопасности шаг, и отвечать
на вопрос при каждой загрузке страницы не требуется.
Пойдем дальше. Чтобы определить, как далеко от гостиницы
Lambeau Field вы находитесь, нужно знать координаты гостиницы.
Кроме того, не обойтись без функции, вычисляющей расстояние
по паре координат.
Координаты гостиницы можно сохранить в переменной:
var lambeau = {
"laf : 44.5013805,'
•long1 : -88.062*25
}
Функция вычисления расстояния немного сложнее в математи-
ческом отношении.
Алгоритм доступен под лицензией Creative Commons благодаря
платформе Movable Type (www.movable-type.co.uk/scripts/latlong.html):
1. //creative commons distance function
2. function calculateDistance(latl, lonl, Iat2, Ion2) {
3. var R = 3959; // miles
4. var dLat = (Iat2 - latl).toRad();
5. var dLon = (Ion2 - lonl).toRad();
6. var a = Math.sin(dLat / 2) * Math.sin(dLat / 2) +
Math, cos (latl.toRadQ) * Math.cos(lat2.toRad()) *
Math.sin(dLon / 2) * Math.sin(dLon / 2);
7. var с = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(l - a));
8. var d = R * c;
9. return d;
10. }
11. Number.prototype.toRad = function() {
12. return this * Math.PI / 180;
13. }
Конечным результатом работы этой функции является рас-
стояние в милях между двумя точками. Я не буду вдаваться
в подробности его вычисления, так как это довольно сложно.
Интересующиеся могут самостоятельно почитать в Интернете
о формуле гаверсинуса.
Теперь, вооруженные знанием координат гостиницы Lambeau
Field и умением вычислять расстояние между двумя точками, мы
легко можем написать следующие строки кода:

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 275
//проверка наличия поддержки
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(function(pos) {
results.innerHTML += "<p>Only " + calculateDistance
(pos.coords.latitude, pos.coords.longitude, lambeau.lat,
lambeau.long) + " miles from hallowed Lambeau Field.</p>";
}, function(error) {
alert('Проблема! Код ошибки: ' + error.code);
});
В строке 3 ваши координаты и координаты гостиницы переда-
ются в функцию calculateDistance. Она возвращает расстояние
в милях и добавляет его в элемент results (рис. 9.5).
Testing the geolocation API.
Only 105Л1465752151724 raiics from babwed Lambeau Field.
Рис. 9.5. Сложные математические вычис-
ления позволяют Geolocation API показать
расстояние от вас до пункта назначения
Это простой пример, но мы можем его расширить.
Скажем, при работе с устройством, которое используется на ходу,
не помешает видеть примерное направление движения к цели.
Координаты широты и долготы позволяют вычислить угол между
направлениями и показать стрелку, указывающую на объект:
<span id="arrow">&#8593;</span>
Функция calculateBearing также взята со страниц Movable Type:
1. function calculateBearing(latl, lonl, Iat2, Ion2) {
2. return Math.atan2(
3. Math.sin(lon2 - lonl) * Math.cos(Iat2),
4. Math.cos(latl) * Math.sin(Iat2) -
5. Math.sin(latl) * Math.cos(Iat2) *
6. Math.cos(Ion2 - lonl)
7. ) * 180 / Math.PI;
8. }
Теперь можно обновить код, включив проверку направления
в процедуру вычисления местоположения:
1. if (navigator.geolocation) {
2. navigator.geolocation.getCurrentPosition(function(pos) {
3. results.innerHTML += lf<p>Only " + calculateDistance
(pos.coords.latitude, pos.coords.longitude, lambeau.lat,
lambeau.long) + " miles from hallowed Lambeau Field.</p>";
4. var bearing = calculateBearing(pos.coords.latitude,
продолжение

276 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Рис. 9.6. Немного
дополнительных
усилий, и поль-
зователь получит
возможность
увидеть, в каком
направлении ему
следует двигаться
5.
6.
7.
8.
9.
18.
11.
12.
13
14. }
pos.coords.longitude, lambeau.lat, lambeau.long);
var arrow = document.getElementById('arrow1);
arrow.style.transform = 'rotateZ(' + bearing + 'deg)';
arrow.style.msTransform = *rotateZ(' + bearing + 'deg)1;
arrow.style.mozTransform = 'rotateZ(' + bearing + 'deg)';
arrow.style.webkitTransform = 'rotateZ(' + bearing + 'deg)';
, function(error) {
//Неудача!
alert('Проблема! Код ошибки: ' + error.code);
От предыдущей версии она отличается небольшими дополнени-
ями. Строка 4 теперь вычисляет отклонение в градусах. Строка 5
берет стрелку, и в строках 6-10 она поворачивается при помощи
преобразования rotateZ из CSS3. Теперь при загрузке сайта
в поддерживающий геопозиционирование браузер вы увидите
стрелку, указывающую направление на Lambeau Field (рис. 9.6).
Testing the geolocation API.
Only 105.11465752151724 miks from hallowed Lambeau Field.
Вы можете спросить, зачем эта стрелка на настольных компьюте-
рах, и будете совершенно правы. Сложно представить человека,
который будет прогуливаться с включенным ноутбуком в попытке
определить местоположение объектов.
Но на смартфонах и планшетах польза от стрелки несомненна.
Можно запрашивать свое местоположение каждые несколько
секунд, обновляя ориентацию стрелки (и расстояние до объекта),
что в итоге приведет вас к нужной цели. Это простое, но эффек-
тивное улучшение пользовательского интерфейса.
Посмотрим на более современные варианты применения API-
устройств, чтобы получить представление об их потенциале.
MEDIA CAPTURE API
Интерфейс Media Capture API предоставляет программный
доступ к камере и микрофону устройства при помощи метода
getUserMedia. Он уже поддерживается как браузером Opera

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 277
Mobile, так и специальными сборками Chrome Canary. Mozilla на-
деется встроить полную поддержку Media Capture API в Firefox 17.
Как и в случае с множеством других API-устройств, остается
только удивляться, сколького можно добиться при помощи не-
большого кода.
Создание компаса
Благодаря встроенному датчику поворота экрана устройства с доступом к Интернету
могут показать свою ориентацию. Например, многие телефоны используют эти све-
дения для поворота экрана при повороте самого устройства. Изменение ориентации
устройства приводит к событию deviceorientation.
Последние сборки WebKit, реализованные в iOS5, добавили к этому событию два экс-
периментальных свойства: webkitCompassHeading и webkitCompassAccuracy. Первое
возвращает направление относительно северного полюса в градусах. Например,
истинный север находится на 0 °, направлению на восток соответствует значение 90 °.
А свойство webkitCompassAccuracy предоставляет сведения о точности наведения.
Скажем, если оно имеет значение 5, точность наведения составляет ±5 °.
При помощи этого API Джеймс Пирс (James Реагсе), глава отдела по связям с раз-
работчиками социальной сети Facebook, создал компас, построенный целиком
на HTML, CSS и JavaScript. Владельцы смартфонов iPhone могут зайти на страницу
http://jamesgpearce.github.com/compios5 и оценить демонстрационную версию,
В процессе перемещения телефона в пространстве стрелка меняет свое положение
в соответствии с направлением.
Этот полностью функциональный компас построен исключительно средствами
HTML, CSS и JavaScript.

278 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Для демонстрационных целей возьмем несложный HTML-код:
1. <html>
2. <head>
3. <meta name=Mviewport" content="width=device-width" />
4. <style type="text/css">
5. #canvas{
6. background: #eee;
7. border: lpx solid #333;
8. }
9. </style>
10. </head>
11. <body>
12. <video id="myVid" width-"390" height="375"
autoplayx/video>
13. <input id*"camera" type»"button"
disabled="true" value="Take Photo"></input>
14. <canvas id»"still" width="300" height«"375"x/canvas>
is. </body>
16. </html>
Действий тут немного, но незнакомые с HTML5 могут обнару-
жить несколько непонятных элементов.
Элемент <video> позволяет встраивать видео, не прибегая к тех-
нологии Flash. Обычно тут указывается источник видеофраг-
мента, но в приведенном ранее примере мы динамически на-
строили его на использование камеры, поэтому пустой элемент
прекрасно работает.
Элемент <canvas> позволяет рисовать различные объекты при
помощи JavaScript. Можно отображать текст, фотографии, ани-
мацию, графики — все что угодно. В приведенном примере на
холсте появится фотография, как только владелец камеры сделает
снимок.
Теперь нам требуется несколько строчек JavaScript, чтобы за-
ставить работать камеру. Добавьте на странице сразу после за-
крывающего тега body следующий код:
1. <script>
2. navigator.getUserMedia({video: true}, function(stream) {
3. var video « document.getElementById("video");
4. var canvas = document.getElementById("still");
5. var button ■ document.getElementByld("camera");
6. video.src = stream;
7. button.disabled = false;
8. button.onclick ■ functionQ {
9. canvas.getContext("2d").drawlmage(video, 0, 0);

ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ 279
п. Ь function(err) { alert("there was an error " + err)});
12. </script>
Строка 2 вызывает метод getUserMedia, который принимает
три аргумента. Первый указывает устройству, к какой среде нам
требуется доступ. Этот аргумент должен быть передан как объект
JavaScript. В данном случае мы передаем объект {video: true},
указывая, что нужен доступ только к видео. Для получения до-
ступа как к видео, так и к аудио используйте выражение {audio:
true, video: true}.
При попытке доступа к камере пользователю будет предложено
разрешить или запретить доступ аналогично тому, как это проис-
ходило в Geolocation API. Вторым аргументом является функция,
которая запустится, если доступ будет разрешен. Бели метод
обратного вызова успешно начал работу, поток предоставляется
обратно пользователю. Третий же аргумент является функцией,
которая запускается в случае отказа в доступе. Это необязатель-
ный аргумент.
Строки 3-5 берут видео, кнопку, которая позволяет сделать
фотографию, и холст, на котором эту фотографию потом можно
будет отобразить.
Строка 6 задает свойство sre видео как поток, который устрой-
ство передает обратно в код. Строка 7 активизирует кнопку.
Отключать кнопку по умолчанию вовсе не обязательно, но
в принципе в этом есть смысл. Так как, предоставляя камере
сайта доступ, пользователь может получить проблемы с безопас-
ностью, отключенная по умолчанию кнопка является визуальной
подстраховкой.
Ну и, наконец, функция в строках 8-10 ищет кнопку, которую
требуется нажать. После этого она выводит изображение на холст
при помощи метода drawlmage. Первый параметр (в приведен-
ном ранее примере это видео), переданный методу drawlmage,
относится к выводимому изображению.
Следующие два параметра — это координаты х, у точки вывода
изображения. В приведенном ранее примере, передав значе-
ние "0, 0", мы заставили браузер отобразить снимок в верхнем
левом углу холста.

280 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Рис. 9.7. При
загрузке стра-
ницы в браузере
Opera Mobile
появляется видео
в реальном вре-
мени от встроен-
ной в устройство
камеры (слева).
Щелчок на
кнопке Take
Picture приводит
к появлению под
этой кнопкой
статичного кадра
(справа)
При загрузке страницы в браузере Opera Mobile (который должен
присутствовать на любом устройстве Android) вам предлагается
дать сайту доступ к камере. Если вы примете это предложение,
на экране камеры появится поток видео в реальном времени.
При нажатии кнопки Take Picture на холсте под кнопкой появится
снимок (рис. 9.7).
Это не только эффектная, но и полезная возможность. Пред-
ставьте сайт с пользовательскими профилями. Можно дать поль-
зователям возможность с помощью этих устройств моментально
делать фотографии и помещать их на аватар.
API БУДУЩЕГО
По мере появления все новых и новых API-устройств разработ-
чики получат возможность создавать сайты и приложения, срав-
нимые с технологиями из современной научной фантастики —
отзывчивые технологии, о которых мы пока только мечтаем.
И я надеюсь, что применение этих API станет для нас привыч-
ным делом. Способность взаимодействовать с устройством на
подобном уровне — это аспект, который ранее был просто не-
возможен. Поэтому сейчас мы не имеем права останавливаться

подводя итоги 281
на оптимизации одних только макетов. В противном случае
мы добровольно откажемся от потенциала, который имеет эта
уникальная среда.
Интерфейсы Geolocation и Media Capture — это только начало.
Вот еще несколько API, разрабатываемых в настоящее время
(табл. 9.1).
Таблица 9.1 API-устройства
аи -
Contacts API Чтение, добавление и редактирование контактных данных,
хранящихся на устройстве
Messaging API Отправка и получение SMS-сообщений, а также управление ими
Calendar API Чтение, добавление и редактирование календаря
Battery Status API Слежение за уровнем заряда батареи и за тем, подключено ли
устройство к сети
Vibration API Управление вибрацией для обеспечения тактильной обратной связи
Sensor API Доступ к таким датчикам, как датчик поворота экрана, освещенность,
магнитное поле и расстояние до объектов
HTML Media Capture Взаимодействие с камерой/микрофоном через HTML-формы
Web Intents Интеграция веб-приложений путем обнаружения служб на стороне
клиента
Подводя итоги
Переход к новой среде является непростым делом. Люди имеют
склонность привязываться к привычным и удобным вещам, но
со временем нам удается сбросить ограничения старых сред
и принять новые правила игры.
Интернет — это не набор документов, а интерактивная среда.
Нужно перерасти наше увлечение макетами и приступить к по-
строению отзывчивых интерфейсов. Представление адаптивного
дизайна в виде набора датчиков помогает расширить количество
методов работы.

282 ГЛАВА 9. АДАПТИВНЫЕ ИНТЕРФЕЙСЫ
Сети различаются по своим характеристикам коренным образом,
что в значительной степени влияет на опыт работы пользователя.
По-настоящему адаптивный интерфейс принимает этот фак-
тор во внимание и вносит в себя соответствующие изменения.
В настоящее время доступный инструментарий ограничен, но
Network Information API открывает перед нами новые возмож-
ности.
Варьируется и контекст применения устройств. Нужно быть
крайне осторожными с использованием таких категорий, как
«мобильный». Контекст является сложным понятием, учитыва-
ющим влияние пользователя, задачи, технологии и окружающей
среды. Его суть невозможно передать всего одним словом. По-
этому при разработке сайтов учитывайте все перечисленные
аспекты.
Различные устройства обладают разными возможностями. Диа-
пазон этих возможностей простирается от простых вещей, таких
как различные способы заполнения форм, до сложных примеров
с применением API-устройств. Некоторые из этих API, напри-
мер геопозиционирование, позволяют сделать современный
интерфейс более персональным. По мере реализации все новых
API мы сможем создавать адаптивные интерфейсы, о которых
ранее и не мечтали.

Послесловие
Глядя в будущее
Технология — это не ограничивающий фактор,
а только наше желание вообразить
другое будущее.
Скотт Джексон

284 ПОСЛЕСЛОВИЕ. ГЛЯДЯ В БУДУЩЕЕ
Автомобиль 2013
Ford Fusion осна-
щен сенсорным
8-дюймовым
экраном и техно-
логиями компа-
нии SYNC
Проблемами работы в такой динамической среде, как Интернет,
являются удивительное разнообразие и быстрая эволюция. Но
одновременно это вызывает энтузиазм. Адаптивный дизайн —
это только начало. Это шаг к реализации потенциала Сети, но
всего один шаг. Представляя Интернет с точки зрения существу-
ющего многообразия, вы готовитесь к будущему.
В этой книге рассматривались в основном настольные компью-
теры, мобильные устройства и планшеты. Но скоро ожидается
настоящая лавина. На горизонте маячит умное телевидение, неся
с собой целый клубок новых проблем. Многие телевизоры имеют
то же самое разрешение, что и ваши рабочие мониторы. Вы не
сможете обойтись только редактированием макета, чтобы создать
продукт, одинаково хорошо воспринимаемый как пользовате-
лем, сидящим в полуметре от монитора, так и пользователем,
находящимся в паре метров от экрана. Растет и популярность
автомобилей с сетевыми возможностями. Фирмы Mercedes-Benz,
Ford и Audi уже продают машины с подключением к Интернету.
Можно подвергать сомнению безопасность встроенных в при-
борную панель приложений, но тем не менее их уже разраба-
тывают.
Автомобили и телевизоры — это только начало. Разрабатыва-
ется идея подсоединения к Сети таких устройств, как пылесосы,
оконные стекла и даже холодильники.

ГЛЯДЯ В БУДУЩЕЕ 285
Во введении я упоминал статью Скотта Дженсона (Scott Jenson)
о грядущем зомби-апокалипсисе устройств1. По мере удешевле-
ния технологий количество подсоединенных к Сети устройств
будет быстро расти. Интернет не является платформой; огра-
ниченной одним устройством.
Уже реализованы примитивные варианты перемещения кон-
тента. Такие службы, как Instapaper и Readability, позволяют
найти объект на Рабочем столе, сохранить его и позже прочитать
на телефоне или планшете.
В октябре 2011 года организация W3C анонсировала начало ра-
боты над спецификацией, направленной на обнаружение близко
расположенных устройств2. Это позволит перевести процедуру
перемещения контента на совсем иной уровень. Например,
можно будет при помощи телефона обнаруживать различные
материалы и включать их воспроизведение на ближайшем теле-
визоре.
1 http://designmind.frogdesign.com/blog/the-coming-zombieapocalypse-small-cheap-devices-will-disrupt-
our-old-school-ux-assumptions.htm
2 www.w3.org/QA/2011/10/web_applications_discovering_a.html
Одна шведская
телекомпания
позволяет син-
хронизировать
телефон с браузе-
ром для удален-
ного управления
воспроизве-
дением видео
на настольном
компьютере

286 ПОСЛЕСЛОВИЕ. ГЛЯДЯ В БУДУЩЕЕ
Контроллер jsdo.it
позволяет с теле-
фона управлять
космическим
кораблем в брау-
зере настольного
компьютера
Такие технологии, как WebSockets, уже поддерживаемые браузе-
рами Internet Explorer 10, Chrome 17+ и Firefox 11+ и частично
поддерживаемые в Safari, Opera, iOS и Opera Mobile, позволяют
открывать сеансы между браузером и сервером для последую-
щего взаимодействия. В результате появляется возможность
многопользовательского взаимодействия и взаимодействия
множества устройств.
Расстояние между устройствами быстро сокращается. Так же бы-
стро следует избавляться от концентрации только на компоновке
страниц. Чем больше устройств подсоединяются к Интернету,
тем сложнее становится игнорировать интерактивную природу
этой среды. Нужно отвлечься от уже имеющихся в нашем рас-
поряжении устройств и принять все их многообразие.
Интернет — это удивительно мощная среда, способная реаги-
ровать на произвольное количество датчиков и выходить за
физические границы устройства. Давайте бросим вызов самим
себе и перестанем довольствоваться адаптивными макетами.

Благодарности за фото
ПРИМЕРЫ НА САЙТЕ
Фотография Джейла Ахерама со страницы www.flickr.com/photos/aheram/440478825.
Фотография Джека Ридквиста со страницы www.flickr.com/photos/chaos123115/2994577362.
Фотография Эдда Юрдона со страницы www.Mr.com/photos/yourdon/3890007962.
Фотография Тревора Мантернаха со страницы www.flickr.com/photos/trvr3307/2352092039.
ГЛАВА 1
Страница 26: Фотография Криса Хариссона, университет Карнеги-Мелон. Ис-
пользуется с разрешения.
Страница 32: Фотография из книги Adaptive Web Design: Crafting Rich
Experiences with Progressive Enhancement Аарона Густавсона. Фото использу-
ется с разрешения.
ГЛАВА 4
Страница 126: Фотография Джона Мартинеза Палвиги со страницы www.flickr.
com/photos/virtualsugar/2972610947.
Страница 135: Правами на иллюстрации обладает Гринвичская королевская
обсерватория.
ГЛАВА 5
Страница 152: Фотография Люка Вроблевски со страницы www.flickr.com/photos/
lukew/7382743430/in/set-72157630151452558. Используется с его разрешения.
Страница 169: Фотография Джереми Вандела со страницы www.flickr.com/photos/
jeremy_vandel/4279024627.
ГЛАВА б
Страница 188: Фотография Джереми Кейта со страницы www.flickr.com/photos/
adactio/2888167827.
Страница 193: Фотография Дэвида Фалмера со страницы www.flickr.com/photos/
daveynin/6027218091.
ГЛАВА 9
Страница 263: Фотография Элка Деккера со страницы www.flickr.com/photos/
eeikedekker/5339017351.

06 авторе
Тим Кадлек работает веб-разработчиком в северном Висконсине.
Его опыт работы с малыми компаниями, крупными издатель-
ствами и индустриальными корпорациями дал возможность
понаблюдать, как правильное применение веб-технологий влияет
на бизнес любого размера.
Тим является одним из учредителей конференций Breaking
Development, посвященных веб-дизайну и разработке для мо-
бильных устройств. Он обожает Интернет и часто выступает с докладами о своих
наработках на различных конференциях.
Он написал ряд материалов для книги «Web Performance Daybook Volume 2», также
с его творчеством можно познакомиться в блоге http://timkadlec.com и в Твиттере @tkadlec.
Тим с женой и тремя дочерьми проживает в маленьком городе Три Лейке, штат
Висконсин.
О научном редакторе
В 2000 году Джейсон Григсби приобрел свой первый мобильный
телефон. И его захватила идея, насколько лучше стал бы наш мир,
если бы у каждого в кармане появилось устройство, дающее до-
ступ к любой информации. Эти мечты разбились о суровую реаль-
ность — протокол WAP оказался неудачным. Поэтому Джейсон
пошел работать в Интернет и занимался этим до 2007 года, когда
появился первый смартфон и стало ясно, что его час пробил. Он
объединился с тремя самыми умными людьми, которых знал, и основал фирму
Cloud Four.
После этого ему повезло работать над множеством фантастических проектов,
включая приложение Obama э08 для iPhone. Джейсон является основателем и пре-
зидентом компании Mobile Portland, локальной некоммерческой организации, за-
нимающейся развитием в городе Портленд штата Орегон мобильного сообщества.
Джейсон является соавтором книги «Разработка веб-сайтов для мобильных
устройств» и востребованным оратором и консультантом по сотовым телефонам.
Теперь он увлечен ими намного сильнее, чем это было в 2000 году. Он ведет блог
http://cloudfour.com, имеет персональный сайт http://userfirstweb.com, а также доступен
в Твиттере как @grigs.