Touch interactions

The tablet can display a question over a dimmed screen. We ship a five-star rating that appears after a conversation ends. This entire feature is a single file — apps/tablet/src/prompts.ts — that a partner edits, forks or deletes. A prompt is a name plus three answers: when it opens, how long it stays, and what it draws.

Nothing about it touches the plugin, the wire format or the library, so replacing the rating with a form, a poster, a video or a 3D viewer takes just one file in your own app — the full detail is in the Touch documentation. The answer returns as an ordinary command, so a graph can use it or ignore it. README.md has the details, including the one line of Blueprint that arms it and where to put your own analytics call.

Both rules come from real installations. Both seem harmless until they bite.

A finger that slides sends nothing. Move a fingertip two millimetres while it is down, and the browser reclassifies the gesture as a pan: it fires pointercancel and dispatches neither pointerup nor click. A button listening for click draws its ripple but does absolutely nothing — no command on the wire, nothing in the host’s log — because from the host’s side, the press never happened. Every control in the sample uses onTap() from gestures.ts, which activates when the finger lands for touch and keeps the click for a mouse. Our <pk-button> does this internally.

An element that hides itself on pointerdown presses whatever is behind it. It destroys its own hit-testability mid-gesture, so the browser’s compatibility click goes to the element underneath — meaning your visitor dismisses an overlay and starts a conversation with one tap. Dismiss on click instead, with pointercancel as the other half.