Переходимо до адаптивного вебу

7 хв. читання

Давайте почнемо з чуйного або реагуючого (responsive) веб-дизайну.

Кожен веб-розробник сьогодні знайомий з концепцією чуйного веб-дизайну (RWD). В травні 2010, концепція була прийнята в якості передової практики, процес почав вдосконалюватися і з'явилися безліч варіантів реалізації.

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

Але не дивлячись на величезний успіх чуйного веб-дизайну, він теж мав свої недоліки.

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

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

адаптивний веб-дизайн

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

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

Все приводить нас до того, що по праву вважається наступним етапом зростання в веб-розробці: Адаптивний Веб-дизайн (AWD).

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

Перевагами AWD є:

    <video src="…"></video>

Замість цього:

    <video>
     <source src="...mp4" type="video/mp4">
     <source src="...webm" type="video/webm">
     <object data="...swf" type="application/x-shockwave-flash">
     <param name="allowfullscreen" value="true">
     <param name="allowscriptaccess" value="always">
     <param name="flashvars" value="file=...mp4">
     
     <p>Your browser can't play HTML5 video. <a href="...webm"> Download it</a> instead.</p>
     </object>
    </video>

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

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

Отже, як сервер може визначити, які пристрої виконують запит?

Як не дивно, ми повертаємося до User-Agent, але на цей раз з сервера. Подивимося на рядок User-Agent, який поставляється з початковим заголовку запиту. Він буде виглядати приблизно так в Chrome's DevTools:

chrome developer tools

AWD код на сервері буде порівнювати його зі значеннями в базі даних, і повертати інформацію про даний пристрій.

Легко, правда?

Якщо не думати про набір даних в базі…

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

Це схоже на гарний час, щоб згадати кілька із слабких місць AWD:

  • Обслуговування бібліотеки виявлення типу пристрою \- За той час як ви обновили бібліотеку встигли вийти нові пристрої, нові переглядачі та іх версії.

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

  • "Різний сайт" на різних пристроях \- Деякі користувачі могли знайти недоречним використовувати якийсь модуль сайту або змісту при перегляді на одному пристрої, але потім, при перегляді на іншому пристрої не можуть знайти цей компонент (цього можна уникнути, завжди пропонуючи посилання на різні версій ваших сайтів).

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

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

І це буде здорово!

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

Ви ще тут?

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

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

    if (device.type === 'mobile phone') {
    // insert a module that will only go to mobile phones
     
    } else if (device.type === 'tablet') {
    // insert a module that will only go to tablets
     
    } else {
    // insert a module that will go to all other devices
    }

Чи:

    if (device.video.format === 'mp4') {
    echo '</video><video src="...mp4" type="video/mp4"></video>';
    } else if (device.video.format === 'webm') {
    echo '</video><video src="...webm" type="video/webm"></video>';
    } else if (device.video.format === 'swf') {
    echo '<object data="...swf" type="application/x-shockwave-flash">';
    echo ' <param name="allowfullscreen" value="true">';
    echo ' <param name="allowscriptaccess" value="always">';
    echo ' <param name="flashvars" value="file=...mp4">';
    echo '  ';
    echo '</object>';
    } else {
    echo '<p>Your browser can't video. <a href="...webm">Download it</a> instead.</p>'; 
    }

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

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

Помітили помилку? Повідомте автору, для цього достатньо виділити текст з помилкою та натиснути Ctrl+Enter
Codeguida 5.6K
Приєднався: 8 місяців тому
Коментарі (0)

    Ще немає коментарів

Щоб залишити коментар необхідно авторизуватися.

Вхід / Реєстрація