Global and local search need distinct entry points
Aliases: site search versus find in page · search entry points
What it is
Global search looks for objects not yet open; local search looks inside an already open object for a span of text, a row, a control. Their entries have to be separable in placement, appearance, and shortcut—the top-bar magnifier, in-document “find on this page,” in-table “filter this column” cannot share one unlabeled box. When entries merge, people run in-page highlight with global expectations, or treat a zero on this page as “not in the library.”
Distinct entries are not a choice of default scope, and not a dropdown that switches scope inside one box. The question is whether two wholly different lookup acts are still pretending to be one control.
Why it happens
Global search returns a new list. Local search returns a highlight or a scroll on the current place. The feedback channels differ, and so do the meanings of failure: global zero says “not in the collection”; local zero says “not in this article.” A shared entry writes both failures as the same “not found,” and the next move is then the wrong one—broadening a corpus query, or paging to the next document, when the other act was required.
Habits compete for the entry as well. Browsers trained Ctrl-F / Cmd-F as in-page find; many sites bind / or the same chord to a global box. Shortcut collision is entry collision in miniature: the hand has already pressed before the layer is the one that was assumed.
Studying it
Compare “one box for both lookups” with “two entries” when task type switches.
- Paradigms: two task classes in one product—find an object not yet open, and locate a sentence in an open document; interface conditions of a shared box, two side-by-side entries, or swapped shortcuts. Record which layer the first action hits.
- Independent variables: spatial separation of entries, icon and label contrast, whether shortcuts collide with platform in-page find.
- Dependent variables: match rate between task type and entry chosen, times a no-match on the page is reported as “not in the library,” recovery time after a shortcut misfire.
- Methodological note: measuring only global tasks makes a shared box look sufficient. Interleave both classes in one session or the misremembered entry will not show. Mobile has no Ctrl-F; use discoverability of in-page find as the local-entry metric instead.
Where it stops holding
A tool with no openable object, only one list, collapses local find into list filtering—often the same act on the same collection—and a second entry is duplication. Command palettes that prefix “go to file” versus “symbol in current file” are a grammar for experts, not mixed entries; occasional users still go wrong with no prefix. Embedded widgets (search the map versus search labels in the current view) that sit visually together need distinct verbs, not placement alone.
Applying it
- Put global search in application chrome (top bar, a stable magnifier). Put in-page or current-view find in the content area or on the platform-standard shortcut. Write different verbs (“Search,” “Find on this page”).
- Do not let one unlabeled box bind to global on some pages and local on others. A control that shapeshifts by page cannot be learned.
- Follow the platform on shortcuts: in-page find stays the system find; global search uses a product chord that does not steal it.
- Verify by running, in one session, “find a document that is not open” and then “find a sentence in the open document.” Watch whether the first key or click hits the matching entry. If a miss is still narrated as “search can’t find it,” the entries are still one thing semantically.