Основы адаптивной типографики

Автор: Оливер Райхенштайн (OLIVER REICHENSTEIN), 1 июня 2012
Оригинал: http://ia.net/blog/responsive-typography-the-basics/
Адаптированный перевод: Егор Стремоусов, 1 ноября 2013

Раньше создание сайта мы начинали с определения базовых параметров шрифта. Он диктовал, какой будет ширина основной колонки с текстом, а все остальные элементы выстраивались сами собой. До недавнего времени этот подход работал, поскольку разрешения экранов были более или менее одинаковы. Сегодня же мы имеем дело с большим разнообразием размеров и разрешений. И это все немного усложнило.

В процессе перезапуска сайта на свет появилась статья про адаптивную типографику, в которой я сфокусировался на нашем последнем эксперименте: адаптивных шрифтах. Без знания истории компании iA, вы могли бы упустить некоторые ключевые аспекты типографики и дизайна, представленные на обновленном сайте. Поэтому, вместо того, чтобы устроить кашу из записей по этой тематике, я решил начать все с начала и подробно, шаг за шагом, рассказать про адаптивную типографику. В этой статье нам предстоит сделать первый шаг.

Для того, чтобы не рисовать разные макеты для всевозможных устройств и экранов, веб-дизайнеры применяют концепцию адаптивного дизайна. По сути это идея автоматической модификации макета под разрешение экрана. У этой концепции есть несколько способов реализации, но мне нравятся следующие варианты:

1. Адаптивный макет: пошаговое изменение макета под ограниченное число размеров экрана.

2. Резиновый макет: когда макет использует всю доступную ширину экрана.

И хотя оба определения имеют свои и достоинства, и недостатки, нам кажется, что адаптация с минимально возможным количеством точек модификации — это более правильный путь, поскольку удобочитаемость контента намного важнее, чем резиновый макет, тянущийся под все разрешения. Это спорное мнение по довольно сложному вопросу, но оптимальная читаемость требует определенного контроля над параметрами текста (шириной колонки), и в этом смысле резиновая верстка создает больше проблем, чем решает. Однако, это тема для совсем другого разговора.

Примечание: Поскольку адаптивный дизайн включает в себя управление макропараметрами типографики (размер шрифта, высота строки, длина строки), он также во многих смыслах определяет и адаптивную типографику. То, на чем мы сосредоточились в нашей первой статье про типографику, по большей части касалось использования адаптивных шрифтов. Об этом я расскажу в следующей статье, а сейчас мне бы хотелось более подробно погрузиться в рассмотрение макропараметров типографики.

Выбор шрифта

Правильный характер

Рано или поздно вам придется выбрать, какой шрифт вы хотите использовать. Вопрос выбора шрифта во многом означает выбор его характера. Но, поскольку каждый шрифт имеет свое собственное качество исполнения и определенные требования (или ограничения) к применению, выбор шрифта имеет также множество визуальных и технических последствий. На данный момент мы имеем множество начертаний для веб-шрифтов, так что поиск подходящего превращается в еще одну проблемой.

Мы разработали свой собственный шрифт для нашего сайта с целью проведения адаптационных экспериментов. Мы выбрали шрифт с засечками, поскольку это соответствует нашему характеру и отражает изысканность наших материалов (по крайней мере, нам так кажется). Для iA Writer мы использовали моноширинный шрифт. Поскольку главной целью этого приложения является помощь в написании черновика, мы умышленно взяли Nitti — шрифт, который делает текст сильным и, в тоже время, аккуратным. Решение использовать моноширинный шрифт было продиктовано еще и тем фактом, что операционная система первого iPad не имела автоматического кернинга для пропорциональных шрифтов. Вместо того, чтобы использовать пропорциональный шрифт, который будет плохо смотреться, мы решили запустить приложение в жизнь с моноширинным шрифтом.

С засечками или без?

Обычно жребий падает между шрифтом с засечками и шрифтом без засечек. Сам по себе это сложный вопрос, но есть одно правило, которое может вам помочь: «Шрифт с засечками — это священник, а без засечек — хакер». Это не значит, что один лучше другого. Нет, просто по ряду причин антиква лучше передает авторитарные ощущения, а гротеск более демокартичен. Учтите, что пять тысяч лет типографского дела уместились в одно это кривое определение, поэтому не стоит относится к нему слишком серьезно.

Многие люди считают, что вопрос «с засечками или без» для экранной типографики уже давно решен. На самом деле, не все так просто. Вопреки распространенному мнению обе категории шрифтов могут хорошо работать, если вы выберите для основного текста размер шрифта больше 12 пикселей. Шрифты с засечками меньше 12 пикселей теряют четкость отрисовки. К тому же для современных мониторов 12 пикселей уже определенно мало. И это плавно переносит нас к следующему пункту.

Какой размер?

Размер шрифта для основного текста не зависит от ваших личных предпочтений. Он зависит от дистанции чтения. Поскольку большинство компьютеров физически находятся дальше от читателя, чем книги, метрические размеры шрифта на экране компьютера должны быть больше, чем размеры на печатном носителе.

Иллюстрация, представленная ниже, показывает, что чем дальше располагается текст, тем больше должен быть используемый размер шрифта. Две черных и две красных буквы «А» имеют одинаковые метрические размеры. Но, поскольку, правая пара букв находится дальше от глаз читающего, их воспринимаемые размеры становятся меньше. Красная буква «А» с правого изображения воcпринимается по размеру равной черной букве «А» с левого изображения:

