Сегодня мы подготовили для вас перевод статьи Джереми Джирарда о том, как он создавал лучший адаптивный дизайн сайта для своей компании. К слову, Джереми — директор по развитию веб-департамента Providence, Rhode Island и преподаватель веб-дизайна в Род-Айлендском университете. Умолчим о том, что наш сегодняшний герой перевода родился с шестью пальцами на каждой ноге — это уже совсем другая история.

В этом году я начал редизайн веб-сайта нашей компании. Мы уже планировали использовать обычный метод адаптивного подхода к веб-дизайну, который был для нас лучшим решением для поддержки работы на различных устройствах. Но, услышав некоторые откровенные разговоры на конференции An Event Apart в Бостоне об ограничениях и проблемах адаптивного веб-дизайна, я понял, что наше решение нужно немного видоизменить.

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

Мобильные устройства
Определение целей

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

Единый сайт для создания, поддержания и развития.

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

Перевод

Экстремальные версии нового дизайна сайта
Сначала мобильные

Подход «сначала мобильные» (mobile-first) в адаптивном дизайне не нов. Он заключается в том, чтобы в первую очередь выстроить макет сайта для мобильных устройств, а потом использовать медиа-запросы для настройки по мере увеличения размера экрана.

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

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

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

@media only screen and (min-width: 660px) {
html {
background: url(/images/bg-watercolor.jpg) no-repeat fixed center top;
}
}

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

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

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

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

В рамках этого подхода мы создали графику и установили фоновое изображение: вертикальные линии шириной в 320 пикселей (наименьший размер), а затем контрольные точки через каждые 100 пикселей, начиная с 400. Так мы масштабировали окно браузера, чтобы определить, где дизайн начинает давать сбой. В итоговых медиа-запросах, добавленных в CSS, были использованы приблизительные значения пикселей.

Такой фон позволяет определить точки, нужные для адаптивного дизайна

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

Одним из элементов нашего веб-сайта, где очевидно увеличение медиа-запросов, является навигация.
Адаптивная навигация

Одна из самых непростых задач в верстке адаптивного сайта — это навигация. В нашем случае есть четыре её основных элемента.

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

Так как CSS сайта разработана по методу mobile-first, в первую очередь мы создавали навигацию для образца наименьшего экрана. Это означало отключение выдачи всех разделов кроме основной навигации.

#helpNav, .subNav, footer nav {
display: none;
}

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

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

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

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

Так выглядит CSS нашей вспомогательной навигации:

#helpNav {
display: block;
position: absolute;
top: 1px;
right: 0px;
width: 100%;
text-align: right;
}

#helpNav ul {
padding-left: 10px;
}

#helpNav li {
display: inline;
padding-right: 6px;
padding-left: 6px;
background-color: #2f6a98;
}

#helpNav a {
font-size: 12px;
padding: 0 6px;
color: #FFF;
border-radius: 20px;
}

#helpNav a:hover {
background-color: #f66606;
}

И навигация по вложенным страницам:

.subNav {
display: block;
width: 25%;
float: left;
}

.subNav h4 {
padding-bottom: 8px
}

.subNav ul {
list-style: disc;
color: #c65204;
padding: 0 0 20px 20px;
}

.subNav li {
padding-bottom: 14px;
}

.subNav a {
color: #186483;
font-size: 21px;
font-family: 'RokkittRegular', Times, "Times New Roman", serif;
line-height: 1;
}

Наконец, наша навигация по нижней части страницы:

footer nav {
display: block;
margin-top: 40px;
}

footer nav ul {
list-style: none;
}

footer nav li {
padding-bottom: 24px;
width: 19%;
padding: 0 5% 20px 0;
float: left;
}

.innerNav li {
width: 100%;
float: none;
padding-bottom: 4px;
}

footer nav a {
color: #575454;
font-size: 12px;
}

.innerNav a {
font-weight: normal;
}

Пиксели против em

В медиа-запросах мы используем значения пикселей. Как многие интерфейсные дизайнеры, мы начали применять именно такую технику, реализуя адаптивный дизайн, и сохранили эту традицию как часть рабочего процесса. Кстати, укажу на статью о пропорциональных медиа-запросах на базе em, которая привлекла наше внимание в ходе работы. По существу, чтобы улучшить внешний вид сайта при увеличении масштаба, рекомендуется перевести медиа-запросы из px в em, разделив все пиксельные значения с помощью font-size body.

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

Наша основная навигация представлена на широких экранах как горизонтальная строка в верхней части макета. На маленьких экранах структура меняется на большую кнопку «Меню» в верхней части страницы, ведущую к навигации в нижней части страницы. Для осуществления этого мы добавили ссылку с ID menuLink и классом tabButton в заголовке. Затем мы поставили разделитель в ID mainNav в конце разметки. Без этого основная навигация — просто неупорядоченный список с другими неупорядоченными списками, соответствующими меню вложенных страниц. У нас есть еще точка привязки с ID toTop, действующая как связующее звено с нижней частью страницы.

Верхняя кнопка «Меню» на экране с маленьким разрешением

В рамках подхода mobile-first для экранов с маленьким разрешением мы стилизовали ссылку на меню в верхней части макета под кнопку.

#menuLink a {
float: right;
margin: -56px 8px 0 0;
}

.tabButton a {
color: #FFF;
font-family: 'RokkittRegular', Times, "Times New Roman", serif;
font-size: 20px;
background-color: #45829b;
padding: 10px 12px;
border-radius: 10px;
}

.tabButton a:hover {
background-color: #f66606;
}

Наше меню основной навигации настроено для работы на маленьких экранах:

#mainNav {
margin-top: 30px;
width: 100%;
}

#mainNav #toTop a {
float: right;
margin: 0 8px 0 0;
font-size: 20px;
}

