Адаптація дизайну (конкретний випадок)

18

Від автора: Це – історія того, чого ми навчилися під час переробки дизайну для нашого самого вимогливого клієнта — самих себе! У цій статті з власного досвіду оновлення веб-сайту нашого агентства я поясню, чому ми закинули окремий мобільний сайт, і зроблю огляд процесу створення нового адаптивного дизайну.

У себе в Cyber-Duck вже протягом декількох років ми робили відразу і адаптивні вебсайти, і адаптивні мобільні сайти. Обидва варіанти, звичайно, мають свої «за» і «проти». На окремому мобільному сайті є можливість пристосовувати до контексту своїх користувачів вміст і навіть взаємодія, тоді як адаптивний вебсайт означає краще контентне рівність для користувачів і підтримку єдиного вебсайту.

Навіщо адаптувати дизайн?

Історія нашої реконструкції почалася в серпні 2012р. До того наша попередня стратегія подання окремого мобільного, планшетного і настільного вебсайтів в реальності була досить непогана; зміни вносилися, а користувача активність була порівнянна з нашим вебсайтом для десктопів. Повинен сказати, що в той час ця стратегія народилася виключно з потреби термінового підгонці нашого старіючого настільного вебсайту під зростаюча кількість «таблетных» і мобільних користувачів.

Адаптація дизайну (конкретний випадок)

Для створення свого попереднього оптимізованого під мобільні пристрої вебсайту ми застосовували jQuery Mobile в якості швидкої підгонки свого старіючого вебсайту для настільних комп’ютерів під зростаюча кількість мобільних користувачів.

Ми спеціально створили планшетний і мобільний сайти, пам’ятаючи про користувачів цих пристроїв — найбільшим пріоритетом для нас була продуктивність. Ми хотіли значно поліпшити час завантаження свого настільного вебсайту; домашня сторінка для десктопів важила 2,2 MB при 84 HTTP-запити, так і мобільна все ще була завелика – 700 KB при 46 HTTP-запити. Також ми створили дизайн інтерфейсів спеціально під сенсорне введення, застосувавши jQuery Mobile для поліпшення враження свого користувача.

ЗМІНА ПІДХОДУ

Незважаючи на це, деякі фактори привели нас до висновку, що даний підхід для нашого власного вебсайту вже нежиттєздатний через:

Необхідність підтримки безлічі баз вихідних текстів,

Управління контентом,

Появи нових міні-планшетів і фаблетов.

Два перших не були ідеальними, але, принаймні, з ними можна впоратися. Третій фактор, однак, все руйнував. Звичайно, ми могли створити дизайн сайту, оптимізованого під міні-планшети, але при такій кількості здатних вийти в Мережу пристроїв всіх форм і розмірів, щодня випускаються на ринок, це був лише питання часу: коли нам доведеться думати про оптимізацію під нові форм-фактори.

Адаптація дизайну (конкретний випадок)

Ми хотіли зробити свій новий вебсайт легким у підтримці і більше future-friendly до неминучого припливу нових форм-факторів.

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

ВИЗНАЧЕННЯ ЦІЛЕЙ АДАПТИВНОГО ДИЗАЙНУ

На самому початку перегляду ми поставили перед собою кілька простих цілей або, якщо хочете, принципів, яких хотіли досягти в своєму адаптивному дизайні:

Швидкість. Продуктивність впливає на всіх.

Доступність. Повинен працювати без стилів, фонів або JavaScript’а.

Рівність вмісту. У всіх платформах повинні бути однаковий контент і функціональність.

Апаратна незалежність. Не залишати платформи.

Future-friendly. Скоротити підтримку.

Спираючись на ці цілі, у якості вихідної точки дизайну ми вирішили зробити огляд свого чинного мобільного веб-сайту і використовувати його як базу для адаптивного дизайну. Ми вивчили, як зробити поліпшення для широких екранів, а не намагатися втиснути свій попередній настільний сайт у мобільний формат.

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

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