Чем дальше находится текст, тем визуально меньше кажется его размер. Вам придется увеличить размер шрифта для такого текста, чтобы скомпенсировать более длинную дистанцию чтения. На сколько увеличить — это уже наука сама по себе. Если у вас не достаточно опыта в этом вопросе, есть один трюк, который может вам пригодиться. Просто сравните ваш экранный текст с текстом хорошо напечатанной книги, держа ее на удобной для чтения дистанции перед монитором.

Графические дизайнеры, у которых нет опыта работы в вебе, зачастую удивляются, насколько огромным выглядит основной текст в вебе по сравнению с полиграфией. Имейте ввиду, что шрифт огромен, только если сравнивать его с печатным без учета перспективы.

Если после такого увеличения размера шрифта он начнет вас раздражать, не беспокойтесь, это нормально. К тому же, после того, как вы к нему привыкнете, вы уже не захотите вернуться назад к «стандартным» маленьким размерам.

Мы пропагандируем эти размеры, «пропорциональные перспективе», с 2006 года. Изначально, наше утверждение, что шрифт Georgia размером 16 пикселей превосходно подходит для базового шрифта, вызвало волну агрессии и усмешек. Однако, теперь это более или менее устоявшийся стандарт. С ростом разрешений экранов этот стандарт медленно устаревает, но об этом позже.

Высота строки и контраст

Если размер текста может быть найден при помощи трюка с книгой, то высота строки тоже требует определения. Учитывая более длинную дистанцию чтения и так называемую «пиксельную грязь», разумно задать высоту строки экранному тексту больше, чем печатному. 140% — это хороший ориентир, но, естественно, конкретное значение зависит от используемого шрифта.

Это даст вам уверенность, что контраст не слишком слабый (например, серый текст на светло-сером фоне) и не слишком сильный (например, розовый на желтом). Поскольку экранные шрифты были разработаны для печати черным по белому, использование темных фонов является затруднительной, но вполне выполнимой задачей. С современными высококонтрастными мониторами предпочтительнее выбирать либо темно-серый цвет для текста или светло-серый для фона вместо чисто черного или белого цветов. Но и это, опять же, не самый главный вопрос.

iPhone vs iPad

Все, что мы узнали про адаптивную типографику, пришло из процесса поиска идеальной типографики в нашем приложении. Когда мы разрабатывали iA Writer для iPad, мы потратили несколько недель на разработку правильных параметров текста. Тогда высокое разрешение экрана iPad стало для нас испытанием, которое потребовало определенного времени на преодоление. Когда Apple встроила retina-дисплеи в iPad и iPhone, все началось заново. Мы могли бы написать целую книгу о том, как получили канонический вид шрифта в iA Writer, но пока есть так много, что нужно рассказать о более общих вещах, я попридержу коней.

Если вы сравните текущую версию iA Writer для iPhone с версией для iPad, вы можете заметить, что размер шрифта в них разный.

Почему он разный? Если вы внимательно читали то, что написано выше, то вы уже наверняка догадались.

1. Потому что дистанция для чтения не одна и та же. В общем случае вы держите iPad немного дальше. Когда вы используете ваш iPad на столе во время завтрака, на коленях, когда сидите на диване, или держите его прямо перед лицом, лежа в кровати — все это дает различные дистанции для чтения. И это определенно нежданная загвоздка, поскольку расстояние до ноутбука или настольного компьютера не варьируется так сильно. Для покрытия решением всех представленных случаев мы использовали для определения размера шрифта самую длинную дистанцию. В результате это дает немного больший размер шрифта, когда вы читаете лежа в кровати, но это вполне удобно. К тому же, как правило, никто не набирает текст лежа на животе.

2. Экран iPhone меньше, и приходится учитывать это ограничение.

К счастью, iPhone держат к лицу ближе, что позволяет более мелкому шрифту работать превосходно. На средней между iPhone и iPad дистанции чтения, размер шрифта визуально выглядит одинаково.

Поскольку iPhone преподносится к лицу ближе, а размер экрана у него меньше, то высота строки также уменьшается:

Не все работает в вашу пользу, когда вы проектируете для экрана. Проектирование взаимодействия — это инженерная деятельность, которая подразумевает поиск не идеального внешнего вида, а наилучшего компромисса. В нашем случае нам пришлось уменьшить не только высоту строки, а также отступы и межбуквенное расстояние:

Эти изменения настолько тонкие, что, если вы не знаете о них, то вы их и не заметите. Почему мы вообще не убрали отступы? Отступ это не декоративный элемент. Он добавляет в текст воздуха и помогает глазам перепрыгивать от строчки к строчке. Если вам кажется, что все это звучит как-то слишком эзотерично, то смею вас заверить, что мы рассмотрели лишь основы.

А что с настольными компьютерами?

Некоторые люди жаловались на слишком большой шрифт в Writer для Mac. Точно так же, как мы нашли оптимальный размер шрифта для iPad (среди множества дистанций для чтения), мы нашли подходящий размер шрифта и для Mac. Тогда мы проводили тесты на 24-дюймовом iMac с высоким разрешением экрана, на котором воспринимаемый размер шрифта более или менее соответствовал всем другим устройствам.

