Дизайн ui android что это

Стилизация Android-приложений и дизайн-система: как это сделать и подружить одно с другим

В какой-то момент любое крупное приложение разрастается так, что сложно везде поддерживать однотипный дизайн и динамично реагировать на любые изменения и тенденции в дизайне и UX-требованиях.

Поэтому решили внедрить в наше приложение дизайн-систему и добавить поддержку нескольких тем оформления.

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

Компоненты дизайн-системы

Дизайн-система и её компоненты предназначены для унификации дизайна и стилевого единства во всем приложении.

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

Проектирование, отладка и доработка компонентов дизайн-системы

Заказчиками компонентов дизайн-системы являются дизайнеры. С ними на первом этапе согласовываем надобность элемента (оценка переиспользуемости) и его функциональность.

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

Далее дизайнеры отрисовывают компонент в своих средах и отдают на разработку.

При реализации компонента нужно добавить поддержку тем (светлая или темная тема и т.д.) О том, как компонент поддерживает несколько тем, я расскажу ниже.

Лучшие методики

• Создать модуль с компонентами дизайн-системы. Из положительных моментов: отдельный модуль может быть использован в других приложениях, а модульность позволяет быстрее ориентироваться.
• Создать тестовое приложение с компонентами дизайн-системы. Это ускоряет разработку и отладку.

Способы внедрения темы в приложение

Мне известно два способа поддержки стилей в Android:

• Программный (программная перекраска).
• Стандартные механизмы стилей в Android.

Программный способ

Мы перекрашиваем всю иерархию view в runtime. Рекурсивно проходимся по ней и по определенным правилам перехода из одной темы в другую перекрашиваем компоненты. Те из них, которые не должны перекрашиваться, маркируются с помощью android:tag или android:contentDescription . Эти компоненты не учитываются при разборе иерархии экрана.

Перекрашивать можно как перед отображением экрана (например, в onStart() у Activity ), так и при работе с ним.

Недостатки

• Требует дополнительных ресурсов, снижает производительность. Стилизация применяется после инициализации всех компонентов.
• Нужно быть внимательным к правилам перехода из одной темы в другую. Требуется учесть огромное множество правил перекраски, можно что-то забыть. Получается длинная простыня из switch — case (Java) или when (Kotlin). И в довесок требуется учесть элементы, которые не нужно красить при помощи вышеупомянутых тегов.
• Нельзя частично перекрасить в соответствии с темами. В любом правиле есть исключения, и не всегда всё в приложении делается по дизайн-системе. Непонятно, как действовать если требуется частичная перекраска некоторых элементов.

Применение стиля сводится к описанию изменений в конкретных элементах:

Достоинства

Не требует пересоздания Activity (это важно! Нет морганий при смене темы).
Я внедрил этот подход в одном известном всем продукте (см. скриншоты). Работает довольно быстро при простой однотипной вёрстке(в данном случае она была простая).

Стандартный механизм стилей в Android

Стиль — локальная стилизация экрана или view, затрагивающая только отдельный экран или view. Часто такую стилизацию называют «ThemeOverlay», или «легковесная» тема, которая позволяет переопределить атрибуты основной темы).

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

Темой можно считать множество стилизаций, которые можно переключать.

Примеры

В теме могут содержаться как стили конкретных view элементов, так и конкретные цвета.

Здесь объявлен стиль для конкретной view:

Стили поддерживают явное и неявное наследование:

• Явное: Header1 унаследован от BaseTextWidget .
• Неявное: Header1.Light унаследован от Header1 .

Если к текстовому элементу мы применим стиль Header1 , то подтянется только Header1 . А атрибуты Header1.Light или Header1.Dark не применятся.

Если к текстовому элементу мы применим стиль Header1.Light / Dark , то подтянутся стили Header1.Light / Dark и Header1 (достоинство неявного наследования)

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

Стили каждого компонента дизайн-системы мы решили размещать в файлах attrs_component_name.xml (см. attrs_header1 , attrs_button и т.д.)

Стилизация компонентов дизайн системы. Архитектура компонентов. Поддержка нескольких тем

Стандартный конструктор view

Стандартный конструктор view предоставляет обширные средства для настройки элемента. Внешний вид элементов можно изменить через .xml-атрибуты или через определение стиля по умолчанию в стандартном конcтрукторе view.

Рассмотрим стандартный конструктор view на примере H1Component (задаёт крупный текст в шапке экранов):