Адаптація дизайну (конкретний випадок)

Наша дизайнерська команда користувалася вправами з сортуванням карток для реорганізації існуючого вмісту для нового сайту.

Пріоритет віддається продуктивності

Потенційна пастка адаптивного веб-дизайну, якої немає на окремому мобільному сайті, полягає в тому, що може постраждати продуктивність, особливо якщо при певній ширині екрану ви просто приховуєте контент за допомогою display: none. Нам хотілося уникнути цієї проблеми, заклавши в серцевину свого дизайну і технічних рішень швидкість сайту. Перевага цього у тому, що вебсайт з найкращою продуктивністю задовольнить всіх користувачів, не тільки мобільних.

Для досягнення цієї мети ми визначили функціональний бюджет — набір цілей для покращення швидкості та розміру свого нового сайту. Для мобільних користувачів нам був потрібен такий сайт, який виконувався б щонайменше як наш існуючий мобільний сайт; тобто, для мобільного контрольної точки нам потрібно було завантажувати не більше 40 HTTP-запитів і 500 KB даних. (Це тільки для початку. Наступним кроком було зниження цього обсягу менш ніж до 100 KB.)

СТОРОННІ СКРИПТИ

Найбільш простий спосіб зрізати жирок – як можна більше оголити сторонні скрипти. Згідно Zurb, «під завантаження кнопок соціальних мереж Facebook, Twitter і Google за загальну кількість в 19 запитів займається 246,7 KB пропускної здатності». В результаті ми замінили важкі плагіни соціальних мереж на легковагі посилання на них.

Адаптація дизайну (конкретний випадок)

Заміна важких сторонніх кнопок соціальних мереж простими посиланнями на ці мережі може значно знизити кількість HTTP-запитів і час завантаження сторінки.

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

БУЛА ПОТРІБНА CMS НАСПРАВДІ?

Раніше при обговоренні вимог до нового вебсайту ми обмірковували, чи взагалі нам потрібна система управління контентом (CMS). Адже, як і очікується від цифрового агентства, члени команди здебільшого знайомі з HTML, CSS і Git, так що ми виразно могли впоратися з вмістом і без CMS.

Скориставшись внутрішніми інструментами моніторингу продуктивності, такими як New Relic, можна було бачити, що наша попередня CMS стала ключовим фактором повільного завантаження сторінок. Так що було прийнято досить радикальне рішення про повному видаленні CMS з нашого вебсайту. Зробили виняток ми тільки для блогу, якому для ефективного управління із-за об’єму і частоти опублікованого контенту все ще була потрібна CMS.

Адаптація дизайну (конкретний випадок)

Попередня домашня сторінка запитувала сервер бази даних 1,459 раз за загальний час виконання 2,34 секунди.

Наш старий сайт був побудований на архітектурі model-view-controller’а (MVC), що з’єднувалася з CMS WordPress. Для прикладу – звичайна сторінка з WordPress використовує для своєї завантаження від 600 до 1500 запитів; сервер бази даних запитується сотні разів, а просто видаливши CMS нам одним махом вдалося знизити цю кількість до нуля.

Адаптація дизайну (конкретний випадок)

Команда розробляла прототипи, щоб бачити шляхи покращення продуктивності та адаптивності.

Видаливши CMS для статичних сторінок, ми усунули необхідність в базі даних і динамічних шаблонах. За допомогою популярного каркаса PHP Laravel ми реалізували настроювану систему «динамічного маршруту і статичного шаблону». Це означає, що кожен раз при виклику ДО а на нашому вебсайті маршрутизатор Laravel точно знає, який шаблон завантажувати, зіставивши URL з його назвою, а в шаблоні весь контент вже статично розкладений в HTML.

В результаті цього єдиного дії, нам вдалося поліпшити час обробки вебсайту більш ніж на 3900%. Якщо взяти за приклад домашню сторінку, в середньому ми поліпшили серверну швидкість з 2,2 секунд до 56 мілісекунд.

