G3.12.3distinct global and local search entries设计研究
全局与局部搜索的入口需区分
别名: 站内搜索与页内查找 · find in page · 搜索入口
概念解释
全局搜索在集合里找还没打开的对象；局部搜索在已经打开的对象里找一段文字、一条记录、一个控件。两者的入口必须从位置、外观和快捷键上能分开——顶栏的放大镜、文档里的「在此页查找」、表格上的「筛选此列」，不能共用一个无标记的框。入口混用时，人会用全局预期去操作页内高亮，或把本页查找的零命中当成库里没有。
区分入口不是选择默认作用域，也不是在同一框里用下拉切换范围。它问的是：两种完全不同的查找动作，是否还假装是同一个控件。
机制
全局搜索的结果是一份新列表，局部搜索的结果是当前位置上的高亮或滚动。反馈通道不同，失败含义也不同：全局零结果说「集合里没有」；局部零结果说「这篇里没有」。共用入口会把两种失败写成同一种「没找到」，后续动作就会选错——放宽全库查询，或翻到下一页文档，而真正该做的是另一件事。
习惯也在抢入口。浏览器把 Ctrl-F / Cmd-F 训练成页内查找，许多站点又把 / 或同一快捷键绑到全局框。快捷键冲突是入口冲突的快捷版本：手已经按下，才发现搜的不是以为的那一层。
怎么研究
比较「一个框承担两种查找」与「两个入口」在任务类型切换时的错误。
- 范式：同一产品里安排两类任务——找到尚未打开的对象、在已打开文档里定位一句话；界面条件为共用框、并列两个入口、或快捷键对调。记录第一次动作落在哪一层。
- 自变量：入口的空间分离、图标与标签差异、快捷键是否与平台页内查找冲突。
- 因变量：任务类型与入口选择的匹配率、把页内无匹配说成「库里没有」的次数、快捷键误触发后的恢复时间。
- 方法论注意点：只测全局任务会让共用框看起来够用。两类任务要在同一会话里交错，才暴露入口被记错。移动端没有 Ctrl-F，要改用「页内查找是否可发现」作为局部入口指标。
边界
没有可打开对象、只有一张列表的工具，局部查找会退化成列表过滤，与全局搜索可能是同一集合上的同一动作，强行做两个入口是重复。命令面板把「跳到文件」和「当前文件里找符号」做成带前缀的同一框，对专家是一套语法，不是混入口；偶发用户仍会在无前缀时走错。嵌入式小部件（地图搜地点 vs 搜当前视野内的标注）若视觉上贴在一起，区分要靠明确的动词，而不是只靠位置。
怎么落地
- 全局搜索放在应用级铬位（顶栏、稳定的放大镜）；页内或当前视图查找放在内容区或平台标准快捷键，两者标签写成不同动词（「搜索」「在此页查找」）。
- 不要让同一无标记框在不同页面分别绑定全局和局部，这种「随页面变身」无法被学习。
- 快捷键遵循平台：页内查找用系统的查找，全局搜索用产品自己的、且不抢系统查找。
- 验证：在同一会话里连续做「找一篇没打开的文档」和「在打开的文档里找一句话」，看第一次按键或点击是否打在对应入口。打错之后若还说「搜不到」，入口在语义上仍是一个。