G3.04.1spelling correction revert设计研究

自动纠正需告知原查询并可还原

别名: 拼写自动纠正 · Did you mean · 纠错可还原

概念解释

系统把「recieve」改成「receive」再去排结果,这是拼写纠错(spelling correction)的自动纠正。纠正一旦发生,界面必须同时做两件事:说出原来提交的是哪一句,并提供一键按原文再搜。Hearst 讨论的典型形态是「已按 X 显示结果,仍可搜 Y」——X 是纠正后的词,Y 是原文。缺任何一件,用户都无法判断眼前的列表是自己的查询,还是系统改写过的查询。

自动纠正的对象是用户看见的那次查询,不是索引内部的模糊匹配。内部容错可以不改写框里的字;一旦改写了,告知和还原就是这次改写的一部分,不是附加的礼貌。

机制

自动纠正把一次查询换成另一次,结果页上的每一条都是对第二次查询的回答。人用「我键入的词是否出现在条件里」来核对系统听懂了没有。条件里只剩纠正后的词,核对失败:列表看起来合理,却可能是另一个对象。错误归因会落在内容(「没有我想要的」)而不是改写(「你搜的不是我写的」)。

还原必须便宜。纠正若多数时候是对的,用户会形成「回车即出结果」的节奏;偶发的错纠正如果要删掉结果、改回框、再提交,节奏被打断,人会接受错的列表或放弃。把原文做成结果页上的并列动作(「改为搜索 [原文]」),让那一次核对和那一次撤销发生在同一视线里。静默改框内文字更糟:工作记忆里的字和屏幕上的字对不上,下一次改写查询时用户从错误的当前值出发。

怎么研究

把「是否发现被改写」和「改写是否正确」分成两件事测。

  • 范式:拼写纠错的 UX 实验——正确纠正 vs 错误纠正 vs 不纠正,记录是否注意到横幅、能否还原;查询日志里「showing results for」之后立即点「search instead」的比例。Hearst 将 Did-you-mean 作为搜索界面的标准部件来讨论。
  • 自变量:纠正是否改写输入框、横幅是否同时展示原文与新查询、还原是一键还是要手动重输。
  • 因变量:错误纠正的检出率、还原时间、把失败归因于内容缺失的比例。
  • 方法论注意点:材料里要包含纠正正确和纠正错误两类,否则被试会学会「横幅总是对的」而不去看。实验室若把拼写错误印在任务书上,被试会预期被纠正,检出率被高估。日志里的还原点击只覆盖发现了横幅的人,未发现的静默接受不会出现在该计数里。

边界

用户正在使用的就是那个「错」拼——品牌、代号、故意的非标准写法——纠正在语言上正确、在意图上错误,告知和还原是唯一安全阀;专有名词的判定是相邻问题。命令式搜索(输入即执行)没有结果页可放横幅,纠正应发生在执行前的确认,而不是执行后。无结果时还没发生自动纠正,谈的是主动提供近似查询,不是「已纠正需告知」。极高置信且原文完全无法命中时,仍要告知,不能因为「反正原文没有结果」就省掉横幅。

怎么落地

  • 发生自动纠正后,在结果列表上方用一句话同时写出新查询和原文,并提供「仍搜索 [原文]」。
  • 不要静默改掉输入框里的字;框内保持提交时的原文,或改了也要能一眼退回。
  • 还原后的这一次不要立刻再次自动纠正成同一新词,否则还原入口是假的。
  • 验证:故意提交一个会被改错的词(能命中的专名被改成常见词)。若列表当正常结果出现且无处看见原文,告知失败;看见原文却要点进框里重打才能还原,还原失败。

延伸

  • 同组G3.04.2 专有名词的纠错风险最高 · G3.04.3 无结果时应主动提供近似查询
  • 相邻G3.03 搜索建议 · G3.14 拼写纠错与近似匹配 · G1.08 术语一致性
  • 站内检索spelling correction · did you mean · query rewrite

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/G3.04.1