Створення більш адаптивного вебсайту

16

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

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

Створення більш адаптивного вебсайту

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

Першим зробленим кроком в нашому проекті стало створення списку переваг і перешкод на шляху застосованого нами адаптивного підходу. Наш список виглядав так:

ПЕРЕВАГИ

1. Побудова, підтримка та просування одного вебсайту.

2. Підтримка безлічі розмірів екранів, не тільки екстремально великих моніторів настільних комп’ютерів і маленьких портативних пристроїв.

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

ПЕРЕШКОДИ

1. Вміст, призначений тільки для большеэкранных пристроїв, часто передається на маленькі екрани і просто «вимикається» з допомогою медиазапросов CSS, створюючи непотрібні завантаження.

2. З-за «безрозмірною» розмітки ми нездатні змінити початковий порядок такої розмітки (або повністю виключити з неї неважливі елементи) в залежності від пристрою або розміру екрана.

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

Починаючи з вмісту

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

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

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

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

Дані диктують напрям

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

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

Створення дизайну крайніх точок

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

Для адаптивного дизайну я застосовую метод, до якого ставлюся як «дизайн крайніх точок». Я починаю з створення версії веб-сайту для настільного комп’ютера. У ній я проробляю друкарську розмітку текстів дизайну, стиль і загальне візуальне напрямок — а також розмітку широкоекранного виду вебсайту. Коли я задоволений цією версією вебсайту, працюю над малоэкранной або «мобільного» версією, застосовуючи те ж саме візуальне напрямок, але підганяючи розмітку відповідно більш маленького екрану. До кінця цього процесу у мене вже є візуальні приклади двох найбільш різних розміток веб — версій даного проекту для найбільшого і найменшого екранів. Ці два приклади стануть моїми орієнтирами при розробці зовнішнього інтерфейсу веб-сайту.

Створення більш адаптивного вебсайту

Mobile First

Підхід до адаптивного дизайну «mobile-first» – ідея не нова. Цей метод, згідно з яким ви спочатку будуєте мобільний розмітку вебсайту, а потім застосовуєте медиазапросы для підгонки і додавання в цю розмітку по мірі збільшення розміру екрану, зараз вже деякий час вважається кращою практикою в адаптивному веб-дизайні. Підхід вже не новий, він все ще дуже важливий, а, будучи об’єднаним з нашим планом «почати з вмісту», він допоміг нам направити енергію на один з недоліків, ідентифікованих в адаптивних проектах — проблему передачі не дуже важливого вмісту.

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

Зображення, досить велика, призначалося стати частиною дизайну тільки на великих екранах (від 660 px і більше). Так як наш CSS починається з дизайну для мобільних пристроїв, ця велика графіка ніколи не відправляється на малоэкранные пристрою, тому що медиазапрос, завантажує зображення, активується тільки великими екранами. Медиазапрос, застосовує фон до елементу html, виглядає так:

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

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

Створення заради дизайну, а не пристроїв

Почавши застосовувати адаптивний дизайн в своїх веб-проектах, ми зосередилися на відомих пристроях і розмірах екранів, і наші медиазапросы часто відображали саме їх (iPhon’и, ipad’и – як в портретній так і альбомній орієнтації – лептопи, широкоекранні десктопи і т. д.). З часом виявилося, що це не найкращий підхід, тому що адресований тільки тим пристроїв і розмірами екранів, які популярні сьогодні, а не тим, які могли б з’явитися в майбутньому. Одна з потужних перспективних сторін адаптивного веб-дизайну – його спрямованість у майбутнє. Тому для повної реалізації цієї сильної сторони ми відійшли від побудови заради пристроїв замість того, щоб дозволити дизайну самому диктувати контрольні точки медиазапросов.

Метод mobile-first заклав CSS-базу нашого вебсайту. При ній в наявності, ми запустили веб-сайт у браузері та масштабували його до самого маленького розміру нашої розмітки (ми встановили в CSS мінімальну ширину 320 px). Поступово розмір вікна браузера збільшувався, щоб бачити, як відповідає на це розмітка. По мірі збільшення вікна ми помітили, що розмітка починала деформуватися. Саме в таких точках нам потрібно встановити нові медиазапросы для підгонки розмітки.

Щоб розібратися з цим методом, ми створили графіку і встановили її в якості фону десктопа. Вертикальні лінії показували ширину 320 px (наш найменший розмір), потім розставлялися на кожній сотні пікселів починаючи з 400, і застосовувалися в якості направляючих по мірі масштабування вікна браузера для визначення того, де дизайн починав «ламатися», а потім ми використовували ці приблизні значення в пікселях остаточних медиазапросах, які додали в CSS.

