Основы применения адаптивного дизайна

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

На сайте http://www.cyber-duck.co.uk/ мы уже несколько лет раскручиваем обе версии сайта: компьютерный веб-сайт и адаптивный мобильный сайт; и там, и там есть свои плюсы и минусы. Имея отдельный сайт для мобильных устройств мы можем приспособить контент, в то время, как на компьютерном улучшена функция равенства контента для пользователей, да и в постоянном обслуживании находится только второй.

Зачем нужен адаптивный дизайн?

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

Наши сайты для мобильных и планшетов создавались специально для таких пользователей, и их внешний вид был нашей главной задачей. Мы хотели улучшить время загрузки главной страницы: для обычной версии сайта, её параметры были равны 2,2 МБ и 84 HTTP запроса, в то время как для мобильной: 700КБ и 46 HTTP запросов. Также, для удобства пользователей, был специально разработан интерфейс для сенсорных устройств при помощи jQuery Mobile.

Изменение подхода

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

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

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

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

Постановка целей.

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

1. Скорость. В эффективности заинтересованны все.
2. Доступность. Он должен работать без всяких стилей, фонов и JavaScript.
3. Равенство контента. На всех платформах один и те же контент и функциональность.
4. Универсальность. Независимость от платформы.
5. Удобство в будущем. Минимум обслуживания.

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

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

Также мы использовали данные аналитиков с наших предыдущих сайтов, используя информацию с Google Analytics, Lead Forensics и CrazyEgg, чтобы лучше понять, чего от нас ждут, и что именно нужно нашим пользователям. В результате, мы смогли расставить приоритеты стратегии контента, основываясь на том, каким именно юзеры захотят видеть наш сайт.

Производительность стала приоритетной

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

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

Сторонние скрипты

Самый простой способ убрать с сайта все лишнее - настолько, насколько это возможно избавиться от сторонних скриптов. Согласно с Zurb, “кнопки загрузки Фейсбука, Твиттера, Гугл и других соц-сетей, в общей сложности занимают 19 запросов и 246,7 КБ пропускной способности.” В результате мы заменили тяжелые плагины соц-сетей на легковесные.

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

Нужна ли нам Система Управления Содержимым (CMS)?

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

С помощью серверного мониторинга производительности инструментов, таких, как New Relic, мы отследили, что именно из-за CMS предыдущая версия сайта загружалась медленно. Вот почему мы избавились от этой системы. Исключение было только для блога, где, в связи с объемом и частотой добавляющегося контента, CMS необходим.

Наш старый сайт был написан на архитектуре Model-View-Controller (MVC), связанной с CMS WordPress. Для примера, типичной странице WordPress для загрузки требуются от 600 до 1500 запросов, сервер БД запрашивается сотни раз, и просто удалив CMS, мы одним махом обнулили эти цифры.

Стоило удалить CMS для статических страниц, и необходимость в БД и динамических шаблонах отпала. Используя популярный PHP фрэймворк Laravel, мы внедрили систему “динамических маршрутов и статических шаблонов”. Это означает, что при каждом вызове URL нашего сайта, маршрутизатор Lavarel точно знает, какой именно шаблон загружать, путем сопоставления URL с именем шаблона, а содержимое шаблона уже загружается из HTML.

В результате, нам удалось улучшить скорость обработки веб-сайта более чем на 3900%. Вот, например, для главной страницы мы свели скорость обработки на сервере, в среднем, от 2,2 секунды до 56 миллисекунд.

Конечно, данный подход не удовлетворит всех (да и немногих наших-же клиентов), но вначале каждого проекта, следует понять, какой CMS будет удобнее, и нужен ли он вообще. Есть, конечно, и другие варианты, допустим, файловые CMS (например, Kirby и Statamic), облегченные CMS (как Perch), или же улучшенные реализации кэширования (например, при помощи Varnish).

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

Избегаем готовых CSS- фрэймворков

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

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

Также мы поработали с контентом,т.е., контент был сформирован так, чтобы не переплетаться.

@media only screen and (min-width: 120px) and (min-device-width: 120px) {

   // Uses mobile grid
   .container {
      width: 100%;
   }
   .col12, .col11, .col10, .col9, .col8, .col7, .col6, .col5, .col4, .col3 {
      width: 92%;
      margin: 0 4% 20px 4%;
   }
   .col2 {
      width: 46%;
      float: left;
      margin: 0 4% 20px 4%;
   }
}

@media only screen and (min-width: 600px) and (min-device-width: 600px) {

   // Uses custom grid to accomodate content
   .home-content {
      article {
         width: 92%;
         clear: both;
         margin: 0 4% 20px 4%;
      }
      .image {
         float: left;
         width: 40%;
      }
      .text {
         float: left;
         width: 50%;
         margin-left: 5%;
         .btn {
            @include box-sizing(content-box);
            width: 100%;
         }
      }
   }
}

