Design / Behavior
Interaction Design
This page is for the behavior layer of the site: what changes when a person hovers, tabs, clicks, opens, closes, tunes, or revisits a surface. The useful question is not only whether an interaction looks nice. It is whether the interaction makes structure clearer, consequences legible, and next actions easier to infer.
Good interaction design reduces ambiguity. A control should say what it is, what state it is in, what will happen next, and how to recover if the user changes their mind.
What this page should help answer
- What should be visible before interaction, and what can wait until focus, hover, or expansion.
- How to make state changes legible: open versus closed, selected versus unselected, saved versus unsaved.
- When motion, color, or ornament help explain behavior, and when they only add noise.
- How progressive enhancement changes the design boundary: what still works as plain HTML, and what requires JavaScript.
Working principles
Affordance before flourish
A control should read like a control before any animation or decorative treatment is added. If the user cannot identify the action, the styling is premature.
State should persist in more than one channel
Do not rely on color alone. Labels, pressed state, expanded state, focus treatment, and region visibility should reinforce each other.
Feedback should match consequence
A small local change can use subtle feedback. Navigation, destructive actions, and async changes need clearer acknowledgment.
Recovery matters
Users should be able to back out, close, reset, or re-find where they were without having to reconstruct the interface from scratch.
Reference points
ARIA Authoring Practices Guide
Useful when a pattern becomes widget-like and needs explicit roles, states, keyboard behavior, and tested examples.
APG practices
Use this when the question is about keyboard interaction, landmarks, names, descriptions, or widget semantics rather than pure visual behavior.
MDN: Keyboard accessible
A concise reference for the minimum behavioral discipline that interactive components need on the web.
Website interaction register
The local site-facing reference for how this repo currently thinks about shell behavior, tuneable surfaces, and named interactions.