Поскольку разнообразие компьютеров Mac конечно по своей природе, мы смогли определить перечень возможных разрешений. Мы тестировали на каждой из возможных конфигураций, чтобы быть уверенными в оптимальном результате для большинства версий Mac.

Вы можете спросить: «Почему вы не позволили пользователю самому определять размер шрифта?». Потому что размер шрифта не зависит от вкусовых предпочтений человека, а определяется дистанцией чтения. Поскольку большинство сайтов и приложений используют небольшой размер шрифта, новые пользователи с самого начала будут устанавливать привычный им маленький размер и никогда не смогут испытать настоящее удовольствие от работы с нашим приложением. Наша цель не в том, чтобы добиться одинакового отображения у всех пользователей, а в том, чтобы iA Writer работал без настроек и без лишних заморочек, позволяя сосредоточится лишь на написании текстов. Такой подход является ключом к успеху этой программы и, если его поменять, пропадет сама суть приложения. (Что действительно стоит улучшить, так это доступность для людей с ограничениями по зрению).

Хорошо, но почему бы тогда не подстраиваться под разрешение экрана автоматически? Не будет ли это действительно адаптивной типографикой? Все верно, и мы уже работаем в этом направлении. Но сейчас, помимо адаптации к разрешению экрана необходимо также выбирать правильный оптический вес текста, чтобы быть уверенным, что шрифт работает именно так, как и задумывалось, во всех размерах и разрешениях. С изменением размера шрифта поменяется также и оптическое восприятие текста. Вот почему версии iA Writer для Mac, iPad 1/2 и iPad3 отличаются друг от друга. Чтобы объяснить логику адаптации шрифтов полностью, а также наши соображения, которыми мы руководствовались при разработке нового сайта, мне потребуется немного больше времени и пространства. Так что ждите продолжение!

Отзывы

Несмотря на отсутствие социальных кнопок на странице, эта статья получила большое количество ретвитов и очень мало критических замечаний (в основном по вопросу разницы между адаптивностью и резиновостью, который я хочу рассмотреть позднее). Я был удивлен когда Джошуа Портер (JOSHUA PORTER) спросил:

«@iA Дочитал до фразы „проектирование взаимодействия — это инженерная деятельность“. Что это значит?» @bokardo

На случай, если кому-то еще будет интересно… Полная цитата звучит так:

«Не все работает в вашу пользу, когда вы проектируете для экрана. Проектирование взаимодействия — это инженерная деятельность, которая подразумевает поиск не идеального внешнего вида, а наилучшего компромисса».

Обычно я говорю:

«Веб-дизайн — это инженерная деятельность, которая подразумевает поиск не идеального внешнего вида, а наилучшего компромисса».

С термином «веб-дизайн» высказывание становится немного проще из-за более понятного технического подтекста. В данном случае я применил «проектирование взаимодействия» только потому, что использовал мобильное приложение в качестве примера.

Это означает, что в то время, как графический дизайн дает вам достаточно большую степень контроля, веб-дизайн с самого начала заставляет думать о компромиссах между визуальной и технической составляющей. Для получения оптимального результата вам нужно рассмотреть множество вариантов, у каждого из которых свои плюсы и минусы, и попробовать найти наилучший компромисс между неоптимальными решениями.

Обычно в этот момент графические дизайнеры вступают в разговор, утверждая, что тоже имеют дело с большим количеством технологий. Конечно, имеют. Любое творчество, любое проектирование требует технической подкованности. Но, так же как существует разница между разработкой двигателей для автомобилей и созданием сайтов, точно так же существует разница между проектированием веб-сайтов и версткой журналов. Эта разница определяется степенью участия в проекте инженера.

Резюмируя, можно сказать, что в процессе проектирования сайтов и приложений, большую часть времен мы думаем о компромиссах и выбираем из всех зол наименьшую. Это то, что выбивает большинство графических дизайнеров из колеи, поскольку они привыкли к тотальному контролю. Больше информации об этом вы можете почерпнуть в великолепной презентации Чои Вина (KHOI VINH) «Разница между графическим и экранным дизайном» (2007).

Адаптивный веб-дизайн

Автор: Этан Мэркотт (ETHAN MARCOTTE)
Иллюстрации: Кевин Корнэлл (KEVIN CORNELL)
Оригинал: http://www.alistapart.com/articles/responsive-web-design/ (25 мая 2010)

Контроль над результатом, который есть у дизайнеров в полиграфии, и о котором они часто мечтают в вебе, — это просто результат фиксированного размера печатной страницы. Мы должны принять тот факт, что в вебе нет таких ограничений, и проектировать с учетом этой гибкости. Но для начала мы должны «принять изменчивую природу вещей».
— Джон Олсопп, «Дао веб-дизайна»

Английский архитектор Кристофер Врэн однажды пошутил, что его область деятельности «стремится к бесконечности». Юмор подобной формулировки в том, что в отличии от веба, который не смотрит дальше следующей недели, архитектура — это дисциплина, для которой постоянство является определяющей характеристикой.

Фундамент здания задает форму основанию. Основание определяет, каким будет твердый каркас здания. Каркас, в свою очередь, задает внешний облик фасада. Каждый этап архитектурного проектирования все меньше и меньше поддается изменениям по сравнению с предыдущим. Творческие решения определяют довольно точные формы физического пространства и задают пути перемещения по нему людей на протяжении десятилетий или даже веков.

