[譯] 自動補全規則

• 原文地址：Rules for Autocomplete
• 原文做者：Jeremy
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：fireairforce
• 校對者：Fengziyin1234, Endone

使用已知值去進行自動補全文本彷佛是一個很容易解決的問題，可是不少不少的界面設計都錯了。我常常看到這樣的錯誤，與其逐一抱怨，我決定寫下一些它們常常違背的規則。

可能這些規則中的某些並非最好的，可是打破這些規則應該須要一個很好的理由（例如，若是所填的值都必須來自一個固定集合，那麼就沒必要遵照其中的一些規則，例如美國的州列表）。遵循這些規則至少能有不錯的體驗：

• 精確匹配老是第一位的。若是用戶準確輸入一個選項，則其餘選項必須始終低於用戶輸入內容的選項。

• 除了精確匹配以外，最早被考慮的應該是前綴匹配。若是我輸入 「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 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。