Open a new window only when leaving the current flow
Aliases: new window for side paths · in-place default · keep the flow in place
What it is
The legitimate reason for a new window is not “this link is important, they might get lost.” It is this task is unfinished, and the hop being clicked is not part of it. A form in progress that needs a help article, a terms page, or a ticket in another system will lose its unfinished frame if the jump happens in place; that is when another context is worth considering, freezing the main flow in the original window. Next steps inside the flow, list-to-detail, neighbouring wizard steps, all move in place—they are the next frame of this task.
Why it happens
People track one task chain at a time. An in-chain jump that opens another window splits attention onto a new context; “what’s next” becomes switching between two windows, and working memory must hold two places. Off-chain reference is the opposite: open it in place and the main flow’s form, validation, and scroll are torn down; after the reference is read the main flow may already be gone. New window versus in-place asks whether this hop is a continuation of the task or a side branch.
Typical side branches are help, legal text, an external ticket system, a calculator or calendar used as a reference. They are meant to be dropped after reading, with the main flow still there. Open the side branch in place and the main flow becomes the previous frame on history; Back can return, but uncommitted input, file picks, and payment sessions are often already dead. Open an in-chain next step in a new window and the main flow is frozen while the person believes they are going forward; Back no longer means “previous step.” The test is an edge on the task graph: edges on the main path go in place; edges that leave the main path may fork.
Studying it
Give the same checkout two kinds of link: terms, and “Next.” Compare all-new-window, all-in-place, and “only terms in a new window.”
- Dependent variables: whether the form still exists, misuse of Back, time to finish the main task, whether filling continues after the side branch.
- Independent variables: which class of link opens new, whether the form has uncommitted values, whether the side branch is in-site help or another site.
- Methodological note: a short flow with no uncommitted state makes “all in place” look harmless, because nothing can be lost. Click the side branch with the form half-filled. Do not replace task completion with an attitude item about “preferring new tabs”—that measures habit, not which edges should fork.
Where it stops holding
Footnotes in a long article are side branches of a reading task, yet many readers want in-place jump and Back, because the reading history is the task. Forcing a new window cuts the reading chain. Preview in an editor can be a split view rather than a new window; forking is not the only tool. An in-page drawer keeps the main flow without a second history and should beat a new window. When the user has already asked the OS for a new tab, honour that fork; do not re-judge “in flow or not.”
Applying it
- Draw the main path of the current task. Links on that path (next, detail, neighbouring wizard steps) must not use
target="_blank". - Consider a new window or a drawer only for clear side branches—help, terms, an external system used as reference. If an in-page drawer can leave the main frame intact, do not open new.
- When a side branch does open new, keep uncommitted state in the main window; do not submit or reset on the jump.
- Verify: from a half-filled form, tap “Terms” and tap “Next.” Terms may use a new context or a drawer, and the form must still be there. Next must become the next frame in the current window, with Back returning to this step. If both taps open the same way, the choice is not yet keyed to the task edge.