Skip to content

feedback_interactive_fidelity.md

Latest commit

 

History

History
24 lines (18 loc) · 2.96 KB

feedback_interactive_fidelity.md

File metadata and controls

24 lines (18 loc) · 2.96 KB
Raw
name feedback-interactive-fidelity
description Full-fidelity means INTERACTIVE fidelity, not just visual. Every tab must switch panels, every button must do something (navigate or fire a toast), every toggle must change state. Rendering the control without wiring it is a stub, not a port.
metadata
type
feedback

A screen is not full-fidelity until every interactive element actually works. Visual fidelity (it looks like the mockup) is necessary but not sufficient.

Why: Confirmed 2026-05-23. After porting Day Book / Coa / Ledger / Approvals "to full fidelity", the user found: (1) side-panel tab strips were dead clicks — the strip rendered with the active class hardcoded to index 0 and no onClick; (2) action buttons (New Voucher, Export, Print, Approve, etc.) did nothing. User: "none of the tabs in ledger page are functioning" and "new voucher button also doesnt do anything !!" and "same for all other pages you completed, they are not at full-fidelity". This extends [[feedback-full-fidelity-ports]] — that rule was read as "render every section"; it also means "wire every control".

How to apply — checklist before declaring any page done:

  • Tabs: use the @mtp/ui Tabs (Radix-backed: Tabs.Root + Tabs.List + Tabs.Trigger + Tabs.Content). Each tab MUST have its own Tabs.Content panel with real content. Never render a <button> strip with a hardcoded active index. (We shipped dead strips 4 times before fixing — the Tabs primitive existed in @mtp/ui the whole time, unused.)
  • Buttons must do one of: (a) navigate via useShellStore().navigate(pageId) when a real target screen exists (e.g. "New Voucher" → voucher, "Open Ledger" → ledger); (b) fire a useToast() toast describing the action when there's no backend yet ("Export queued — …", "New Account — form pending backend"); (c) mutate local state (filter chips, view toggles, period chips). A button with no handler is a bug.
  • Toggles / chips / view-switchers must flip state and ideally change what's shown. A chip that looks selectable but does nothing is a stub.
  • Selectable rows (ledger entries, queue rows, tree nodes) must update the selection + the detail panel.
  • Verify in the browser: click every tab, every button, every toggle via chrome-devtools before commit. For tabs, confirm data-state="active" moves and the panel content changes. For toast buttons, confirm a toast node appears in the [aria-label="Notifications"] region (it auto-dismisses in 5s, so assert programmatically right after click, don't rely on a screenshot).

Infrastructure now in place (use it, don't re-stub):

  • @mtp/ui Tabs — Radix tabs. ToastProvider (mount once at root) + useToast() — toasts. Tooltip + TooltipProvider — hover detail.
  • @mtp/hooks useShellStore — navigation store; navigate(pageId, moduleId?), setModule, setTab.

Related: [[feedback-full-fidelity-ports]], [[feedback-verify-data-grids]], [[project-mtp-component-authoring]].