Cinematic UI 2.0中文

Docs / 08

App mode: directing dashboards and back offices

Cinematic UI 2.8 directs dashboards, admin panels and consoles with a task playhead, a signature view and eight designed states, screened by app-screening.

Cinematic UI directs apps too, on a smaller budget. When the brief is a dashboard, back office, admin panel, console, internal tool or the signed-in side of a SaaS product, the agent works in app mode. The playhead is no longer the scrollbar. It is the task. A view is a shot, moving between views is a cut, and the record the crew is working on is the lead.

The audience is not a visitor who watches once. It is a crew that comes back every day, often for a whole shift, and does the same few jobs hundreds of times. Cinema gets about a tenth of the frame. The rest is a quiet, dense, keyboard-driven instrument. A marketing site and its product app are two productions.

Site mode versus app mode

Site App
Playhead Scroll (and the visitor’s other triggers) The task: routes, selection, filters, the record’s state
Output A website people visit A dashboard, back office, console or logged-in product a crew works in all day
Rhythm set by The visitor’s hand The shift: the same few jobs, hundreds of times
Shot size By section By job: wide is the overview, medium is a list or queue, close is one record, insert is one field or event
Opening A loader as shot one No loader. First paint is readable and data loads inside its own frame
Accent One accent, spent rarely One accent meaning “a human must act here”, plus a separate status system

references/app-mode.md replaces stages 1, 6, 7 and 9, the award pass, the loader and the lazy cut, and changes how the rest apply.

Why a separate mode

Three blind tests (a SaaS analytics office, an order back office, an on-call console) built with site mode alone came out competent and interchangeable: three directors, one look, with a muted ground, one accent, boxed panels and four equal KPI cells on top. The film reached the palette, not the structure. The kit and screening were unusable for apps, nobody designed empty, loading or error states, and one accent could not carry status.

What app mode adds

  • The shift replaces the logline. The agent writes who works in the app, for how long, what interrupts them and what the worst minute looks like, then lists the three most frequent jobs and the one rare, high-stakes job. A view that serves none of them is cut.
  • The signature set replaces the KPI row. Each app finds a view only it could have, drawn from its own data.
  • The lighting plan. Attention is lit where the crew should look; everything else is quiet.
  • The eight states. Every view is designed and screened in each state it can reach.
  • Accent versus status. The accent says “a human must act here” and marks the exceptions. Status is carried by its own system, never by colour alone.
  • Motion by frequency. Anything used fifty times a day does not animate.
  • Data casting. Stand-in data has real shape: long tails, noisy series with events, mixed-locale names, edge rows.
  • Keyboard and undo. Shortcuts with a sheet, row navigation, a command palette, undo toasts.

The eight states

State Rule
Default Real volume, real ugly values
Loading Skeletons sized like the final content; the shell never disappears; no layout shift when data lands
Empty, not yet Says what will appear and the one action that creates it
Empty, filtered to zero Says which filters caused it and offers to clear them; never a create button
Empty, all done A cleared queue. Calm, short, earned
Error What happened, what to try, a copyable request id; inside the region that failed
No permission Who can grant it
Huge Ten thousand rows, a 60-character name, seven-figure values: nothing overflows

The tools

  • kit/app.js: hash router with filters, sort and selection in the URL, forced screening states (?state=), a frozen clock (?now=), keyboard shortcuts with sequences and a shortcut sheet, j/k row navigation, a peek or modal drawer, a command palette, and toasts with undo. It has no look of its own.
  • kit/fixtures.js: seeded stand-in data with real shape.
  • kit/app-shell.html: a grey animatic of an app with the shell, overview, list, a record in a peek panel, and every state.
  • scripts/app-screening.mjs: every route by state by viewport by theme, contact sheets, and flags for proportional digits, left-aligned numbers, clipped text, layout shift between loading and loaded, low contrast, small targets, hidden focus and blank states.

What the retests showed

The same three briefs, run again blind on this version, came back with no KPI row in any of them. Each found its own signature set (a three-month bridge where only the deviation is lit, a fleet as a fixed plan, the day’s collection gates as a letterboxed yard). Lists went from 8-15 to 20+ rows on screen, and every route was screened in all eight states. The retest also fed more rules back in, such as the uncast app grade of olive or putty with amber, which appeared in four of six first-round apps.