Адаптивный дизайн, или Когда не все помещается в экран

Зачастую к новым моделям проектирования пользователи относятся с недоверием. Их воспринимают как недоработанные, некачественные или сделанными наобум, без учета конкретных задач. К примеру, большие и перегруженные меню, скрытые за элементами навигации, некорректное отображение или несоответствие проекта особенностям конечного продукта — вот небольшой перечень наиболее распространенных претензий.

Но эта статья все же не об этих моделях. В ней описываются некоторые особенности малоизвестных проектных шаблонов, таких как «гибкие» интерфейсы автомобильных сайтов-конфигураторов, выпадающей меганавигации (список открытых окон из двух и более колонок), содержания сетки интерфейса, карт и диаграмм, а также адаптивных художественных направлений. Обратите внимание на то, что эта статья не техническая. Она об интересных UX-моделях пользовательских интерфейсов, встречающихся повсеместно, а не о программных шаблонах. Будьте внимательны, чтобы не пропустить ответы на свои вопросы.

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

Сложность адаптивной графики

Я думаю, что правильнее рассматривать адаптивный дизайн как сложную структуру с множеством компонентов, которые включают текстовое оформление, расположение окон, удобство пользования, навигацию и производительность (указаны лишь некоторые параметры). Поэтому каждый раз приступая к проектированию, мы пытаемся разместить нужные детали в нужном месте, учитывая данные параметры и гарантируя создание устойчивой системы, которая, вместе с тем, может трансформироваться в зависимости от наших желаний и от настроек пользователя. Исходя из этого, сам процесс разработки адаптивных веб-сайтов, выглядит достаточно сложным и болезненным, не так ли?

На самом деле, построение таких моделей — это действительно достаточно сложный процесс. Именно потому мы продолжаем исследовать чужие и пересматривать собственные проектные решения и разработки, пытаясь везде найти лучшие примеры. Они могут быть очень полезными, так как служат подсказками, когда мы оказываемся в тупике и не знаем, что делать дальше — они помогают нам сэкономить время, позволяют повторить примеры, которые уже доказали свою целесообразность. Это не значит, что мы применяем одни и те же приемы в каждом проекте, но мы можем взять их за основу, переработать их и создать новые, в зависимости от поставленной задачи. И после этого такие проектные модели могут стать невероятно ценными.

В этой статье мы внимательно изучим пять проектных адаптивных моделей: начиная от автомобильного конфигуратора (это программа для графического конструирования) до карт и инфографики.

Приготовьтесь — будет интересно!

Адаптивный интерфейс для автомобилестроения

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

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

Время на исходе, а как вы приблизились к решению этой задачи?

Каждый раз, когда нам необходимо придумать и построить сложную систему, мы начинаем двигаться в нескольких направлениях, выбирая тот вариант, который бы лучше работал на решение конкретной задачи. Для начала нужно хорошо представлять суть предполагаемой разработки — ее цели и задачи, и только затем конструировать кроссплатформенный интерфейс. Нужно сосредоточиться на содержании и функциях конечного продукта, а не на форме и внешней структуре. Для такого проекта, как автомобильный конфигуратор, базовой функцией должна стать возможность пошаговой или поэтапной комплектации модели автомобиля.

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

Как только мы достоверно поняли, что мы разрабатываем, мы можем моделировать каждый раздел и расположить модули по значимости внутри предполагаемого интерфейса. Возможно, нам по ходу придется менять назначение, внешний вид и даже функциональность этих модулей. Другими словами, мы попытались бы разбить сложную структуру на меньшие, но более управляемые компоненты и «вписали» бы их в картинку, исходя из размеров экрана. Оттолкнувшись от пилотной «заготовки», расширяя экран, добавляя нужные элементы или отбрасывая лишнее, добиваемся улучшения интерфейса. Ведь мы знаем, что делаем.

Если мы посмотрим на автомобильный конфигуратор BMW, то мы его сразу узнаем. На небольшом экране пользователи могут выбрать название модели в выпадающем меню или фотографию из автомобильного ряда. В мобильной версии конфигуратора пользователь, в основном (75% взаимодействия), применяет функцию прокрутки.

Таким образом, внизу экрана целесообразно добавить навигацию и кнопку «далее». Чтобы пользователи могли быстро переходить между разделами конфигуратора, мы также можем использовать значок «обзор», который запрашивает полноэкранный обзор всех этапов работы.

Вместо иконок для каждого раздела, которые могли быть собраны на одной странице, у каждого этапа есть своя страница. А на каждой странице, если мы не можем вывести на экран все команды сразу — например, все цвета или все виды колес — мы можем предоставить пользователям слайдер. Пролистав графическую строку влево или вправо, можно найти необходимую или понравившуюся функцию. Очевидно, мы должны сфокусироваться именно на деталях автомобиля в каждом из этапов процесса. Таким образом, мы сможем удалить все вспомогательные функции и подсказки и скрыть их (возможно, в другом выпадающем меню).

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

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

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

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

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

Адаптивная или раскрывающаяся навигация

