Frontender Magazine

Создаем более отзывчивый сайт

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

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

Устройства

Разнообразие устройств, используемых для просмотра нашего сайта, достигло рекордного числа. (Автор фото Блейк Пэттэрсон (Blake Patterson))

Определяем цели

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

Достоинства

  1. Возможность разрабатывать, поддерживать и продвигать один-единственый сайт.

  2. Поддержка самых разных размеров экрана, а не только крайних случаев вроде больших мониторов и мобильных телефонов.

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

Недостатки

  1. Контент, предназначенный только для экранов с большим разрешением, загружается на устройства с маленьким разрешением и затем «выключается» с помощью CSS media queries (медиавыражений), создавая ненужные загрузки.

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

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

Контент прежде всего

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

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

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

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

Данные диктуют направление

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

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

Дизайн крайностей

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

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

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

Версии

«Предельные» версии нового дизайна нашего сайта

Сначала мобильные

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

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

Например, наш новый дизайн предусматривал использование акварельной тестуры в качестве фонового изображения. Это довольно большая картинка, и она должна быть включена для показа только на больших экранах (шириной 660 пикселей и больше). Поскольку наш CSS начинается со стилей для мобильных устройств, это изображение никогда не попадёт на устройство с маленьким экраном, ведь медиавыражение, которое его загружает, активируется только для больших экранов. Вот так выглядит медиавыражение, который задаёт фон для нашего элемента html:

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

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

Разработка, ориентированная на дизайн, а не устройства

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

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

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

Фон

Это фоновое изображение для рабочего стола можно использовать для определения контрольных точек отзывчивого дизайна

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

Количество медиавыражениий существенно возрастает отчасти благодаря изменениям в навигации.

Отзывчивая навигация

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

  1. Основная навигация.

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

  3. Навигация в подвале сайта.

  4. Навигация внутри разделов, которая отображается в левой колонке внутренних страниц сайта (для широких экранов).

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

#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, которую нам посоветовали, когда эта статья ещё только была написана и проходила редактирование. Если коротко, рекомендуется в медиавыражениях перевести пиксели в em посредством деления всех пиксельных значений на размер шрифта body, что позволит улучшить вид сайта при увеличении масштаба.

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

Основная навигация

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

Меню

В верхней части макета для маленьких экранов есть кнопка «Меню»

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

#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;
}

Мобильная навигация

Основная навигация сайта на небольших экранах

Подменю, скрытые по умолчанию, могут отображаться в зависимости от текущей страницы. Каждому из этих подменю присвоен уникальный идентификатор, например servicesTab, и для каждого раздела сайта для тега body прописан класс. Для раздела «Компания» это класс companyPage. С помощью этого класса мы можем отдельно стилизировать целый раздел сайта. Класс, присвоенный разделу подменю, можно использовать, чтобы отобразить это подменю, когда мы находимся в соответствующем разделе.

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

Навигация внутренних страниц

Отображение навигации внутренних страниц на небольших экранах

Увеличение

Когда дело доходит до экранов с большим разрешением, мы кардинально изменяем вид основной навигации (опять же, используя медиавыражения для экранов шириной 660 пикселей и больше). Во-первых, отключаем отображение кнопок 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 спешит на помощь

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

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

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

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

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

Разделы

Приятно видеть иллюстрации к резюме статей, но они не влияют на контент или внешний вид страницы

Синтаксис довольно простой. Когда переменная задана (в вышеупомянутой статье обьясняется, как это проще сделать, добавив маленький скрипт в системный файл config.php), её можно использовать в проверке через выражение if.

{if global:site_version=='full'}<img src="{teaser-image}" alt="{title}" />{/if}{if global:site_version=='mobile'} {title}{/if}

Это синтаксис ExpressionEngine, но вы можете взглянуть на этот код и без труда разобраться что происходит. Если сработало условие с переменной full, тогда teaser-image загружается из соответствующей записи в базе данных. Если же верно условие с переменной mobile, тогда для статьи загружается title.

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

{exp:channel:entries channel="news" {if global:site_version=='full'}limit="3"{/if}{if global:site_version=='mobile'}limit="1"{/if}}

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

Еще один шаг вперед

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

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

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

Подход «сначала мобильные» в сочетании с дополнительными возможностями CMS позволяют нам существенно уменьшить размер главной страницы — с 738,3 КБ для десктопной версии до 174,4 КБ для мобильных устройств.

Альтернативные решения

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

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

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

Улучшение, а не достижение идеала

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

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

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

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

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

Что думаете вы?

Как вы разрабатываете отзывчивые сайты? Используете ли определение устройства или его отдельных характеристик? В каких случаях вы предпочитаете использовать тот или иной способ? Мы ждём ваших комментариев!

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Jeremy Girard
Наталья Фадеева
Переводчик:
Наталья Фадеева
вКонтакте:
natatik_l
Twitter:
@very_busy_girl
GitHub:
NatalieF

Комментарии (2 комментария, если быть точным)

Автар пользователя
Pentaprizm

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

Автар пользователя
Farmatique

Спасибо! Интересная статья. Новых идей я для себя не открыл, но изложено очень доходчиво и последовательно.