Привет, Хабр! Меня зовут Александр, я работаю frontend-разработчиком в Т-Банке. В этой статье я расскажу о UX (User Experience) на основе MUI (Material User Interface): исследую интересные практики и покажу, какие элементы UI можно использовать, чтобы улучшить UX.
Статья — выжимка из документации MUI по их принципам дизайна. Обратите внимание, что в статье нет акцента на особенностях UX, присущих MUI, но выделена полезная информация, которую можно использовать вне рамок MUI:
— поверхности;
— раскладка;
— сжатие;
— цвета;
— темная тема;
— показ ошибок.
Поверхности
Мне приходилось участвовать в обсуждении дизайна, когда созданные интерфейсы внезапно начинали «мозолить глаз» и нужно было найти ответ на вопрос, что не так.
К примеру, такой дизайн был в одном из разрабатываемых мной приложений.
Вид верхней панели казался странным, но я не мог понять почему. Как раз в то время, по счастливой случайности, я ознакомился с концепциями поверхностей в MUI и понял, что в верхней панели попросту использовалось слишком много разграничителей: через тень и границу. Я убрал границы и оставил только тень.
Панель будто бы вырвалась из оков границ, удалось сбросить лишнюю нагрузку с интерфейса.
Концепция показа областей интерфейса в MUI основана на том, что отображение элементов разбивается на определенные поверхности. При этом каждая поверхность может отделяться от другой на основе трехмерных координат с помощью света, поверхности и теней. Наиболее важную роль в выделении поверхностей играют тени, потому что они позволяют задавать высоту по Z-оси.
Тени позволяют выделять более важные и менее важные поверхности, помогают пользователю легче найти информацию, подчеркивают интерактивность элемента. Например, если взглянуть на диаграмму поверхностей, можно увидеть, что у диалогового окна наибольший приоритет по высоте по сравнению с другими поверхностями.
Элементы с равной высотой через тени расцениваются как равные по приоритету.
Затенение фона (skimming) выделяет поверхность по приоритету, но не подчеркивает изменение высоты по Z-оси.
Но не стоит злоупотреблять тенями и «навешивать» их на обычные элементы.
Раскладка
Важная составляющая раскладки — консистентность отступов, правильное масштабирование и привычный вид, который знаком большинству пользователей, так называемый закон Якоба. Закон гласит, что пользователи имеют модель мышления, которая сформировалась на основе использования других систем. То есть они ожидают от новой системы похожего поведения. Например, раскладка с панелью сверху, навигацией сбоку и контентом внизу смотрится привычно.
Панель приложения в раскладке может служить для показа часто используемой или приоритетной информации и функциональности.
Для отделения панели приложения от других поверхностей приложения можно использовать заливку фона, границы или изменение высоты через тени.
Панель навигации может иметь свернутый и развернутый вид. При больших разрешениях монитора удобнее показывать панель в развернутом виде, а при маленьких разрешениях это может быть модальная панель навигации, которая при раскрытии может перекрывать контент (skimming).
На мобильных устройствах можно вынести часто используемые действия или навигацию в нижнюю панель.
Способ отображения основного контента играет важную роль, поэтому очень полезно группировать элементы. Группировку можно сделать по принципу схожести. Например, карточки с одинаковой внутренней раскладкой и типографикой будут восприниматься как одна группа.
Если же элементы различаются визуально, можно использовать группировку с помощью уменьшения отступов между элементами, которые нужно сгруппировать, и увеличения между группами элементов — так называемую неявную группировку.
Можно использовать явную группировку через установку границ для группы элементов или изменение высоты через тени.
В MUI есть таблица, которая помогает определить поведение и отображение компонентов при изменении размеров экрана:
Тип компонента | Мобильное отображение | Планшетное отображение | Десктопное отображение |
Навигация (вариант 1) | Нижняя навигация | Шторка навигации (navigation rail) | Боковая панель |
Навигация (вариант 2) | Модальная панель навигации | Модальная панель навигации | Открытая боковая панель |
Коммуникация | Полноэкранное модальное окно | Модальное окно | Модальное окно |
Действия | Нижняя панель | Меню | Меню |
Сжатие
Сжатие тесно связано с плотностью размещения элементов, ведь на маленьких экранах сжатие можно применять на большом количестве однообразной информации — таблицах, формах, списках, чтобы улучшить читаемость и фокусировку на контенте.
Задачи, подразумевающие интерактивность, и компоненты, основанные на уведомлениях, не должны применять сжатие. Например, увеличение сжатия в диалоговом окне уменьшает фокусировку, читаемость и важность.
Или, к примеру, слишком сильное сжатие элементов выпадающего меню может привести к тому, что на мобильных устройствах пользователю будет неудобно выбирать опции. Подобные правила описаны законом Фиттса: интерактивные элементы должны быть большими, иметь большое расстояние между собой и быть легко находимыми.
Компоненты с большим сжатием должны иметь более крупные внешние и внутренние отступы.
Цвета
Основной цвет (primary) чаще всего применяется в приложении для различия UI-элементов между собой:
Primary-цвет можно по умолчанию применять к кнопкам или, к примеру, к заголовкам, чтобы сделать акцент на них. Нежелательно использовать primary-цвет для обычного текста параграфов.
Secondary-цвета позволяют добавить еще больше особенностей в приложение. Такие цвета можно применять на floating-кнопках, прогресс-барах, заголовках, при выделении текста и так далее.
Цвета могут иметь темные и светлые вариации.
Увеличение контраста между цветом фона и элементом на нем может привести к увеличению акцента.
Если приложение не содержит высококонтрастных цветов, применение контрастного цвета на элементах выделит их и придаст важности.
Цвета должны консистентно использоваться по всему приложению. Допустим, если для индикации выбора используется secondary-цвет, все подобные индикации должны выделяться этим цветом.
Очевидно, но черный цвет текста рекомендуется использовать на светлом фоне, а белый цвет — на черном.
Вместо использования оттенков серого для цвета текста или иконок на цветном фоне куда лучше применить прозрачность. Так текст будет смотреться более мягко в сочетании с фоном.
Разный уровень прозрачности текста может показывать определенные состояния. Выделяющийся текст может иметь процент прозрачности около 87%, подсказки и обычный текст — около 60%, но подсказка текста ошибки должна иметь прозрачность 100%. Disabled-текст — около 38%. То же самое можно сказать про иконки.
Следует избегать обильного использования разных цветов в тексте. Такая практика может быть применима для текстов заголовков, кнопок или ссылок, чтобы привлечь внимание пользователя.
Кстати, в MUI есть удобные инструменты для генерации цветовой палитры и генерации темы.
А MUI 3 предлагает реализацию динамической генерации цветов для мобильных устройств.
Темная тема
Невозможно не упомянуть применение темной темы, когда речь заходит о цветах в приложении.
Принципы построения темной темы:
оттенки серого лучше, чем черный цвет.
больше темного, чем акцентных и светлых цветов.
важно следить за контрастом, чтобы все было хорошо видно.
В темной теме высота поверхностей измеряется яркостью цвета. Чем выше яркость, тем выше поверхность. Для этого создается верхний слой (overlay), который накладывается на поверхность. Overlay на основной слой позволяет увеличить контраст между разными поверхностями и выразить высоту.
Соотношение контраста между текстом и поверхностью должно быть примерно 15,8:1, и это подходит под стандарты WCAG's AA (соотношение текста и фона 4,5:1):
Primary- и secondary-цвета следует использовать с пониженной контрастностью, чтобы избегать напряжения глаз.
Еще несколько комментариев:
Brand-цвета можно использовать без снижения контрастности, но с осторожностью.
Яркие цвета лучше всего использовать для небольших поверхностей вроде кнопок, переключателей и так далее. Можно применять и поверхности со светлой темой, чтобы выделить их. Например, для модальных окон или уведомлений.
Чем важнее текст, тем менее прозрачным он должен быть.
Показ ошибок. Оптимистичные и пессимистичные обновления
Как правило, приложение с хорошим UX подразумевает не только красивые цвета, удобное расположение кнопок и так далее. Важную роль играет фидбэк от взаимодействия пользователя с приложением.
Если приложение не дает должного фидбэка или дает его с опозданием, пользователь может посчитать, что приложение «тормозит». Подобное восприятие приложения пользователем называют порогом Доэрти: ответная реакция от системы должна быть быстрой, около 400 миллисекунд, иначе система будет казаться медленной. Например, при долгой загрузке изображения можно сначала загрузить его эскиз и размывать это изображение. Или не обязательно ждать отклика от системы — например, на запрос. Можно сразу отобразить желаемый отклик на действие пользователя, а потом уже показать уведомление, когда запрос завершится.
В книге «Дизайн привычных вещей» Норман пишет, что отсутствие фидбэка приводит к разрыву оценки, то есть пользователь не может сопоставить свои ожидания от взаимодействия с приложением.
Но пока что все это теория, и неплохо бы подкрепить слова примерами.
Представим, что приложение не смогло получить права для пользователя при входе в приложение. Что лучше всего показать: дашборд с пустым экраном или уведомление? Например, покажем дашборд, в котором вся функциональность будет заблокирована.
Система не получила прав пользователя, и это критическая ошибка. На верхнем скриншоте видно, что пользователь не сможет работать с приложением, поэтому нет смысла показывать сломанную функциональность из-за ошибки.
Важно обратить внимание пользователя на эту ошибку и показать диалоговое окно, которое заблокирует дальнейшую работу с приложением и предложит варианты решения проблемы.
Уже лучше, но стоит обратить внимание на текст ошибок и не смущать пользователя терминами наподобие «пермишены» и «запрос».
Подобный фидбэк — крайняя мера, потому что он блокирует дальнейшую работу пользователя. К примеру, было бы странным показывать диалоговое окно об ошибке, если в приложении упал запрос на получение подсказок для поля ввода.
В таком случае лучше показать уведомление, которое пользователь может заметить, а может упустить из виду, продолжив работу.
Не всегда важно ожидать окончания того или иного запроса или процесса в приложении. Для улучшения UX можно сразу показывать результат действия пользователя — это называется оптимистичными обновлениями.
К примеру, такое часто практикуется при отправке сообщений.
Куда менее предпочтительно было бы блокировать экран на время загрузки сообщения и показывать диалоговое окно об ошибке, если отправка сообщения провалилась. Это пессимистичное обновление.
Заключение
Я рассмотрел разные стороны построения UX на основе дизайн-принципов MUI.
Благодаря изучению MUI я получил массу полезной информации о UX, которую можно взять за основу, когда возникнут вопросы о построении интерфейсов.
Вот несколько важных для меня выводов:
Концепция выделения поверхностей по высоте через тени и подложки (в темной теме) выглядит интересно и вполне может быть применима вне рамок MUI.
При построении раскладки вполне можно будет опираться на таблицу раскладок MUI, упомянутую в статье.
Понимание различия цветов (primary, secondary и так далее) позволит грамотно построить цветовую схему и выдержать цветовое оформление приложения.
Правильный показ ошибок обеспечит хорошее впечатление от пользования приложением и ответит на вопрос, какую ошибку показывать в том или ином случае.
А что вы думаете по поводу пользы знания UX для frontend-разработчика? И из каких источников черпаете информацию?