@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {

   // Uses regular desktop grid system
   .container {
      width:960px;
      margin:0 auto;
   }
   .col4 {
      width: 300px;
      float: left;
      margin: 0 10px;
   }
}

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

$sass --watch --style compressed scss:css

Также, в рамках Sass, была использована функция для построения наших сеток. Это код для иконок рабочего стола: .

@import "vars";

// Grid system
$wrap: $col * 12 + $gutter * 11;
@for $i from 2 through 12 {
   .col#{$i} {
      width: $col * $i + $gutter * $i - $gutter;
      float: left;
      margin: 0 $gutter/2 $vgrid $gutter/2;
   }
}
@for $i from 1 through 11 {
   .pre#{$i} {
      padding-left: $col * $i + $gutter * $i;
   }
}
@for $i from 1 through 11 {
   .suf#{$i} {
      padding-right: $col * $i + $gutter * $i;
   }
}
.container {
   width: $wrap + $gutter;
   margin: 0 auto;
   padding-top: 1px;
}
.colr {
   float: right;
   margin: 0 $gutter;
}
.alpha {
   margin-left: 0;
}
.omega {
   margin-right: 0;
}

Отсюда мы можем настроить ширину столбцов и колонок в сетке, лишь изменив файл конфигурации vars.

// Grid
$vgrid:      20px;
$col:        60px;
$gutter:     20px;

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

Загрузка JAVASCRIPT

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

Еще RequireJS обладает удобным инструментом оптимизации, который для уменьшения размера файла JS объединяет связные скрипты и их мини-файлы через UglifyJS.

Оптимизируем изображения

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

Еще для сжатия изображений и спрайтов мы использовали ImageOptim и TinyPNG. Эти инструменты удаляют все ненужные данные, не влияя на качество изображения. Это привело к снижению веса основных частиц изображения, например, от 111 до 40 КБ.

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

Как видно на рисунке выше, для мобильной версии баннер со слайд-шоу меньше. Код CSS:

@media only screen and (min-width: 120px) and (min-device-width: 120px) {
   .item-1 {
      background: $white url('carousel/dmd/background-optima-m.jpg') 50% 0 no-repeat;
      .computer, .tablet, .phone, .eiffel, .bigben, .train {
         display: none;
      }
   }
   /* Total loaded: 27 KB */
}

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

Код CSS:

@media only screen and (min-width: 1024px) and (min-device-width: 1024px) {
   .item-1 {
      background: $white url('carousel/dmd/background.jpg') center -30px no-repeat;
      .computer {
         background: url('carousel/dmd/computer.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-computer.jpg') center top no-repeat;
         }
      }
      .tablet {
         background: url('carousel/dmd/tablet.png') center top no-repeat;
         div   {
            background:  url('carousel/dmd/sc-tablet.jpg') center top no-repeat;
         }
      }
      .phone {
         background: url('carousel/dmd/phone.png') center top no-repeat;
         div {
            background: url('carousel/dmd/sc-mobile.jpg') center top no-repeat;
         }
      }
      .eiffel {
         background: url('#{$img}carousel/dmd/eiffel.png') center top no-repeat;
      }
      .bigben {
         background: url('#{$img}carousel/dmd/bigben.png') center top no-repeat;
      }
      .train {
         background: url('#{$img}carousel/dmd/train.png') center top no-repeat;
      }
   }
   /* Total loaded: 266 KB */
}

Увеличиваем скорость загрузки контента

Золотое правило производительности от Yahoo гласит, что “80-90% времени отводится на загрузку компонентов страницы: изображения, таблицы стилей, скрипты, Flash, и т.д. ” Короче говоря, каждому запросу необходимо время на загрузку, поэтому каждый запрос (например, получить доступ к файл с сервера) неизбежно влечет к увеличению времени загрузки.

Используя сеть доставки контента CloudFlare (CDN), мы разделили задачу обслуживания файла на веб-сервере от обработки веб-сайта. Это значит, что наш сервер концентрируется на приложении, а не на обслуживании статических файлов. Мы убрали все статические ресурсы на отдельный субдомен (в данном случае, в static.cyber-duck.co.uk) для снижения количества cookie, отправляемых с каждым запросом, что, в свою очередь, снижает пропускную способность, необходимую каждому ресурсу.

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

К CDN добавим, что в .htaccess мы использовали правила и время жизни Gzip. Здесь для сжатия исходных файлов в браузере используется модуль Apache mod_deflate, также он устанавливает срок действия заголовков на будущее, чтобы обеспечить лучшее кэширование веб-сайта.

Создание настоящего адаптивного веб-дизайна

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

Для создания настоящего адаптивного дизайна, мы делегировали все стили на CSS, используя при этом JavaScript, чтобы просто изменять "статусы" элементов, добавляя и удаляя CSS классы, не считая скрытие и отображения элементов.