Адаптація дизайну (конкретний випадок)

Серверна швидкість обробки тепер всього 56 мілісекунд при нулі запитів до бази даних — приблизно у 40 разів швидше, ніж була.

Природно, такий підхід не всіх влаштовує (і багатьох наших клієнтів, насправді), але в початку будь-якого проекту слід запитати себе, яка CMS підходить найбільше, і чи потрібна вона взагалі. Звичайно, існують і інші можливості, включаючи CMS на файлової основі, такі як Kirby і Statamic, побудова або пристосування легковагих CMS, таких як Perch, або просто застосування кращого кешування на серверній стороні, наприклад, з допомогою Varnish.

Зрештою ми вирішили видалити CMS, тому що навіть сама легка з них і добре оптимізована з «розумним» кешуванням має свій стелю і не може поєднувати продуктивність і серверне простір статичних файлів.

УНИКНУТИ ГОТОВИХ КАРКАСІВ CSS

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

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

При створенні дизайну ми виходили з вмісту, тобто воно формувало розмітку і сітку в протилежність тому, коли розмітка визначає вміст.

Адаптація дизайну (конкретний випадок)

За годинниковою стрілкою згори: Розмітка з трьох колонок для десктопа стає однією колонкою в мобільному пристрої і користується перевагою додаткового простору на «таблетках» шляхом зсуву зображення вліво від контенту.

@media only screen and (min-width: 120px) and (min-device-width: 120px) {
// Застосовує мобільний сітку
.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) {
// Застосовує власну сітку для підгонки вмісту
.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) {
// Застосовує звичайну систему сіток для настільного комп’ютера
.container {
width:960px;
margin:0 auto;
}
.col4 {
width: 300px;
float: left;
margin: 0 10px;
}
}

Щоб уникнути повторення коду, ми використали для розробки клієнтської сторони Sass, стежачи за тим, щоб кожен клаптик CSS використовувався насправді. Sass також здатний мінімізувати висновок і гарантувати, що CSS буде якомога менше.

$sass —style watch-compressed scss:css

Крім того, ми скористалися функціями всередині Sass для побудови користувацького сітки. Ось код для сітки десктопа:

@import «vars»;
// Система сіток
$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.

//Сітка
$vgrid: 20px;
$col: 60px;
$gutter: 20px;

Сітка розраховує ширину колонок на основі їх кількості в цьому діапазоні, роблячи їх гнучкими для будь-якої конфігурації розмітки або сітки. Ми виклали цей код з відкритим попередником на GitHub, так що будь ласка – беріть і адаптуйте цю гнучку систему сіток до вимог власного проекту — і дайте нам знати, як у вас виходить!

УМОВНА ЗАВАНТАЖЕННЯ JAVASCRIPT’А

Для подальшого прискорення нового вебсайту нам потрібно було завантажувати JavaScript тільки тоді, коли він потрібен або підтримується. Досягли ми цього за допомогою RequireJS: гарантували завантаження JavaScript’а тільки після перевірки його доступності в запитуваній браузера і завантаження тільки тих скриптів, які даний браузер може підтримувати. RequireJS також працює як завантажувач модулів, забезпечуючи виклик будь-якого JavaScript’а тільки якщо той потрібен на цій сторінці.

Крім того, в RequireJS міститься зручний інструмент оптимізації, що поєднує пов’язані скрипти та мінімізує їх допомогою UglifyJS з метою зменшення розміру файлу JavaScript’а.

Адаптація дизайну (конкретний випадок)

Оптимізація зменшила розмір JavaScript’а з 411 KB до 106 KB.

ОПТИМІЗАЦІЯ ЗОБРАЖЕНЬ РЕСУРСІВ

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

Адаптація дизайну (конкретний випадок)

Провівши знебарвленню і зробивши розмиття несуттєвих частин зображень, ми значно зменшили їх розмір.

