Relevance ranking and recency ranking must be switchable
Aliases: newest versus relevant · ranking mode switch · date sort
What it is
“Most like what I asked” and “most recently happened” are ranking questions that cannot substitute for each other. Relevance and recency ranking must be switchable means the same result set has to let the user change roads between those two criteria, rather than a permanent “combined” score deciding for them. For news, tickets, logs, and mail, time is often the answer; for policies, products, and encyclopedias, relevance is. Tasks also change mid-session—find the topic by relevance, then switch to time for the latest instance—so both criteria must exist as selectable states at once.
This is about reaching two ranking philosophies, not whether the sort dropdown looks clear or whether the default is ever changed. How the control is shown is another layer; without two switchable criteria, a clear control has nothing to switch.
Why it happens
Relevance ranking optimizes match between query and document; recency ranking optimizes position on a timeline. Folding time into a relevance score (“a bit newer, a bit more points”) produces an irrefutable mixture: a slightly old, fully on-topic document is buried by a very new, barely related one, and the user cannot tell whether to blame matching or freshness. The mixture also cannot be turned off—when they want only time, relevance still pulls; when they want only relevance, time still pushes.
Switching splits the mixture. People can pick a dimension for the current question: newest logs to debug, most on-topic samples to write from. Bates’s berrypicking path changes not only words but also “what to look by.” If time is unreachable, new events sit deep in a relevance list; if relevance is unreachable, old authoritative documents are crowded out by fresh noise. Both failures look like “search is inaccurate”; the root is a locked dimension.
Studying it
Use tasks whose answer moves with time, and tasks whose answer is stable, and measure the loss of locking one dimension.
- Paradigms: news or ticket tasks (target is the latest instance) versus policy or encyclopedia tasks (target is the most on-topic); switching allowed versus a combined score only; in query logs, the rate of switching to a time order and the successful click after. Hearst treats sort options as a standard search-UI control.
- Independent variables: whether pure relevance and pure time are offered, which is default, whether a combined score remains as a third item.
- Dependent variables: match between task type and chosen criterion, time lost on the wrong dimension, whether the user knows the other dimension exists.
- Methodological note: if lab timestamps are all similar, time order has no discriminative power and demand cannot be measured. Use a collection with enough span. Low switch rates in logs cannot be read as “time is unneeded”—the control may be invisible or not look like time. Separate “switch to time order” from “filter last 7 days”; the latter is filtering, not ranking.
Where it stops holding
Collections without a usable time field (all nulls, mixed created/updated/published meanings) will lie if switched to time; fix the field before shipping a fake switch. Live streams (an ongoing call, a market feed) have time as the only meaningful axis; a relevance switch has no object. Strong known items (exact titles, IDs) land near the top under either ranking, so the observable gain of switching is small. Time zones and DST can make the visual “newest” disagree with the user’s “just now”; that is a time-semantics problem and cannot be papered over by switching back to relevance.
Applying it
- For collections that have both text and real timestamps, offer two pure options: by relevance, by time (and say whether that is published, updated, or occurred).
- Do not replace the switch with an unsplittable “combined”; if combined remains, it must still be leavable.
- A switch may only change order—not drop the query or selected filters—or people will not redo the whole search just to see time.
- Verify with one very new but off-topic target and one very on-topic but older target: can the two criteria each lift their target into a findable position. If a combined score leaves both too low and cannot be left, the dimension is locked.