В одном из своих эссе создатель системы управления проектами Basecamp Джейсон Фрид утверждал, что «основная трудность в процессе разработки продукта и дизайна интерфейса исходит от попыток сбалансировать необходимое, удобное и возможное».

Это звучит, как достаточно обобщенное наблюдение, но на практике оно оказывается действительно ценным. Фактически, каждый раз при попытке организовать и разработать навигацию мы группируем навигационные элементы именно в эти три блока. То, как вы их сгруппируете — и определит порядок выведения навигации на экран по всему веб-сайту. Что же это значит?

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

• Удобное — это все, что касается функций и разделов, которые используются часто, но не постоянно. Это то, где мы как разработчики должны сбалансировать критическое и некритическое. Такие элементы зачастую сложно выявить. Обычно эти разделы претендуют на роль основных навигационных элементов, которые доступны по щелчку кнопки или переключателя в выпадающем меню.

• Возможное — все, что касается блоков веб-сайта, которые редко используются и обычно не требуют особого внимания. Они должны быть доступными, но не находиться на виду и, тем более, в центре экрана. Лучше, чтобы они были скрытыми. Эти элементы обычно хорошо работают во вспомогательной навигации.

Итак, что будет, если мы используем это разделение задач применительно к навигации интерфейса?

В первую очередь мы занялись бы определением «необходимых» позиций (например, поиском наиболее посещаемых разделов веб-сайта) и выведением их на экран во всевозможных модулях. Мы смогли бы выявить «удобные» навигационные функции с комфортным раскрытием (например, кнопкой «Мeню» или переключателем), обеспечить доступ к «возможному» на отдельной странице, как только пользователь нажимает на один из модулей подразделов «Меню», и не располагать эти позиции на основной панели навигации.

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

При создании интерфейса для сайта Всемирного фонда дикой природы пошли именно по этому пути. Вместо того, чтобы вывести на экран сразу все модули навигации во всех режимах просмотра, там выбрали наиболее важные из них. А возможность доступа ко всем остальным оставили только при необходимости. В режиме увеличенного просмотра верхняя функциональная панель навигации представлена в виде семи выпадающих меню. В режиме уменьшенного экрана вы можете видеть только две ссылки («О проекте» и «Пожертвовать»), расположенные на самом видном месте экрана. Здесь же есть линейка иконок, скрывающих список основных навигационных функций, но не ссылки, которые открываются на весь экран в виде всплывающих окон после наведения на них курсора мыши. Эти функции остаются доступными, когда пользователь выполняет прокрутку страницы раздела.

В данном случае

• «очевидными» или «необходимыми» позициями могли бы быть функции «Внести» и «Принять»;
• «удобными» — основные категории в линейке меню;
• «возможными» — все функции, доступные после открытия каждого отдельного раздела.

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

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

Однако в некоторых ситуациях, видимость и доступность таких элементов целесообразны. Особенно, если многие пользователи часто возвращаются к веб-сайту или даже к определенным разделам. Анализ этих данных позволит ответить на вопросы, должны ли такие элементы войти в «удобный» или в «возможный» блоки. И именно здесь нужно разрешить все наши сомнения.

Данную стратегию можно применить к линейной навигации, а также к раскрывающемуся меню. Такой подход часто выбирают большие веб-сайты с десятками разделов. И это хорошая возможность вывести на экран одновременно большое разнообразие продуктов и разделов. Да, это хорошо работает на рабочем столе, по крайней мере там, где есть достаточно пространства. Но такой интерфейс не годится для мобильной версии. Что мы можем сделать в этом случае? У нас есть несколько вариантов.

Еженедельная газета The Guardian использует комбинацию раскрывающегося меню и шаблона «приоритет +», чтобы вывести на экран как можно больше элементов на всех этапах просмотра. Затем эти элементы помещаются в выпадающее меню каждый раз, когда они больше не востребованы. На маленьких экранах расположение элементов линейное со всеми навигационными функциями, представленными в большом списке. Выбор нужной позиции выводится на экран в верхней части.

Газета Financial Times решила представить интерфейс в виде большого меню, снабженного вкладками. Вместо того, чтобы все элементы вывести на экран в длинном списке ссылок, каждую группу представили как вкладку, которая открывается после наведения на нее курсора или после клика.

Институт вероисповедания, труда и экономики (Institute for Faith, Work, Economics) использует подобный метод для упрощенной навигации. Если первичная навигация помогает выбрать раздел сайта, то вторичная создана для того, чтобы направлять пользователя к определенным страницам. В данном случае на больших экранах в режиме ожидания представлена вторичная навигация. На маленьких экранах вторичная навигация выведена на правую сторону навигационной панели. Стрелка справа указывает на вторичную навигацию. Вероятно, что этот указатель должен быть крупнее.

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

Сайт Евровидения (EuroVision) имеет последовательное расположение навигационных элементов и позволяет flexbox (инструмент управления блоками веб-сайтов) заботиться о заполнении пространства экрана рационально и автоматически. Результат не всегда совершенен, но это быстро и просто. И не критично для макета.

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