Здесь attrs — атрибуты из определения .xml (в том числе кастомные атрибуты view). Они парсятся и применяются стандартным образом (см. ниже на примере FabComponent ).

defStyleAttr — стиль view по умолчанию.

context — контекст view, при помощи которого она создана.

ВАЖНО: чтобы view успешно переключала тему, необходимо чтобы она была создана при помощи контекста, унаследованного от android.view.ContextThemeWrapper (то есть контекст activity подходит, а applicationContext — не подходит (применится тема, которая подтянется из стиля, указанного в Manifest экрана).

ВАЖНО: при такой реализации главный приоритет у атрибутов, объявленных в .xml. У стилей, описанных в теме, приоритет ниже.

Интеграция стиля в компоненты дизайн системы и его связь с темой

Для поддержки темы компонентами дизайн-системы мы определяем в компонентах defStyleAttr и переключаем его в соответствии с темой, в которой он определен.

Реализация темы в приложении

Создаем две темы:

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

Тут определены стили каждой темы для этого элемента:

Применяем тему через стандартный механизм Android.

При создании Activity указываем нужную тему. Тогда MyBestText подтянет нужный стиль и окрасит свой текст в белый или черный в зависимости от темы (см. выше описание темы MyBestText ).

Цвета из темы мы будем разрешать прямо из .xml и подтягивать из темы.

ВАЖНО: начиная с Android 5.0 допускается отовсюду динамически разрешать android:background=»?attr/primary_background» (селекторы, shape, vector drawables и т.д.) В Android 4.4 есть ограничение на селекторы, при попытке динамически разрешить итоговый цвет из селекторов система упадёт.

При всех достоинствах такой реализации компоненты дизайн-системы не могут в preview Android Studio полноценно работать со стилизованными темами (к элементам не будут применяться стили).

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

Тестирование компонентов дизайн-системы

Для тестирования и анализа степени покрытия приложения дизайнеры предложили разработать отладочную панель с настройками стилей компонентов, цветов и т.д.

Темы в Android являются неизменяемыми, но их всегда можно перезаписать полностью или частично через Activity.setTheme ( @StyleRes final int resid ). Так можно в нужный момент получить любую комбинацию стилей и собрать свою собственную тему. Но все стили должны быть объявлены в .xml заранее.

Программно изменять атрибут темы без отсылок к объявленным стилям, к сожалению, нельзя. По крайней мере, я не нашёл способа.

Если знаете, как подсунуть свой цвет в атрибут темы (не объявленный в ресурсах как style ), то напишите мне. Тогда мы сможем прямо из коробки манипулировать цветами с бэка на уровне стилизации всего приложения!

Делаем рабочее preview компонентов дизайн-системы в Android Studio

Темы экранов приложения должны наследоваться от темы дизайн-системы.

Preview компонентов в .xml

При некорректно установленной теме экрана компоненты дизайн-системы тоже не будут отображаться корректно (не применятся стили и цвета):

При установке темы, унаследованной от темы дизайн-системы, мы получим вот что:

Видно, как разрешились все атрибуты темы и правильно подтянулись стили компонента.

Проверка поведения компонентов в другой теме в Preview без пересборки приложения

Чтобы проверить отображение в другой теме достаточно переключить тему в Preview light/dark.

Если конкретные реализации темы завязаны на ресурсы values/values-night, то можно переключать из preview в dark mode. И всё будет работать из коробки без выставления setTheme в Activity .

Переключение тем в приложении

Переключение тем в приложении может быть завязано на системное переключение dark-mode. В таком случае темы должны быть определены в директориях values и values-night.

Источник

iOS vs. Android: полное руководство по дизайну приложений

Если вы разрабатываете одновременно версии приложения для iOS и Android (Material Design), то это руководство станет вашим новым лучшим другом 😎.

Мы рассмотрим наиболее важные различия между iOS и Android для UX/UI-дизайнеров. Если вы уже создали приложение для одной платформы, здесь собрана большая часть того, что нужно знать, чтобы «перевести» его на другую платформу. Но! Это рекомендации, и практически всё, что я скажу, уже где-то опровергнуто, даже самими Apple/Google. Речь пойдет о «переводе» «iOS- мышления» на «Android-мышление» и наоборот.

Вот список тем, о которых мы поговорим. Пропустите его или дотошно изучите. Решение за вами.

1. Обзор основных отличий.
2. Навигация.
3. Элементы управления.
4. Типографика.
5. Другие стандарты платформ.

UI-дизайн для iOS vs. Android: основные различия

Наиболее важные различия, которые UX/UI-дизайнеры должны учитывать при «переводе» приложения с iOS на Android или наоборот:

Прежде чем углубиться в эту тему, давайте ответим на один важный вопрос, это повлияет на всё, о чем пойдет речь далее…

Должен ли я делать приложения для iOS и Android разными?

Если кратко, то — нет.

Apple и Google — очень умные компании с бессчетным количеством пользователей. Они будут совершать UX-ошибки, как и все остальные компании. Но они не совершат вопиющих ошибок, определяя стандартный язык дизайна своих систем. Поэтому, хотя ниже я и представляю два способа реализации (способ iOS и способ Android), ни один из них не является неправильным. Если пользователи могут уверенно перемещаться по вашему приложению и работать с ним, никто не запрещает вам использовать вкладки в iOS или модальные окна в Android.

Эта статья написана в духе обучения «iOS-мышлению» или «Android-мышлению». И если ваша цель — создать такое приложение для обеих платформ, которое будет нативным для каждой из них, то это руководство вам очень поможет.

А теперь давайте углубимся в тему.

Сравнение навигации в iOS и Android

Навигация в верхней части экрана

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

В iOS (опционально) действие вверху слева на странице почти всегда является действием «назад» — последовательно к предыдущему экрану (из «Шага 2» пользователь возвращается к «Шагу 1») или иерархически к родительскому экрану (из «Входящих» пользователь возвращается в «Почтовые ящики»). Кроме того, таким образом могут быть связаны не связанные изначально страницы. Заголовок страницы практически всегда присутствует, и он изначально большого размера, но уменьшается вместе с верхней панелью во время прокрутки (до прокрутки большой заголовок выравнивается по левому краю, во время прокрутки уменьшенный заголовок выравнивается по центру. — Прим. пер.). Единичное действие вверху справа на странице может отображаться как текстовая ссылка, а несколько действий — как несколько значков действия.

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

Основные «пункты назначения»

Основные «пункты назначения» в приложении реализуются по-разному.

В приложениях для iOS они представлены в виде вкладок/табов в нижней части экрана:

• от 2 до 5 вкладок;
• названия набраны 10-м кеглем;
• вкладки представляют собой основные места назначения.

Многие популярные сторонние приложения для iOS также соответствуют нескольким дополнительным правилам:

1. Любая вкладка, представляющая основное действие приложения (например, добавление новой фотографии в приложении для работы с фотографиями), располагается по центру.

2. Любая вкладка, относящаяся к профилю или настройкам, появляется последней.

3. Поиск находится на втором месте.

С другой стороны, в стандартных приложениях для iOS:

1. Не поощряется размещение действий на вкладках.
2. Вкладки не содержат разделы, относящиеся к профилю или настройкам.
3. Поиск идет последним.

Самое большое отличие приложений для Android состоит в том, что одни и те же основные «пункты назначения» в большей степени распределены по всему интерфейсу — часто между: (a) кнопкой-гамбургером, (b) панелью поиска, (с) вкладками или (d) плавающей кнопкой действия. Мы рассмотрим все эти 4 случая в следующих разделах. Да, и обратите внимание: Android совсем недавно начал использовать навигацию снизу аналогично тому, как это реализовано в приложениях для iOS, — так что в этом у приложений для Android и iOS может не быть никаких существенных различий.

Источники: iOS панель вкладок, Material Design принципы навигации (здесь больше теории).

Вторичная навигация

В iOS навигация, которая не поместилась в меню в нижней части экрана, может размещаться на универсальной вкладке «Еще» (More) или же в верхнем левом или в верхнем правом углу экрана.

В Android вторичная навигация отображается в виде списка в боковом меню, доступном при нажатии на кнопку-гамбургер.

Примечание: хотя Apple не поощряет использование кнопки-гамбургера (или ее использование в приложениях для iOS по умолчанию), во многих сторонних приложениях для iOS она есть, и это просто ваш выбор — использовать ее или нет. Лучшей практикой считается не скрывать важное, потому что очевидное всегда побеждает.

Источник: Material Design Navigation drawer.

Возврат к предыдущему экрану

В iOS можно вернуться к предыдущему экрану четырьмя способами, в зависимости от контекста.

Что такое модальные и полноэкранные окна? Сейчас расскажу.

Модальное окно — это задача с одним экраном, которая появляется по свайпу вверх и располагается поверх предыдущего экрана, который лишь немного виден на заднем плане. Чтобы закрыть модальное окно, нужно свайпнуть вниз или нажать кнопку «Назад» наверху.

Полноэкранное окно — это медиафайл, например фотография или видео, занимающий весь экран. И в iOS, и в Android его можно закрыть свайпом вниз.

В Android возвратиться к предыдущему экрану намного проще: в версии 10 и более новых версиях достаточно просто свайпнуть от любой стороны экрана к его центру. В версии 9 используйте кнопку «Назад» в нижнем левом углу экрана.

iOS vs. Android: дизайн элементов управления

Главные кнопки призыва к действию

В iOS главная кнопка на экране обычно расположена в верхнем правом углу.

В Android главная кнопка на экране в большинстве случаев расположена в нижнем правом углу в виде FAB (англ. floating action button — плавающая кнопка действия. — Прим. пер.).

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

Иногда в iOS главные кнопки на экране могут располагаться на нижней панели инструментов. Apple утверждает, что она очень сильно отличается от панели вкладок. В Android можно встретить такие кнопки в верхней части экрана.

Поиск

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

Одно из различий между реализацией поиска в iOS и поиском в Android:

• чтобы отменить поиск, нужно нажать Cancel в iOS или ← в Android;
• чтобы очистить поле ввода, нужно нажать на круглую пиктограмму крестика в iOS или на пиктограмму крестика в Android.

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

Если поиск не является главной функцией и им нечасто пользуются, то получить доступ к нему можно другими способами.

В iOS поиск обычно отображается среди основных вкладок или как одно из действий в верхней навигационной панели.

В Android вы также можете увидеть поиск на верхней панели контекстных действий.

Источники: iOS search bars, Material Design search pattern.

Меню действий

В iOS меню действий можно вызвать нажатием на любую кнопку или попыткой выполнить любое действие. Меню появляются снизу вверх, на них легко нажимать пальцами.

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

У обеих платформ есть стандарты для всплывающих меню.

Если в iOS 13 вы нажимаете на элемент или удерживаете его, то в «контекстном меню» показываются подходящие действия. Когда отображается «контекстное меню», фон размывается.

В Android многие меню появляются прямо на элементе. В новых версиях Android меню закрывает пиктограмму «кебаб-меню».

Элементы управления выбором

На мобильном устройстве стоит отличать выбор из нескольких вариантов от выбора из большого количества вариантов.

В iOS для реализации выбора из нескольких вариантов используйте элемент управления picker («подборщик» — Прим. пер.). Его можно закрепить внизу на экране (как показано выше) или встроить в контент (см. «Выбор даты»).

Для выбора из нескольких вариантов в Android обычно используется раскрывающееся меню (появляется рядом с выбором) или модальное окно со списком вариантов (появляется в центре экрана, фон затемняется).

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

Выбор даты

В iOS выбор даты похож на любой другой элемент выбора (picker control), но с отдельными колонками для месяца, даты и (опционально) года.

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

Источники: iOS picker, Android date picker (обратите внимание на различия в спецификации Material Design).

Вкладки

В iOS отсутствуют вкладки в привычном понимании, но есть сегментированные кнопки, которые
позволяют реализовать функциональность вкладок.

На Android вкладки выполнены в привычном виде.

Источники: iOS segmented controls, Material Design tabs.

Отмена действия

В iOS уведомления появляются в центре экрана, но они также могут всплывать в нижней части экрана (на языке iOS это action panels). Деструктивные действия (например, удаление чего-либо) выделены красным цветом.

На Android некоторые уведомления появляются в центре экрана. Однако для уведомлений, которые не требуют действий от пользователя и исчезают через несколько секунд, можно использовать «снек-бары» (snackbars). «Снек-бары» позволяют сообщить пользователю, что его действие было успешным, а также на них можно предложить выполнить одно действие или выбрать одно из двух действий. Это делает их идеальным решением для функции «Отменить». Я бы предпочел давать пользователям возможность отменить ошибочное действие, чем спрашивать их дважды перед каждым важным действием.

Источник: iOS Undo, Material Design snackbars.

IOS vs. Android: типографика

Шрифт по умолчанию

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

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

Системный шрифт Android называется Roboto. Он очень похож на SF, но есть пара отличий — буквы выше и расстояние между ними немного больше. Этот шрифт можно скачать здесь.

Также в Android часто используется шрифт Product Sans от Google, который недоступен для использования сторонними разработчиками.

Источник