Long tasks need visible progress rather than silent execution

What it is

Observable robot task progress shows that a long task has started, which meaningful stage is active, and whether work continues. Progress need not be a percentage; for search, navigation, and multi-step manipulation, current stage, completed milestones, and next event are often more truthful.

Why it happens

Internal computation can produce no visible change, making processing, resource waiting, deadlock, and disconnection look alike. People check or repeat commands, potentially creating conflicting work. Verified milestones externalise evidence of progress and support resuming attention later.

Studying it

No feedback, activity, stage, percentage, and event history can be compared on repeated action, checking, wait estimates, context resumption, and workload. Duration must vary; fixed animation exaggerates prediction. Displayed and logged progress error should be measured.

Where it stops holding

An animation proves display activity, not task advancement, and unknown search spaces do not support honest percentages. Progress does not replace safety monitoring. Bystanders need coarse state while operators may need detailed stages and blockers.

Applying it

• Use stages or milestones tied to real completion criteria, not timed animation.
• After attention returns, show completed, current, next, and last-update time.
• Under variable duration, disconnect, and retry, compare display with logs and count repeated commands, checking, and stale state.

Related

• Same group: X3.05.2 Remaining-time estimates support waiting decisions better than completion percentage alone · X3.05.3 Stalled progress should explain why rather than resemble failure · X3.05.4 Progress precision must match task predictability; false precision misleads
• Adjacent: X3.01 Visible current state · X4.03 Supervisory control
• Search terms: progress visibility · task milestone · automation monitoring