Перестаньте робити звичайні сайти. Адаптив - це не страшно

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

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

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

Ліричний відступ

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

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

Навіщо і кому це потрібно?

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

Не вистачає аргументів для продажу? Тоді знайте, що Гугл знижує у видачі сайти, які не «mobile friendly». А де Гугл, там і інші пошукові системи підтягнуться.

І ось ми у клієнта

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

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

Сміття

Візьмемо до уваги, що у вас є якийсь базовий кошторис, за яким ви складаєте КП для клієнта. Очевидно, базовий кошторис залежить від складності проекту.

Так от...

Як відрізняються кошториси при створенні сайту «з нуля» з адаптивним дизайном і без нього?

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

  • У проектуванні час збільшився на 30%. Це повністю покрило час на створення адаптивного прототипу.
  • Додався рядок «Опис поведінки активних елементів на гаджетах - 3ч»;
  • У верстці час кожного макета збільшився в 1,5 рази + скоригувалися ризики;
  • Тестування верстки також збільшилося в 1,5 рази + скоригувалися ризики;
  • Налагодження верстки збільшилося в 2 рази.

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

З сайтом «з нуля» все досить ясно, але що робити, якщо клієнт не хоче змінювати велику версію сайту?

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

Тепер повернемося до кошторису для такого проекту.

Я вже сказав про те, що вам доведеться пройти майже весь технологічний процес, що і при створенні сайту «з нуля». Кошторис сильно залежить від того, яким шляхом адаптації ви вирішили піти. В середньому по лікарні, кошторис зміниться так:

  • Проектувальник повинен скласти прототип, враховуючи структуру поточного сайту, і вибудувати блоки так, щоб логіка при перебудові не ламалася. Сміливо збільшуйте час у 2 рази від базового кошторису. Пам'ятайте, проектувальник тут робить найвідповідальнішу роботу.
  • Дизайнер. Тут можна вкласти дизайн двох дозволів однієї сторінки в бюджет, але тоді його буде складно затвердити, та й не дуже-то професійно це:) Я рекомендую закладати роботу дизайнера на завдання типу «Відмальовка іконок в SVG» (ви ж користуєтеся ним, так? 21 століття на дворі), «Відмальовка додаткових елементів сайту» (наприклад: зовнішній вигляд галереї для телефонів, меню, підказки форм тощо).
  • У верстці і далі все як у проекті «з нуля» (див. вище).

Процес розробки

Адаптив вносить деякі зміни в процес розробки сайту.

Найважливіше, щоб проектувальник, дизайнер і frontend-розробник домовилися про сітку проекту на самому початку. Інакше потім буде боляче переробляти все. Для сайтів, в яких дизайн великої версії вже готовий, раджу використовувати 24 колонки, оскільки набагато простіше буде підтягнути поточний сайт під сітку.

Проектування

Як я говорив вище, проектувальник повинен робити адаптивний прототип. У нас з цим проблем не виникло, ми використовуємо в роботі Axure RP, він дозволяє робити кілька лайаутів. Проектувальник також повинен вирішити, що буде бачити користувач на дозволі 1024.

Проблема 1024

Ще залишилися користувачі, які сидять з моніторами 1024 px за шириною. Погодьтеся, показувати їм версію для планшетів (наприклад, iPad в горизонтальному положенні має 1024 px) якось нелогічно. По ідеї, такі користувачі повинні побачити версію для ПК. Але тут вирішувати вам.

За статистикою проектів, з якими стикався я, відсоток користувачів з монітором 1024px був мізерно малий, і ми просто нехтували ними.

Дизайн

Якщо ви вибрали варіант відмальовки всіх макетів, то процес в дизайні не дуже сильно змінюється, просто йде набагато більше часу. Але якщо ви вибрали часткову відмальовку, то вам доведеться потрудитися, щоб нічого не пропустити. Для початку складіть список елементів сторінок, які найчастіше повторюються по сайту, назвемо це сторінкою віджетів. Обов "язково покажіть, як від розміру екрана змінюються кнопки, поля вводу, повідомлення про помилку форм, заголовки тощо, гадаю, вам зрозуміло. Після цього намалюйте меню для мобільних пристроїв, щоб точно розуміти, як воно буде виглядати і працювати. Не забудьте про векторні іконки та іншу невелику графіку, яку потрібно буде прибрати в спрайт. Якщо у вас e-commerce проект, то після цього етапу можна повернутися до проектування і внести зміни до прототипу. Так ви краще зрозумієте, як користувачі будуть взаємодіяти з сайтом.

Frontend-розробка

Тут майже ніяких змін. Фронтендер використовує раніше обумовлену сітку і керується принципом «Mobile first».

У завданні виконавець повинен отримати від вас такий набір:

  1. Прототип (допомагає орієнтуватися на поведінку блоків);
  2. Дизайн (віджети і текстовий опис змін при ресайзі);
  3. Чек-лист особливостей, які потрібно враховувати.

Говорячи про особливості, я маю на увазі такі штуки як:

  1. По тапу на номер телефону людина повинна перейти в додаток дзвонилки;
  2. В інпутах, де можливе введення тільки цифр, повинна відкриватися нумерна клавіатура;
  3. Мобільний користувач не повинен страждати і качати картинки по 2 мегабайти;
  4. Якщо є функціонал, який неможливо реалізувати на мобільних платформах, не забувайте робити зрозумілу заглушку для користувачів;
  5. Сторінки повинні адекватно проходити тест від гуглу (https://developers.google.com/speed/pagespeed/insights/?hl=ru).

Програмування

Наявність адаптивного сайту майже не впливає на процес програмування.

Є кілька випадків, коли програмісту потрібно буде бути більш уважним:

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

Висновки

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

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

P.S.

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

COM_SPPAGEBUILDER_NO_ITEMS_FOUND