Формы в адаптивных макетах | UX Fox

75статья

Формы в адаптивных макетах

Опубликовал Александр Иваничкин, 22 февраля 2013

Адаптивные и отзывчивые макеты

В каких типах сайтов/проектов лучше всего использовать адаптивный макет (фиксированные точки разрыва)? И в каких типах сайтов лучше использовать отзывчивый макет (гибкие сетки)?

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

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

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

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

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

Согласованность пользовательского интерфейса с устройствами против устройство-ориентированных условностей пользовательского интерфейса

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

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

  1. Фокус: Чтобы сохранять соответствующий пользовательский интерфейс на всех платформах, нужны причины, связанные с брендом; особенно это касается малоизвестных брендов, которые еще не запечатлелись в сознании потребителей. Однако, обычно пользователи более знакомы с условностями специфичных пользовательских интерфейсов, чем брендовых. Якоб Нильсен обычно говорит, что «Пользователи проводят большую часть времени на других сайтах», а так как мы говорим не только о сайтах, этот принцип актуален и здесь (говоря о смартфонах, можно просто заменить слово «сайты» на «приложения»).
  2. Ознакомленность: Тратит ли большинство ваших пользователей несколько часов в день на пользование вашим сервисом? Давно ли они им пользуются? Или большую часть составляют редкие или новые пользователи? Представьте себе, что у вас есть коммерческий или производственный сервис, и вы знаете, что большинство пользователей на протяжении всего года проводят в нем много времени. В таком случае, знакомство с приложениями важнее условностей пользовательского интерфейса устройства, так как пользователь потратил достаточно много времени на изучение уникального интерфейса. С другой стороны, если пользователи не проводили много времени в данном сервисе и не создали тесной когнитивной и эмоциональной связи с вашим дизайном и функциями, тогда условности пользовательского интерфейса определенного устройства приведут к созданию лучшего юзабилити.
  3. Функциональность: Данный фактор включает два аспекта: а) Решает ли ваш сервис только одну проблему при помощи единственной функции, или он более расширенный? и б) Различается ли функциональность и свойства на различных устройствах? Если функции, которые вы предлагаете, сильно отличаются на различных платформах, тогда придерживайтесь условностей пользовательского интерфейса, так как кросс-платформенная совместимость приведет к едва заметным результатам с точки зрения юзабилити (использование одинаковых брендовых и эстетичных видов дизайна не помогут пользователю, если функции отличаются слишком сильно – фактически, они могут даже причинить вред, так как пользователь будет считать, что все должно совпадать, хотя на самом деле все не так). С другой стороны, если вы решаете одну простую проблему, тогда отклонение от условностей пользовательского интерфейса устройства вполне допустимо, так как пользователь достаточно быстро разберется в вашем уникальном интерфейсе, и вы будете иметь возможность решать связанные с вашей функцией проблемы интерфейса более активно, чем это могут общие условности.

Вкратце: соблюдение устройство-ориентированных условностей пользовательского интерфейса – это хороший, хоть и простой, практический метод.

Балансирование исследования юзабилити с уникальными и креативными концепциями

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

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

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

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

Оптимальное размещение меток поля формы

Как наилучшим образом разместить метки поля формы для поля ввода? Над полем, слева, справа? А что с внутренними метками?

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


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

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

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


Пример внутренних меток, где метки выступают в качестве текста-заполнителя в поле формы.

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

Это перевод статьи под названием “Adaptive Vs. Responsive Layouts And Optimal Form Field Labels” от Christian Holst. Перевели в компании UXDepot с одобрением издания Smashing Magazine.

PS от переводчиков: Надеюсь, вам понравилась статья. Мы будем рады, если вы укажете нам на ошибки в переводе, чтобы мы могли их оперативно исправить. Пишите нам по адресу editor@uxfox.ru, пожалуйста 🙂

VK.init({apiId: 2745953, onlyWidgets: true}); VK.Widgets.Like(‘vk_like_5881’, {type: ‘button’, pageTitle: ‘Формы в адаптивных макетах’, pageUrl:’/adaptive-vs-responsive-and-form-layouts/’, verb: ‘0’}, 5881);

Все комментарии:

    Нет комментариев.


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