Перестаньте делать обычные сайты. Адаптив — это не страшно

Перестаньте делать обычные сайты. Адаптив — это не страшно - 1

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

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

Если вы не знаете, что такое адаптивный сайт, и работаете менеджером интернет-проектов, мне вас искренне жаль. Вы сильно отстали от жизни, срочно бегите в гугл. Я не буду тратить время даже на копипаст из википедии.

Лирическое отступление

Я не стал рассматривать отдельную мобильную версию сайта в статье, так как считаю, что этот формат родился мертвым. Устройства растут с каждым годом, меняются соотношения экранов, количество пикселей на дюйм и так далее. Отдельная мобильная версия не выдержит всех этих краевых случаев или потребует неоправданно большой бюджет на поддержку.

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

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

Автор: de_arnst

Источник

Оставить комментарий