Проектировать для веба — совершенно другой вопрос. Результат нашей работы примечателен небольшим сроком жизни. Как правило, он модернизируется или полностью обновляется через год иди два. Противоречивые размеры окон браузеров, многообразные разрешения экранов, специфические настройки пользователей и шрифты, которые у них установлены, — это далеко не полный перечень вещей, с которыми нам надо договориться о гармонии, когда мы запускаем проект в жизнь. Стоит отметить, что за прошедшие годы мы стали в этом довольно искусны.

Но жизнь меняется, возможно, даже быстрее, чем мы бы этого хотели. Ожидается, что мобильный интернет обгонит по популярности выход в интернет с обычного компьютера в течении ближайших трех—пяти лет. Две из трех самых популярных игровых приставок уже имеют веб-браузеры (причем один из них весьма не плох). Мы проектируем для мышек и клавиатур, для Т9-клавиатур, для игровых джойстиков и устройств с сенсорными экранами. Проще говоря, мы находимся лицом к лицу с таким множеством устройств, способов ввода данных и браузеров, какого раньше никогда не было.

В последние годы я часто встречаю компании, которым нужен «сайт под iPhone» как дополнение к основному проекту. Это интересное словосочетание. По сути, оно характеризует мобильный WebKit и как качественный браузер, и как мощный пример выхода бизнес-мышления за рамки обычных настольных компьютеров.

Однако, мне кажется, что мы, будучи дизайнерами, слишком любим комфорт, который дают такие четкие ограничения, поскольку в подобных случаях они позволяют легко разложить по полочкам все стоящие перед нами проблемы.

Мы можем изолировать мобильные версии сайтов по разным поддоменам, отдельно огородить «сайты не под iPhone». Но что дальше? «Сайт под iPad»? «Сайт под N90»? Можем ли мы на самом деле продолжать брать на себя обязательства по поддержке каждого нового устройства с уникальными параметрами взаимодействия?

В определенный момент начинает казаться, что это игра в «дурака» с самим собой. И как же нам и нашим проектам не проиграть?

Гибкая основа

Давайте рассмотрим пример. Я сверстал эту страницу для вымышленного журнала. Ее простая двухколоночная разметка реализована при помощи резиновой верстки с добавлением небольшого числа масштабируемых картинок.

Мне, как стороннику резиновой верстки, давно кажется, что она имеет больший запас прочности на будущее просто потому, что в ней учтена неопределенность. В какой-то мере это так и есть: резиновая верстка не делает предположений о ширине окна браузера и прекрасно адаптируется под устройства и с портретной, и с альбомной ориентацией страницы.

Огромные изображения огромны.
Наша верстка, несмотря на то, что она резиновая,
не реагирует должным образом на изменение разрешения или размера области просмотра.

Но в реальной жизни дизайн страницы (фиксированный или резиновый — не важно) вынужден плавно масштабироваться вне контекста, для которого он был спроектирован изначально.

Наш пример прекрасно ведет себя при изменении размеров окна браузера, однако, при низком разрешении начинают проявляться некоторые его недочеты. Если размер области просмотра сделать менее, чем 800×600 пикселей, то иллюстрация за логотипом обрезается, текст в пунктах меню может переноситься на другую строку неподобающим образом, а изображения с портретами становятся слишком малы и неразборчивы.

И подобные проблемы происходят не только при низком разрешении: если просматривать эту страницу на широкоформатном мониторе, то изображения увеличиваются до громоздких размеров, заслоняя и вытесняя собой весь окружающий контент.

Проще говоря, наша резиновая верстка достаточно хорошо работает в условиях, для которого она создавалась, но не оптимизирована для ситуаций, связанных с выходом за определенные рамки.

Начинаем реагировать

Молодая дисциплина, называемая «адаптивной архитектурой», еще совсем недавно поставила вопрос о том, как физическое пространство может реагировать на присутствие проходящих через него людей.

Используя комбинацию встроенной робототехники и гибких материалов, архитекторы экспериментируют с художественными инсталляциями и интерактивными стенами, которые гнутся и расширяются, когда человек подходит к ним. Датчики движения могут быть соединены с системой климат-контроля для управления температурой и освещенностью комнаты по мере того, как она заполняется людьми. Некоторые компании уже производят «умное стекло», которое может автоматически становиться непрозрачным, когда количество присутствующих в комнате достигает определенного уровня.

В своей книге «Интерактивная архитектура» Майкл Фокс (MICHAEL FOX) и Майлс Кемп (MILES KEMP) описывают этот более гибкий способ организации пространства как «многозвенную систему, к которой кто-то подключается для общения; постоянный и конструктивный обмен информацией».

Я выделил эту часть цитаты курсивом, поскольку считаю, что в ней заключается тонкое, но довольно важное отличие. Вместо того, чтобы создавать статичные и неизменяемые пространства, которые дают только заданный вид взаимодействия, авторы предлагают строить помещения таким образом, чтобы их жители и структура могли (и должны) взаимно влиять друг на друга.

Такой подход дает возможность двигаться дальше и нам. Вместо того, чтобы собирать в единое лоскутное одеяло отдельные дизайнерские решения, ориентированные на всё увеличивающееся число веб-устройств, мы можем рассматривать их как различные грани одного и того же варианта взаимодействия.

Мы можем разрабатывать дизайн, стремясь к оптимальному качеству представления, при этом встраивая в него технологии, которые предлагают не только более гибкую, но и более адаптивную к различным устройствам отображения реализацию.