#mainNav nav {
padding-top: 80px;
}

#mainNav ul {
list-style: none;
}

#mainNav li {
background: #45829b;
border-bottom: 1px solid #abc7d2;
padding: 4px 10px 4px 15px;
}

#mainNav li:hover {
background-color: #f66606;
}

#mainNav a {
font-size: 24px;
color: #FFF;
font-family: 'RokkittRegular', Times, "Times New Roman", serif;
}

Навигация первого уровня на экране с небольшим разрешением

Наши подменю, которые изначально не отображались, теперь выводятся согласно требованиям страницы. У каждого подменю есть уникальный ID, как servicesTab, и у каждого раздела есть класс, с которым используется тег body. Класс для «Компания» — companyPage. Его мы используем, чтобы установить стили для всего раздела.

.companyPage #companyTab ul,
.newsPage #newsTab ul,
.contactPage #contactTab ul,
.servicesPage #servicesTab ul {
display: block;
}

Нижний уровень навигации на экране с небольшим разрешением
Увеличение

По мере увеличения экрана мы кардинально меняем макет основной навигации. Для начала отключается отображение кнопок menuLink и toTop — они больше не нужны:

#menuLink a, #toTop a {
display: none;
}

Далее мы размещаем в верхней части страницы mainNav:

#mainNav {
position: absolute;
top: 92px;
margin: 18px 2% 0 2%;
width: 96%;
text-align: center;
}

#mainNav nav {
padding: 5px 0;
border-top: 1px solid #bacfd7;
border-bottom: 1px solid #bacfd7;
}

#mainNav li {
background: none;
display: inline;
border-bottom: 0;
border-right: 1px solid #bebebe;
padding: 0 6px 0 8px;
margin: 4px 0;
}

#mainNav a {
font-size: 16px;
color: #45829b;
}

#mainNav a:hover {
color: #f66606;
}

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

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

@media only screen and (min-width : 767px) {
#mainNav a {
font-size: 18px;
}
}

Этот паттерн мы продолжаем еще несколько раз, в итоге увеличивая размер шрифта до 27 пикселей при максимальном размере экрана. В этом случае навигация сайта действительно соответствует дизайну и экрану используемого устройства.
Используем CMS

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

Одним из основных недостатков адаптивного подхода является невозможность применять различную разметку для разных типов устройств. Именно эту проблему мы хотели решить с помощью нашей CMS. В ходе экспериментов и исследований мы наткнулись на статью «Настоящий адаптивный подход с ExpressionEngine». Используя описанный в этой статье подход, мы смогли применить скрипт определения устройства, чтобы установить переменные mobile или full. В этом случае мы можем загружать определенную разметку в зависимости от переменной.

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

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

Изображения — милое дополнение, но, однозначно, не критичное, так что мы вообще не добавляем этот контент в мобильную версию. Я не имею в виду, что с помощью CSS мы отключаем их отображение, в случае чего данные все равно будут доставлены в браузер; вместо этого мы используем переменные, чтобы убирать изображения из разметки, если в них нет необходимости.

Тизер, некритичный для контента

Синтаксис довольно прост. Как только вы ввели переменные (вышеупомянутая статья объясняет, как сделать это, добавляя небольшой скрипт в системный файл config.php), их можно использовать как оператор «если».

{if global:site_version=='full'}
alt="{title}" />{/if}{if global:site_version=='mobile'} {title}{/if}

Это синтаксис ExpressionEngine, но вы понимаете, что именно происходит. При переменной full мы отображаем изображение из базы данных. А в случае переменной mobile отображается заголовок.

Тот же подход мы используем для разделов «Новости» и «Блог», включая три изображения для полной версии и только одно для мобильной. Так выглядит синтаксис:

{exp:channel:entries channel="news" {if global:site_version=='full'}

limit="3"{/if} {if global:site_version=='mobile'}limit="1"{/if}}

Вы видите канал news в ExpressionEngine. Мы используем переменную, чтобы определить количество поставляемого контента путем добавления параметра limit.
Идем дальше

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

Для каждой статьи мы делаем два набора изображений: полноразмерные шириной в 650 пикселей и вариант в два раза меньше. Затем добавляем с помощью кода ExpressionEngine и включаем оба набора в разметку, но в браузер попадет только один. Для мобильных устройств предназначены меньшие изображения, для остальных — полноразмерные.

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

Благодаря подходу mobile-first и помощи CMS, мы смогли представить размер нашей домашней страницы в 738.3 KB для пользователей настольных компьютеров, сократив его до 174.4 KB для мобильной версии.
Резервные планы

Одним из вопросов, которые всегда беспокоили меня при подходе, ориентированном на определение мобильного устройства, был «Что произойдет, если устройство не удастся определить?» Что, если «нормальная» версия сайта доставляется на мобильное устройство, сводя к нулю все ваши старания по созданию меньшей версии? Это стало одной из причин, по которым я избегал подобного подхода.

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

Так как мы начинали разработку именно с мобильной версии, не предназначенные для маленьких экранов элементы, как, к примеру, огромная фоновая графика, просто не будут отображаться. Единственное, что может нас подвести — генерируемые переменные определения устройства. В худшем случае, если определение не удастся, в мобильной версии появится несколько дополнительных изображений, или разметка, или JavaScript, которые там не нужны. Однако макет все еще будет подходить для мобильного устройства. Неплохо для «худшего случая», правда?
Прогресс, а не совершенство

Несколько лет назад один клиент сказал мне слова, которые я помню по сей день. Когда мы обсуждали работу над сайтом, он отметил:

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

Я до сих пор руководствуюсь этой идеей, она напоминает мне никогда не упускать лучшее решение только потому, что оно не совершенно.

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

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