Чем отличается дизайн для SDUI (он же BDUI)?

Прежде чем SDUI снова ворвётся в мою работу и в контент на канале, хочется разобраться — чем вообще отличается процесс и технология дизайна в таком подходе. Для начала важно сделать шаг назад и понять: на что именно влияет технология, и какие вообще бывают варианты реализации SDUI. Ключевые области, которых касается внедрение безрелизности, — это бизнес-логика, вёрстка и автоматизация. 🌟Начнём с бизнес-логики. Бизнес-логика в данном случае — это то, что управляет реакцией приложения на действия пользователя. "Если пользователь нажимает на кнопку — показывается окно выбора..." — вот подобные штуки и есть бизнес-логика. Она может быть реализована по-разному. Чаще всего встречаются три варианта (которые могут комбинироваться): —Тонкий клиент. Вся бизнес-логика выполняется на сервере, а клиент получает только результат — изменения в контенте и вёрстке. — Толстый клиент с управлением через actions. Здесь логика описывается в виде процедур или функций, часто — довольно атомарных и гибко настраиваемых. Контракт (обычно это JSON с вёрсткой) уже содержит вызовы этих функций. Например, в случае перехода достаточно указать в контракте саму функцию и её параметры (тип перехода, линк и т. д.). — Толстый клиент с загружаемыми скриптами. В этом варианте бизнес-логика исполняется на клиенте, но поставляется с сервера в виде загружаемых скриптов — чаще всего на JS. Как это влияет на работу дизайнера? Во-первых — это влияет на мышление. Реализация через actions требует другого подхода к проектированию: всё начинает дробиться на действия, функции, состояния. Анимации переходов становятся частью логики, что подталкивает к систематизации, стандартизации и визуальному единообразию. Такой способ мышления полезен не только в контексте SDUI — он помогает пересматривать сущности, улучшать сценарии и думать о интерфейсе как о системе. Во-вторых — это вопрос планирования. В модели тонкого клиента отрисовка результата бизнес-логики происходит на фронте, на основе правил и механизмов дизайн-системы или дизайн-платформы. Обновление этих правил требует обновления самого клиента — то есть выкладки новой версии в стор. Поэтому так важно сразу продумать архитектуру, заложить гибкость в ключевые решения и сделать инструмент, который покрывает основные сценарии — без постоянного обновления сборки. - - #sdui #bdui #бизнеслогика 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru