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.

This page is also a specimen of its own subject. The sigils beside each heading are live handles — hold one, or right-click it, to open a menu that inspects the region it names, marks it, or traces others like it. Press g to open the surface map of every frame and route, [ and ] to step between frames, or / to filter them. The behavior described here is the behavior you are already using to read it.

~"interaction_questions"

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"

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"

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.

?["content_dimensionality"]

One interaction, four lenses

The same interaction — a press-and-hold on a sigil — read through shifting dimensions. Switch lenses with the chips below, or manipulate this frame's own sigil (above, beside the heading): click it to advance a lens, shift-click to step back. The content does not change; your angle on it does — and the sigil you turn is the very gesture the lenses describe.