Ми також скористалися ImageOptim і TinyPNG для стиснення своїх зображень і спрайтів. Ці інструменти видаляють всі непотрібні дані без втрати якості зображення. Так, наприклад, вага спрайту основного зображення знизився з 111 KB до 40 KB.

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

Адаптація дизайну (конкретний випадок)

На наведеному вище зображенні видно, що на мобільному пристрої елементи слайдшоу набагато легше.

@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;
}
}
/* Загальна завантаження: 27 KB */
}

Адаптація дизайну (конкретний випадок)

На десктоп завантажується більше ресурсів.

У той же час на настільному комп’ютері ми завантажуємо більше матеріалів, щоб зробити доступними розміри для великих екранів.

@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’) top center no-repeat;
div {
background: url(‘carousel/dmd/sc-computer.jpg’) top center no-repeat;
}
}
.tablet {
background: url(‘carousel/dmd/tablet.png’) top center no-repeat;
div {
background: url(‘carousel/dmd/sc-tablet.jpg’) top center no-repeat;
}
}
.phone {
background: url(‘carousel/dmd/phone.png’) top center no-repeat;
div {
background: url(‘carousel/dmd/sc-mobile.jpg’) top center no-repeat;
}
}
.eiffel {
background: url(‘#{$img}carousel/dmd/eiffel.png’) top center no-repeat;
}
.bigben {
background: url(‘#{$img}carousel/dmd/bigben.png’) top center no-repeat;
}
.train {
background: url(‘#{$img}carousel/dmd/train.png’) top center no-repeat;
}
}
/* Загальна завантаження: 266 KB */
}

ШВИДКА ДОСТАВКА ВМІСТУ

Золоте правило продуктивності Yahoo свідчить, що 80-90% часу відгуку кінцевого користувача витрачається на завантаження всіх компонентів сторінки: зображень, таблиць стилів, скриптів, flash’а і так далі». Коротше кажучи, будь-якого запиту потрібен час на виконання; отже, кожен запит (як, наприклад, доставка файлу з сервера) буде неминуче збільшувати час завантаження.

Застосовуючи ery CloudFlare (CDN), ми відокремили завдання веб-сервера по доставці файлів від обробки вебсайту. Це означає, що наш веб-сервер зосереджується на програмі, а не доставці статичних файлів. Ми перемістили всі статичні матеріали в окремий субдомен (в нашому випадку static.cyber-duck.co.uk) для зменшення до мінімуму кількості куки, що посилаються з кожним запитом матеріалу, що в свою чергу зменшує ширину смуги пропускання, що вимагається для кожного ресурсу.

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

Додатково до CDN ми застосували правила Gzip і заголовки expires у файлі .htaccess HTML5 Boilerplate. Вони використовують модуль Apache’а mod_deflate для стиснення виводу файлів в браузер, а також встановлюють заголовкам припинення по закінченню строку на далеке майбутнє, щоб гарантувати краще кешування веб-сайту для повернулися відвідувачів.

Створення цього адаптивного дизайну

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

ВІРНИЙ КОД ДЛЯ ЦІЄЇ ЗАДАЧІ

Застосовуючи цей метод, ми змогли зробити спеціалізовану мобільний оптимізацію – перетворення верхнього меню на мобільному пристрої так, щоб у ньому з’явилися кнопки телефону і карти для надання можливості нашим мобільним відвідувачам зателефонувати або швидко відшукати наш офіс.

Ми застосовували цей підхід до всього сайту для активації і деактивації динамічних елементів, завжди гарантуючи, що при недоступному 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, де він все одно відмінно відображався.

Адаптація дизайну (конкретний випадок)

Наші дизайнери і команда розробки користувальницького інтерфейсу тестували новий вебсайт на величезній кількості пристроїв, включаючи старі моделі, такі як цей Nokia X2.

Ще більше доступності

Наш обов’язок як веб-дизайнерів і розробників — не тільки зробити вебсайти більш доступними, але і показати своїм клієнтам і колегам, про що їм слід потурбуватися. Нижче наведено пара способів виграшу в доступності, які ми застосували на своєму вебсайті.

ТЕКСТ

Текст чітко помітний на фонах при співвідношенні контрастності в 3:1 для заголовків і 4,5:1 — для основного тексту.

Структурований Текст відповідними заголовками і в значимому порядку, і описує тему або мета вмісту.

Розмір тексту можна міняти без втрати вмісту і функціональності.

ПОСИЛАННЯ

Призначення всіх посилань прояснюється описовим текстом, а коли це непрактично — альтернативним текстом.

Перша посилання кожної сторінки обходить навігацію для переходу прямо до вмісту. Вона приховано за замовчуванням в стандартному браузері, але доступна при відповідних сценаріїв.

Адреси сторінок (тобто ДО и) можуть читатися людиною і постійні, де це тільки можливо.

Ми реалізували ключі доступу для швидкої навігації до важливих сторінок і властивостями.

Ось HTML для «швидкої» посилання:

Navigation Skip

І CSS:

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

ЗОБРАЖЕННЯ

У всіх зображень вмісту альтернативний текст (атрибут alt), який показується там, де зображення відключені або не підтримуються.

Вміст доступно і зрозуміло при відключених або непідтримуваних зображеннях.

ВІДЕО

У всіх розміщених на YouTube відеороликів є супровідні підпису (субтитри), якщо в них є усна мова.

ФОРМИ

Всі елементи управління формами і поля ретельно і чітко марковані.

Вводах форм призначені типи і атрибути для завантаження на сенсорні пристрої відповідної клавіатури.

Всі важливі поля форми при її відправленні перевіряються на помилки.

Будь-яка знайдена помилка описується користувачеві у вигляді тексту разом з пропозиціями про її виправлення.

У всіх форм є відповідний порядок фокусування для того, щоб по них можна було переміщатися за допомогою кнопки Tab на клавіатурі.

Всі форми можна подавати з допомогою клавіш «Enter» або «Enter».

Застосовувати відповідні типи введення і атрибути, такі як required і placeholder легко і вони роблять форму більш доступною.

Лише початок

Результати виходу у світ нового web-сайту пару тижнів тому вражають. Мобільний трафік збільшився більш ніж на 200% (при 82% збільшення всього трафіку в середньому); середня тривалість відвідування сайту зросла на 18%, а рівень виходу з домашньої сторінки для мобільних користувачів знизився більш ніж на 4000%. Хоча статистика може сказати нам про це, дані показують, що адаптивний вебсайт демонструє на мобільних пристроях кращу продуктивність, ніж наш попередній спеціальний мобільний вебсайт.

Адаптація дизайну (конкретний випадок)

Згідно з Google Analytics, час відповіді сервера зменшилася в середньому з 1,21 секунд до 170 мілісекунд. Точно так само час завантаження сайту зменшилася в середньому з 9,19 секунд до 1,82 секунд.

Важливо пам’ятати, що це всього лише початок. Ми знаємо, що можемо ще поліпшити деякі області: оптимізуючи далі продуктивність, зменшуючи розмір файлів, пам’ятаючи про майбутній розвиток пристроїв при створенні контрольних точок, застосовуючи рішення серверної сторони, такі як адаптивні зображення для подальшого контекстуального поліпшення, наводячи свої проекти у відповідність зі стандартами «AA» керівництва по досягненню доступності веб-вмісту.

Адаптація дизайну (конкретний випадок)

Адаптивність — тільки перший крок нашого вебсайту.

На інавгураційній конференції Smashing в 2012р. Бред Фрост (Brad Frost) процитував Бенджаміна Франкліна, який сказав: «Якщо перестав змінюватися, то ти – пропащий чоловік». Для всіх працівників веб-індустрії це твердження істинне у вищій ступеня. Ми працюємо в такому засобі масової інформації, яке швидко і постійно еволюціонує. Втриматися на хвилі в цьому постійно мінливому ландшафті — складне завдання, але саме вона робить роботу з веб такою фантастичною і хвилюючою.

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