Привет, Хабр! Меня зовут Иван Некипелов, я работаю в Сбере в подразделении «Цифровой Корпоративный Банк» и занимаюсь развитием мобильных приложений СберБизнеса. В статье расскажу о том, что стало для нас особенно актуальным при выводе сервисов в мобильные приложения в условиях закрытых маркетплейсов и нехватки рук мобильных разработчиков.

Так, на основе уже известной технологии Server-driven UI мы смогли создать собственное решение, которое позволило сэкономить более 1 000 человеко-часов при выводе продуктов и сервисов. Давайте разберёмся, как это работает.

Ищем новый путь для себя — почему и зачем?

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

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

Тем не менее у этих решений есть определённые недостатки, с которыми нужно считаться.

Проблемы WebView:

• Вёрстка адаптива. Её очень сложно регламентировать: часто те или иные компоненты просто «плывут», и это всё носит характер проблемы. При этом не всегда компоненты в адаптиве соответствуют нативным в «мобилке», что может привести к UI/UX-шоку клиента.

• Безопасность WebView. Каждое выведение продукта этим способом — целый квест команды по работе с сотрудниками кибербезопасности. При этом JavaScript в WebView должен быть выключен, так как является уязвимостью для мобильных приложений. А это напрямую влияет на функциональность пользовательских интерфейсов. ч

Нативная разработка:

• Банальная нехватка рук. Если у вас есть потребность в найме специалиста, то, по нашему опыту, это может занять не менее двух месяцев поиска опытного сотрудника с момента возникновения такой потребности. Также нужно учитывать период адаптации, ведь «пилить» формы он начнёт не сразу.

• Обновление клиентов на новые версии. Мы удалены из маркетплейсов, поэтому лишены платформенных механизмов автообновления версий, что значительно влияет на скорость перетекания клиентов на актуальные. Даже если использовать in-app update, конверсия в обновление — не более 15 %.

Реализация пути и наши возможности

Мы начали двигаться в новом направлении — создании фреймворка, способного выводить продукты в «мобилке», опираясь на внутренние ресурсы и возможности:

• Кроссплатформенная команда. У нас сосредоточена экспертиза iOS/Android, мы можем достаточно точно и быстро синхронизировать любое техническое и продуктовое решение.

• Развитая дизайн-система «Триплекс», которая включает в себя весь набор компонентов, необходимых для вёрстки более 80 % существующих экранных форм в «мобилке».

Что такое «Триплекс»

Это совокупность правил того, как строить UX-сценарии в СберБизнесе. В первую очередь подключение продукта, его промоушн в мобильном приложении, использование продуктов и сервисов: работа со списками, работа с детальными формами, заполнение заявок и многое другое. Проще говоря, «как сделать интуитивно понятно пользователю». Ядро дизайн-системы составляют компоненты, с помощью которых можно создать почти любой клиентский сценарий.

В качестве примера компонента можно привести текстовое поле. Какими могут быть текстовые поля? Они могут быть редактируемыми, когда пользователь вводит данные, могут быть с «масками» для упрощения ввода (номер телефона, номер паспорта, дата и другие), могут триггерить клиента о том, что он допустил ошибку (подсвечивать красным и сообщать, в чём именно ошибка), или нередактируемыми, когда клиент просто видит отображение какого-нибудь поля заявки.

Ещё один пример — кнопки. Они могут выполнять роль CTA (Call to action) с целевым действием клиента на форме («Купить») и всегда быть «прибиты» к нижней части экрана. То есть как бы клиент ни взаимодействовал с контентом, CTA всегда будет на виду. Также кнопки могут быть расположены внутри основного контента, чтобы увести клиента в альтернативные сценарии. При этом у кнопок также есть состояния «кликабельна» или «некликабельна», то есть основная или альтернативная.

Таких концептуальных компонентов у нас более 20. Всё это регламентирует «Триплекс».

Наши принципы и критерии для приложений

1. Один запрос — одна страница. Полноценный экран описывается в ответе на запрос от сервера.

2. «Атом», или «кирпичик» экрана, — компонент дизайн-системы. Экраны состоят только из платформенных компонентов «Триплекс» и только в регламентированных местах.

3. Хендлеры для взаимодействия с пользователем. Весь интерактив с пользователем строится на основе универсального списка хендлеров «событие-действие». Подробнее о них расскажу ниже.

4. Сложные зависимости компонентов обрабатывает бэкенд.

Наше решение: подробности и принцип работы

Перейдём к тому, что из себя представляет наше решение. Можно заметить, что зачастую мобильные приложения имеют чёткую структуру экрана, которую можно описать тремя блоками: Navigation, Fieldset, ActionField.

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

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

3. ActionField — Call to action или просто нижний блок компонентов, закреплённый на нижней части экрана.

Всё это хорошо укладывается в достаточно стройную модель JSON.

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

Таким образом, этот «конструктор» позволяет нам создавать большое количество востребованных форм: лендинг, формы для заполнения, статусные экраны, главные экраны и экраны с разделами.

Теперь немного о компонентах

JSON компонента должен содержать в себе все необходимые поля для его описания, то есть в какой-то степени ViewModel. На примере простого компонента здесь представлена модель. Справа — состояние компонента в дизайн-системе, слева — его описание в JSON. Самый последний объект является фишкой нашего решения, потому что в целом описать интерфейс по JSON не так уж и сложно. Куда сложнее в этом JSON передать логику. Объект events отвечает именно за неё. Давайте перейдём к событийной части.

Хендлеры

В описании логики на форме мы исходим из событийной модели. Произошло событие — нужно действие. Какие события может генерить пользователь в мобильном приложении на самом низком уровне? Для нас это TAP — событие тапа или клика на компонент и Scroll, когда клиент листает. Это самые базовые события, которые необходимы приблизительно в 90 % случаев. Однако такая модель хорошо масштабируется при необходимости добавления более сложных механик: лонгтап, дабблтап, свайп и т. д.

Ответом на событие становится действие. Вот что мы умеем. В примере при тапе на какой-то компонент покажется компонент с идентификатором pullerControlId.

Анализ проделанного пути: ошибки и результаты

Ошибки

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

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

2. Второе важное изменение коснулось событийной обработки. Вначале мы исходили из модели «поставщик-подписчик». То есть условная мини-Kafka в «мобилке». Событие генерировалось компонентом, а другой компонент должен был уметь на него подписываться. Это выражалось в необходимости прописывать механику взаимодействия у двух компонентов сразу. Усложнялась интерпретация конечного JSON, и в конечном счёте мы пришли к одному блоку events.

Результаты

Используя наше решение, которое внутри мы назвали Back 2 Front, мы уже вывели в ПРОМ четыре продукта без использования ресурса мобильных разработчиков. Опираясь на опыт вывода первых четырёх продуктов, мы прогнозируем, что среднее время вывода продукта с нуля в ПРОМ составит около двух месяцев, а дальнейшие его апдейты займут около недели.

По итогу вывода первых продуктов мы получили 30k MAU-продуктов на SDUI.

В конце статьи хотелось бы выделить несколько важных моментов. Один из них — то, что клиентские сценарии ограничены развитием решения. Мы понимаем, что нам есть куда расти и как развивать Back 2 Front для наращивания клиентских путей в будущих продуктах и сервисах. В данный момент нам трудно реализовывать сложные зависимости UI-компонентов. Пока что мы не приступали к реализации анимации: это направление кажется достаточно сложным и трудозатратным.

И ещё — решение требует обеспечения обратной совместимости мобильного приложения с бэкендом.

Теперь, кажется, всё. Если у вас есть вопросы или предложения к статье, пишите в комментариях, обсудим!