itmo_conspects

Лекция 5. Дизайн-система и интерфейс, управляемый бэкендом

Дизайн-система

Дизайн-система - это система, которая помогает создать единый и последовательный дизайн для всех устройств

Дизайн-система представляет из себя набор правил и компонентов, таких как цветовая схема, типография, готовые макеты из элементов и их компоновка

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

Разберем, для чего нужны эти компоненты:

• Цветовая схема - набор цветов, использующихся в дизайне продукта. Этот набор включает основные цвета, второстепенные цвета, цвет фона и так далее

• Типография - это набор шрифтов и правил их использования вкупе с разными размерами и стилями

• Иконография - набор иконок и визуальных элементов, которые используются в дизайне
• Макет - способ организации контента и элементов, которые создают понятный дизайн
• Интерактивные элементы интерфейса - элементы, реагирующие на действия пользователей, такие как кнопки, поля ввода и так далее
• Дизайн-токены - примитивные значения, из которых собирается интерфейс: цвета, размеры текста, радиусы скругления, отступы, тени и так далее
• Паттерны - готовые решения для типовых пользовательских сценариев, например авторизация, оформление заказа, поиск, работа с ошибками
• Правила доступности - требования к контрастности, размеру кликабельных зон, поддержке экранных дикторов и понятной навигации

Дизайн-система должна быть:

• Унифицированной и последовательной - дизайн должен быть единым для всех компонентов продукта
• Масштабируемой - дизайн должен быть расширяемым под разные требования и технологии
• Адаптируемым - дизайн должен быть легко адаптирован под разные контексты и устройства

Дизайн-система позволяет:

• ускорить разработку новых экранов
• уменьшать число визуальных и логических расхождений между экранами
• намного упрощать поддержку за счет переиспользования компонентов

В Android-разработке дизайн-система часто выражается в виде темы приложения, набора стилей, токенов и библиотеки компонентов

Для создания дизайн-системы можно воспользоваться такими инструментами: Sketch, Figma, Adobe XD, Lunacy и так далее

Интерфейс, управляемый бэкендом

Сейчас мобильные приложения можно разделить на два типа:

• Локальные - данные обрабатываются только на устройстве и не покидают его (например, будильник или калькулятор)

• Клиент-серверные, в которых устройство общается с сервером или другими сервисами

  В таком подходе клиенты можно разделить на два типа:

  • Толстый клиент - он содержит всю бизнес-логику, обработку данных и работу с API. Сервер только хранит некоторые данные

  • Тонкий клиент - такой клиент имеет только логику интерфейса, все остальное делает сервер

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

Поэтому появляется архитектура интерфейса, управляемого бэкендом (Backend Driven UI или Server Driven UI), - при таком подходе интерфейс приложения строится на основе данных, полученных с сервера

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

Обычно это выглядит так:

1. Клиент отправляет запрос на сервер
2. Сервер возвращает схему экрана, например, в формате JSON
3. Клиент разбирает ответ и сопоставляет каждый тип блока с локальным компонентом интерфейса
4. На экране строится итоговый интерфейс

Например, сервер может прислать описание такого вида:

{
  "screen": "profile",
  "components": [
    { "type": "text", "value": "Профиль" },
    { "type": "image", "url": "https://example.com/avatar.png" },
    { "type": "button", "title": "Редактировать" }
  ]
}

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

Преимущества интерфейса, управляемого бэкендом:

• Можно менять интерфейс и логику сценариев без обязательного выпуска новой версии приложения
• Удобно проводить эксперименты и A/B-тесты
• Проще поддерживать единые сценарии в Android-, iOS- и Web-приложениях
• Бизнес-логика и конфигурация экранов централизуются на сервере
• Быстрее исправляются ошибки в описании экранов, если проблема находится в серверной конфигурации

Однако существуют недостатки:

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

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

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

This site is open source. Improve this page.