Prototype the TUI information architecture #3

New Issue

2026-08-31T08:03:03Z

xavierk commented

2026-08-31 08:03:03 +00:00

Parent map: Chart Fenris’s persistent TUI monitoring redesign

Question

What TUI information architecture and interaction model makes Fenris’s overview, usage history, drive health, settings, service state, warming-up state, projection confidence, unexplained gaps, and changing habits understandable in a keyboard-first terminal? Build a cheap interactive or concrete prototype, gather the human’s reaction, and resolve the screen hierarchy, navigation, critical actions, and presentation priorities.

Parent map: [Chart Fenris’s persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question What TUI information architecture and interaction model makes Fenris’s overview, usage history, drive health, settings, service state, warming-up state, projection confidence, unexplained gaps, and changing habits understandable in a keyboard-first terminal? Build a cheap interactive or concrete prototype, gather the human’s reaction, and resolve the screen hierarchy, navigation, critical actions, and presentation priorities.

xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 08:03:03 +00:00

xavierk added the wayfinder:prototype label 2026-08-31 08:03:03 +00:00

xavierk added a new dependency 2026-08-31 08:03:19 +00:00

#4 Define the lifespan projection and confidence model

xavierk added a new dependency 2026-08-31 08:03:19 +00:00

#8 Define the collector, service, and CLI lifecycle

xavierk added a new dependency 2026-08-31 08:03:19 +00:00

#6 Evaluate Python TUI frameworks for Fenris

xavierk commented

2026-08-31 10:45:23 +00:00

Context from the lifecycle decision (ADR 0003), now unblocking this prototype: present boot enablement, runtime activity, last collect outcome, and freshness as separate facts; Pause asks for confirmation, Resume doesn't; collect-now and pause/resume run through the polkit prompt via a terminal-attached subprocess — validating that tty passthrough works under the chosen TUI framework is part of this prototype.

Context from the lifecycle decision ([ADR 0003](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/adr/0003-service-lifecycle-and-sanctioned-toggle.md)), now unblocking this prototype: present boot enablement, runtime activity, last collect outcome, and freshness as **separate** facts; Pause asks for confirmation, Resume doesn't; collect-now and pause/resume run through the polkit prompt via a terminal-attached subprocess — validating that tty passthrough works under the chosen TUI framework is part of this prototype.

xavierk self-assigned this 2026-08-31 10:51:47 +00:00

xavierk referenced this issue from a commit

2026-08-31 11:00:32 +00:00

prototype(tui): throwaway TUI information-architecture prototype (ticket #3)

xavierk commented

2026-08-31 11:00:38 +00:00

Prototype asset ready for reaction: prototype/tui-ia on branch prototype/tui-information-architecture (throwaway branch, not main).

Run: cd prototype/tui-ia && ./run (Textual 8.2.8; uv-based venv).

Variants (switch with ←/→): A Panes — one dense screen, everything at once; B Pages — persistent lifespan·confidence·freshness header + pages 1–5; C Ledger — one scrolling narrative document. Structurally different information architectures over the same contract.
States (cycle with s): steady·Supported, warming up·Limited, habit changed·Limited, stale·Supported→Limited, no baseline·Unavailable, paused·Limited — covering confidence presentation, warming-up, unexplained gaps, and changing habits.
Actions: p pause (asks confirmation), r resume (does not), c collect now (synchronous outcome) — each suspends the TUI and runs a polkit stand-in on the real terminal, validating the tty passthrough ADR 0003 requires. Outcomes land in the tty log (variant B service page).
Headless SVG captures of every variant at 80×24 and 140×40 are in screenshots/ (smoke_test.py, all checks green).

Awaiting the human's reaction before resolving: which variant (or mix — header of B with density of A is a valid answer), whether the four service facts read as separate facts at a glance, whether confidence + contributing facts read as evidence rather than a percentage, whether pause has the right friction, and whether the polkit stub actually prompted in the terminal (the mechanism check).

Prototype asset ready for reaction: [prototype/tui-ia on branch prototype/tui-information-architecture](https://git.bongbetic.com/xavierk/Fenris/src/branch/prototype/tui-information-architecture/prototype/tui-ia) (throwaway branch, not main). Run: `cd prototype/tui-ia && ./run` (Textual 8.2.8; uv-based venv). - **Variants** (switch with ←/→): **A Panes** — one dense screen, everything at once; **B Pages** — persistent lifespan·confidence·freshness header + pages 1–5; **C Ledger** — one scrolling narrative document. Structurally different information architectures over the same contract. - **States** (cycle with `s`): steady·Supported, warming up·Limited, habit changed·Limited, stale·Supported→Limited, no baseline·Unavailable, paused·Limited — covering confidence presentation, warming-up, unexplained gaps, and changing habits. - **Actions**: `p` pause (asks confirmation), `r` resume (does not), `c` collect now (synchronous outcome) — each suspends the TUI and runs a polkit stand-in on the real terminal, validating the tty passthrough ADR 0003 requires. Outcomes land in the tty log (variant B service page). - Headless SVG captures of every variant at 80×24 and 140×40 are in `screenshots/` (`smoke_test.py`, all checks green). Awaiting the human's reaction before resolving: which variant (or mix — header of B with density of A is a valid answer), whether the four service facts read as separate facts at a glance, whether confidence + contributing facts read as evidence rather than a percentage, whether pause has the right friction, and whether the polkit stub actually prompted in the terminal (the mechanism check).

xavierk commented

2026-08-31 11:45:04 +00:00

Resolution — Variant A (Panes) adopted.

The human ran the prototype live and picked A · Panes: one dense keyboard-first screen, no page navigation — headline lifespan + confidence with contributing facts and scenario range across the top, usage history (sparkline with ▲ habit-change / ? gap markers, habit-split bar) as the left pane, drive health + settings right, and a service strip with the four separate facts plus the action legend at the bottom.

Four service facts (boot enablement / runtime activity / last collect outcome / freshness) confirmed separable at a glance in this layout.
Confidence state + contributing facts confirmed to read as evidence, not a percentage.
Pause-confirmation asymmetry kept: p asks, r doesn't.
tty passthrough validated on a real terminal — the TUI suspended, the terminal-attached polkit stand-in prompted, and control returned cleanly. The mechanism ADR 0003 §8 requires works under Textual 8.2.8 on Python 3.13, corroborating the framework decision.
Prototype preserved as primary source: prototype/tui-ia, with headless SVG captures of every variant × state in screenshots/.

This settles the map's first fog patch (exact presentation of confidence, warming-up, unexplained gaps, changing habits). The acceptance-criteria fog graduates to its own ticket, blocked by the remaining open decisions.

**Resolution — Variant A (Panes) adopted.** The human ran the prototype live and picked **A · Panes**: one dense keyboard-first screen, no page navigation — headline lifespan + confidence with contributing facts and scenario range across the top, usage history (sparkline with ▲ habit-change / ? gap markers, habit-split bar) as the left pane, drive health + settings right, and a service strip with the four separate facts plus the action legend at the bottom. - Four service facts (boot enablement / runtime activity / last collect outcome / freshness) confirmed separable at a glance in this layout. - Confidence state + contributing facts confirmed to read as evidence, not a percentage. - Pause-confirmation asymmetry kept: `p` asks, `r` doesn't. - **tty passthrough validated on a real terminal** — the TUI suspended, the terminal-attached polkit stand-in prompted, and control returned cleanly. The mechanism ADR 0003 §8 requires works under Textual 8.2.8 on Python 3.13, corroborating the framework decision. - Prototype preserved as primary source: [prototype/tui-ia](https://git.bongbetic.com/xavierk/Fenris/src/branch/prototype/tui-information-architecture/prototype/tui-ia), with headless SVG captures of every variant × state in `screenshots/`. This settles the map's first fog patch (exact presentation of confidence, warming-up, unexplained gaps, changing habits). The acceptance-criteria fog graduates to its own ticket, blocked by the remaining open decisions.

xavierk closed this issue

2026-08-31 11:45:05 +00:00

xavierk referenced this issue

2026-08-31 11:45:30 +00:00

Chart Fenris’s persistent TUI monitoring redesign #1

xavierk referenced this issue

2026-08-31 18:13:48 +00:00

Write the Fenris redesign specification and close the map #19

Sign in to join this conversation.