«Для каких проектов и сайтов лучше использовать адаптивную вёрстку (с ограниченным числом стилей), а для каких — гибкий макет на основе сетки?»

Чисто теоретически гибкий макет на основе сетки ^[1] лучше адаптивного, но иногда последний вариант — более практичное решение.

Адаптивный макет позволяет лучше контролировать работу сайта: здесь приходится учитывать лишь несколько состояний, в то время как у гибкого макета их число может превышать сотню. Безусловно, в массе своей варианты будут мало чем отличаться. Тем не менее, иногда трудно спрогнозировать поведение сайта в тех или иных условиях. Тестировать гибкий сайт и предугадывать все возможные проблемы довольно сложно. Но в этом своеобразная красота гибкого макета: при некоторой неопределённости в деталях вы всегда можете быть уверены в крепком фундаменте постройки. Конечно, вы не сможете с точностью до пикселя представить, как будет выглядеть страница в окне 943×684 px. Зато можно гарантировать уверенную работу сайта, и не сомневаться, что базовые функции и схема разметки будут представлены так, как задумано.

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

Говоря о преимуществах адаптивной разметки, в качестве аргумента часто приводят особенности работы с типографикой: контроль над шириной колонок и возможность избежать коротких концевых строк в заголовках. Несколько ценных мыслей по этому поводу высказал Трент Уолтон (Trent Walton). Фактически, регулируя размер шрифта (это легко сделать, задавая его в em’ах), вы можете добиться удобной для чтения ширины (50-75 знаков в строке) и в гибком макете. Остаётся решить проблему коротких концевых строк. Кто-то считает, что «против природы веба не попрёшь», но зачастую усилия по оформлению заголовков оправдывают себя. Здесь на помощь приходят такие плагины, как FitText.

[1] Не существует чёткого разграничения понятий «адаптивный дизайн» («adaptive design») и «создание гибкого макета» («responsive design»). Джеффри Зельдман (Jeffrey Zeldman) настаивает на том, что обозначение термином «responsive design» отдельного технологического подхода слишком узко. Ведь их общая цель — обеспечить удобство использования сайта на всех устройствах, даже на тех, которые нам ещё неизвестны, и потому фиксированные разметки (fixed breakpoints) также должны быть включены в определение «responsive (web) design». Аарон Густафсон (Aaron Gustafson) определяет адаптивный дизайн как «создание интерфейсов, адаптирующихся под условия, в которых работает пользователь (как сточки зрения формы, так и с точки зрения функций)», а под понятием «responsive design» понимает «гибкий макет на основе сетки, гибкие изображения и использование медиазапросов». Отвечая на читательский вопрос, я намеренно ограничил предмет дискуссии рамками макета — адаптивного или гибкого. Определения, указанные в вопросе, я сохраняю на протяжении всего ответа, то есть под «responsive layout» я понимаю гибкий макет на основе сетки, а под «adaptive layout» — набор фиксированных по ширине разметок (fixed breakpoints).

Единый интерфейс для разных устройств vs. проектирование с учётом платформы

«Что важнее при создании продукта для широкого диапазона устройств (например, Netflix или Pandora): постоянство бренда и единый интерфейс или следование правилам, указанным в руководствах конкретных платформ (iPhone, Android, телевидения, Xbox)?»

Здесь нужно учитывать три фактора: сферу деятельности, степень знакомства пользователей с интерфейсом и различия в функциях приложения для разных платформ.

1) Сфера деятельности

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

2) Степень знакомства пользователей с продуктом

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

3) Функции

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

Кратко: придерживаться решений, выработанных в рамках платформы — беспроигрышный вариант.

Как найти компромисс между удобством для пользователей и необычным экспериментальным дизайном

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

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

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

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

Правильное расположение названий полей в форме

«Как лучше расположить названия полей в форме? Над полем, слева от него, справа? Что вы можете сказать по поводу текста внутри полей?»

Кратко: для большинства веб-форм, будь то формы связи, страницы регистрации или платёжные формы, оптимальным решением будет расположить название над полем ввода. Исследование движений глаз при чтении названий, проведённое в 2006 году Маттео Пензо (Matteo Penzo), подтверждает это правило.

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

Исключение из правила следует делать для очень длинных форм, где пользователь должен быстро найти нужные пункты — здесь боковое расположение названий придётся кстати. То же самое относится и к полям с «рыбой» — когда от пользователя требуется заполнить всего лишь несколько пунктов (например, при редактировании профиля).

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

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

Оригинал: http://uxdesign.smashingmagazine.com/2012/11/08/ux-design-qa-with-christian-holst/

Григорий Коченов
Креативный директор в AGIMA

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

Хорошая заметка про названия полей. Еще раз убедился, как был прав наш аналитик Артем Гриценко, критикующий меня за расположение названий форм в самих формах.

Максим Степанов
Руководитель группы разработчиков в AGIMA

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

Артем Лебсак
Владелец в Joomru LLC

Адаптивный макет лучше гибкого, при возможности переключиться на полную версию на мобильном устройстве (планшете с экраном высокого разрешения, к примеру). Гибкий макет, он же «резиновая вёрстка» («responsive design», это те же яйца, только в профиль) — этой идеологии 100 лет в обед и она по-прежнему актуальна, но имеет существенный изъян. Недостаток гибкого макета в масштабировании графических элементов страницы. То есть, добиться сносного отображения шрифтов при масштабировании в большинстве браузеров можно, но вот показывать красивые фоны или иллюстрации в правильном(!) соотношении с другими элементами страницы — вот это уже очень и очень затруднительно. Отображение адаптивного макета проще прогнозировать.

Итого: Адаптивный макет — проще, быстрее, а значит дешевле.

P.S. Для себя я сформулировал разницу между «адаптивным дизайном» («adaptive design») и «созданием гибкого макета» («responsive design») в том, что в адаптивном дизайне мы изменяем положение и количество элементов на странице, а при создании гибкого макета изменяем сами элементы.