Привет, Хабр! Меня зовут Иван Некипелов, я работаю в Сбере в подразделении «Цифровой Корпоративный Банк» и занимаюсь развитием мобильных приложений СберБизнеса. В статье расскажу о том, что стало для нас особенно актуальным при выводе сервисов в мобильные приложения в условиях закрытых маркетплейсов и нехватки рук мобильных разработчиков.
Так, на основе уже известной технологии 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. Всё это регламентирует «Триплекс».
Наши принципы и критерии для приложений
Один запрос — одна страница. Полноценный экран описывается в ответе на запрос от сервера.
«Атом», или «кирпичик» экрана, — компонент дизайн-системы. Экраны состоят только из платформенных компонентов «Триплекс» и только в регламентированных местах.
Хендлеры для взаимодействия с пользователем. Весь интерактив с пользователем строится на основе универсального списка хендлеров «событие-действие». Подробнее о них расскажу ниже.
Сложные зависимости компонентов обрабатывает бэкенд.
Наше решение: подробности и принцип работы
Перейдём к тому, что из себя представляет наше решение. Можно заметить, что зачастую мобильные приложения имеют чёткую структуру экрана, которую можно описать тремя блоками: Navigation, Fieldset, ActionField.
Navigation — верхняя часть экрана, которая может включать в себя кнопки быстрого действия, кнопку перехода назад по StackView, компоненты для фильтрации или переключения разделов, заголовок и описание.
Fieldset — основной контент экранной формы, то, с чем пользователь взаимодействует напрямую большую часть времени нахождения на форме.
ActionField — Call to action или просто нижний блок компонентов, закреплённый на нижней части экрана.
Всё это хорошо укладывается в достаточно стройную модель JSON.
Проще говоря, задача сводится к тому, чтобы в соответствующие блоки положить компоненты дизайн-системы по макетам от дизайнера.
Таким образом, этот «конструктор» позволяет нам создавать большое количество востребованных форм: лендинг, формы для заполнения, статусные экраны, главные экраны и экраны с разделами.
Теперь немного о компонентах
JSON компонента должен содержать в себе все необходимые поля для его описания, то есть в какой-то степени ViewModel. На примере простого компонента здесь представлена модель. Справа — состояние компонента в дизайн-системе, слева — его описание в JSON. Самый последний объект является фишкой нашего решения, потому что в целом описать интерфейс по JSON не так уж и сложно. Куда сложнее в этом JSON передать логику. Объект events отвечает именно за неё. Давайте перейдём к событийной части.
Хендлеры
В описании логики на форме мы исходим из событийной модели. Произошло событие — нужно действие. Какие события может генерить пользователь в мобильном приложении на самом низком уровне? Для нас это TAP — событие тапа или клика на компонент и Scroll, когда клиент листает. Это самые базовые события, которые необходимы приблизительно в 90 % случаев. Однако такая модель хорошо масштабируется при необходимости добавления более сложных механик: лонгтап, дабблтап, свайп и т. д.
Ответом на событие становится действие. Вот что мы умеем. В примере при тапе на какой-то компонент покажется компонент с идентификатором pullerControlId.
Анализ проделанного пути: ошибки и результаты
Ошибки
Конечно, такое решение не родилось сразу же. На протяжении года у нас были минорные и мажорные изменения концептуального вида JSON. Расскажу о двух наиболее значимых.
Изначально мы передавали в JSON сразу несколько экранов, что значительно увеличивало его размер, а самое главное, сильно усложняло его разработку. Найти какую-нибудь ошибку было очень сложно. В конечном счёте решили отказаться от идеи передачи нескольких экранов в одном запросе просто потому, что у команд не было такой потребности.
Второе важное изменение коснулось событийной обработки. Вначале мы исходили из модели «поставщик-подписчик». То есть условная мини-Kafka в «мобилке». Событие генерировалось компонентом, а другой компонент должен был уметь на него подписываться. Это выражалось в необходимости прописывать механику взаимодействия у двух компонентов сразу. Усложнялась интерпретация конечного JSON, и в конечном счёте мы пришли к одному блоку events.
Результаты
Используя наше решение, которое внутри мы назвали Back 2 Front, мы уже вывели в ПРОМ четыре продукта без использования ресурса мобильных разработчиков. Опираясь на опыт вывода первых четырёх продуктов, мы прогнозируем, что среднее время вывода продукта с нуля в ПРОМ составит около двух месяцев, а дальнейшие его апдейты займут около недели.
По итогу вывода первых продуктов мы получили 30k MAU-продуктов на SDUI.
В конце статьи хотелось бы выделить несколько важных моментов. Один из них — то, что клиентские сценарии ограничены развитием решения. Мы понимаем, что нам есть куда расти и как развивать Back 2 Front для наращивания клиентских путей в будущих продуктах и сервисах. В данный момент нам трудно реализовывать сложные зависимости UI-компонентов. Пока что мы не приступали к реализации анимации: это направление кажется достаточно сложным и трудозатратным.
И ещё — решение требует обеспечения обратной совместимости мобильного приложения с бэкендом.
Теперь, кажется, всё. Если у вас есть вопросы или предложения к статье, пишите в комментариях, обсудим!
