На шляху від чуйного веб-дизайну до адаптивного

14

Від автора: Сьогодні не знайти такого веб-розробника, який не чув би про концепції чуйного веб-дизайну (responsive web design або RWD). З тих пір як Ітан Маркотт придумав цей термін у травні 2010 року, чутливий веб-дизайн був визнаний одним з кращих напрямків, встиг сформуватися, а також з’явилося безліч можливостей і способів його реалізації.

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

Однак, незважаючи на, безперечно, величезний успіх чуйного веб-дизайну, він має також і свої недоліки.

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

Теги video і audio дозволяють вирішити проблему підтримки медіа-контенту шляхом додавання декількох елементів source для того, щоб браузери могли вибрати відповідний їм файл. Однак це обходиться ціною появи великої кількості додаткової розмітки (навіть тоді, коли нам відомо, що для конкретного пристрою знадобиться тільки один файл).

На шляху від чуйного веб-дизайну до адаптивного

Обидва завдання є частиною набагато більш складної проблеми – проблеми контенту та контексту. Мобільний контекст – це цілий світ потенційних обмежень, що включає пропускну здатність Інтернет-з’єднання, розміри екранів і потужність процесора (CPU). Незалежно від того, який пристрій використовується, ми, як веб-розробники, повинні завжди прагнути до того, щоб відправляти користувачеві тільки ті ресурси, які дійсно необхідні.

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

Крім цих великих завдань, є завдання та поменше, такі як, наприклад, недостатні функціональні можливості самого пристрою. Під фронт-енді (front-end) дана задача в більшості випадків вирішується за рахунок використання JavaScript, після повного завантаження сторінки. Однак тоді працездатність сайту або програми буде сильно залежати від JavaScript, з’явиться ще більше коду, який необхідно буде завантажити користувачеві. І це часто може привести до некоректної відображенні сторінки, після того, як рішення буде застосовано.

Що таке адаптивний веб-дизайн?

Все це веде нас до того, що я сподіваюся, стане наступною фазою розвитку в веб-розробці: адаптивний веб-дизайн (adaptive web design або AWD).

Цю концепцію називають іноді чуйний дизайн + серверні компоненти (responsive web design + server side components або RESS). Але, незалежно від назв, вона передбачає ухвалення рішень з боку сервера про те, що має або не має бути надіслано користувачеві, тобто щоб не було надіслано нічого зайвого. Ось кілька плюсів адаптивного веб-дизайну:

Зменшення навантаження на пропускну спроможність з’єднання – за рахунок того, що ви можете для кожного відеофайлу на вашому сайті відправити щось на зразок наступного:

..замість чогось такого:

Ваш браузер не може коректно відображати вміст HTML5 елемента video. Завантажити файл.

Модулі, що відповідають за контекст, тобто ви можете використовувати модуль «Зателефонуйте нам» тільки на пристроях, що підтримують прямий виклик, модуль «Камера» — тільки на пристроях, що мають камери, і т. д.

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

Серверні модулі для роботи з кешем – І як тільки вся важка робота буде виконана на сервері, чому б не використовувати кеш для того, щоб не потрібно було заново обробляти дані при кожному завантаженні сторінки?

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

Вибір мови програмування – Що стосується браузера, то вибір очевидний – це JavaScript. Однак ваш сервер може використовувати будь-яку мову програмування, лише б на виході виходив код, який зможе обробити браузер.

Звичайно, концепція процесу визначення пристроїв не є новою. Вона з’явилася на самих ранніх етапах розвитку мобільних пристроїв (зазвичай, щоб переадресувати користувача на зовсім інший сайт і/або URL), і вона навіть відноситься до ще більш раннього етапу розвитку Інтернету, коли JavaScript використовувався для отримання інформації про клієнтському додатку (User-Agent), щоб визначити, яким чином наш «заплутаний» код буде функціонувати.

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

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

На шляху від чуйного веб-дизайну до адаптивного

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

За винятком невеликого словосполучення «значеннями в базі»…

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

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

Схоже, що це підходящий момент згадати кілька слабких сторін адаптивного веб-дизайну:

Підтримка бібліотеки визначення пристроїв – В тому момент, коли бібліотека визначення пристроїв оновлюється, вона вже буде застарілою, тому що нові пристрої, нові браузери і нові версії браузерів з’являються кожен день, якщо не кожну наносекунду…

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

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

Таким чином, адаптивний веб-дизайн необов’язково повинен використовуватися на всіх сайтах. Якщо ваш сайт не потребує контенті в різних контекстах, або на ньому не використовується безліч зображень, або аудіо або відео, тоді вам цілком можна обійтися тільки чуйним веб-дизайном. І це буде здорово!

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

Якщо ви все ще продовжуєте читати, значить, швидше за все, вам це цікаво. Добре. Тоді давайте перейдемо відразу до справи!
Тут буде доречним розгорнуте пояснення, т. к. я працюю в компанії Netbiscuits, і ця компанія є сервіс по виявленню пристроїв. Однак є кілька сервісів, які відрізняються набором опцій і вартістю, тому це буде вашим невеликим домашнім завданням – вирішити, який сервіс або продукт більше підходить під ваші потреби та бюджет. Незалежно від того, яке рішення ви виберіть, в кінцевому рахунку, ваші серверні шаблони будуть містити приблизно наступне:

if (device.type === ‘mobile phone’) {
// вставляє модуль, призначений тільки для мобільних телефонів
} else if (device.type === ‘tablet’) {
// вставляє модуль, призначений тільки для планшетів
} else {
// вставляє модуль, призначений для всіх інших пристроїв
}

Або:

if (device.video.format === ‘mp4’) {
// це пристрій підтримує mp4, тому відправляємо тільки той тег , який містить цей кодек.
echo «;
} else if (device.video.format === ‘webm’) {
// пристрій не підтримує mp4, але підтримує «webm», тому відправляємо тільки той тег , який містить цей кодек.
echo «;
} else if (device.video.format === ‘swf’) {
// пристрій не підтримує жоден з вищевказаних кодеків, але підтримує swf, тому відправляємо тільки цей код:
echo «;
echo ‘ ‘;
echo ‘ ‘;
echo ‘ ‘;
echo ‘ ‘;
echo «;
} else {
// це пристрій нічого не підтримує, тому відправляємо користувачеві посилання для завантаження файлу…
echo ‘

Ваш браузер не відображає вміст тега video. Завантажити файл.

‘;
}

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

На сайті компанії Netbiscuits, наприклад, ми використовуємо сервіс по визначенню пристроїв для того, щоб з’ясувати, який CSS-файл надсилати користувачеві, що визначає, крім усього іншого, яким чином будуть відображатися іконки: через SVG data URI, PNG data URI, PNG URL, або PNG URL, пропущений через фільтр «тільки IE» для забезпечення прозорості іконок.

У нас також є доступ до інформації про операційної системи (OS) пристрою, її версією, назву браузера і його версією, і все це робиться через HTML-атрибути data-. Таким чином, ми можемо додати окремий CSS-файл для усіх «шкідливих» пристроїв, які не бажають вести себе, як належить. Ось два приклади:

На шляху від чуйного веб-дизайну до адаптивного

На шляху від чуйного веб-дизайну до адаптивного

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

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