Проще говоря, нам необходимо начать применять на практике адаптивный веб-дизайн. Но как это сделать?

Знакомьтесь, это — Media Query

Еще со времен CSS 2.1 наши таблицы стилей имеют некоторое представление об устройствах отображения благодаря media types. Если вы когда-либо писали таблицу стилей для печати, то основная суть вам уже известна:

<link rel="stylesheet" type="text/css" href="core.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

В надежде, что мы будем создавать дизайн страниц для вывода не только на экран или принтер, CSS-спецификация предоставила нам список допустимых media types, каждый их которых соответствует определенному классу устройств.

Но, к сожалению, большинство браузеров и устройств не воссоединились с духом спецификации.Часть из приведенных типов была реализована не полностью, а другая часть и вовсе оставлена без внимания.

Следует поблагодарить W3C за то, что он включил media queries в состав спецификации CSS3, тем самым улучшив перспективность media types. Media queries позволяют нам ориентироваться не только на определенный класс устройств, но и в режиме реального времени проверять их физические характеристики.

Например, после недавнего роста и улучшения мобильного WebKit, media queries стали популярной клиентской техникой отдачи специализированных таблиц стилей для iPhone, Android-телефонов и ему подобных. Чтобы добиться этого, мы можем добавить media query в атрибут media для соответствующей таблицы стилей:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />

Media query состоит из двух частей:

1. media type (screen)
2. и, собственно, сам запрос в скобках, содержащий конкретную media feature (max-device-width) и ее точное значение (480px) для проверки.

Мы как бы спрашиваем устройство о том, меньше или равно его разрешение по горизонтали (max-device-width), чем значение в 480 пикселей.

Если тест пройден успешно (т.е., мы просматриваем верстку на устройстве с маленьким экраном, как, например, у iPhone), то устройство подгрузит себе файл shetland.css. В противном случае ссылка на эти таблицы стилей будет проигнорирована.

Дизайнеры и раньше экспериментировали с макетами, поведение которых зависело от разрешения экрана. В основном эти опыты опирались на такие JavaScript-решения, как великолепный скрипт Кэмерона Адамса (CAMERON ADAMS).

Но спецификация media queries обеспечивает поддержку целого ряда media features, которые выходят далеко за рамки простого разрешения экрана и значительно расширяют спектр того, что мы можем подвергнуть тестированию.

Вы можете одновременно тестировать в одном запросе значения нескольких свойств, объединяя их при помощи ключевого слова and:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />

Кроме того, мы не ограничены в добавлении media queries только в тег link. Мы можем добавить их непосредственно в CSS-код, как часть правила @media:

@media screen and (max-device-width: 480px) {
.column {
float: none;
}
}

Или как часть директивы @import:

@import url("shetland.css") screen and (max-device-width: 480px);

В любом случае эффект один и тот же. Если устройство проходит тест, заданный нашим media query, то соответствующий CSS-код применяется к верстке.

Проще говоря, media queries — это своего рода условные комментарии. Вместо того, чтобы ориентироваться на конкретную версию конкретного браузера, мы можем в режиме реального времени вносить изменения в верстку макета, если она при масштабировании выходит за пределы базового/идеального разрешения.

Адаптация, реакция и преодоление

Теперь направим наше внимание на изображения, которые находятся внизу нашей страницы. В текущей версии CSS-код, который к ним относится, выглядит примерно так:

.figure {
float: left;
margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
width: 31.121642969984202211%;             /* 197px / 633px */
}
li#f-mycroft,
li#f-winter {
margin-right: 0;
}

Я специально опустил ряд типографических свойств, чтобы сфокусироваться на блочной модели. Каждый элемент с классом .figure занимает примерно треть от ширины родительского контейнера. К тому же последнее изображение в каждом ряду имеет нулевой правый внешний отступ (li#f-mycroft, li#f-winter).

И этот код работает довольно хорошо вплоть до того момента, пока область просмотра не становится заметно меньше или, наоборот, шире, чем мы изначально проектировали. При помощи media queries мы можем внести небольшие правки, которые учитывают текущее разрешение экрана, и, таким образом, адаптируют дизайн для наилучшей реакции на изменение параметров отображения.

Для начала сделаем поток контента на нашей странице линейным, когда область просмотра по ширине становится меньше заданного порогового значения, скажем, в 600 пикселей. Для этого в конце нашей таблицы стилей добавим следующий блок @media:

@media screen and (max-width: 600px) {
.mast,
.intro,
.main,
.footer {
float: none;
width: auto;
}
}

Если вы посмотрите на новый вариант страницы с нашим примером в современном браузере, при этом сделав ширину окна менее 600 пикселей, то media query отключит свойство текучести у основных структурных блоков и поставит их в одну линию друг над другом.

Таким образом наш миниатюрный дизайн получил привлекательные формы, однако, изображения все еще уменьшаются не разумно. Если мы добавим другой media query, то сможем изменить принцип их отображения:

@media screen and (max-width: 400px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 48.341232227488151658%;          /* 306px / 633px */
}
li#f-watson,
li#f-moriarty {
margin-right: 0;
}
}

Наши изображения смогли адаптироваться
для более лучшего отображения на небольших экранах.

Не обращайте внимания на чудовищную форму записи процентов. Просто значение ширины для резиновой верстки мы пересчитали в соответствующее значение для нового линейного принципа расположения блоков.

