Switching scope should keep the query string
Aliases: keep query on scope change · re-run in new scope
What it is
People are changing the collection boundary, not the description of the need. Moving from “this section” to “entire site,” or from “this mail folder” to “all mail,” should keep the query string and re-run it in the new scope. Clearing the box forces that newly constructed sentence to be typed again, and turns a scope correction into a fresh query formulation.
What persists is the string, not the previous scope’s filters, sort, or scroll. Those states are bound to the old collection and will lie if they travel; the query describes the need and can follow.
Why it happens
Scope switches usually follow disappointing results: too few, wrong, or a known object missing. The query is still alive in working memory; attention has already turned to “wrong place?” If the switch empties the box, regenerating the sentence competes with disappointment for resources. People substitute a shorter, vaguer string, or they quit. Query logs often show near-identical strings in different scopes a few seconds apart in one session—that is this correction, not two independent lookups.
From the engineering side, scope is a modifier on the query. Changing the modifier should keep the head. Resetting the whole request object treats “change of field” as “start a new match.”
Studying it
Treat a scope switch as a kind of query reformulation, not as a navigation jump.
- Paradigms: a known target lives outside the current scope; a scope switch is available; compare whether the box still holds the original string and whether it re-runs. Logs can score edit distance and emptiness of the query around switch events.
- Independent variables: whether the query survives the switch, whether it auto-submits, whether filters travel with it.
- Dependent variables: keystrokes after the switch, rate of shortening the query, task completion, immediate abandonment after the switch.
- Methodological note: if the target actually sits in the current scope, people will not switch, and persistence cannot be measured. Place the object outside the scope. Auto-submit versus keep-without-submit are different designs; score time-to-complete and false triggering separately.
Where it stops holding
When the query contains terms bound to the old scope (internal codes for a section, tags that exist only in that folder), the original string may retrieve noise or zeros in the new one. Persistence should still happen, with a note that the sentence was written for the previous scope. Switching from full-text search into “find on this page” (in-page highlight) can make a long query an illegal in-page pattern; after keeping it, say that the match rule changed. An empty query has no string to keep; only the scope state should update.
Applying it
- When the scope control changes, leave the string in the box. If the product logic is “search now,” re-run that string in the new scope.
- Do not carry the old scope’s filter chips unless those filters are still defined on the new collection.
- After a re-run that yields zero, keep the original string and offer a path back to the previous scope, so people do not think the query was lost.
- Verify by searching, in a local scope, a term deliberately absent there, then switching to global. The box should still hold that term, and results should recompute globally. An emptied box, or a freeze on the old results, means the switch did not keep the query.