Sync wiki after UX decisions accepted
@@ -1,4 +1,4 @@
|
||||
<!-- codex-wiki-sync:cf53d20eede728869b7f3de3 -->
|
||||
<!-- codex-wiki-sync:152f0f41a0121022597b1435 -->
|
||||
|
||||
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/UI_UX_DECISION_LEDGER.md`.
|
||||
> Origin: `repository`.
|
||||
@@ -36,29 +36,27 @@ exist, but it must be deliberately layered.
|
||||
| UX-008 | Similar concepts must use shared placement and components: server/credential/policy rows, problem lists, review steps, advanced panels, confirmation modals, and empty/error states. | Accepted | Core WebUI and module WebUIs |
|
||||
| UX-009 | Preflight and diagnostics are product UX. Validation, policy, permission, dependency, and capability failures must be written for operators before exposing internal details. | Accepted | Installer, connectors, policy, package import |
|
||||
|
||||
## Decisions Due Now
|
||||
## Confirmed Implementation Decisions
|
||||
|
||||
These decisions should be made before the first implementation slice because
|
||||
they shape reusable components and screen structure.
|
||||
These decisions were accepted on 2026-07-09 for the first implementation slice.
|
||||
They shape reusable components and screen structure. Future changes must revise
|
||||
this section and update affected screens.
|
||||
|
||||
### DUE-001: Primary Admin Configuration Shell
|
||||
|
||||
Decision needed: should admin/configuration surfaces standardize on a
|
||||
two-zone layout?
|
||||
Decision: admin/configuration surfaces should standardize on a two-zone layout.
|
||||
|
||||
- Left or top area: searchable overview/list, status, and primary actions.
|
||||
- Main area: selected item summary and common settings.
|
||||
- Modal/wizard: create, connect, edit, test, review, and confirm actions.
|
||||
- Collapsed advanced panels: rarely used technical fields.
|
||||
|
||||
Recommended default: yes. Use this for file connectors and mail servers first,
|
||||
then migrate policy, retention, API keys, and module operations.
|
||||
Use this for file connectors and mail servers first, then migrate policy,
|
||||
retention, API keys, and module operations.
|
||||
|
||||
### DUE-002: Wizard Step Model
|
||||
|
||||
Decision needed: standard wizard steps and names.
|
||||
|
||||
Recommended baseline:
|
||||
Decision: standard wizard steps and names use this baseline:
|
||||
|
||||
1. Choose type or scope.
|
||||
2. Enter essentials.
|
||||
@@ -72,9 +70,7 @@ where applicable.
|
||||
|
||||
### DUE-003: Explanation Placement
|
||||
|
||||
Decision needed: where do richer explanations live?
|
||||
|
||||
Recommended baseline:
|
||||
Decision: richer explanations should use this placement model:
|
||||
|
||||
- Short helper text below labels only when it prevents common mistakes.
|
||||
- Tooltips for icon-only controls and compact terms.
|
||||
@@ -85,9 +81,8 @@ Avoid permanently visible paragraphs inside dense admin cards.
|
||||
|
||||
### DUE-004: Advanced Options Contract
|
||||
|
||||
Decision needed: what qualifies as advanced?
|
||||
|
||||
Recommended baseline:
|
||||
Decision: advanced options are fields that are needed for control, compatibility,
|
||||
or diagnostics but are not part of the common setup path.
|
||||
|
||||
- protocol-specific endpoints, ports, path overrides, TLS/signing toggles,
|
||||
timeout/retry tuning, raw headers, migration/destructive flags, and fallback
|
||||
@@ -99,10 +94,10 @@ Advanced fields must still be editable through typed controls.
|
||||
|
||||
### DUE-005: Blocker Language Contract
|
||||
|
||||
Decision needed: should all disabled/blocked actions use a shared structured
|
||||
reason object?
|
||||
Decision: all disabled or blocked primary actions should use a shared structured
|
||||
reason object.
|
||||
|
||||
Recommended default: yes. Shape:
|
||||
Shape:
|
||||
|
||||
- `summary`: short plain-language reason.
|
||||
- `details`: optional explanation.
|
||||
@@ -113,9 +108,7 @@ Recommended default: yes. Shape:
|
||||
|
||||
### DUE-006: First Migration Surface
|
||||
|
||||
Decision needed: first screen family to convert.
|
||||
|
||||
Recommended default: file connectors, then mail servers. They share the same
|
||||
Decision: convert file connectors first, then mail servers. They share the same
|
||||
server/credential/policy model, are high-value, and will prove the reusable
|
||||
patterns quickly.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user