Створення більш адаптивного вебсайту

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

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

Адаптивна навігація

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

1. Основна навігація;

2. Те, що ми називаємо «допоміжної навігацією», яка посилається на різні портали і сервіси, що використовуються нашими клієнтами;

3. Навігація нижнього колонтитула;

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

Так як наш CSS — mobile-first, однією з перших турбот стала установка навігації для малоэкранной розмітки. Це означає відключення відображення всіх розділів навігації, крім основної навігації.

#helpNav, .subNav, footer nav {
display: none;
}

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

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

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

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

Ось 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: 6px 0;
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% 0 20px;
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’и, представлену нашій увазі під час редагування цього розділу. По суті справи, щоб поліпшити зовнішній вигляд сайту при збільшенні zoom in, дуже сильно рекомендується конвертувати px-медиазапросы в em-медиазапросы шляхом ділення всіх піксельних значень на розмір шрифту body.

Ця чудова стаття спонукала нас переглянути свої погляди на медиазапросы на основі пікселів, і це ще один приклад того, як ми продовжували вдосконалювати адаптивний метод. Тоді як ми не застосовували em’и в своїх медиазапросах в цьому окремому проекті, зараз ми з ними експериментуємо, і цей підхід варто згадки тут.

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

Наша основна навігація представлена на широких екранах, як горизонтальний ряд, що проходить через весь верх розмітки. На маленьких екранах структура основної навігації змінюється так, що вгорі кожної сторінки з’являється велика кнопка «Меню», яка посилається на навігацію внизу сторінки. Щоб домогтися цього, ми додали в заголовок посилання ID menuLink і клас oftabButtonr, що вже майже є початком розмітки. Потім помістили розділ ID mainNav в самий кінець розмітки. Всередині цього розділу перебуває наша основна навігація, яка являє собою просто ненумерованний список з кількома іншими невпорядкованими списками для меню розділів субстраниц всередині. У нас також є прив’язка-«якір» з ID toTop, яка діє як посилання наверх сторінки.

Створення більш адаптивного вебсайту

В продовження принципу mobile-first ми визначили стилі ссылке меню вгорі малоэкранной розмітки, щоб та виглядала як кнопка.

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

Створення більш адаптивного вебсайту

Наші підменю, які не відображаються у вихідному положенні, тепер можна показувати, як того вимагає сторінка. У кожного з цих підменю є унікальний ID, такий як servicesTab, і у кожного розділу вебсайту є клас, застосований до тегу body. Клас розділу «Company» – companyPage. Ми застосовуємо цей клас для призначення стилів всьому розділу сайту. Для включення підменю ми використовуємо клас розділів підменю, як воно потрібне, коли розділ активований.

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

Створення більш адаптивного вебсайту

Увеличиваемся

По мірі вступу большеэкранных розміток — знову з медиазапросом 660px і вище — ми суттєво змінюємо розмітку основної навігації. По-перше, відключаємо відображення кнопок 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: 6px 0 0 8px;
margin: 4px 0;
}
#mainNav a {
font-size: 16px;
color: #45829b;
}
#mainNav a:hover {
color: #f66606;
}

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

Спочатку розмір нашого шрифту встановлений на 16px. Досягнувши ширини 767px, ми збільшуємо його до 18px.

@media only screen and (min-width : 767px) {
#mainNav a {
font-size: 18px;
}
}

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

Отримуємо допомогу від CMS

Бажана нами CMS – ExpressionEngine, і наступного розділу статті стосуються цієї платформи, але основна ідея того, чого ми досягли за допомогою ExpressionEngine може, безсумнівно, бути застосована до інших популярних CMS-платформ.

Одна з найбільших перешкод адаптивного підходу полягає в тому, що ви не можете надати різну розмітку або різний вихідний код в різні пристрої. Це перешкода ми і хотіли перемогти за допомогою нашої CMS. Протягом експериментів та досліджень ми натрапили на статтю з назвою Справжня адаптивність з допомогою ExpressionEngine (Going Truly Adaptive With ExpressionEngine). Застосувавши докладно описану в цій статті методику, нам вдалося використовувати скрипт визначення пристроїв, щоб встановити змінну мобільного або повнорозмірної системі. Потім ми змогли завантажувати розмітку на свій сайт залежно від того, яка з цих змінних нам зустрілася.

Просунувшись вперед і застосувавши визначення пристрою, ми змогли виконати інші дуже маленькі зміни для подальшого поліпшення враження від застосування мобільних пристроїв. Для нас це було ніби прогресивного поліпшення, де ми створили якісне рішення, а потім спробували просунути його вперед, щоб донести злегка оптимізований досвід. Обов’язково прочитайте таку ж думку Кріса Койера (Chris Coyier) про комбінуванні RWD та мобільних шаблонів, де він сперечається з приводу змішування і поєднання в своєї мобільної стратегії різних технік.

