- PVSM.RU - https://www.pvsm.ru -
Прошло около двух лет с момента запуска первого адаптивного сайта нашей компанией, примерно столько же этому вопросу в России вообще. С этого момента мне, как проектировщику, уже удалось пройтись по многим граблям, поэтому в первом своем посте хотел бы поделиться мыслями, что поменялось у нас в процессах проектирования сайтов вместе с приходом адаптива.
Подробно описывать весь процесс проектирования я не буду, по этому вопросу достаточно статей на хабре, а остановлюсь лишь на нескольких моментах.
Итак, усредненный процесс проектирования в общем виде у нас выглядит так:
Ниже я привел несколько основных эволюционных дополнений к процессу, которые привносит адаптивный дизайн:
Надо сказать, что 2 года назад, как это обычно бывает со всем новым, клиент очень настороженно относился к реализации у себя адаптивности по причине затратности и непонимания преимуществ. Сейчас у 80% наших новых проектов адаптивность — одно из обязательных входящих требований. При этом клиента все еще не очень волнуют пределы адаптивности, или имеют место случаи, когда ее границы клиентом определяются ошибочно.
Пример 1: Клиент знает, что на его сайте есть мобильная аудитория (исходя из данных статистики), но не имеет информации о ее поведении.
Пример 2: Клиенту кажется, что мобильная аудитория предпочитает статьи новостям его портала. Результаты исследования показали, что клиенту действительно казалось, а по факту все в точности наоборот.
На что повлияют сделанные выводы? На выбор границ адаптивности, а именно:
Поэтому для того, чтобы не наломать дров с самого начала, нужно выслушать клиента и все его гипотезы проверить уже на измеряемых параметрах, используя известные инструменты (Google Analytics, Яндекс.Метрику).
Что делать, если у клиента вообще не было сайта? Нужно проводить полный цикл классического проектирования с тестированием прототипов, анализировать среду, конкурентов и целевую аудиторию доступными способами и обязательно удостовериться, что все правильно после выпуска проекта. Хороший интерфейс — это, как известно, процесс. Сделать идеально сразу не получится.
Работа с аналитикой также дает нам информацию о реальных пользовательских группах, ключевых задачах и сценариях взаимодействия без их синтетического придумывания. Но это применимо ко всем сайтам вообще.
Один из самых сложных и холиварных этапов работ. Собственно, этап, ради которого весь этот адаптив и нужен. Предмет горячих дискуссий — что делать с контентом при миграции между версиями сайта, рассчитанными на разные устройства.
Основные возможности работы с контентом:
По мере уменьшения рабочей области окна браузера мы корректируем шрифт, таблицы, изменяем количество изображений для публикации в строку и т.п. Это базовое правило работы с контентом.
Контент, который, исходя из аналитики и/или составленных пользовательских сценариев является второстепенным, мы прячем за каким-либо действием (кликом, скроллом) и т.п.
Иногда для мобильной аудитории нам важнее сказать или показать что-то в первую очередь, тогда мы можем менять приоритет контента. У интернет-магазинов, например, часто достаточно четко можно выделить группы товаров, которые интересуют мобильную аудиторию больше, чем остальной ассортимент.
Мы привыкли, что на обычных мобильных сайтах мы представляем пользователям урезанную версию контента, при этом сохраняя возможность перейти к полной версии. Адаптивный дизайн лишает нас такой возможности, поскольку версия сайта одна. Можно ли теперь удалять контент?
Начну с предпосылок для этого — существует мнение, что сценарии использования мобильными устройствами отличаются от сценариев использования десктопных устройств. У мобильной аудитории свои специфические задачи, они более ориентированы на результат. Пользователи серфят через мобильные платформы прерывисто и хаотично. Так ли это? И что такое мобильные устройства на сегодняшний день?
Ответ на эти два вопроса, при современном уровне портативности и размытости границ мобильной аудитории, звучит так: для формирования основных пользовательских задач мы должны учитывать не только платформы, но и обстоятельства, условия, текущие потребности, т.е. контекст использования. Маленькие экраны устройств пользователей не означают их ограниченные потребности, они вообще ничего не означают.
Поэтому очень часто дифференцировать аудитории бывает проблематично, но также есть и ситуации, когда различия в задачах и поведении очевидны и значительны.
Таким образом, показывать пользователю весь контент, или, как чаcто можно встречать в обсуждениях, только «несколько глав книги» нужно исходя из действительных пользовательских задач. А придумывать их, как и пытаться переосмыслить опыт других сайтов схожей тематики, достаточно опасно. Поэтому есть простое правило: если не уверен, не удаляй. Удалять контент можно только при условии, что есть достоверные данные или возможность проверить отсутствие потребности в нем со стороны нужного сегмента аудитории. В качестве инструмента проверки все те же сервисы веб-аналитики.
Тут начинается самое интересное. Даже если задачи мобильной аудитории совпадают с задачами «десктопной», это совсем не означает, что мы не должны подготовить контент в том числе и по смысловой оптимизации. Если зайти на сайт с мобильного — это будет уже другой сайт, и не все пользователи будут рады серфить среди «вороха» страниц маркетингового текста в поисках ответов.
Что мы делаем? Не даем всему контенту десктопной версии в том же виде перемещаться в мобильный сектор. Задача данной оптимизации — исключительно в сокращении публикуемого объема и увеличении скорости потребления контента.
Это нужно далеко не всегда, и точно не подходит для:
Для наглядного представления, мы оформляем трансформацию в рамках контентных таблиц:
Все выглядело несколько проще и складывалось из фиксации высокоуровневых требований: структуры контента и взаимосвязей, типов контента, формата контента, требований к составу атрибутов, а также более детальных контентных таблиц с ключевыми характеристиками содержания.
При разработке адаптивного сайта, мы сталкивается с множеством неопределенностей, связанных с многообразием устройств (разными вьюпортами, производительностью, интерфейсами). Естественно, без достаточного абстрагирования от устройств спроектировать сайт становится просто невозможно.
И здесь на помощь нам приходят широко распространённые еще до адаптива методы разработки:
Все они помогают нашему интерфейсу оставаться устройствонезависимым и обеспечивать заданный уровень отказоустойчивости.
Поскольку, в основном, их используют непосредственно в разработке, хочу кратко остановиться на вопросе, как эти методы влияют на организацию проектирования.
В Graceful Degradation мы начинаем проектирование с самых функциональных версий сайта, а в Progressive Enhancement — наоборот, с самых нефункциональных и простых. Как правило, это означает, что в Graceful Degradation начинаем с десктопных версий, а в Progressive Enhancement — c мобильных, но это не обязательно именно так. А Mobile First, как раз, рекомендует нам начинать только с мобильных устройств и вообще отлично сочетается с Progressive Enhancement.
Какой подход выбрать?
Для себя я определил следующие критерии выбора:
Progressive Enhancement/Mobile First хорош, когда на момент начала проектирования все функциональные требования уже сформированы. У нас, как правило, под эту категорию попадают: внутренние (все уже 100500 раз обговорено, обрисовано, записано заранее) и промо-проекты (нет серьезной и сложной функциональности). Поэтому ничего не мешает начать с прототипирования мобильной версии (Mobile First) и, затем, постепенно наращивать функциональные возможности.
Когда же прототипы — элемент извлечения и утверждения требований, как это у нас принято для большинства клиентских проектов, нужно начинать с Graceful Degradation.
Иными словами, если мы работаем с требованиями при создании прототипов, надо работать с ними на примере самых функциональных состояний интерфейса. В контексте адаптивного дизайна это может быть версия не под самые большие размеры экрана, но это должна быть версия, функциональность которой не должна быть превышена любым другим состоянием этого интерфейса. Это позволяет не растерять функциональные требования (как на рисунке ниже, где показано что одно из требований может быть не очевидно) и дает четкое понимание проекта в целом — и для нас и для клиента.
После этого можно двигаться вниз по адаптационной лестнице, а иногда и вниз и вверх.
Сейчас на рынке большое количество устройств. Разрешений тоже не мало (коллеги собрали неплохой список тут [1]). Адаптивный сайт должен непрерывно отображаться на всем целевом диапазоне разрешений. Для этих целей существует понятие breakpoint-ов или пограничных состояний интерфейса. Их количество, естественно, сильно меньше всех возможных разрешений на нужном диапазоне.
Существует три подхода к выбору этих точек:
Третий способ гибкий, правильный, поскольку абстрагирован от устройств вообще и нравится дизайнерам, но абсолютно непрогнозируемый по трудозатратам. На проектах с фиксированной стоимостью его использовать сложно.
Первые два удобны проектировщикам и нравятся менеджерам, поскольку прозрачны и не создают дополнительных неопределённостей, а также поддаются учету при первичной оценке трудозатрат на проект.
Так же к самому процессу прототипирования у нас добавляется проектирование адаптационных закономерностей. Адаптация интерфейса должна происходить логично, закономерно и максимально однообразно. Однотипные элементы и блоки (таблицы, списки и т.п.) разных разделов должны обладать минимально достаточной вариативностью, т.е. лучше стремиться использовать одинаковые паттерны. Это касается и контентных и функциональных блоков. Их примеры можно посмотреть тут [2].
И еще пара слов о том, что не стоит забывать при проектировании адаптивного интерфейса:
Поскольку адаптивность связана с динамическим изменением структуры страниц и контента, возникает следующая проблема: в каком виде презентовывать конечный результат? Варианта у нас два:
Несмотря на тенденцию использования интерактивных прототипов, если их не нужно активно тестировать, можно использовать статику без последствий.
Согласовывать нужно поэтапно, показывая только одну версию (при использовании GD, самую функциональную). Как только она будет утверждена, переходить к разработке следующей. Это страхует нас от того, что в случае каких-либо изменений в прототипах со стороны клиента нам придется менять вместо одного макета — 4 и больше.
На практике самый понятный и беспроигрышный вариант — согласовывать статичные макеты. Они просты для понимания, внесения правок, при этом, сама механика адаптации и связанный с ней интерактив клиенту часто неинтересны. Предоставление макетов порциями — не так утомительно для клиента, хотя все же наблюдается тенденция, что его внимания не хватает на все согласования.
Более сложный вариант — интерактивные прототипы. При этом существует риск согласовать не все, не зная об этом. Причина проста: с появлением движущихся/интерактивных элементов, отсутствия четких фиксированных положений вероятность упустить что-либо из виду значительно выше.
Адаптив подкинул проектировщикам достаточно дополнительной работы, увеличив ее по моим подсчетам примерно в 2,5 раза и затребовал дополнительные ресурсы, а так же сильно подружил их с фронтэндами и тестировщиками. Им, кстати, досталось больше всего, но это тема другой статьи.
Если вам интересно узнать подробнее о каких-то аспектах или есть свой опыт в проектировании адаптивных сайтов — пишите, обязательно обсудим в комментариях.
Автор: RGD
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/interfejsy/36428
Ссылки в тексте:
[1] тут: http://spirelightmedia.com/resources/responsive-design-device-resolution-reference
[2] тут: http://bradfrost.github.io/this-is-responsive/
[3] пример: http://www.agima.ru/upload/habr/alfa.gif
[4] Источник: http://habrahabr.ru/post/182974/
Нажмите здесь для печати.