[DRAFT] APP: UI/UX: Пользовательские интерфейсы и сценарии FoodTracker

Published

June 11, 2026

WarningОграничение публичной документации

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

  • Полная спецификация метода: Будет доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).

1 Экран «Пополнение запасов» (Ввод продуктов)

Экран отвечает за первичную регистрацию продуктов питания в системе. Интерфейс поддерживает три альтернативных режима ввода (User Journeys) для минимизации рутинных действий пользователя.

1.1 Визуальные элементы и элементы управления (UI Elements)

  • Матрица ручного ввода (Таблица): интерактивная сетка со столбцами: «Наименование» (предикативный ввод с автоподсказками), «Количество (шт)», «Чистый вес (кг/г)» и «Цена закупки (руб)».
  • Кнопка «Сканировать чек»: активирует системную камеру смартфона для захвата изображения.
  • Кнопка «Голосовой ввод»: удерживаемая кнопка записи аудиопотока.
  • Главная кнопка «Оприходовать на баланс»: инициализирует отправку DTO-пакета на бэкенд.

1.2 Продуктовые сценарии поведения

  1. Сценарий «Ручной пакетный ввод» (Роль: User): Пользователь последовательно заполняет строки таблицы. Валидация на фронтенде блокирует кнопку отправки, если вес или цена равны нулю. При нажатии «Оприходовать» вызывается метод POST /api/v1/supply.
  2. Сценарий «Оцифровка чека»: Пользователь фотографирует чек. Интерфейс блокируется экраном загрузки (Shimmer Effect), пока ИИ-движок OCR распознает позиции. Результат возвращается в виде автоматически заполненной таблицы ручного ввода, где пользователь проверяет корректность весов и цен перед финальным сохранением.
  3. Поведение симулятора (Роль: Bot_Simulator): Стохастический симулятор генерирует синтетические пакеты данных, имитируя закупку раз в 3 дня. Симулятор умышленно игнорирует ИИ-методы и шлет готовые валидные DTO-массивы напрямую в API.
Figure 1: Интерфейс экрана Кухня

2 Экран «Цифровой холодильник» (Текущие остатки)

Центральный экран приложения, отображающий текущий баланс еды в доме. Это главная зона внимания пользователя и ключевой объект исследования для Process Mining.

2.1 Визуальные элементы и элементы управления (UI Elements)

  • Плиточный виджет запасов (Grid View): карточки продуктов, сгруппированные по категориям (Мясо, Молочные продукты, Овощи). Каждая карточка визуально отображает шкалу заполненности (прогресс-бар) на основе параметра weight (Остаточный вес).
  • Контекстные кнопки быстрого действия: на каждой карточке доступны быстрые свайп-кнопки «Я съел часть» (Потребление) и «Испортилось» (Выбросить).

2.2 Продуктовые сценарии и сбор поведенческих паттернов

  1. Паттерн «Пассивный просмотр»: Ситуация, когда пользователь открывает экран остатков (вызывается метод GET /api/v1/fridge/inventory), скроллит ленту, но не нажимает ни одну из кнопок действия и закрывает приложение.Продуктовое требование: Если зафиксировано более 4 таких пустых сессий за сутки, прямо внутри плиточного виджета генерируется динамический баннер: «У вас заменяется срок хранения Куриного филе. Предлагаем приготовить блюдо…».
  2. Частичное списание объемов: При нажатии «Я съел часть», интерфейс открывает колесо выбора веса (Picker). Пользователь указывает, например, 0.2 кг. Фронтенд отправляет дельту веса. На карточке сыра шкала заполненности уменьшается, но сам Case ID продукта остается активным.
Figure 2: Интерфейс экрана Кухня

3 Экран «Кухня» (Трансформация продуктов)

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

3.1 Визуальные элементы и элементы управления (UI Elements)

  • Селектор ингредиентов: список продуктов «В наличии», где пользователь чекбоксами отмечает, что именно он берет для готовки.
  • Поле «Название шедевра»: текстовое поле для ручного ввода имени готового блюда (например, «Бабушкин суп»).
  • Кнопка «Начать готовку»: запускает процесс трансформации.

3.2 Продуктовые сценарии и логические ограничения

  1. Сценарий «Кулинарная конверсия»: Пользователь отмечает галочками Мясо (0.5 кг) и Томаты (0.3 кг), пишет в поле название «Мясное рагу» и нажимает кнопку. Фронтенд отправляет бэкенду Go Core ID ингредиентов и строку с названием.
  2. Защита от некорректного контента (Цензура): Если пользователь вводит в поле названия нецензурную лексику или мат, интерфейс перехватывает ошибку от бэкенда (HTTP 400) и отображает поверх экрана модальное уведомление: «Пожалуйста, выберите более аппетитное название для вашего блюда». Вес ингредиентов при этом не списывается.
  3. Автоматическое обновление инвентаря: При успешном ответе сервера (HTTP 201) ингредиенты мгновенно исчезают с экрана «Цифровой холодильник», а вместо них появляется новая карточка Мясное рагу с итоговым весом и новым уникальным Case ID для Process Mining.
Figure 3: Интерфейс экрана Кухня

4 Связь интерфейса с журналом событий Process Mining (Для аналитиков)

Каждое продуктовое действие на этих трех экранах генерирует строго определенный шаг в Event Log на стороне ClickHouse. Ниже представлена продуктовая карта генерации событий: 

  • Нажатие «Оприходовать на баланс» [] Событие: Supply_Registered

  • Успешный разбор чека через камеру [] Событие: Receipt_OCR_Success

  • Открытие экрана остатков [] Событие: Inventory_Viewed (используется для детекции петель)

  • Нажатие «Начать готовку» [] Событие: Cooking_StartedСписание просрочки в корзину [] Событие: Waste_Dropped