Пишем код для каждой задачи

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

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

JavaScript- код:

$('#menu').addClass('closed');
$('.btn-menu').click(function(e){
   e.preventDefault();
   $('#menu').toggleClass('closed');
});

CSS-код для компьютерного сайта:

.nav {
   display: block;
   float: right;
}
.btn-menu, .btn-call, .btn-map {
   display: none;
}

CSS-код для мобильного сайта:

.menu {
   display: block;
   height: auto;
   overflow: hidden;
}
.menu.closed {
   height: 0;
}
.btn-menu, .btn-call, .btn-map {
   display: block;
}

Анимация, как усовершенствование

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

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

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

Анимация на CSS позволяет использовать аппаратное ускорение по максимуму.

.menu {
   height: auto;
   transition: height 200ms linear;
}
.menu.closed {
   height: 0;
   transition: height 200ms linear;
}

Брейкпоинты теперь зависят от контента и дизайна, а не от устройства.

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

Данный подход универсален и гарантирует, что не нужно будет оптимизировать код под различные устройства. Мы включили (хоть и не ограничили) брейкпоинты на 120, 240, 600, 760, 980 и 1360 пикселей, также как и запланировали медиа запросы для особого контента.

Хоть мы и не установили брейкпоинты, зависящие от устройств для дальнейшего удобства, мы проверили наш сайт на ужасающем количестве устройств и браузеров (включая даже Lynx, Playstation 3, Kindle Paperwhite, PSP Vita и пр.). Кроме того, мы тестили сайт на старых устройствах Nokia, и он все еще хорошо работал.

Больше доступности

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

Ниже приведено несколько быстрых способов сделать сайт доступным.

Текст

• Текст без фона виден лучше всего, причем, для заголовков коэффициент контрастности - 3:1, а для основного текста - 4,5:1,
• Текст должен быть структурирован с соответствующим заголовком и в правильном порядке,
• Размер текста можно менять без потери без потери информации.

Ссылки

• У каждой ссылки должно быть понятное описание, и, по возможности, альтернативный текст,
• Первая ссылка на любой странице минует навигацию сайта и сразу переходит к содержанию,
• Адреса страниц (URL-ы) должны быть интуитивно понятны, и ,по возможности, неизменны,
• Мы реализовали специальные ссылки для быстрой навигации к самым важным страницам и функциям.

HTML-код для “пропуска” навигации:

<a href="#content" title="Skip to content" accesskey="s" class="btn-skip">Skip navigation</a>

CSS-код:

.btn-skip {
   position: absolute;
   left: -9999px;
}

Изображения

• Все изображения содержат текст (с аттрибутом alt), который выводится на экран, когда изображение в браузере отключены или не поддерживается,
• Контент доступен и понятен, даже если изображение отключено или не поддерживается.

Видео

• Все видео, размещенные на Youtube, имеют заголовки (субтитры), если в них есть речь.

Формы

• Все элементы управления формами и полями правильно и четко обозначены,
• Всем формам ввода назначены необходимые атрибуты, чтобы на сенсорных устройствах загружалась нужная раскладка клавиатуры,
• При отправке формы все необходимые поля проверяются на наличие ошибок,
• Любая найденная ошибка описывается пользователю, наряду с подсказкой по её исправлению,
• По любой форме можно передвигаться с помощью кнопки Tab на клавиатуре,
• Отправка форм может быть осуществлена путём нажатия клавиш “Return” или “Enter” .

Использование таких атрибутов, как required и placeholder облегчает работу с формой.

<input type="email" id="email" name="email" value="" required="" placeholder="Pop your email address in here">

Начальный запуск сайта.

Мы уже получили впечатляющие результаты, хотя запустили сайт всего пару недель назад. Мобильный трафик вырос более чем на 200% (общий трафик вырос на 82%), средняя продолжительность посещения сайта возросла до 18%, а процент пользователей, покинувших сайт сразу после захода на главную страницу снизился более чем 4000%. Эта статистика много о чем говорит, в данном случае, о том, что адаптивный дизайн работает намного лучше предыдущей версии отдельного мобильного сайта.

И это только начало! Мы знаем, что еще можно улучшить на сайте: в дальнейшем оптимизировать производительность, максимально сжать файлы, обобщить мультитач- жесты для всех брейкпоинтов, использовать серверные решения (например, адаптивные изображения), соответствовать в наибольшей степени стандартам Web Content Accessibility Guidelines’ “AA”.

В 2012 году на Smashing Conference Брэд Фрост в своей торжественной речи цитировал Бенжамина Франклина: “When you are finished changing, you’re finished.”- “Вы завершите работу тогда, когда закончите что-либо менять.” Наиболее правдоподобно это звучит для тех, кто работает в веб-индустрии. Мы работаем в среде, которая постоянно развивается, и нам нелегко держать руку на пульсе новых технологий, но именно это и греет душу.

• Комментарии