Incoming Call
A call screen where answering costs a deliberate slide and declining costs a tap, because only one of the two can be taken back.
Sam
incoming · acme voice
Build an incoming call screen. Structure: a dark card with a pulsing avatar, a name, a state line, a slide-to-answer track, and a decline button. The decision that shapes everything: ANSWERING IS A SLIDE, DECLINING IS A TAP. Answering cannot be undone and usually happens with a phone against a face, so the irreversible action gets the gesture a pocket cannot perform. Reversing this - two identical adjacent buttons - is exactly how people answer calls they meant to reject. The pulse: render TWO expanding rings behind the avatar, animating scale 1 -> 1.75 and opacity 0.45 -> 0 over ~1.6s on an infinite loop, with the second delayed by half the cycle. The offset is what removes the dead beat where the avatar sits still and the call looks like it ended. The pulse belongs to the RINGING state only - it must be gone the instant the call connects or is declined, or the screen says the decision did not register. The slide: pointer events with the listeners on the window, a handle that tracks the finger exactly (transitions disabled while held, restored on release so a partial slide snaps back with weight), and a commit threshold around 70% of the track. touchAction: "none" on the handle. Place the two actions far apart, in green and red, on separate rows. Accessibility: the state line ("incoming" / "connected" / "declined") is aria-live="polite", so the outcome does not depend on a button colour. The handle has its own aria-label. Under prefers-reduced-motion, drop the pulse; both controls behave identically. Colors as tokens: ink card, one accent for the avatar, semantic green for accept and red for decline. Use a placeholder name. Build the component, not this demo of it. - Ambient motion that IS the component may loop: a drifting background, a marquee, a spinner while something is genuinely loading. - Do not add any timer, interval, loop or script that performs a person's action by itself. No auto-hover, no auto-click, no cycling through states, no pretend submitting, no replaying the interaction on a schedule. - Every state that answers a person waits for a real event from that person. - Placeholder copy and sample content are welcome. Simulated behaviour is not.