The notice must show what the action did

What it is

After someone acts on a card, the result must write back onto that card: "archived," a short confirmation, or a clear "it did not send." If the card looks as it did before the tap, people cannot tell whether the command was received. What follows is either a second tap or an app launch to check—the switch the shortcut was meant to save.

This is acknowledgement after the action. It does not decide which actions belong on a notice, and not whether destructive ones should be there.

Why it happens

The shade is not an in-app object view. The only surface still in play is this card. Feedback has to land on it, or state updates elsewhere while the eyes stay in the shade. The network is asynchronous: there is a seam between tap and server confirm. With no in-progress mark in that seam, the tap is read as missed. With no error on the far side of a failure, the tap is read as done.

Feedback also has to survive a glance. Instant disappearance is read as a swipe, not a completion. Change the copy or show a brief confirm, then remove; closure has to be perceptible.

Studying it

Have people act on a card under different feedback: no change, instant vanish, in-progress then success/fail, a success line that lingers. Ask what the state is now, and watch duplicate submits and check-opens of the app.

Independent variables: feedback form, latency, whether failure is retryable. Dependent variables: correctness of state judgment, repeat taps, unnecessary app opens, false-done rate.

Lab networks are fast and will not show "I tapped and nothing happened." Insert delay and failure. Task time alone is a poor metric—people can tap quickly and still have no idea what happened.

Where it stops holding

Some desktops withdraw the card the instant the action succeeds; feedback must appear before withdrawal, or a replacement card must take its place. Assistive tech must be able to read the new state; color alone is not enough. Acting on one member of a bundle should feed back on that member, not flash the whole card. Offline queues must distinguish "queued" from "done"; both are legitimate feedback, and mixing them produces reconciliation errors.

Applying it

• Enter in-progress on tap and block a second fire of the same action while there is no feedback.
• On success, rewrite the card as the result (replied, archived) and leave it long enough for a glance or a short timeout before removal.
• On failure, keep the original card, name the reason and the next step (retry, open app), and do not silently revert to untouched.
• Verify by slowing the network and failing once. People should be able to say "sending" and "did not send." If the card looks never-tapped, or they open the app to check, feedback did not land on the notice.

Related

• Within the group: H5.06.1 Acting on the notice should skip launching the app · H5.06.3 Destructive actions do not belong on a notice
• Adjacent: H5.04 Notification bundling · H1.16 Post-submit result presentation · H3.10 Retry strategy
• Search terms: action acknowledgement · in-shade feedback · optimistic notification action