Проще говоря, мы переходим от трех-колоночной версии макета к двух-колоночной, когда область просмотра становится менее 400 пикселей по ширине. При этом разборчивость изображений улучшается.

На самом деле мы можем точно так же поступить и с широкоформатными экранами. Для больших разрешений мы можем создать из наших изображений шесть колонок, расположив их все в один ряд:

@media screen and (min-width: 1300px) {
.figure,
li#f-mycroft {
margin-right: 3.317535545023696682%;    /* 21px / 633px */
width: 13.902053712480252764%;          /* 88px / 633px */
}
}

Теперь наши изображения работают прекрасно во всем спектре разрешений, оптимизируя свои размеры и взаимное расположение в зависимости от ширины окна браузера или разрешения экрана.

Указав большее значение для min-width в новом media query,
мы можем расположить наши изображения в один ряд.

И это только начало.

Используя media queries в нашем CSS-коде, мы можем изменить не только расположение нескольких изображений. Мы можем внедрять новые/альтернативные варианты дизайна, тонко настроенные под различные диапазоны разрешений. Мы можем делать навигацию более заметной на широких экранах, или перемещать ее в позицию над логотипом для устройств с небольшим экраном.

Проектируя адаптивно, мы можем не только расположить
контент линейно и последовательно,
но и оптимизировать его отображение для целого ряда экранов.

Но адаптивный дизайн не ограничивается изменениями в раскладке страницы. Media queries позволяют нам заниматься невероятно тонкой настройкой этих изменений. Мы можем:

• увеличивать для сенсорных устройств с маленькими экранами область клика ссылки согласно закону Фитса;
• выборочно показывать или скрывать элементы, которые могут улучшать навигацию;
• и даже использовать адаптивную типографику для плавного изменения размера шрифта и переформатирования текста, улучшая его читаемость на соответствующих устройствах.

Технические моменты

Следует отметить, что media queries имеют хорошую поддержку во всех современных браузерах.

Браузеры Safari 3+, Chrome, Firefox 3.5+ и Opera 7+, а также Opera Mobile и мобильный WebKit, имеют встроенные парсеры media queries (в старых версиях этих браузеров такой поддержки нет). И хотя Microsoft взяла на себя обязательства по поддержке media queries в 9 версии Internet Explorer, на данный момент их реализацией этот браузер похвастаться не может*.

*На момент написания статьи Internet Explorer 9 еще не вышел в релиз. В 9-ойверсии браузера от Майкрософт обещанная поддержка была полностью реализована. — Прим. переводчика.

Однако, если вас интересует реализация поддержки возможностей media queries в старых браузерах, то вот вам JavaScript-овые лучики надежды:

• jQuery-плагин 2007 года выпуска предлагает несколько ограниченную реализацию media queries, в которой используются только свойства min-width и max-width, добавляемые в тег link.
• Недавно разработанная библиотека css3-mediaqueries.js, которая обещает «научить IE 5+, Firefox 1+ и Safari 2 парсить, тестировать и применять CSS3 Media Queries» путем подключения их через блоки @media. Несмотря на то, что версия библиотеки еще только «1.0», мне она показалась довольно стабильной, и я планирую следить за ее дальнейшей разработкой.

У разработчиков бывают вполне объяснимые ситуации, когда использовать JavaScript-решение не приемлемо. Именно такие случаи дают дополнительный вес решению делать верстку резиновой. Она обеспечит ваш дизайн определенным запасом гибкости в браузерах и устройствах, которые не поддерживают media queries.

Только вперед

Резиновая верстка, масштабируемые изображения и media queries — вот три технических составляющих адаптивного дизайна. Но для их использования необходимо думать по-другому.

Вместо того, чтобы изолировать наш контент в обособленные и зависимые от устройств представления, мы можем использовать media queries для постепенного улучшения наших проектов в самых различных контекстах.

Это не означает, что создание отдельных сайтов для отдельных устройств не имеет смысла с точки зрения бизнеса. Например, если перечень целей, которых желает достичь посетитель мобильной версии вашего сайта, более ограничен по сравнению с обычной версией, то соседское сосуществование обеих версий может быть вполне удачным решением.

Но такая модель дизайнерского мышления не должна быть моделью по-умолчанию. Сегодня мы проектируем продукты, которые, как никогда ранее, должны поддерживать всю палитру вариантов взаимодействия. И по большому счету, адаптивный веб-дизайн открывает нам дорогу вперед, позволяя «создавать изменчивую природу вещей».

Об авторе

Этан Мэркотт — веб-дизайнер и разработчик, которого глубоко волнуют красивый дизайн, элегантный код, а также их взаимное пересечение. На протяжении нескольких лет Этан имел удовольствие работать с такими заказчиками, как the Sundance Film Festival, Stanford University, New York Magazine and The Today Show.

Он обильно общается в твиттере и хочет стать неудержимым ниндзя-роботом, когда вырастет.

Его последняя книга называется «Адаптивный веб-дизайн».

Это не адаптивная веб-разработка, это — адаптивный веб-дизайн

Автор: Франциско Инхосте (FRANCISCO INCHAUSTE)
Оригинал: http://www.getfinch.com/finch/entry/its-not-responsive-web-building-its-responsive-web-design/ (11 августа 2011)

