tegwick
cb517b613a
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: sonnet Assistant-Process: 295952@bnt-lap001 Assistant-Session: e93f64ad-516c-46eb-9666-aad8d300c477
3.6 KiB
UX review: old console vs first native UI (2026-09-29)
Reviewer: Bernd. Recorded by Claude. Compared security-bootstrap-console
(NetKingdom, :8876) with the first rtut ui (:8877) on the NetKingdom packs.
The comparison is unequal
The old console is more accessible and more professional on first impression, and it models a far more complicated procedure. Each of its stages is about the size of one of the new example runbooks. The new UI was built for flat sequences and looks like a config form with comments as content. Design polish (spacing, dark mode, visual guidance) is a renderer job. The specification must not be complicated to enable eye-candy; a clear specification should render well.
Findings
| # | Finding | Consequence |
|---|---|---|
| 1 | The new flows are the basic element only: simple sequences with no hierarchy, no alternatives. The old console's stages give progress feedback and structure | The spec needs stages, hierarchy, alternatives and parallelism |
| 2 | Two different states are needed: nil/set/err/ok is about setting the parameter (a datapoint); todo/running/done/failed is about applying it (a step) |
Datapoints get their own state, separate from step state |
| 3 | Next-action guidance is necessary. Several actions may be available once their prerequisites are met, but exactly one is recommended | The pack captures parallelism; a canonical, optional serialization gives a single operator one path |
| 4 | An overview with very clear state transparency, in several views by dimension (from canon standards where available), is a core feature. Hierarchical organization of complex runbooks is how orientation and learning happen | Overview and hierarchy are first-class |
| 5 | The pack must define and explain actors, roles, privileges; otherwise nothing says what is relevant | Actors and roles are part of the pack |
| 6 | Showing what a run produced and where it lives is what makes the UI more valuable than a wizard, script or config files | Artefacts (non-secret references) are part of the pack |
| 7 | Both confirmation styles are needed: a confirm button for reversible actions, a typed phrase for irreversible ones | Derive the style from reversibility; default confirm |
| 8 | Layout: the new UI is unpolished and gives too little visual guidance | Renderer work, after the spec |
| 9 | Two views, two use cases. A serial guided questionnaire is the main interface. A dimension/tag organized, random-access view of the collected datapoints is a second interface, independent of the flow. In the old console the two are intermingled | Separate the flow from the data view |
| 10 | Gates are not clearly tied to stages or to quality-assurance goals in the old console, and gates are missing from the new UI entirely | QA gates become a first-class concept, attached to stages and goals |
| 11 | Threat checks in the footer are misplaced: they are framing to keep in mind, not a final gate to pass | Show framing at the start; keep gates separate |
Usability defects in the first UI (to fix in the renderer)
- Ticking the manual confirm box shows "passed" but the step stays
runninguntil "Mark done" is pressed. Unticking then changes nothing. The check, record and lock-in cycle is not visible. - Steps after the first show no Start button and no reason. A blocked step must say what it is waiting for.
- The good part, to keep: parameter form, then a run view with copy command, run in terminal, feedback, confirm.
Later extension (noted, not scheduled)
Operator feedback on a step feeds a runbook-aware assistant that may diagnose the deployment, giving a feedback, retry, feedback, confirm loop.