plast-track/UI.md

UI Guide

Purpose

This file documents the current frontend UI direction for Plast Track MVP.

The product surface is now organized as module tabs instead of one long dashboard page. The goal is to keep the operator focused on one task area at a time while preserving fast access to workshop status, selected machine context, and actions.

UI Direction

The current UI aims for:

• modern industrial dashboard
• simple and readable operator flows
• elegant but restrained visual language
• fast status scanning
• clear separation between monitoring modules and operator actions

Design principles:

• show machine state first
• reduce visual noise
• separate workflows into tabs
• keep passive acquisition and machine safety explicit
• avoid sending any command back to machines

Layout

The application uses a tabbed module workspace:

Hero Header
Summary Ribbon
Module Tabs
Current Module Panel

Current module tabs:

• Atelier: machine cards, filtering, sorting, quick actions, fullscreen workshop mode
• Machine: selected machine detail, cycles, events, downtime history
• TRS: daily OEE/TRS and per-machine OEE
• OF: production order creation and status management
• Arrets: open downtime qualification and timeline
• Rebuts: scrap declaration and recent scrap log
• Config: selected machine signal and timing configuration

Desktop, tablet, and mobile all use the same module model. On smaller screens, tab buttons and module content stack naturally without horizontal page scroll.

Main UI Blocks

1. Hero Header

Purpose:

• establish product identity
• show realtime connection status
• provide top-level hierarchy

Content:

• product title
• realtime status
• error feedback if data loading fails

2. Summary Ribbon

Purpose:

• provide workshop-level scanning before entering a module

Current metrics:

• global OEE
• machines in production
• open downtimes
• produced quantity vs scrap quantity

3. Module Tabs

Purpose:

• separate supervision, production order, downtime, scrap, TRS, and configuration workflows
• avoid crowding all operator forms on one page
• keep each module readable on tablets and production displays

4. Atelier Module

Purpose:

• show every machine at a glance
• support quick triage and routing to the right workflow

Features:

• machine card grid
• status filter
• sort by code, OEE, or stops first
• fullscreen workshop mode
• state duration badge
• no-active-OF empty state
• quick actions to OF, Rebuts, and Arrets modules

5. Machine Module

Purpose:

• turn the selected machine into the focal point

Contains:

• status KPIs
• current order
• average cycle
• daily OEE
• machine context
• recent cycle SVG bars
• recent events
• downtime history

6. TRS Module

Purpose:

• keep daily performance visible without mixing it with operator forms

Contains:

• global OEE
• availability
• performance
• quality
• per-machine OEE list

7. Operator Action Modules

Purpose:

• keep write workflows focused and auditable

Modules:

• OF: create, start, pause, and close production orders
• Arrets: qualify open downtimes
• Rebuts: declare scrap
• Config: update passive signal configuration

All forms use inline validation, inline API error feedback, and success toasts.

Visual Language

Typography

Fonts:

• Instrument Sans for interface text
• Space Grotesk for headings and numeric emphasis

Color

Base direction:

• light industrial gray background
• industrial blue primary structure
• anthracite text and secondary structure
• technical orange active accent
• white panels for contrast

Final palette:

Usage	Color	Code
Couleur principale	Bleu industriel	#0A2F5A
Couleur secondaire	Gris anthracite	#2B2B2B
Couleur accent	Orange technique	#F28C28
Fond clair	Gris tres clair	#F5F7FA
Fond / contraste	Blanc	#FFFFFF

Status colors:

• production: industrial blue
• arret_non_qualifie: technical orange
• arret_qualifie: anthracite
• reglage: mixed industrial blue / orange
• hors_planning: neutral anthracite tint

Surfaces

Surfaces use:

• rounded panels
• soft shadows
• token-driven borders
• high contrast status text

Responsive Behavior

Desktop:

• centered workspace
• full tab row
• wide machine grid
• split layouts inside form/list modules

Tablet:

• tab row wraps to fewer columns
• form/list modules stack

Mobile:

• single-column flow
• summary cards stack
• tabs stack
• tables scroll horizontally only inside their wrapper
• touch targets remain at least 44px high

Operator Experience

The UI is designed so an operator or supervisor can quickly:

1. see which machines are running or stopped
2. filter or sort machines by operational need
3. open a selected machine detail view
4. create or manage production orders
5. qualify downtime
6. declare scrap
7. review daily TRS/OEE
8. configure passive signal timing per machine

Current Frontend Files

Core files:

• frontend/src/App.tsx
• frontend/src/styles.css
• frontend/src/components/MachineCard.tsx
• frontend/src/components/Panel.tsx
• frontend/src/components/CycleBarChart.tsx

Suggested Next UI Improvements

Near-term:

• improve table empty states for OF and machine event history
• add optimistic row updates for order and downtime actions
• add tablet-first operator shortcuts for common reason codes

Medium-term:

• create separate operator and supervisor views
• add richer downtime timeline with duration buckets
• add historical trend charts for OEE and scrap
• add saved workshop display presets

High-value UX additions:

• keyboard-friendly action flow for industrial tablets
• larger gloved-use mode
• alarm emphasis rules without overusing red
• quick action drawer for the selected machine

UI Goal

The target is not a generic admin panel.

The target is a calm, production-oriented interface that helps people notice problems fast, act with minimal friction, and understand machine performance in context.