阅读 373

[译] 自动补全规则

使用已知值去进行自动补全文本似乎是一个很容易解决的问题,但是很多很多的界面设计都错了。我经常看到这样的错误,与其逐一抱怨,我决定写下一些它们经常违背的规则。

可能这些规则中的某些并不是最好的,但是打破这些规则应该需要一个很好的理由(例如,如果所填的值都必须来自一个固定集合,那么就不必遵守其中的一些规则,例如美国的州列表)。遵循这些规则至少能有不错的体验:

  • 精确匹配总是第一位的。如果用户准确输入一个选项,则其他选项必须始终低于用户输入内容的选项。

  • 除了精确匹配之外,最先被考虑的应该是前缀匹配。如果我输入 “Fr”,我想要的是 “Fresno”,而不是 “San Francisco”。

  • 在前缀匹配之后,再进行字符串匹配。从子字符串开始匹配基本上都是错误的,因为用户开始输入单词时是在开头而不是在中间的某个地方。

  • 如果没有子字符串匹配,则可以选择回退到子序列匹配。这仅仅在某些情况下有用。

  • 如果没有子序列/子字符串匹配,则可以选择回退到近似匹配。这种情况一般很少很少出现。

  • 匹配应该按照字典序进行排序。

  • 当一个选项是另一个选项的前缀时,把最短的选项放在最前面

  • 匹配应该不分大小写,除非有两个选项只是大小写不同。在这种情况下,选择和用户输入最匹配的。

  • 使用选择的操作(例如搜索术语)必须与接受第一个建议的操作不同,除非你必须先进行一些操作来开始使用自动补全的建议(例如,按向下箭头)。用户永远需要采取额外步骤来使用自动补全。

  • 如果有当前自动补全选项,tab 键应该始终接受这个选项(无论是在下拉菜单中突出显示,还是在行内显示)。

  • 如果自动补全选项是突出显示的,那么按 Enter 键应该始终使用该选项。即使有一部分页面还没有完全加载,它也永远不该恢复为默认选项。如果某些内容还在加载,最好忽略 Enter 按键而不是选择错误的选项。

  • 当使用自动补全的字段没有被聚焦时,自动补全不会被按键激活。

  • 一般情况下,结果应该在 100 毫秒内呈现出来。

  • 当用户快速输入其他字母时,可以暂停自动补全,但是不要在用户输入补全之后显示这一串字母中间的结果。最好等待更长的时间然后更改一次结果,而不是显示看上去完成实际上还没有完成的结果(我承认这条规则相当主观)。

  • 如果某个选项被突出显示,那就永远不要更改它,即使加载了新数据也是如此。

有些可选功能在某些确切类型的自动补全中有意义,而在其他类型则未必如此。我确信对这些功能,会有比我所给出的更正确的名称。

  • 当我聚焦输入框但是还没有输入任何内容时,显示我之前使用的选项。

  • 自动补全到最近的模糊前缀。如果我输入 “g” 并且匹配 “Google” 和 “GoodReads”,那么这个操作将填入两个 “o”,然后允许我输入 “g” 或 “d” 来选择我想要的选项。

  • 多部分匹配。这对于自动补全文件路径很有用,我可以输入 “e/b/a” 来自动补全 “env/bin/activate”。ZSH 做得很好。

  • 递归匹配。由于自动补全有时作为快速浏览选项的一种方式有双重用途,所以有时你希望从一个广泛的过滤器开始,然后在这些结果中进行搜索。例如,如果我输入 “.pdf” 来查看所有的pdf文件,那么我就可以按某个键(也许是逗号)开始在这些结果中搜索,即使我现在输入的内容实际上已经在我之前输入的文件名中出现过。

  • 拼写纠正。这往往在搜索引擎中很有用。

  • 别名。尝试自动补全用户名时,可以允许此人的姓/名自动补全他的用户名。对于表示完整状态的州的缩写也是如此。

  • 结果中的其他信息。如果你是自动补全函数名称,那么如果能够看到它们的参数列表,用户会很高兴。

  • 上下文感知建议。这在自动补全代码或单词(通常在移动电话上)时非常有用,其中上下文可以预测所需要的结果可能是什么。

  • 接受自动补全建议后,可以返回我输入的内容。(使用向上箭头来进行这个操作是一个比较好的方法)。

如果发现译文存在错误或其他需要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。


掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 AndroidiOS前端后端区块链产品设计人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划官方微博知乎专栏

关注下面的标签,发现更多相似文章
评论