Files

Mockups

Self-contained HTML files demonstrating the Blocao operator console and the audio transcript counterpart. Open any file in a modern browser — no build step, no server needed.

Files

File Description Use as reference for
index.html Unified Blocao operator console. Aterriza en SYNOPSIS (SCADA-style live diagram). Rail navega entre Engineering / Operator / System. Includes: SYNOPSIS, CAMS, FRIGATE, GITOPS, MQTT, HEALTH, FORENSICS, Setup Wizard, Camera Onboarding. The complete product UI.
transcript-forensics.html Audio transcript forensics panel. Query chat, waveform with speaker bands, transcript turns, audio player, topics+speakers panel. Transcript product UI.
forensics-only.html Earlier standalone version of the video forensics panel. Historical / forensic patterns reference.
gitops-only.html Earlier standalone version of the GitOps panel. GitOps panel patterns.
frigate-config.html Frigate integration mockup with cameras list and config editor. Frigate-specific panel.
palette-comparison.html Toggle between classic LCARS (orange-dominant) and complementary palette (cyan-dominant). Decision rationale for ADR-0001.
router-ui-original.html The very first sketch of the router console. Kept for historical reference. History only. Don't use as design reference.

How to use

  1. Investor/stakeholder demo: open index.html. Aterriza en SYNOPSIS. Click through rail entries to show the breadth.
  2. Designer reference: index.html is the canonical source for tokens, patterns, and chrome behavior.
  3. Engineer reference: each panel in index.html shows the data layout the corresponding API needs to support.
  4. Sales conversation: use index.html for video, transcript-forensics.html to show the audio counterpart and demonstrate platform breadth.

Design language

LCARS-inspired with complementary palette — cyan-dominant rather than the classic orange-dominant. Rationale and tokens documented in:

Modifying mockups

These files are HTML + inline CSS + minimal JS. To iterate:

  1. Branch from main.
  2. Edit the HTML file.
  3. Test in a browser locally.
  4. PR with screenshot of the change.

For substantial UX changes (new view, new pattern), add a new ADR to decisions/ first, then update the mockup.

Migration plan

These mockups will eventually be reimplemented in the real console SPA (apps/console/ in the future code monorepo). The migration:

  1. Extract design tokens to packages/design-tokens/.
  2. Extract reusable components to packages/ui-components/ (web components or React, TBD).
  3. Reimplement each panel as a real component consuming real APIs.
  4. Keep these mockup files as frozen reference during migration.

Until the real console is shipped, these files are the source of truth for visual design.

Browser compatibility

Tested on:

  • Chrome 120+
  • Firefox 120+
  • Safari 17+

Edge cases on older browsers may show CSS Grid layout issues — not a priority since the operator console will run in modern Chromium-based environments by default (Cell-served via OpenWrt + Caddy, accessed from operator's modern browser).

Why HTML files instead of Figma

We considered Figma. Chose HTML because:

  • HTML is interactive — click handlers, animations, real cursor states, real form inputs. Figma is mostly static.
  • HTML is versioned in git alongside the rest of the docs, with the same review/audit workflow.
  • HTML is portable — anyone with a browser can review without a Figma account.
  • HTML can embed real CSS animations (the SCADA flow lines, the pulse dots, the cursor blink) which are part of the product feel.
  • HTML doubles as a codebase starting point when migration begins.

The trade-off: less polished visual fidelity than a Figma file produced by a senior designer. Acceptable for our stage; will revisit when the real product ships and a designer joins full-time.