通常來說，人們會理所當然的認為觸屏裝置要比幾十年的電腦滑鼠和鍵盤直觀的多。使用者與觸屏直接互動，縮小了使用者行為與軟體響應之間的距離。然而，在移動裝置上——尤其是在智慧手機上——打字是一件相當恐怖的事情。因為那既慢，又痛苦，而且容易出錯。
最明顯的原因是鍵盤字元的尺寸和按鍵之間的臨近，但是還有很多其他重要因素需要考慮，包括：
- 適當的使用自動更正的字典
- 貼切的將字母自動大寫
- 提示輸入型別
- 保持標籤順序
- 保持自定義鍵盤的一致性
在最近一次大規模的針對18個最大的移動電子商務網站的1：1可用性測試中，我們觀察了在填寫表格過程中，現在的觸屏鍵盤的某些功能與限制是如何與使用者的預期相沖突的。一旦衝突出現，使用者的受挫感會立刻上升，比如表單欄位驗證錯誤的提示一個接一個的彈出來，或者更糟的是，使用者被卡住並最終放棄了網站。
當面對一個不那麼理想的觸屏鍵盤是，使用者會對網站失去信心，有的甚至懷疑自己用智慧手機填完一個表單的能力。顯然，好的移動終端的使用者體驗需要一個具有良好可用性的表單，觸屏鍵盤也是其中的關鍵一環。
在本篇文章裡，我們將圍繞觸屏鍵盤的可用性問題做深入一點的探討，包括5條設計準則，可以緩解一些問題。這個設計準則摘自移動電子商務可用性報告中147條指南。前段時間我們在Smashing Magazine上看了移動電子商務10條準則，這5條觸屏鍵盤的準則會更具有通用性，可以應用於使用者與觸屏鍵盤有互動的任何手機網站。
此外，我們還以這5條準則為基準審視了排名前50的線上零售商的移動端網站，發現98%的網站犯了一個或多個錯誤，70%的熱門移動端網站犯了至少兩個錯誤（截至到2013年7月31日）。儘管有些指南可能剛開始看起來是顯而易見的，但當如此多的電子商務站點都犯了這樣的錯誤，我們顯然需要更仔細的審視這些指南。
1、當詞典匱乏時，禁用自動更正（92%的網站犯了此錯誤）
問題：當使用者真的注意到差勁的自動更正時會感到很挫敗，如果他們沒有注意到更改，將會是一件更糟糕的事情。
自動更正通常在以下情況表現非常糟糕：縮寫，街道名稱，email地址以及其他詞典裡沒有的詞彙。這在整個測試過程中造成了很大的問題，隨著被試者完成購買，大量錯誤資料被提交。
關於自動更正的一個主要問題就是，使用者通常不會注意到更正（因為使用者通常關注的是他們正在輸入什麼，而不是已經輸入的內容）。如果更正是正確的，那就沒問題，但如果更正是錯誤的，那將會是很糟糕的事情。例如，在測試過程中多次碰到的例子，由於被試者並沒有注意到自動更正，原本有效的地址資訊被自動更正為無效資訊並被提交。
在沒有地址驗證的網站上，這會導致訂單被送到錯誤的地址，除非被試者特意仔細的檢視訂單確認頁（畢竟，自動更正的資訊通常看起來與輸入的資訊非常相似，這也使得使用者很少會注意到資訊是錯誤的）。當然，自動更正在地址上的慘痛失敗並不僅僅是在邊界的例子（如“weatherman”），而且在一些常見的（標準化）縮寫也是如此，比如“Rd”會被自動更正為“Ed”。
話雖這麼說，自動更正在其他場景還是有用處的，會將無效資料更正為有效資料。因此，並不推薦在所有場景（如評論區）禁用自動更正。相反，要慎重使用自動更正，只在詞典匱乏的場景禁用。這通常包括各式各樣的正確名稱（街道，城市，人物）以及其他標識（email地址，優惠券程式碼，等等）。
儘管看似簡單，實踐起來這卻是迄今為止觸屏鍵盤可用性當中最容易被忽視的部分；幾乎所有的熱門移動電子商務網站都會犯這個錯誤。上文提到的調查顯示，其中有92%的網站在地址輸入框裡沒有禁用自動更正。鑑於在地址和email地址輸入框使用自動更正帶來問題的嚴重性，卻幾乎沒有什麼網站在這裡禁用自動更正，這真的很驚人。
你可以在<input>標籤上增加<autocorrect>屬性並設定為關閉，來禁用自動更正，就像這樣：
2、彈出合適的鍵盤（60%的網站犯了此錯誤）
問題：彈出不合適的鍵盤會降低輸入速度，使用者經常會因為標準鍵盤上數字的很小的點選區域以及間距而打錯很長一串數字。
智慧手機上觸屏鍵盤的一個很大侷限就是它的尺寸。字元本身也都是非常小的。事實上，在iPhone4豎屏時一個字元的大小是4*5.9毫米。
再來對照一下蘋果自己的設計準則，其中提到所有可點選的介面元素至少要有6.85*6.85毫米，因為任何小於這個尺寸的元素點選準確度都會非常的差（微軟和諾基亞同樣制定了最小點選區域為7*7毫米）。可以預見，這將會導致拼寫錯誤。
但是通過更改輸入框程式碼的一到兩個屬性，你就可以讓使用者的手機自動顯示所需輸入的最合適的鍵盤。例如，你可以為信用卡號輸入框呼叫數字鍵盤，為電話號碼輸入框呼叫撥號鍵盤，為電子郵件地址輸入框呼叫電子郵件的鍵盤。這樣可以節省使用者必須切換傳統鍵盤的時間，並且在輸入數字的場景中，最大限度的減少輸入錯誤，因為這樣的專用鍵盤按鍵尺寸更大，會減少意外輸錯的機率。
在整個測試中，很多被試者都注意到了專用鍵盤，並對它們讚許有加。事實上，在iOS中，數字鍵盤的點選區域要比標準鍵盤大471%（數字鍵盤209*108畫素vs標準鍵盤52*76畫素）。更重要的是，我們發現在數字輸入框裡採用數字鍵盤時錯別字明顯減少。這會導致更少的驗證錯誤，反過來，也可以將網站引向一個更好更無縫的購物體驗。這對於長數字佇列尤為明顯，比如電話號碼以及信用卡號。
呼叫專用鍵盤的另一個好處就是可以表明需要輸入的是什麼內容，如果輸入框標題滑出視線範圍或是使用者不確定要輸入什麼的時候，這會很有用。然而，數字鍵盤也有一定的侷限性，因為它不允許使用者輸入拼音字元，只有少量特殊字元或分隔符，也可能連這個都沒有。所以，只有最合適的時候再呼叫這樣的鍵盤，這很重要，比如輸入電話號碼、郵政編碼、信用卡號以及信用卡安全碼。同樣的，在呼叫鍵盤時，確保你給出的格式樣例是可以複製的。
根據給出的樣例格式（比如“555-555-5555”）輸入電話號碼在iOS上是不可能的，因為調出的鍵盤是沒有橫劃線的。（有趣的是，在Android系統上輸入是可以的，這也說明了為什麼在多個平臺測試有助於確保在格式樣例只在有些平臺上必須。）
說了這麼多可用性上的優點，你可能會想這種專用鍵盤是被廣泛應用的。然而，60%的熱門移動電子商務網站在對應的場景並沒有呼叫它們，如電子郵件（電子郵件鍵盤）、電話號碼（撥號鍵盤）以及信用卡號（數字鍵盤）。
技術上來說，有很多種方式可以調出數字鍵盤，每種鍵盤之間略有差別（如撥號鍵盤和數字鍵盤），不同平臺間行為也會有輕微的不同（iOS，Android等）。大體來說有兩種HTML屬性可以呼叫數字鍵盤，分別是type和pattern屬性。
Type屬性承載語義的含義，僅僅當輸入時有合適的型別可呼叫時才會被用到，這主要是針對電話號碼和電子郵件地址的場景。不過對於數字輸入，更推薦使用pattern屬性來替代。（注意如果你僅僅是想要瀏覽器呼叫鍵盤，並不強制格式，可以加入novalidate屬性。）
針對任何電話號碼框，用如下程式碼：
針對其他你想要呼叫數字鍵盤的輸入框，用如下程式碼：
針對任何電子郵件地址框，用如下程式碼：
正如上面提到的，各種數字鍵盤之間會有一些區別，在不同平臺之間也會有一些不同。例如，在iOS平臺上，上述程式碼調出的電話鍵盤可以讓使用者輸入數字以及少量電話相關的特殊字元和分隔符，而調起的數字鍵盤只能輸入數字。與此同時，在Android平臺上，調起的電話鍵盤則有著更多的特殊字元，支援更多格式的電話號碼。
但是，由pattern屬性調起數字鍵盤在Android上根本不支援，相反，它只會調起常用的字母鍵盤。雖然在iOS和Android平臺上，你都可以使用type=“number”調起數字鍵盤，但將type設定為number帶有語義含義，在很多場景下並不合適（比如信用卡號是一個數字佇列，不單單是一個數字）。
所以，我們推薦更為保守的策略，使用pattern=“\d*”，這樣在iOS平臺上可以有更好的體驗，在其他不支援該屬性的平臺上也不會有什麼影響。（當然了，如果輸入框就是針對一個數字的，比如價格或是數量，那麼顯然應該使用type=“number”了。）
3、保持一致，呼叫合適的鍵盤（54%的網站犯了此錯誤）
問題：如果一個輸入框呼叫了專用鍵盤而其他類似的輸入框卻沒有，那麼在沒有呼叫專用鍵盤時使用者會感到困惑，並開始質疑這個輸入框所需輸入的型別。
為特定輸入框呼叫合適的鍵盤是正確的做法（參見上面的推薦），但是要確保在你的網站上保持一致，否則會讓使用者很困惑。換句話說，如果郵政編碼的輸入框呼叫了數字鍵盤，那麼類似的輸入框也要有同樣的做法。
儘管這聽起來是顯而易見的，但很多網站都沒有在呼叫專用鍵盤上保持一致。例如，花店FTD（如上圖）在填寫信用卡號的時候呼叫了數字鍵盤，但在緊接著下面的安全碼輸入框卻沒有，雖然這兩個值都是數字。
在50個快速增長的熱門線上零售商中，54%的網站在他們的移動站點上犯了這個錯誤，多多少少都會有一個或是多個電話輸入框，信用卡號碼或是信用卡核對（CVV）輸入框沒有呼叫數字鍵盤。這54%的資料細則如下（絕對值）：24%的網站沒有為這三類中任何一種呼叫數字鍵盤（儘管這也是一致的，但是錯誤的示範），剩下30%的網站（包括FTD）不一致，只有在一部分輸入框才會呼叫數字鍵盤。
更令人驚訝的是，在整個可用性測試中，由於這樣的問題讓一些被試者很困惑。他們開始質疑對於個別輸入框最初的解讀，認為可能需要填寫一些其他的內容。例如，當看到“信用卡安全碼”輸入框彈出了標準鍵盤時（如上圖FTD的網站），被試者開始懷疑這是否就是填寫信用卡背面的那三個數字，或是印在卡上的其他字串。
4、兌現“上一項”和“下一項”按鈕的行為（4%的網站犯了此錯誤）
問題：如果“上一項”和“下一項”按鈕把使用者帶去了不合邏輯順序的輸入框，使用者會很煩惱和困惑。
在測試中，被試者在未能兌現“上一項”“下一項”按鈕行為的網站上感到煩惱。使用者預期的行為很簡單：當使用者點選“下一項”按鈕，他們會預期跳到表單中下一個合乎邏輯的輸入框，沒有其他變化，甚至提交表單。“上一項”按鈕也一樣，當然是換個相反的方向。
這不僅僅是需要有正確的標籤序列（雖說這是一個好的開始）。當需要依賴於使用者先前的選擇處理動態輸入控制元件時，事情往往會出差錯。在這些情況下，我們已經看到使用者資料被刪除或是標籤序列被違反。我們也必須要格外注意自定義表單的介面。例如，在迪士尼商務網站，定製化的狀態選擇器不屬於標籤序列（因為從技術上來說它並不是一個輸入元素），所以使用者就會跳過這個狀態控制元件。
這些按鈕的功能基本上是充當鍵盤上tab鍵的移動版；所以，它們應該採用和電腦鍵盤tab一樣的序列規則。它們應該提供從一個輸入框到下一個輸入框的快捷方式，不需要任何點選（不論是滑鼠還是手指）。這在手機上是尤為重要的，因為當鍵盤撥出的時候，螢幕空間是有限的，下一個輸入框可能被部分遮擋，這個時候“下一項”按鈕則用起來很方便。所以，儘管“上一項”和“下一項”按鈕有可能不會被所有使用者用到，但禁用這些按鈕的行為會導致很嚴重的後果。
幸運的是，大部分網站這一點都做的很好。只要程式碼是清晰的，手機瀏覽器會預設將輸入框出現的順序作為標籤序列。在熱門移動端網站中，只有4%的網站犯了此錯誤。
5、在適當的情況下，禁用自動大寫（38%的網站犯了此錯誤）
問題：幾乎所有的被試者都認為他們的電子郵件地址必須要小寫，所以這項資料自動大寫會給整個過程帶來不必要的麻煩。
智慧手機預設會把標準文字輸入框的首字母大寫，這在大部分情況下是合適的。然而，在有些情況下禁用自動大寫是更合適的，特別是像電子郵件地址這種絕大多數使用者都以為要小寫的情況。
測試中的大部分時候，被試者都注意到了大寫字母，並明確的將其改為小寫。最合理的解釋是他們不確定是否允許填寫大寫字母，或電子郵件地址是否區分大小寫。在那些電子郵件輸入框禁用了自動大寫的網站上，沒有被試者會主動將首字母大寫。推薦大家在電子郵件或是其他合適的場景（如網址URL）禁用自動大寫。
在熱門移動電子商務網站中，38%的網站在電子郵件地址輸入框沒有禁用自動大寫，把它們設定為純文字輸入框，給使用者留下非技術性的困惑。
可以在<input>標籤上加入autocapitalize屬性並設定為off，來禁用自動大寫，如下所示：
當然，針對電子郵件輸入框，你也可以設定一個type屬性為email：
在iOS系統上，設定type屬性為email將會自動禁用自動大寫。然而，最好仍然設定autocapitalize屬性，因為這不僅在iOS系統上奏效，而且在其他還不支援email輸入框型別或是實現方式不同的平臺也可以使用。
測試以及絕密小抄
雖然這些基本原理看上去是顯而易見的，但是要記得全球最大的移動電子商務網站中98%的網站違反了至少一條（參看任務完成列表）。70%的網站違反了兩條甚至更多的“基礎“觸控鍵盤準則。事實上，24%的網站根本沒有為觸屏鍵盤輸入做過什麼優化，就算是省掉標準鍵盤（在輸入電話、電子郵件、數字等情況），偶爾呼叫專用鍵盤（一致性很差），在合適的地方禁用自動更正，抑或是在電子郵件地址輸入框禁用自動大寫，這些都沒有。
不遵守設計準則的一個原因可能是，針對一個大型網站所做的全域性測試需要去發現所有的明顯缺陷——故而，理想情況下的第三項建議中提到呼叫鍵盤的一致性問題，是不必要被提及的。另外一個原因是，在前一篇文章中提到的，手機和觸屏介面是一個相對較新的平臺，它的全新的介面理論需要大家去關注無數的小的細節——這些細節對於我們網頁設計師和開發者來說還不習慣去主動尋找和設計。
綜合以上原因，我們將用一個絕密小抄來作為文章的結尾，此小抄是設計觸屏介面輸入框最常見的細節點，包括可複製貼上程式碼以及正確呼叫了鍵盤的手機觸屏優化demo，你可以把它當作是一個設計開發手機端以及桌面端網站的清單。
- 可互動的觸屏鍵盤小抄，以及手機端優化demo
這些輸入框通常都會出現在以下型別的表單中：帳號註冊，帳號登入，搜尋，調查，完整的結賬過程，註釋表單以及聯絡表單。我們建議你搜尋整個程式碼庫，來捕獲到每一個例項。