Trigger
What the user does or what state changes the system observes. JMF allows only user-initiated triggers.
Foundations
Microinteractions
Motion is the vocabulary. Microinteractions are where that vocabulary becomes felt. Each one is the interface answering a user action — a depressed button, a traveled toggle, a drawn checkmark.
Why microinteractions matter
A static interface asks the user to do extra work. Did the system register my click? Did the toggle actually flip? Was that the right radio I selected? Microinteractions answer those questions in the same beat as the action that raised them. The user does something; the interface answers in motion the user can feel without thinking about it. That tiny acknowledgment is what makes an interface feel responsive rather than stiff.
The line between feedback and decoration is the most important line on this page. Feedback teaches; decoration distracts. Every microinteraction in the library below exists because the user did something. None of them play on a timer or attempt to delight without earning it.
The four-part framework
Nielsen Norman Group’s framing, narrowed to enterprise applications.
Rules
What the microinteraction does given the trigger. The logic — what changes, in what order, with what constraints.
Feedback
How the user perceives the result. Visual, motion, sometimes audio, never haptic on the desktop.
Loops and modes
How the microinteraction extends over time (loops) or adapts to context (modes). Most microinteractions are stateless; loops are the exception, not the default.
The JMF trigger rule
Every microinteraction must be on user input. Click, hover, focus, keyboard, scroll. No autoplay. No on-load animation that runs without the user having done anything. No timed reveals.
| Accept | Reject |
|---|---|
| Button depresses on :active | Button bounces on page load |
| Toggle thumb travels when clicked | Toggle wiggles when the user hovers the page |
| Checkmark draws when the box is checked | Checkmark redraws every 30 seconds for visual interest |
| Error message shakes when submit is clicked with bad input | Error message shakes continuously while the field is invalid |
| Skeleton fades out when content loads (the user requested the page) | Idle skeletons pulse forever on an empty section |
| Tooltip fades in on focus | Tooltip appears on a timer to draw the user's attention |
The page-load case is the most common violation. A button that bounces when the page loads is decoration, not feedback. The trigger is not “the page mounted.” The trigger is “the user did something.”
Demo library
Eight microinteractions JMF uses. Each card shows the demo, the rule, and the tokens it consumes. Hover, click, or focus the demo to trigger it. Every demo respects prefers-reduced-motion: the state change still happens; the motion does not.
Feedback on user action
Button press
A visual depression and shadow change when the user presses the button. Confirms the click was received without adding an extra step.
Success flash
A short sage confirmation state on a successful action. Uses the brand accent green, not the alerting feedback green, because the user expected this outcome.
Error shake
A single horizontal shake on bad submit, paired with an error message. Once. Never on every keystroke.
Checkbox check
The checkmark draws as a stroke when the box is toggled on, giving the action a tactile quality without slowing it down.
State changes
Toggle
The thumb travels between off and on positions on click. The travel teaches which state is active without reading the label.
Email notifications
Skeleton load
A shimmering placeholder for content the user requested. Replaced with real content as soon as it lands.
Vendor: Acme Inc.
Contract renewed 12 days ago.
Owner: Sergio U.
Affordances and reveals
Hover reveal
Secondary actions surface on row hover or keyboard focus. Hidden until the user signals interest in the row.
Vendor: Acme Inc.
Undo toast
A confirmation toast with a countdown bar appears after a destructive action. Clicking Undo reverses the action; running out the bar finalizes it.
Vendor: Acme Inc.
Relationship to Motion
Microinteractions ride on the Motion foundation. Three things are shared by reference.
- Tokens. Every demo on this page uses
--motion-duration-*and--motion-easing-*tokens from Motion. No raw durations. No custom cubic-beziers. - Reduced motion. Every demo respects
prefers-reduced-motion: reduceby collapsing the transform-based animations to a state change. The user still gets feedback; they do not get the motion. - Vocabulary. When a demo description says “spring easing,” it means
--motion-easing-springfrom Motion. The Motion page documents the values; this page applies them.
See Motion for the vocabulary. Come back here for the application.
Anti-patterns to avoid
- Autoplaying decoration. Animation on page load with no user trigger. Decoration looks alive on the design mock and exhausting in real use.
- Attention-stealing animation. Anything that draws the eye away from where the user is working. Reserved for genuine alerts, never for marketing-style “look at this” moments inside the product.
- Motion-as-brand-flourish. A “JMF-branded” easing curve applied everywhere because it feels distinctive. Distinctive motion is system-wide, not per-component theatrics.
- Long durations on common actions. A button that takes 600ms to depress feels broken, not delightful. Common actions stay at
--motion-duration-fast(100ms) unless there is a specific reason. - Motion that does not survive reduced-motion. Any microinteraction the page hides under
prefers-reduced-motion: reduceinstead of degrading gracefully. Reduced motion is not “no feedback,” it is “no movement.”
Related anti-patterns
Catalog entries that describe specific motion failures. Each links to the full entry with wrong and right examples.
- highAnimations that ignore prefers-reduced-motionJavaScript-driven animations that don't check the user's reduced-motion preference will fire for users who have explicitly asked their device to hold the motion.
- highHardcoded duration and easing in component codeWriting `transition: opacity 250ms ease-in-out` instead of using motion tokens bypasses the system and creates animations that visually disagree across the product.
- mediumStaggering animations across too many elementsStaggering 20+ list items 50ms apart creates a slow cascade the user has to wait through before they can interact with the page.