app-interaction-patternslisted

# App interaction patterns Interactivity is not a feature list, it is a set of promises: that the page will tell you what it is doing, what it is showing, and how to get back. Most interactive dashboards fail on the second and third. --- ## The state machine — build this first Every data surface has **seven** states. Designing three of them and discovering the rest in production is the normal failure. | State | Looks like | The mistake to avoid | |---|---|---| | **Loading** | Skeleton in the shape of the result | A spinner that hides the layout, so the page jumps when data lands | | **Ready** | The data | — | | **Empty (genuine)** | "No transactions in this period" + what would produce some | Rendering an empty chart frame, which reads as broken | | **Filtered to nothing** | "No results for these filters" + **which filters** + a reset | Same blank panel as genuine empty — completely different meaning | | **Partial** | The data you have, plus what is missing and why | Silently showing 8 of 12 segments as if that were all of them | | **Stale** | The data, plus its age, plus a retry | Showing a stale figure as current | | **Error / no access** | What failed and what to do | A blank region, or a raw error string | **Empty and filtered-to-nothing are different states.** Conflating them is the most common interaction bug in dashboards: the user cannot tell whether there is no data or whether they broke the view. Skeletons should match the final layout's dimensions so nothing