ahmido
c36cb43741
This PR introduces the Global Surface Information Architecture Contract, detailing rules for decision-first display, metadata separation, and zero-state suppression across UI surfaces. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #441
51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# UI Bloat Pattern Registry
|
|
|
|
Verification level: derived from existing implementation using Spec 368 audit findings and recommendations.
|
|
|
|
## Pattern 1: Repeated Lifecycle Or Status Language
|
|
|
|
- **Observed in**: Operations, Backup, Restore, Customer Review.
|
|
- **Impact**: Dilutes the primary decision and makes healthy pages feel busy.
|
|
- **Rule**: One first-viewport block owns status, reason, impact, and next action.
|
|
- **Allowed exception**: row-level badges for independent rows.
|
|
|
|
## Pattern 2: Zero Metric Card Spam
|
|
|
|
- **Observed in**: Environment Dashboard, Operations Hub, Restore Run.
|
|
- **Impact**: No-action states look like dashboards of warnings.
|
|
- **Rule**: Suppress zero cards when the primary decision already says no action is needed.
|
|
- **Allowed exception**: zero is itself proof or audit-significant.
|
|
|
|
## Pattern 3: Technical Metadata In Main Content
|
|
|
|
- **Observed in**: Backup Set, Baseline Profile, OperationRun.
|
|
- **Impact**: Operators parse internals before the decision.
|
|
- **Rule**: Move IDs, timing, normalization lineage, provider details, and operation context to sidebar or collapsed details.
|
|
- **Allowed exception**: explicit diagnostic/system surface.
|
|
|
|
## Pattern 4: Shell Chrome Density
|
|
|
|
- **Observed in**: most captured admin/customer pages.
|
|
- **Impact**: Page question is delayed below navigation, notification replay, and repeated context.
|
|
- **Rule**: First viewport must keep the page's current question visible.
|
|
- **Allowed exception**: critical active warning or blocking context.
|
|
|
|
## Pattern 5: Evidence And Diagnostics Ambiguity
|
|
|
|
- **Observed in**: Evidence Snapshot, Required Permissions, System Panel blocked/partial audit.
|
|
- **Impact**: Reviewers cannot tell whether a claim is supported by evidence, diagnostics, or unverified runtime state.
|
|
- **Rule**: Evidence proves claims; diagnostics explain failure. Keep them visually and verbally separate.
|
|
- **Allowed exception**: support surfaces may show both, but still label them separately.
|
|
|
|
## Pattern 6: Provider Readiness Inference
|
|
|
|
- **Observed in**: Provider Connections list.
|
|
- **Impact**: Operators infer readiness from capability/config columns instead of seeing a primary readiness decision.
|
|
- **Rule**: Configuration surfaces lead with readiness, blocker reason, required action, and affected scope.
|
|
|
|
## Pattern 7: Customer-Safe Surface Density
|
|
|
|
- **Observed in**: Customer Review Workspace.
|
|
- **Impact**: Good customer-safe content still demands too much scanning.
|
|
- **Rule**: Customer/auditor first viewport shows outcome, limitation, evidence/report availability, accepted risks when relevant, and one handoff/review action.
|