Signature gesture utility

Name the one gesture the product is organized around, show it working in the first screen, then unfold the catalogue of actions it reaches.

Section sequence

6sections, in the order the visitor meets them. Bar height is the section's weight in the page.

  1. OrientGesture name
  2. DemonstrateGesture in motion
  3. NavigateAction catalogue
  4. ProvePlatform availability
  5. ProveMaker proof
  6. ConvertInstall

How the page argues

  1. 1

    Name the gesture, so the visitor has a handle for what they are about to see.

  2. 2

    Show it happening at real speed, without narration.

  3. 3

    Immediately show the breadth it reaches: the catalogue of actions behind one motion.

  4. 4

    Confirm platform availability before the visitor invests curiosity.

  5. 5

    Let makers and extension authors vouch for the ecosystem.

  6. 6

    Make install the only primary action on the page.

What each section has to be

OrientGesture name
The keystroke or motion, named and shown as a key cap or glyph, so it becomes repeatable language.
DemonstrateGesture in motion
A loop at real speed showing invoke, type, act. No narration, no cursor tour.
NavigateAction catalogue
What the gesture reaches, grouped by job, with enough items to imply depth.
ProvePlatform availability
Operating systems, versions and requirements, stated before the download button.
ProveMaker proof
Extension authors, command counts or named power users — proof that the catalogue keeps growing.
ConvertInstall
One dominant install action, repeated at the end, with the platform preselected.

Is this the right sequence?

Who it is for

Power users choosing a daily-driver utility, who care about speed of the core motion more than feature breadth.

Products it suits

Launchers, command palettes, editors and utilities whose value is concentrated in one memorable motion.

Not for

Multi-step workflow products with diffuse value, where a single gesture would be a party trick.

Evidence strategy

Which proof modes carry the page, in the order they land.

  1. Primary: the gesture itself, shown at the speed it will actually be used.
  2. Secondary: catalogue breadth, which turns a trick into a habit.
  3. Tertiary: maker and platform proof, which says the habit will survive.

CTA plan

What the page asks for, what it offers instead, and where.

Primary
Install for the detected platform
Secondary
Browse the action catalogue, or read the extension API
Placement
Install in the header and repeated after the catalogue; nothing competes with it above the fold.

Responsive behavior

What the sequence has to do when the viewport stops cooperating.

  • The motion loop becomes a shorter, lighter clip on mobile, with a static first frame as the poster.
  • Key-cap glyphs remain legible at small sizes; never render the gesture as body text only.
  • On mobile, install detects the desktop platform and offers a send-to-desktop link instead of failing.

Anti-patterns

The failure modes that make this sequence stop working.

  • Describing the gesture in prose without showing it.
  • A catalogue of three items, which reveals the ecosystem is not there yet.
  • A download button that fails silently on an unsupported platform.
  • Competing CTAs above the fold that dilute the single install action.

Build spec

Pro

What an agent needs in order to build Signature gesture utility: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.

Checking access to the build spec

Agent tags

The vocabulary an agent matches this recipe on.

  • signature-gesture
  • motion-proof
  • action-catalogue
  • platform-availability
  • install-cta