ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
platform-dev
TenantAtlas/specs/370-global-surface-information-architecture-contract/artifacts/ui-bloat-patterns.md
ahmido c36cb43741 spec: add global surface IA contract (#441) 
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
2026-06-10 20:25:15 +00:00

2.6 KiB
Raw Permalink Blame History

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.