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