Inline feedback puts the result next to the trigger

What it is

Inline feedback draws an action’s result beside the control, row, or card that triggered it: “Saved” in the row, a check on the button, a failure mark on the list item. It says “what became of the object you just touched,” not field validation, and not an application-level situation. The result should land where gaze already is, so cause and effect can be read without hunting a global slot.

Why it happens

Action and result have to meet in space for attribution to hold. Someone taps Share on this row with their eyes still on this row; if the result appears in another corner, they must match “is that message the thing I just did.” A failed match produces another tap. Inline turns the match into a state change inside the same region; working memory does not have to ferry the object’s identity across the screen. It also lets several objects speak at once: three rows saving can have three endings, instead of collapsing into one “Saved.” Location is the subject. That is the difference from a floating receipt.

Where it stops holding

When the action changes the whole view (publish, then a published view), the new view is the result; a leftover “Published” beside the old button is optional. If the trigger has scrolled off-screen, the inline result is invisible and the row must be scrolled back, or a short receipt that does not steal the subject can join it. On a narrow phone, “nearby” may have to live inside the button’s own state; another line under the row will shove later rows. Validation errors also appear beside fields, but those are unsatisfied rules, not endings after an action already ran. The two inlines should not share color and sentence shape, or “bad format” and “save failed” get filed as one kind of event.

Applying it

• Name a landing for every trigger: the same button, the same row end, the same card footer. Do not default to the top bar.
• Put object identity in the result copy (this row’s title, this file name) so it remains recognizable if the landing leaves the viewport.
• Success and failure should share the landing; do not go inline on success and global on failure.
• Verify by firing an action that is not on the screen’s midline: does gaze have to leave the object to find the result. If it does, the landing is not nearby.

Related

• Within the group: E6.13.2 Inline presentation keeps the result tied to the object · E6.13.3 Inline feedback must look unlike ordinary content · E6.13.4 Bulk inline feedback must split successes from failures
• Adjacent: E6.03 Inline validation · E6.01 Toasts · E4.05 Inline and bulk actions
• Search terms: inline feedback · in-place result · action receipt