Расположение в интерфейсе множества графических элементов и нескольких уровней навигации говорит о том, что проект несовершенен и требует упрощения.

Лучше начать с минимального количества позиций, протестировать проект на удобство использования и по мере необходимости добавлять новые уровни навигации.

Не каждый скрытый раздел в проекте следует сохранять, ведь часто они просто не востребованы.

Заполнение адаптивной мозаикой

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

Легче всего это сделать, расположив элементы в вертикальный список разделов.

На сайте Sapporo применили этот прием. Здесь мозаика не повторяется многократно на странице, а превращение каждого раздела в отдельный блок, работает очень хорошо.

Но это не оптимальное решение для всех веб-сайтов. Typekit представляет сложный образец заполнения мозаикой с уникальным размещением блоков. В данном случае, на странице необходимо было расположить множество блоков. В результате для их вертикального выравнивания потребовалась бы очень длинная страница. Вместо этого разработчики Typekit решили заменить мозаику полосой прокрутки в уменьшенном виде. Пользователи могут провести пальцем влево или вправо для того, чтобы познакомиться с разделами. Хорошо бы было добавить переключатели «предыдущий» и «следующий» в верхнем правом углу каждой полосы прокрутки для того, чтобы помочь пользователям легко перемещаться между этими разделами.

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

Сайт Музея мирового футбола ФИФА (FIFA World Football Museum) отображает блоки наполнения интерфейса в виде сфер. Разработчиков на это вдохновила официальная эмблема ФИФА — шар. Каждая сфера выстроена из шестиугольников, а ее края используются в качестве соединителей между блоками.

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

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

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

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

Адаптивные карты и схемы

Как правило, даже самая совершенная заполняющая интерфейс мозаика не столь детализирована, как большая карта или специфическая инфографика. Часто на картах используются своеобразные фильтры поиска — например, чтобы позволить пользователям визуально выбрать район города, где они хотели бы приобрести недвижимость. Очевидно, поле ввода упростило бы такой поиск — но только, если пользователи точно знают, что они ищут. Что делать, если вы хотите вывести на экран диапазон цен для конкретных территорий, используя цвета и текст так, чтобы пользователь мог щелкнуть мышью по интересующей его зоне и изменить ее масштаб?

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

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

Другой интересный вариант применения карт состоит в изменении точных очертаний территорий на схематические. Это то, что канал новостей CNN решил сделать для политической карты «Оценка кандидата». Вместо того, чтобы изобразить на карте территории штатов в точном размере и очертании, CNN представляет каждый штат в системе координат (по широте и долготе) схематически, с буквенными аббревиатурами внутри и результатами поддержки избирателей по каждому штату. Картинка мало похожа на реальную карту, но она хорошо визуализирует представленные данные и может быть использована в мобильной версии вместо длинного списка вертикальных таблиц с данными штатов.

Адаптивное художественное направление

Модификация картинок и точность деталей для различных по размеру экранов является одним из краеугольных камней адаптивного художественного направления. Можно предположить, что в веб-дизайне, художественное направление чаще всего применяют исключительно для специальных страниц. Например, страниц перехода (переадресации). Здесь мы точно должны быть уверены, что продукт представлен отлично. Значит, стоит потрудится, чтобы изменение визуальных эффектов соответствовало размерам экранов.

Иногда это не только предпочтительно, но и необходимо. У Emirates airlines веб-сайт не адаптивный. Компания использует и мобильную версию сайта. Но, к удивлению, содержание обоих веб-сайтов похоже, хотя и очень отличается с точки зрения художественного оформления.

Основные изображения на верхней части экрана отличаются, в зависимости от языка, который выбирает пользователь при входе на сайт. Например, в международной английской версии женщина смотрит слева направо, держа десерт в правой руке. Этот прием используется также и в мобильный версии веб-сайт.

В мобильной арабской версии сайта женщина смотрит справа налево и держит стакан десерт в левой руке. Такое же изображение и в основной арабской версии сайта.

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

Еще один пример, где необходимо адаптивное художественное направление — это обучающие сайты. Чтобы рассказать историю главного героя — бегуна из Токио, сайт о марафоне Kobe Marathon QBB использует серию мультипликационных картинок. Изображения различны для больших и маленьких экранов. Эти же картинки остаются фоновыми для всех страниц.

Эту идею можно развить и позволить пользователям изменять размер изображений в рамках комикса. Это удобно для просмотра каждого отдельного кадра из всей линейки изображений. Именно так делают в Аль-Джазире (Al Jazeera). Когда пользователь открывает кадр в мобильной версии, кадр увеличивается и оказывается в центре экрана, вытеснив все остальные картинки. Для перемещения по кадрам, пользователю достаточно провести пальцем по экрану влево или вправо.

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

Заключение

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

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

Адаптивное художественное направление — это сложнее, но оно может существенно улучшить страницы переадресации и любой обучающий проект.

‍

Источник: smashingmagazine.com

‍