# The HTML concept demo pattern

The fastest way to show a *reimagined* experience. Hours, not days, and it renders anywhere.

Use it when you need to show what the product **could** look like for this customer, before committing to build anything real.

---

## The core idea

**Render your concept inside the customer's own UI shell.**

Recreate their actual chrome — their brand colour bar, their real left-navigation with their real menu item names, their command bar. Then put your new screens in the content area.

This does two things at once:
- the customer recognises it instantly as *their* system, not a generic mock
- the contrast between the shell they know and the content they don't is the entire argument

Get the shell details from the reverse-demo screenshots: exact menu labels, ordering, terminology, icons.

---

## Layout: stage + notes rail

```
┌───────────────────────────────────┬──────────────────┐
│  screen tabs, grouped by persona  │                  │
├───────────────────────────────────┤   presenter      │
│                                   │   notes          │
│   the customer's UI shell         │                  │
│   with your screens inside        │   • what this    │
│                                   │     replaces     │
│                                   │   • the quote    │
│                                   │     behind it    │
│                                   │   • how it's     │
│                                   │     built        │
└───────────────────────────────────┴──────────────────┘
```

The right-hand rail is what makes it a **team artefact** rather than a personal one. Anyone can pick it up and present it, because each screen carries:

- **What this replaces** — the specific current-state screen and its problem
- **The customer quote that justifies it** — verbatim
- **How it's built** — which standard capability, so you can defend "no customisation"
- **Warnings** — what not to say, what's unverified

---

## Structure

A single self-contained `.html` file. No build step, no server, no dependencies. Opens by double-click, survives being emailed.

```
theme + CSS for the customer's shell
CSS for any secondary product surface (e.g. a BI report)
body: nav groups + #stage + #notes
<script>
  data arrays          // realistic, matching the demo dataset
  helpers              // money/percent formatting, colour by threshold
  shell builders       // d365(v), pbi(v) — wrap content in the right chrome
  screen definitions   // { type, nav, group, label, cmd, html, notes }
  table builders       // filterable grids
  render + wiring      // tab clicks, data-go cross-navigation
</script>
```

### Assembling a large file

If your authoring tool rejects a very large single payload, write it in numbered parts and concatenate:

```powershell
$parts = 1..8 | ForEach-Object { "suite.part$_.txt" }
$sb = New-Object System.Text.StringBuilder
foreach ($f in $parts) { [void]$sb.AppendLine((Get-Content $f -Raw)) }
[System.IO.File]::WriteAllText($out, $sb.ToString(), (New-Object System.Text.UTF8Encoding $false))
```

Delete the parts afterwards.

---

## Screen design rules

**1. Every row answers four questions.**
What, why, how much, and one action. Never a bare record link. A list that just names records is the current state you're replacing.

**2. Ranked, not filtered.**
The screen already knows what matters. If the user has to build a filter to find their priorities, you've rebuilt the problem.

**3. Show the reasoning.**
"Score 92" is a black box. "Score 92: budget confirmed +28, similar to 3 existing top accounts +22, volume specified +19" is a decision aid.

**4. End analytics in an action.**
If you're reproducing their reporting, every page must terminate in a button that lands somewhere actionable. Reporting that tells you *what happened* without telling you *what to do* is the gap you're closing.

**5. Use their numbers.**
Reproduce real figures from the reverse demo — their formula, their categories, their attainment. Showing their own data back, rendered better, is the most efficient credibility you can buy.

---

## Verify it (do not skip)

The `file:` protocol is blocked by browser automation, so serve locally:

```powershell
Start-Process python -ArgumentList "-m","http.server","8907" -WindowStyle Hidden
```

Then drive it and assert on the DOM:

```js
// visit every screen, check it rendered and has no template leakage
for (const k of keys) {
  click(tab(k));
  assert(stage.innerHTML.length > 4000);
  assert(!stage.innerHTML.includes('undefined'));
  assert(!stage.innerHTML.includes('NaN'));
}

// every filter tab: does the row count match its label?
for (const t of tabs) { t.click(); rows = table.rows.length - 1; }

// cross-navigation actually navigates
```

**Check the label against the data.** A tab that says "Stalled (4)" showing 3 rows is the kind of thing a customer notices immediately and you never do.

### Watch for CSS that silently does nothing

Bar/fill elements set with a percentage width render at zero if the element is `display: inline`. Assert on computed style, not just presence:

```js
getComputedStyle(fill).width   // '0px' means broken, even though it's in the DOM
```

Stop the server when finished.

---

## Consistency check across screens

Concept suites drift. The same fact computed in two places must agree:

- a KPI card that says "8 accounts with a gap" vs a table that computes 6
- a tab labelled "13 projects" over an array of 10
- a total on one screen vs the sum on another

Derive from one source array wherever possible, and where you hard-code a headline number, verify it against the array that renders below it.