Without an explicit return stack, nested tasks lose their way back

What it is

Picking an address then searching the map then granting location—each layer is an unfinished task. Nesting needs an explicit return stack: each layer remembers its caller, and on close pops only itself, handing a result to the layer above, rather than demolishing the whole tower to home. It is not a substitute for browser history. It is a back stack the product keeps on the task graph, describing who is waiting for whose return value.

Why it happens

One subtask can still be held by a single “original slot” anchor. Past two layers, the anchor itself is waiting: the map waits on search, the form waits on the map. A single “return to main flow” pointer skips the middle; the point chosen in search has nowhere to land, or is written straight into the outermost form, dropping the map’s intermediate state. What people see is “I was searching, one tap filled the order”—hierarchy collapsed.

Browser history is ordered by when things opened, not by which task called which. Opening search from the map yields form → map → search in history; but cancel in search should return to the map, not the form, and done in search should hand the point to the map, not the form. If the two stacks are welded, system Back pops by time and task Back pops by call, and the destinations disagree. An explicit task stack labels each frame {caller, slot, expected result} and pops only when that layer closes. Deeper than two layers with no stack drawn, people mash system Back until one of the taps also pops the main flow.

Studying it

Build at least three layers: parent form → picker → search or permission inside the picker. Complete or cancel at the innermost layer. Record what each layer received and which layer people thought they were on.

• Independent variables: whether an independent task stack is kept, whether system Back aligns with it, whether the middle layer is skipped or preserved.
• Dependent variables: which layer the result lands on, inner results written to the outermost by mistake, whether repeated Back tears down the parent form.
• Methodological note: two layers cannot show collapse; the middle layer must consume the inner result. Do not say “return to the form” in the brief; say “finish the thing you are doing,” or participants will skip layers on purpose. Score Android’s activity back stack and browser history separately; do not assume they already agree.

Where it stops holding

A product that never nests more than one subtask does not need a separate task stack; one return anchor is enough. Deep recursion through folders is browsing hierarchy, not “calls with return values,” and should Up by level rather than pop a call stack. Two parallel subtasks (two windows, each filling its own) are not nested and must not be pushed on the same stack.

Applying it

• Keep an explicit stack for nested subtasks. Each layer records caller, the slot waiting to be filled, and the expected result type. Closing a layer pops only that layer.
• While a subtask is open, system Back pops the top of the task stack, not an earlier frame that may sit in browser history. The main flow is at the bottom; do not tear it down before the stack is empty.
• The middle layer must get a chance to consume the inner result (the map accepts the search point, then hands it to the form). The inner layer must not write the outermost field directly.
• Verify: form → map → search, pick a point in search. The map should show that point and allow confirm; only then does the form slot get a value. Cancel in search returns to the map, not the form. Repeated system Back from search should walk search → map → form, never exit the form from search in one hop.

Related

• Within the group: G4.06.1 After a detour into a subtask, land back in the same slot · G4.06.2 A subtask’s result must be brought back into the main flow
• Adjacent: G4.01 Back stack and back semantics · G2.01 Hierarchical navigation · H1.01 Form length and stepping
• Search terms: nested back stack · task stack · call and return