What should users see while a background job is running?
A user uploads a file, starts an export, and closes the tab. The work may still be running, but when they come back, they need to know what happened.
I am building Inquir Compute for apps, databases and background jobs. I am interested in the part users see, beyond whether the job itself succeeds.
There are a few options:
A simple waiting screen.
A task page they can return to.
A notification when the result is ready.
What approach worked for your app when a task took longer than someone wanted to wait?
Especially curious about failures: could users retry safely, or did they need your help?
49 views
Replies
a task page beats a notification for this, because a notification only answers "done or not" and a user who comes back mid-run has a different question: "is this stuck or is it actually working." we hit a version of this at Dial with calls that run long, silence on the user's end reads as broken even when it's not, so showing some signal of progress (even just "still going, last update 30s ago") matters more than the final success state.
on retries specifically, the thing that actually matters is whether the user can tell if retrying starts over or picks up from where it died. for an export that's usually fine either way, but if the job has side effects, charging a card, sending an email, writing to another system, a naive retry can double those up. I'd rather the UI be explicit about it ("retrying will redo this from the start") than leave people guessing and hitting retry five times.
@galdayan The awkward case is when the email was sent but the job lost the confirmation
I would show that the result is being checked before offering another send. How would you explain that uncertain state without making it look like the task is stuck?
@al_kub a separate state label does most of the work - not "in progress," not "failed," something like "confirming delivery" that looks visually distinct from the normal spinner. pair it with a timestamp or a visible action, "last checked 2 min ago" or a manual "check again" button, so the user can tell the system is still doing something instead of reading it as frozen. the failure mode to avoid is showing that uncertain state with the same generic spinner as a normal in-progress job - then it's indistinguishable from actually stuck, which is exactly the confusion you're trying to prevent.
When a job fails, does Inquir Compute keep the original input so the user can retry without uploading the file again??
@marissa__bronfman Inquir supports replay from the stored job payload but that is different from keeping an uploaded file
For a file job I would store the upload first and pass its reference to the job. Retrying without another upload then depends on that file still being available