Grim:dev:design:layout Previews

Layout Previews

Turn a spatial design decision into a side-by-side visual choice with aligned ASCII or box-drawing mockups.

A label like "Info-rich HUD" tells the user almost nothing. A tiny rendered frame tells them everything. When the choice is about where things go, show it.

When To Use

Use it when the decision involves a concrete spatial or visual artifact the user benefits from seeing:

• UI / HUD layouts, screen arrangements, panel or component placement
• Navigation / information hierarchy variants
• Diagram or architecture-shape variations
• Config or code-snippet structure choices where shape matters

Do NOT use it for:

• Simple preference questions where the label already says it all ("Dark or light mode?", "Ship now or after tests?")
• Non-visual tradeoffs (naming, yes/no, scope) — plain options are clearer there.

How It Works

• If the current question tool exposes a preview field, use that field according to its actual schema.
• Otherwise show labeled mockups inline in fenced text blocks, then use the available question mechanism to collect the choice.
• Use only tool fields and rendering features exposed by the current host. The visual comparison must still work without a preview-capable question tool.
• Keep each mockup compact and legible inside a monospace box — a few rows, not a full screen.

Mockup Craft

• Align every column. Misaligned box edges read as broken, not as a layout. Count characters; pad with spaces.
• Use box-drawing + glyph chars to imply real UI:
  • frames / panels: ┌ ┐ └ ┘ │ ─ ├ ┤ ┬ ┴ ┼
  • heavy / emphasis frames: ╔ ╗ ╚ ╝ ║ ═ ╟ ╢ ╠ ╣
  • brackets / chips / slots: ⟦ ⟧ [ ] ◈ ▰ ▱
  • bars / fills / accents: █ ▓ ▒ ░ ▮ ▯ ★ ☆ ◆ ●
• Label regions with short text so the structure is unambiguous (HP, MENU, MAP, ★3).
• One clear idea per mockup. The differences between options should be visible at a glance.
• Make the same elements appear in roughly the same place across options so the user is comparing arrangement, not hunting for what moved.

Canonical Example — In-Match HUD

Three alternatives for an in-match HUD. Show the frames inline or in supported option previews.

Option A — Minimal

┌──────────────────────────────┐
│                              │
│                              │
│           [ARENA]            │
│                              │
│                              │
│ ❤30                    ⏱1:24 │
└──────────────────────────────┘

Option B — Info-rich

┌────────────┬───────────────┐
│ UNITS      │    [ARENA]     │
│ ▰ Knight   │                │
│ ▰ Archer   │                │
│ ▱ Mage     │                │
├────────────┤  ❤30   ⚔12     │
│ ⛁ Gold 8   │  ⏱1:24  ★3     │
└────────────┴───────────────┘

Option C — Thematic frame

╔══════════════════════════════╗
║   ◈  ~ THE WARFRONT ~  ◈      ║
╟──────────────────────────────╢
║                              ║
║           [ARENA]            ║
║                              ║
╟───────────❤30────⏱1:24───────╢
╚══════════════════════════════╝

Each frame is the same width, columns line up, and the three layout philosophies (sparse / dense-sidebar / framed-thematic) are obvious side by side.

Checklist

• Choice is spatial/visual, not a plain preference. ✅
• The host supports the chosen presentation and question format. ✅
• Every option has a visible mockup. ✅
• Columns and box edges are aligned across all options. ✅
• Each mockup is compact, labeled, and legible in monospace. ✅

References

• Box-drawing characters: https://en.wikipedia.org/wiki/Box-drawing_characters