Для отрасли, которая генерирует, возможно, больше жаргонных словечек, чем какая-либо другая, мы слишком любим делать вид, что это не так. Если только вы не прожили последний год в лесу, вас наверняка уже задолбал этот термин: адаптивный веб-дизайн (АВД).

Это еще одно понятие из длинной череды ему подобных, которое в конечном итоге породит тысячи статей, сотни книг и станет поводом для тонны дебатов внутри отрасли (если уже это не сделало). Как любое новое направление внутри нашего профессионального сообщества, оно имеет своих сторонников и противников. Хотя противники и немногочисленны.

Mediaqueri.es — свежая галерея, специализирующаяся на адаптивном дизайне.

Я не видел перспективы для АВД сквозь призму проектирования взаимодействия, хотя он и может быть полезным. Мы жили с ним какое-то время, бросались им вокруг, писали посты в стиле «Как это сделать», тестировали разные штуки, и теперь у нас есть галерея примеров (нам еще предстоит узнать, «правильные» они или нет). Он есть и остается частью нашей индустрии.

Круги АВД

Большая часть постов в интернете оставила меня в сомнениях относительно того, что мы подразумеваем, когда говорим об АВД, и что он есть на самом деле. Для того, чтобы разобраться, я попробовал разделить обсуждения и мнения по группам. Назовем их кругами — так, как это сегодня делают все крутые парни, группирующие что-либо. Представляю вашему вниманию: Круги Адаптивного Веб-Дизайна.

Круг «АВД — это метод»

Когда АВД впервые предстал перед миром, он позиционировался как методика. Основное внимание было сосредоточено вокруг сложности проектирования содержания для различных размеров экранов и разрешений. Цель АВД — предоставлять одинаковое содержание для любых веб-устройств и предлагать полноценное функциональное взаимодействие без ущерба для пользователя (например, без изменения размеров окна браузера или демонстрации только части страницы, поскольку она была спроектирована для устройств с более широким экраном).

В этом смысле АВД всегда был с нами. Методика разработки резиновых сайтов не упала к нам с небес позавчера. Мы и раньше использовали ее для разработки настольных приложений, имеющих гибкие настройки. Эти программы появились тогда, когда персональный компьютер стал действительно огромным (в прямом и переносном смыслах). И было бы логично ожидать, что в этих изменившихся условиях наши веб-сайты будут следовать тем же паттернам.

Для этого круга считается нормальным задвинуть такую фразу: «Известно, что люди приходят посмотреть содержание сайта разными способами. Поэтому, вместо того, чтобы заниматься гаданием на кофейной гуще или разрабатывать 15 версий одного сайта (и потом каждый раз соглашаться на доработку чего-то нового), давайте просто сделаем эту хрень адаптивной» [1].

Круг «АВД — это философия»

Для этого круга характерна следующая точка зрения: АВД спасает нас от фиксированной ширины и грехов типа «наилучшее отображение в [Название_Бразуера]». Один из самых больших сторонников АВД, Джефри Зельдман (JEFFREY ZELDMAN) дает такое определение:

«…это очередной этап эволюции в веб-разработке и проектировании взаимодействия. Как с практической точки зрения, так и для всей индустрии
в целом.»

Люди из этого круга считают, что это не просто инструмент или практический метод. Это философия для всего, что связано в веб-дизайном. Что подразумевается под этим? Имеется ввиду сущность АВД. Он является неотъемлемой частью веб-дизайна. В общем случае, когда мы разрабатываем сайт, нам не надо решать, применять АВД или нет — он просто должен быть. Без вариантов. И если ваш дизайн не адаптивный, то, как сказал Энди Кларк (ANDY СLARKE):

«Это уже не веб-дизайн, а что-то другое. Если вы не учитываете в своей работе врожденное непостоянство веба, то вы не веб-дизайнер, а кто-то другой. Веб-дизайн — это адаптивный дизайн, а адаптивный веб-дизайн — это веб-дизайн, и никак иначе.»

Круг «АВД — это тренд»

Этот круг чувствует, что АВД — это еще один тренд и модное техническое слово, которое на самом деле ничего не меняет, поскольку так и не станет спасением от всех наших бед, и на которое возлагают свои надежды люди из предыдущего круга.

Как правило, критики АВД опираются на техническую сторону вопроса, а также на практичность применения такого подхода с точки зрения бизнеса. Это, в свою очередь, заставляет переосмыслить многие вещи, такие как платформа для содержания и затраты на редизайн. Критики также аргументируют тем, что технологии типа @media-queries и javascript до сих пор не поддерживаются браузерами во многих мобильных устройствах.

Несмотря на то, что рассматриваемый метод (философия) еще очень молод, эта группа не слишком ему рада.

Дизайнерский взгляд

Большинство обсуждений АВД уделяет слишком большое внимание техническим аспектам. Это не адаптивная веб-разработка, это — адаптивный веб-дизайн. Смотреть сайт в превосходном качестве на любом экране звучит красиво. Самый простой дизайнерский ответ на вопрос о пользе АВД звучит так: «все зависит от …». Очевидно, что это беспроигрышный вариант. Поэтому далее я попытаюсь сформулировать свое мнение, дав другой ответ.

«Но что значит быть по-настоящему „адаптивным“? Я считаю, что это обязывает понимать человека по другую сторону экрана и, самое главное, контекст, в котором он находится.»
— Джеймс Пирс (JAMES PEARCE)

