Long work needs a task list as a first-class surface
Aliases: job list · task center · export list
What it is
If the product lets work be thrown to the background, it owes a task list: running, finished, failed, laid out per item, tappable. The list is a component, not a pile of progress bars. People will throw several at once (three exports, one transcode, one backup). Without a list, query and notification have nowhere to land — a notice can only return home, progress can only return to the page of the moment, and that page may already be gone.
This leaf makes the list a required surface for long work. Whether items can be reordered, cancelled, or show power draw is scheduling. Here it is enough to admit: without this surface, long work is structurally incomplete in the interface.
Why it happens
A background task is an object: identity, lifetime, terminal state. Objects need a container. A page-level bar parasites the object onto “the page we happened to be on”; leave the page and the parasite dies. A notice compresses the object into a sentence; tapping the sentence needs a stable destination. The list is that destination, and the index when several objects coexist. Without an index, a second task started before the first ends leaves the person with no handle on the first.
Long work also crosses sessions. The next day the question is not “the bar on this page” but “how are yesterday’s items”. The grammar of that question is a list: per item, by time, filterable by state. Implementing the question as scattered toast history or as searchable mail is not a first-class task object.
Where it stops holding
If the whole product ever has only one job and the person is pinned to that screen until the end (an install wizard, a single system update), the list may collapse into that screen. The moment leaving is allowed, or a second job in parallel, the collapse fails. Extremely short background (a three-second image send) may notify without a long-lived list, but if failure must be found later it should still sit in a short-lived list for a few minutes. When permission does not allow seeing others’ jobs, the list filters by identity; it does not cancel the list. Embedded devices with no “pages” can make the list a flippable status slot; the structure is still several addressable items.
Applying it
- Provide one globally reachable task surface: in-flight and recent terminals together, each item openable.
- Progress queries and completion notices both land on the same item’s detail, not two mutually unrecognising records.
- The list can open at zero items and say “nothing in progress”, so the door itself is not intermittent.
- How to check: start two exports in a row, leave the original page. Opening the task door should show both, not only the later one or none. Tapping a notice should enter that item in the list. A cold start the next day should still find the finished item, until the user clears it or retention expires.