Nonblocking Work Needs a Visible Home
Nonblocking work needs a visible home
Making slow work nonblocking is only half the fix. The other half is giving the result somewhere obvious to live.
If the user asks for a thing, or the product starts it because the user is likely to need it, the interface owes them a visible state: queued, running, ready, failed, stale, or unavailable. Otherwise the system can be technically healthy and still feel like nothing happened.
The rule
Background work that produces user-facing value needs a home in the user's current workflow.
A toast is not always enough. Toasts disappear. A modal may be too heavy. The best home is often the place where the result changes the user's next action: above the email body, beside the draft, inside the queue row, next to the command output.
Design shape
- Keep the hot path responsive.
- Show a small persistent loading state where the result will appear.
- Render cached results in the same place as fresh results.
- Let manual refresh reuse the same result surface.
- Ignore stale completions when the user has moved on.
- Put failures in the result surface, not only in logs.
This is the product half of Hot Path vs Warm Path. That note says warm work must not slow the current action. This note says warm work must still become visible when it matters.
Mxr example
In Mxr, thread summaries were a good stress test. The web app already had an AI overview collapsible at the top of a thread, but the TUI had no obvious place to see the summary. Pressing y could be nonblocking and still feel broken if the result had nowhere to land.
The better shape: y starts the summary in the background; opening an uncached long thread may start a debounced background summary; cached summaries come back with GetThread; the reader renders one Summary block above the message/thread body for loading, ready, and error states.
That makes the concurrency fix legible to the user. The app stays responsive, and the result appears where the user is already reading.
Worth Your Time example
The mobile checker in Worth Your Time does not hide AI work behind a toast or replace the screen with a generic spinner. It keeps the selected film in the result card and moves through reading, taste matching, and verdict-writing states. The result replaces that same card when ready, and failures stay in the flow.
Reduced-motion settings remove the decorative movement without removing status. That separation matters: progress is product information, while shimmer and motion are presentation.
Linganisa example
Linganisa carries try-on progress in Convex and Inngest workflow state. The
Expo client renders the backend phase, label, detail, and numeric progress in the
generation surface, then replaces that state with the result. It no longer uses
random rotating copy to imply activity.
That sharpened the rule: a visible home is not enough if the state shown there
is fictional. The home and its contents need the same source of truth. See
Crafted interfaces make system state legible.