E4.12.1popover anchoring to triggerdesignresearch

A popover must be anchored to the control that opened it

Aliases: anchored popover · trigger-aligned layer · floating UI anchor

What it is

A popover is a small layer summoned by a control, and its content belongs to that control. Anchoring to the trigger means the layer’s position is computed from that control: flush to one of its edges, with an arrow or an alignment edge stating “this menu, this date, these actions are this button’s.” A layer centred on the screen is a dialog, not a popover. Anchoring answers who the layer belongs to. It is not how the layer flips at an edge, and not whether it covers the trigger.

Why it happens

People read ownership of a temporary layer from space. If the layer appears against the button just pressed, ownership is almost automatic: this is the continuation of that action. If it appears in the screen centre, or at the coordinates of the last popover, ownership has to be recovered by reading a title, and a vague title sends the action to the wrong object — especially in a row of identical icons, where the layer could serve any of them. Anchoring also clarifies close range: pressing another trigger should close this layer and open that one, because ownership moved. The anchor is the trigger’s border box; the layer aligns to a chosen edge. If the trigger moves during scroll, the layer must move with it, or ownership breaks on the first scrolled frame. Anchoring is not a decorative arrow. An arrow can strengthen the claim; what does the work is adjacency between layer and trigger.

Studying it

Open a popover from a row of identical buttons, comparing flush-to-trigger, centred, and parked at last-time coordinates. Ask “which control does this layer serve” and have people act on the intended object. Independent variables: whether the anchor follows, spacing between buttons, presence of an arrow. Dependent variables: ownership errors, corrections after opening the wrong button. In a scroll container, test whether the layer stays on the trigger. Ownership errors should be reliably higher when centred than when anchored.

Where it stops holding

A popover with no single control (a right-click on empty canvas) still has a spatial origin — the pointer — even if that origin is not a widget. Keyboard invocation should still anchor to the focused control, not to the pointer. If the trigger is outside the viewport, anchoring would place the layer out of sight too; scroll the trigger in first rather than centre the layer. A “popover” large enough to fill the screen has already lost the point of anchoring and should become a dialog or a panel.

Applying it

  • Compute the layer from the trigger’s rectangle and align to a named edge; update on scroll.
  • Anchor each trigger in a row on its own; do not reuse one global popover coordinate.
  • Declare ownership with adjacency and an optional arrow; do not make the title the only ownership cue.
  • How to check: open the layer from a row of icons and ask which icon it belongs to. A wrong point means it is not anchored.

Related

  • Within the group: E4.12.2 Flip the popover when it would hit the viewport edge · E4.12.3 A popover must not cover the control that opened it
  • Adjacent: E4.10 Modal dialogs · E4.13 Tooltips · E5.12 Menus and submenus
  • Search terms: anchored popover · trigger alignment · floating UI

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E4.12.1