History lowers the cost of typing the same query again
Aliases: search history · re-finding · repeat queries
What it is
The same query gets typed a second and third time. Query reuse stores strings that were already issued—successfully or at least attempted—so the next time is a choice rather than a keystroke sequence. Teevan and colleagues note that a large share of web lookup is re-finding: people are not discovering an unknown object, they are returning to last week’s document, product, or error code. History cuts the motor and recall cost of repeating a query. It does not cut the cost of formulating one for the first time—that is the job of suggestions and examples.
Treating history as “recently opened pages” is too narrow. Page history returns to a place; query history returns to the sentence that described the need. Two different sentences can be required to reach the same place again.
Why it happens
Short queries have low entropy, but pulling last month’s exact string out of declarative memory is still expensive: the synonym used, the qualifier added, the misspelling that was left in place, are all harder to regenerate than “I searched something like this.” History turns generation into recognition—seeing the line is enough to know it was yours. Recognition is faster, and less likely to be swapped for a near-synonym that recalls a different set.
Log studies keep finding that repeat queries are a substantial fraction of all queries. Repeats are not failure; they are a work cycle: watching the same issue, checking the same stock, turning a throwaway lookup into a daily entry. Starting from an empty box every time levies a typing tax on that cycle. People move the query into bookmarks or a scratch file, and the search box loses a re-finding channel it could have carried.
Studying it
Count repeats in query logs; measure saved input on re-finding tasks.
- Paradigms: label identical and lightly edited repeats for the same user in live or lab logs; in the lab, compare empty-box, autocomplete, and a clickable history list as starting points for a re-finding task.
- Independent variables: whether history is clickable, how many items and for how long, whether it syncs by site or account.
- Dependent variables: share of repeats taken from history, keystrokes on re-finding, rewrites into near-synonym new queries, time to a known target.
- Methodological note: log repeats include bots, pagination, and refresh. Deduplicate by session before counting intentional reuse. If the lab target’s title already equals the query string, the study measures copy-paste, not recall cost.
Where it stops holding
One-off, high-privacy queries (symptoms, litigation, salary) cost more as residue than they return as reuse; they should not enter durable history. On a shared device, history becomes someone else’s shortcut—the wrong agent is reusing. Queries that were wrong or have gone stale (event over, item delisted) send people back to dead results; they need a freshness or failure mark, not unconditional savings.
Applying it
- On focus, offer recent queries as clicks, newest first, covering at least “what I searched yesterday.”
- A click should issue the query, not merely fill the box, unless the person is clearly mid-edit.
- Mark obviously stale queries with time or failure so reuse of a dead trail is not silent.
- Verify with a task that must be re-found the next day. Compare keystrokes and time with history present versus cleared. If people still type the whole string, the entry is undiscoverable or the line is missing from the list.