Материальный Дизайн — это язык дизайна, введенный Google год назад, представляющий из себя смелую попытку компании создания объединенного пользовательского опыта на всех устройствах и платформах. Это отмечено смелыми цветами, либеральным, но принципиальным использованием теней для обозначения уровней UI и плавную анимацию, которая обеспечивает довольно хороший опыт взаимодействия в Android (и некоторых приложениях Google на iOS).
Однако одна вещь в Материальном Дизайне, напрягает меня с тех пор, как в прошлом году она была введена : Плавающая кнопка действия.
FABs (Floating action button), согласно Google, это круглые кнопки, которые парят над UI и «используются для способствования действию». Они выступают в качестве кнопки призыва к действию, предназначенных для выполнения того действия, которое пользователи производят на этом экране чаще всего.
И из-за смелого визуального стиля Материального Дизайна, FAB довольно трудно игнорировать — и в этом заключается проблема. В то время как на практике, в идеальных условиях, FAB кажется, обеспечивает хороший UX, — злоупотребление FAB будет вредно для UX приложения в целом. Вот несколько тому причин.
Эффект погружения исходит из опыта
FAB выделяются визуально — они буквально сверху любого элемента UI на экране. Также, добавление FAB автоматически привело бы к менее иммерсивному UX, особенно влияя на приложения (или экраны) целями которых является обеспечить интерактивный эффект.
Один пример — новое фото приложение от Google.
Фото приложение открывается в виде галереи с плавающей кнопкой поиска. Но дело в том, что когда я открываю фото приложение, я просто хочу… посмотреть свои фотографии. Таким образом, плавающая кнопка поиска отвлекает пользователя от погружения в просмотр фотографий, который является основной целью приложения. Представленный, умный поиск — уникальная функция фото приложения Google. Но значит ли это что ему нужно дать высший уровень, постоянного FAB в приложении? (Я думаю нет.)
Как ни странно, Google со мной согласен. На странице Материального Дизайна посвященной FABs Google объясняет, что «не каждый экран нуждается в плавающей командной кнопке».
И затем добавляет, что “основное действие это коснуться изображения в галерее, в этом случае кнопка не нужна.
Они выделяются, и стоят на пути.
Это может показаться другой стороной медали, но есть другое, более важное свойство FАB стоящее на пути его полезности. Занимая место на экране, FAB фактически блокирует контент.
Ну да ладно, FAB же это просто маленькая круглая кнопочка, да? Сколько контента она может заблокировать?
Если вы посмотрите на скриншот фото приложения, то поймете, что поисковая FAB блокируют приблизительно 50 процентов уменьшенного изображения — безусловно достаточно чтобы закрыть пару лиц. Это по сути создает необходимость в одной дополнительной прокрутке, на каждое четвертое уменьшенное изображение последнего ряда на экране. И это еще не самое плохое.
Пользователь Dumazy разместил пост на Graphic Design Stack Exchange о проблеме, с которой он столкнулся, когда FAB заблокировал звездочку «избранного», а также время на экране его приложения. Это иллюстрирует проблему всех приложений со списковым представлением, и это становится особенно проблематичным, когда последний пункт в списке не может прокручиваться дальше вверх. Это означает, что целая колонка, должна быть принесена в жертву (меняя местоположение звездочки, и т.д.), чтобы предоставить надлежащее удобство использования экрана.
Следовательно, FAB занимает намного больше пространства на экране, чем предлагает его размер.
Способствование действию скорее всего так часто не используется.
Проэктируя UX, нужно помнить правило 80/20, которое говорит о том, что пользователи будут использовать 20% особенностей 80% времени. Другими словами, большая часть усилий должна быть применена к проектированию того небольшого количества элементов, которые пользователи будут использовать большую часть времени.
FAB фактически это и делает — в теории. Но что, если «Способствование действию» не используется так часто ?
Возьмите, например, приложение Google Gmail.
FAB Gmail приложения — это кнопка создания, которая предполагает, что основное действие пользователей — это создание письма.
Но так ли это?
Многократные исследования показали, что по крайне мере 50 % писем читаются на мобильном устройстве, и почти ни одно не говорит такого о создании электронных писем. Другими словами, как подтвердил бы наш ежедневный опыт, большинство пользователей мобильных устройств склонны использовать свои почтовые приложения чтобы читать электронные письма.
Возможно, какое-то количество людей использует мобильные устройства что бы отвечать на письма, но это происходит только после открытия письма (обратите внимание на то, что это означает, что они обойдут FAB). Такое поведение пользователей, вероятно вызванное довольно несовершенным механизмом ввода виртуальных клавиатур и авто заменой, означает, что основное действие которое выполняют пользователи, это чтение (и ответ) электронных писем, а не создание новых.
Итак, что делает FAB кнопка «создать письмо»? В редких случаях, она доставляет удовольствие пользователям, когда они хотят создать письмо, при помощи этого приложения. Но в остальное время, она только занимает место на экране, блокирует «звездочку» и время, и постоянно отвлекает ярким красным цветом.
Хотим ли мы FAB? Вычеркнуть предыдущее — нужен ли он нам вообще?
Конечно, не все применения FAB ухудшают опыт использования Материальных приложений. Есть некоторые яркие примеры FABs, которые имеют смысл, и которые улучшают UX этих приложений.
Карты Google это отличный пример правильно примененного FAB. Главное действие, выполняемое пользователями на Картах, это получение направлений, таким образом, очень правильно использовать FAB именно для этой цели.
Но учтите, что Карты довольно особый случай, когда пользователи контента заинтересованы почти всегда в попадании в центр экрана (где и находится Ваша синяя точка, отмечающая положение). В большинстве приложений, однако, сетка или списковое представление означают, что пользователи взаимодействуют с содержанием, расположенным везде на экране, включая те места, где обычно расположены FAB.
Учтите также, что скриншоты выше рассказывают только часть истории: при фактическом использовании, FABs остаются на месте, даже когда пользователь использует прокрутку (большую часть времени). Как Google неоднократно подчеркивал в Материальном Дизайне, — дизайн движения так же важен как дизайн UI.
Отсутствие движения — акцентирование на экранном пространстве — в контексте движущегося содержания создает более высокий уровень отвлечения, которое скриншотами никак не показать.
Итак, поскольку у нас почти нет примеров хорошей реализации FAB, то напрашивается вопрос: нужны ли они?
Когда мы смотрим на недостатки наличия FABs в приложениях, мы можем свести это к простому пониманию: пользователи не только выполняют действия в приложениях, они также потребляют содержание.
Дизайн FAB в Материальном дизайне основывается на предпосылке, что пользователи большую часть времени выполняют определенное действие, и, следовательно, ему должен быть предоставлен повышенный статус в виде главной, высокоуровневой кнопки. Но во многих приложениях, пользователи также сосредоточены на потреблении содержания: в фото приложении пользователи хотят рассмотреть фотографии; в приложении Gmail пользователи хотят прочитать свои электронные письма; и в приложении Facebook, пользователи хотят прочитать сообщения своих друзей.
FAB, таким образом, философия дизайна (или по крайней мере выбор дизайна), которая подчиняет оптимальное потребление содержания совершению действия. И мы должны спросить себя: необходим ли такой компромисс? Хотим ли мы вообще идти на такой компромисс?
Когда FABs большую часть времени приводит к ухудшению UX, когда трудно выяснить единственное наиболее используемое действие в рамках приложения, и когда приходится находить окольные пути (когда FAB исчезает при прокрутке или накладывается на другие элементы при пролистывании) я сказал бы, что ответ — нет.
Материальный Дизайн Google, довольно хороший объединенный, принципиальный язык дизайна, но FAB далеко не самое в нем лучшее.