Rebuilding SCADA Quality Control: From Modal Dialogs to Inline Data Entry

When you’re staring at a feature branch called feature/variant-a-migration on a SCADA coating system, you know the refactoring gods are about to test your patience. Today, they were generous—both agent implementations converged, the build passed cleanly, and we had what felt like a minor miracle: zero merge conflicts.

The task was straightforward on paper: improve how operators log and view batch quality data in the coating process. In practice, it meant rethinking two critical UI surfaces that technologists use dozens of times per shift.

Program step durations were the first puzzle. Operators need to see how long each phase of the electroplating cycle takes—but displaying raw seconds like 3665 on a quality report is professional suicide. We implemented a dual-mode display: show time in h:mm:ss format (1:01:05), but let operators input raw seconds. Click the cell, type 3665, hit Enter, watch it transform. It’s a small thing, but it matters when you’re scanning ten programs looking for a bottleneck.

The Quality tab demanded more fundamental surgery. The old approach—modal dialogs and split-column layouts—felt like forcing data into containers designed for something else. We rebuilt it ground-up: chip-based filters (Tutte-sized touch targets at 40px) replacing dropdowns, inline date ranges, summary cards showing pass/conditional/reject counts. Then came the satisfying part: clickable batch rows that expand in place, revealing three parallel detail sections—traceability (program, operator, power supply specs), process data (steps with durations, current, voltage, temperature), and coating results with full audit trails.

The BatchResult type grew to track who entered what and when. More importantly, every correction gets logged: the field that changed, old value, new value, timestamp, operator. It’s not just CRUD anymore—it’s a compliance record that auditors actually want to see.

The tradeoff was real though. Inline expansion instead of modals means less screen real estate per detail view, but operators can now cross-reference three batches without playing modal window Tetris. We kept the data entry form close to the summary—no context switching. Forms appear inline only when needed; otherwise, the workflow is observation → filter → expand → read.

One technical fact worth noting: implementing audit trails for every field change is deceptively complex in React. You need immutable data structures and careful state management to avoid bugs where corrections stomp each other during concurrent edits. We leaned on Pydantic-style validation throughout to keep data integrity tight.

The build passing cleanly felt earned. Two independent implementations, unified in the same codebase, both respecting the existing architecture. That’s when you know the feature design was solid enough to survive parallel development.

Programming is 10% science, 20% ingenuity, and 70% getting the ingenuity to work with the science. 😄