Search must say whether it covers title, body, or metadata

What it is

Searching one’s own library, a query hits different fields: title, body, comments, tags, attachment names, custom properties. People have to know which fields this box covers, or they think “full text” while only titles are indexed, or think “filename” while comments are searched too. This is which layer this locate act hits. Site-level global versus local search, the saved-list entry, and whether the archive is in the results are neighboring issues. Other reasons for empty results, and telling near-duplicates apart, are written elsewhere.

Why it happens

A query matches a field set. If the set is unstated, people interpret failure with the widest model: not found means it does not exist, while the word sits in the body and the box only searched titles. The other way: a hit in a casual comment is taken as a body mention, and the open document does not contain the word. Writing the range in or under the box (“title and body,” “includes comments”) and marking the hit field on the result row lets the estimate be checked. Switching range should change results at once, not look like the same box. A silent default of title-only gets worse as the library grows. Attachments and OCR included on the sly also pull watermark words from scans into results, and the range looks like magic.

Studying it

Place the target word only in the body, only in comments, only in an attachment name. Ask people to retrieve it with the same box. Compare unlabeled fields, a stated title default, and a switch that marks the hit field on the row.

Independent variables: default coverage, whether it can be switched, whether the row names the hit field. Dependent variables: “does not exist” when the word is present, opens that reveal the hit was not in the expected field.

A lab that writes the fields in the brief is not measuring the UI. Use the product’s own placeholder. Do not fold spelling correction into the same miss.

Where it stops holding

A minimal list that can only search titles can freeze the range in the placeholder, with no switch. Encrypted bodies cannot be searched server-side; say “title and metadata only; body is not indexed,” not fake full text. If org policy forbids searching comments, drop comments from the range rather than 403 after a hit. Analyzers may treat title and body differently across languages; marking the hit field matters more.

Applying it

• State default coverage on the box. Offer a switch: title / title+body / include comments and tags.
• Each row names the hit field; the snippet highlights the actual matching span.
• Attachments, OCR, and custom properties, if included, are an opt-out layer, not a silent “full text.”
• Verify: bury the word only in the body. If the default claims full text and misses, or never claimed full text yet people conclude the object is gone, the range was not stated. Opening a hit, the highlight must sit in the named field.

Related

• Within the group: H8.13.2 Recents and frequents are a path besides search · H8.13.3 Empty results need causes other than a narrow query · H8.13.4 Near-duplicate names need extra cues to tell them apart
• Adjacent: G3.12 Search Scope · G3.16 Search Scope and Coverage · H8.10 Marks, Tags, and Classification
• Search terms: search field coverage · title versus body · content search