45 lines
3.6 KiB
Markdown
45 lines
3.6 KiB
Markdown
|
# 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 `running`
|
||
|
|
until "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.
|