A retry control must be reachable where the failure is
Aliases: retry in place · nearby retry · failure-local action
What it is
Once failure is on screen, the next act is almost always “ask for the same thing again”. The retry control must appear where the failure is seen: on this card, in this list’s gap, on this image’s slot — not only at the top of the page, in settings, or behind a pull-to-refresh gesture people have to reinvent. Nearby is about finding and reaching. It is not about backoff, how many tries, or whether parameters may change — that is the retry-strategy group.
Why it happens
Failure pins attention on the piece that broke. If the next act first requires leaving that piece to hunt a button, attention and working memory both move house: which query was that, which filters, how far had I scrolled — easy to drop in the move. Nearby attaches “ask again” to the failure’s own meaning, so context need not be rebuilt. If the only entry is a global one (pull the whole page), a local failure is forced up into a full refresh, successful chunks are redone with it, and scope is kidnapped by where the control sits.
Reachable also means: the person waiting on the failure may already have pointer or focus on this piece. The control must enter tab order, the accessibility tree, and this piece’s hit target — not live only as an unclickable illustration. “Reload” buried in a second-level menu does not exist for someone looking at a hole.
Where it stops holding
Failures that cannot succeed without changing parameters (bad query syntax, unsupported file format) should have a nearby “change then try”, not another doomed identical request — whether parameters may change is a strategy leaf; this leaf only requires that the change controls sit beside the failure, not on another settings page. A fatal whole-page failure’s nearby is the page-level primary button; do not clone it onto every ghost module. While an automatic retry is in flight the nearby control may become “retrying” to avoid a double fire; when automatic retry stops, the control must return. A permission failure’s nearby action may be “request access” rather than “retry”; still nearby, different verb.
Applying it
- Put a retry (or equivalent primary action) for that scope next to every visible failure. Do not rely on page-level pull alone.
- The control must be clickable, keyboard-reachable and announced, in the same visual group as the failure copy.
- Local failures get local buttons. Do not remove them because a global refresh exists.
- How to check: fail the rail, leave the main column successful. Without scrolling to the top or opening a menu, can you retry on the rail’s hole. If not, it is not nearby. Then Tab-only: can focus land on that action.