Починаємо з маленького

Ви, звичайно, могли застосувати ці змінні для доставки зовсім інший розмітки та вихідного коду в різні пристрої, але наш початковий підхід був трохи менш екстремальним. Так як вже вирішено, що будь-які версії нашого сайту отримають доступ до всього вмісту, ми застосували цей метод змінних для невеликого регулювання кількості доставляється контенту. Наприклад, на головній сторінці нашого сайту ми показуємо тизери великої кількості контенту, що знаходиться на вебсайті. У розділах «Culture» і «Project Spotlight» кожному посту супроводжує зображення.

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

Створення більш адаптивного вебсайту

Синтаксис досить простий. Одного разу встановивши змінні — а вищезгадана стаття пояснює, як легко це зробити, додавши в системний файл config.php маленький скрипт — ви можете застосовувати ці змінні як оператор if.

{if global:site_version==’full’}Створення більш адаптивного вебсайту{/if}{if global:site_version==’mobile’} {title}{/if}

Це – синтаксис ExpressionEngine, але ви зможете прочитати його і легко побачите, що відбувається. Якщо зустрічається мінлива full, то ми доставляємо з вступу статті в базі даних teaser-image. Якщо замість цього зустрічається мінлива mobile, то доставляємо назва статті title.

Той же підхід застосовується до розділів домашньої сторінки «News» і «Blog», доставляючи три коротких тізера, якщо зустрічається мінлива 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.

Просуваємося ще на крок

У розділі вебсайту Culture ми опублікували статті, які часто супроводжуються безліччю зображень. На відміну від зображень-тізерів на домашній сторінці вебсайту, зображення в самих статтях є для цього вмісту нагальними, тому що допомагають зберегти або посилити акцент статті. В той час, як ці зображення важливі, вони ще й досить великі — кожне шириною 650px, при цьому велика частина статей включає щонайменше три зображення, а іноді до десяти. Так як мобільні пристрої покажуть зображення приблизно наполовину від їх початкового розміру, досить важливою стане завантаження повнорозмірних зображень. Щоб справитися з цим, ще раз звернемося до визначення пристрою та змінним.

Для кожної статті ми створюємо два набору зображень: один повнорозмірний шириною 650px, і другий – майже наполовину цього розміру. Потім застосовуємо у своїй статті змінні (але спочатку потрібно вирішити в шаблоні сторінки код ExpressionEngine), і додаємо розмітку для обох наборів зображень — але тільки один з них доставляється в браузер. Мобільні пристрої отримують маленькі зображення, а всі інші – повнорозмірні.
Той же підхід застосовується до великої рекламної області домашньої сторінки. Ці обертаються банери і зображення рекламують важливі речі, такі як прийдешні події, нові послуги, оголошення, краще, ніж інші області домашньої сторінки. Рекламний щит – інший приємний у всіх відносинах елемент, який призначений тільки для великих дисплеїв. Знову застосовуємо змінні для донесення розділу основного рекламного щита, а також запускає його JavaScript’а, до відповідного пристрою — що дає нам можливість ефективно розсилати різну розмітку на різні пристрої і усуваючи ще одну перешкоду, позначену нами на початку проекту.

За допомогою підходу mobile-first, нашого CMS ми здатні доставити нашу домашню сторінку до користувачів настільних комп’ютерів в 738.3 KB істотно зменшити її до 174.4 KB для мобільних користувачів.

Плани альтернативних варіантів

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

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

До того ж із-за того, що все відповідає принципу mobile-first, елементи, не призначені для маленьких екранів, такі як вищезгадана величезна фонова графіка, взагалі не відображаються. Єдине, що підведе нас – те, що ми зробили зі своїми змінними, згенерованими для визначення пристрою. Якщо дія розвивається за найгіршим сценарієм і визначення пристрою не спрацює, то мобільна версія просто отримає кілька додаткових зображень, або трохи розмітки, або JavaScript’а. Загальне враження все ще буде підходящим до мобільного пристрою. Непогано для «найгіршого сценарію».

Прогрес, не ідеал

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

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

Ця ідея роками надихала мене і нагадувала про те, що не можна відкидати краще тільки тому, що воно неідеально.

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

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

Як ви вважаєте?

Як ви будуєте адаптивні вебсайти? Ви застосовуєте визначення характеристики або визначення пристроїв? Коли ви рекомендували б застосовувати те чи інше? Ми чекаємо ваших коментарів!