«Родные» приложения предлагают превосходное качество использования, поскольку были спроектированы под конкретное устройство. Предоставление же одного и того же веб-приложения всем подряд ведет к кошмару в плане удобства. Опыт взаимодействия для различных устройств также заслуживает отдельного рассмотрения. Мы можем получить массу технической информации о том, как люди обращаются за содержанием, но мы не можем видеть то, как они с ним взаимодействует. Ну, мы, конечно, можем, но это означало бы работу с людьми *вздох*!

Каждое устройство имеет форм-фактор и относится к определенному классу устройств [2]. Например, смотря телевизор, вы можете откинуться назад и с расстояния в 10 футов взаимодействовать с ним, используя пульт управления.

«Хотя и существует возможность использовать всего один интерфейс для работы с более, чем одним классом устройств, разработка такого интерфейса обычно приводит к существенным компромиссам или рахитичному опыту взаимодействия, который не позволяет воспользоваться преимуществами, делающими каждый из классов превосходным (или наоборот: к богатым функциональным возможностям, которые не загружаются или ломаются на слабых устройствах).»
— Люк Вроблевски (LUKE WROBLEWSKI)

Хорошо известно, что надо проектировать сайты с учетом специфики мобильных устройств. Но при этом большинство считает хорошей идеей сделать что-либо для персонального компьютера, затем вырвать некоторые элементы, что-то поменять местами и в итоге назвать это пригодным для мобильных устройств. И, раз уж мы об этом заговорили, какой, черт побери, смысл вкладывается в слово «мобильность» в наши дни? Многие из нас думают, что это когда люди в движении или постоянно находятся в отвлекающей обстановке. Однако, данные, иллюстрирующие домашний комфорт, противоречат этому [3]:

• 93% людей используют свои смартфоны дома;
• 62% людей используют свои смартфоны для просмотра видео-каналов;
• 39% людей используют свои смартфоны, когда сидят на толчке.

IPad рассматривается скорее как «портативное», чем «мобильное» устройство, поскольку люди не всегда берут его с собой. И при этом, в большинстве случаев люди ожидают полную функциональность, а не урезанную или модифицированную версию [4].

«Больше 10 лет создания веб-сайтов потребовалось сообществу разработчиков на то, чтобы понять, что конкретные знания о наших посетителях действительно очень важны. Почему сегодня, когда некоторые браузеры помещаются в нашем кармане и имеют сенсорные экраны вместо курсора, мы решили, что больше не нуждаемся в хорошей информации о пользователях?»
— Мэтт Генри (MATT HENRY)

Очевидно, есть множество вещей, которые необходимо рассматривать при принятии решения о том, как предоставлять взаимодействие по всему современному цифровому ландшафту.

Панацеи нет

Проблема, которую мы пытаемся решить, очень сложная. Я знаю, что многие люди ведут разработку «от содержания». И это правильно, содержание — во главе всего. Если содержание не имеет значения, то и то, как вы будете делать сайт, тоже не важно. При этом не все так однозначно, поскольку здесь присутствует множество других факторов. Например:

• Является ли продукт/содержание желанным для потребителя?
• Готов ли заказчик, и есть ли возможность донести то видение, которое мы проектируем?
• Готовы ли клиенты попробовать наш новый продукт/услугу вместо текущего решения?

Изображение взято с сайта Yiibu.

Иногда мне кажется, что мы (наша отрасль) очень похожи на определенный тип правительства, которое совершенно оторвано от жизни обычных людей. Самый широкий канал интернета и последняя версия браузера — далеко не для каждого это находится в списке жизненных приоритетов. Мы же, как правило, предпочитаем разрабатывать что-либо для новых устройств, таких как iPhone, потому что там мы действительно можем использовать интересные штуки-дрюки и изучать самые современные технологии. Если даже iPhone имеет слабое проникновение в секторе мобильных устройств [5].

Большинству людей вне нашей отрасли не нужно то дерьмо, которое мы создаем. Просто дайте им самый удобный способ перевести деньги в Farmville (популярная игра в социальной сети Facebook, аналог «Фермы» в Вконтакте — прим. переводчика), чтобы они смогли вырастить еще больше овощей. Я верю в человеческий фактор, и понимание контекста, в котором люди получают интересующую их информацию, — вот что может быть постоянной задачей. Мне кажется, что никогда не будет найдена панацея в дизайне для людей. Мы изучаем то, каким образом люди «думают», гораздо дольше существования интернета. И мы знаем достаточно, чтобы понять, что мы не знаем ни хера.

«Дизайн — это размышление о содержании и его подаче. Фокусируйтесь на картине в целом. Макет — это еще не дизайн.»
— Люк Вроблевски (LUKE WROBLEWSKI)

Противники говорят, что АВД — это тренд, который скоро умрет. С другой стороны медали находятся сторонники, утверждающие, что нашли Святой Грааль. Каждый надеется на очередного спасителя, который избавит нас от всех проблем. Я вижу одно решение: настойчивость и эволюция с целью создания отличного опыта взаимодействия.

[1] Mobile-first Responsive Web Design, Брэд Фрост (BRAD FROST)
[2] Networked Consumer Device Platforms, Люк Вроблевски (LUKE WROBLEWSKI)
[3] The Myth of Mobile Context
[4] Five Lessons From a Year of Tablet Research
[5] Rethinking the Mobile Web