Дизайн кроссплатформенных мобильных приложений

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

На рынке мобильных ОС в 2022 году доминирующее положение занимают две операционные системы – Android и iOS. И это прекрасно, ведь в таком вопросе как платформа наличие двух крупных игроков – это то количество, которое хорошо всем. Apple и Google конкуренция помогает быть в тонусе и не стоять на месте. У пользователя есть выбор и он не так велик, чтобы запутаться.

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

В начале 2019 года, когда речь зашла про обновление мобильного приложения Росбанк Бизнес, команда приняла решение рискнуть и использовать молодой но многообещающий кроссплатформенный фреймворк Flutter от Google. Сейчас, когда прошло уже более 3х лет с этой платформой, можно сказать что это был успешный эксперимент, ведь сейчас приложений на Flutter у нас уже два. Их разработкой занимается всего две команды, и причин для беспокойства у нас пока нет.

Пользователи довольны и не видят разницы в производительности по сравнению с нативными приложениями. 🚀

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

Нет, решили мы, такой подход будет малоэффективен.

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

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

Во главу угла Apple ставит комфорт пользователя и добивается этого довольно жесткими рекомендациями и требованиями к разработчикам.

Google же выбрал другую стратегию. Создавая Material Design они решали задачу привлечения разработчиков, а за счет увеличения разнообразия контент привлекал пользователей к себе. Поэтому Google ориентировался на разработчиков. Гайды по Material Design даже оформлены так что их интересно читать. Тонны анимаций и примеров приложений сделанных сторонними разработчиками. Максимальный простор и минимальные ограничения. «Вот вам инструмент! Творите что хотите! А пользователю достанется много разнообразных приложений.» - говорят нам создатели Material Design.

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

Но давайте перейдем к более осязаемым отличиям.

Единицы изменения

В iOS приложениях используются pt — это единицы координат. Коэффициент масштабирования (ретина-коэффициент) в iOS присваивается каждой новой модели в зависимости от характеристик экрана. Apple может себе такое позволить, ведь их ОС стоит только на их стандартных устройствах. Тут нет такого зоопарка диагоналей и плотности пикселей как на Android.

В Android же все привыкли считать в dp — это более гибкие единицы, и макеты не зависят от плотности пикселей на экране. Одна DP точка равна пикселю на 160 dpi (является средней плотностью экрана). Когда приложение запущено, система обрабатывает изменения в масштабе экрана исходя из плотности используемого экрана и меняет параметры по формуле: 1 пиксель = DP * (DPI/ 160). Экран 240 dpi: 1 dp = 1,5 физических пикселя.

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

Навигация

У iOS существует 3 способа навигации

1. С помощью табов — навигация верхнего уровня

2. C помощью внутренних элементов. Так пользователь проваливается внутрь раздела. Там он может перейти глубже, переключиться на соседний раздел (таб баром), или…

3. Открыть модальное окно — последний способ навигации на iOS. Когда взаимодействие происходит на уровне окна.

Всё это я узнал от Sarah McClanahan.

Теперь давайте посмотрим Android.

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

Но самое интересное для нас то, что средствами Material Design можно реализовать все 3 способа навигации которые есть в iOS. А значит мы просто возьмем в качестве референса к навигации гайд от купертиновцев.

Общие компоненты

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

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

Tab Bar и Bottom Navigation Bar

Эти компоненты очень похожи и решают одни и те же проблемы. С их помощью пользователь перемещается по основным разделам приложения. Их поведение идентично за одним небольшим исключением - в iOS вкладка сохраняет своё состояние после перехода в другой раздел, и когда пользователь вернется назад он увидит её в том состоянии котором он её оставил. На Android состояние сбросится и я думаю, что это не правильно. Поэтом прошу проследить разработчиков чтобы было как на iOS надо, а как на android не надо — не надо!

Sidebar vs Navigation Drawer

В Material Design рекомендуют использовать Navigation Drawer если разделов больше чем 5. В iOS такое можно представить только на устройствах с большой диагональю, так что на смартфонах Sidebars не используют. Sarah McClanahan рекомендует другой тип навигации в таких случаях… Но решение остается за нами.

Navigation Bar vs Top App Bar

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

Segmented Control vs Tabs

Segmented Control можно использовать как вкладки в интерфейсах (во всяком случае я не нашел противоречий в описании этого компонента в HIG), но есть ощущение что его придумали не для того, и ограничения в 5 элементов делает его не рабочим в большинстве случаев. Поэтому я забрал Tabs из Android в нашу кроссплатформенную библиотеку, вместе механиками переходов по свайпу. И не я один так думаю. Постоянно встречаю Tabs в iOS приложениях.

Alert vs Dialog

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

Смотрите какие аргументы у меня есть:

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

Action Sheet vs Bottom Sheet

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

Предлагаю продолжить веселье и забрать из систем все что нам нравится и будет удобно для пользователя. И никто не осудит нас за это :)

В iOS нет компонента Chips - а им так удобно пользоваться. Например при отображении фильтров.

А в Android нет Steper'ов, мы легко можем их туда добавить если нужно.

Но относиться к таким вещам нужно очень аккуратно. Прежде чем расширять свою библиотеку, нужно обязательно спросить пользователя: понятно ли ему поведение компонента; спросить разработчика: есть ли такая библиотека или как сложно будет её реализовать и поддерживать; спросить себя: а не занимаюсь ли я бесполезной работой, мягко говоря?

Кастомизируем аккуратно

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

Изменять поведение компонента можно — но только там где это необходимо.

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

Оставляем то, к чему привыкли пользователи

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

Компонент UIDatePicker iOS и Date Pickers Android, имеют свои плюсы и минусы. Очевидно, что для пользователей платформы они привычны и нет смысла подсовывать им кастомный компонент c непонятным опытом взаимодействия – это раз. Эти компоненты можно вызвать стандартными методами платформы и это упрощает разработку – это два. Все это позволяет приложению выглядеть более нативно – это три.

Добавляем то, чего не хватает

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

Поэтому будьте смелыми и используйте кроссплатформенность во благо!

В статье использовались материалы из официальных гайдов платформ:

Material 3

HIG

Отличная статья от RMR

Чудный обзор систем от канала Droider