編輯導語：開關組件是移動端常見的組件類別之一，這一交互方式簡單易懂，用戶可以通過快速切換轉換狀態。然而開關組件看起來簡單，卻仍有許多方面值得注意。本篇文章里，作者就開關組件的交互狀態、設計注意事項等做了梳理，一起來看一下。

開關控件在大家腦海中是一類最簡單的交互設計組件，是移動端比較常見、同時新手設計師比較喜歡用的一類組件。

但是它真的像我們想象當中這么簡單嗎，是不是有哪些細小的點是我們忽略的，還有哪些小點是我們需要注意的小竅門？今天小編就帶大家抽絲剝繭了解本質。

一、「開關組件」的咬文嚼字

1. 現實世界的隱喻

產品界面上的概念都是現實世界事物抽象后的表現形式，所以現在我們先來看看開關在我們真實物理世界里是怎么樣的。

「開關組件」英語原文為“switch”或者“toggle”，其詞語解釋為開啟和關閉。它還是指一個可以使電路開路、使電流中斷或使其流到其他電路并即時生效的電子元件。

2. 界面上交互特點

結合前文開關在物理世界當中的隱喻，我們很容易給其在界面世界上的交互定義：

1. 允許用戶在兩個相互排斥的選項之間進行快速切換的交互組件。例如，“開/關”、“顯示/隱藏”。
2. 當用戶切換開關時，相應的操作立即生效。

二、「開關組件」的交互狀態

對于「開關」組件的交互狀態其實市面上爭議比較大，就谷歌Material Design而言他給出五種交互狀態的定義，分別是：有啟用、禁用、懸停、聚焦和按壓狀態。

https://material.io/components/switches#behavior

蘋果公司在它的“人機界面指南”當中無論是“IOS”還是“macOS“當中對于開關狀態并沒有詳細的解釋，僅僅簡單的給出了“開”與“關”兩種狀態。

https://developer.apple.com/design/human-interface-guidelines/ios/controls/switches/

https://developer.apple.com/design/human-interface-guidelines/macos/buttons/switches/

微軟公司在它的“Fluent ui”當中指出三種交互狀態的定義，分別是：打開、關閉、禁用。同時在禁用狀態中它還區分“開禁用”與“關禁用”。

https://developer.microsoft.com/en-us/fluentui#/controls/web/toggle

結合“谷歌Material Design”、“蘋果的人機界面指南”、“微軟Fluent ui規范”以及工作當中的實踐經驗，開關組件相對合理且適用的狀態為“打開”“關閉”與“禁用”三類。

這里小編也是查閱大量資料后按自己的理解得出的結果，如果各位朋友有其他意見或者更加合適的資料來探討，同時對hozin老師有關開關狀態的文章也是存疑。

三、開關的加載狀態

基于開關組件的現實隱喻以及其相應操作立即生效的交互特點，這里特別指出加載狀態的開關組件是不存在的，處理狀態也不應該通過在開關上的動畫來表示，因為這樣做會讓用戶難以閱讀和理解。

那么老話說得好，出題不解題就是耍流氓。我們碰到這種實際狀態，開關組件狀態的改變會有延遲該怎么處理呢？

谷歌這里給出的建議當你設計開關時碰到延遲加載情況，用加載條的方式去處理這種問題。

其實小編對于material design的這種處理方法十分的認同，因為它從本質上把組件的“操作”與“狀態”分開去設計處理，一件事歸一件事，使得用戶可以簡單明了地看見當下開關組件的樣子與狀態。

四、開關組件小注意點

各位觀眾老爺們看到這里估計想拿起水瓶想把小編趕下臺去，心里OS：不就一個開關么，還有小技巧，故弄玄虛。先別急，聽我細細講來。

1. 避免添加標簽來描述開關的值

因為開關組件的值已經明顯得不能再明顯，就是“開”與“關”，如果再對于值去設計特別的文字描述就顯得十分多余，反而讓用戶覺得迷惑（特別指出：這里是蘋果設計規范里給出的設計建議）。

而微軟Fluent UI給出的建議又比較奇特，會在開關組件附近給出出當下開關的值，如下圖。

那么至于小編的建議是站邊蘋果，因為開關組件的值實在是太簡單太容易判別，也完全符合現實世界當中用戶對物理開關的心智模型。

但是這里又要特別爆錘下Antdesign的設計，它有一種開關組件的使用建議是把值或者標簽描述放在組件的內部，那么請問如果是海外產品，它的標簽描述或者值是西文語言，那么開關組件長度將會變得非常不可控，甚至于是忽長忽短，這必定不是一個優雅的設計。

2. 提供簡潔的、非中性的標簽

因為從開發角度來看開關組件的本質就是布爾值的選擇，所以說對它的描述需要簡潔易判斷，模棱兩可的語言并不可取。

3. 僅建議在移動端使用開關組件

在移動端產品使用場景當中是直接用手指去操作交互組件，并不會去考慮關心手指下面按住組件的某些交互狀態，但是鼠標操作的場景就麻煩多了，比如有hover狀態，那么開關組件搞個hover狀態是不是很奇怪？

4. 對特殊人群不友好

據調查色盲發生率在我國男性約為5%～8%、女性0.5～1%。那么計算一下我們有多少用戶患有紅綠色盲，那么它對開關的認知就如下圖所示的樣子了。

5. 不建議web使用開關組件

開關組件具有強烈的隱喻，造成它擴展性非常差，只能二選一，同時web端可供使用的組件有很多比如radio button、check box、下單框等，哪一個都是開關組件香。

同時在web產品當中，數據向服務器的提交方式并不一定是實時的，而開關組件的隱喻是即時生效，那就存在著不可調和的矛盾，與用戶的認知也有不同。假如在你點完開關組件的一剎那產品崩潰，那這個時刻開關到底是什么狀態？

6. 開發存在一定成本

雖然很多前端交互框架都提供了Switch組件，但是碰到要適配各種老舊瀏覽器做各種兼容就比較頭疼。同時在HTML的代碼邏輯里并沒有Switch的標簽，這意思就是開關組件并不是web端原生的控件，這樣會讓開發小哥在處理上花上更多的心思，比較容易禿頭。

五、與各個組件之間的差異與關系

有時候，決定使用交互組件元素：radio button、chech box或switch可能會很困難。當你想知道哪個選項適合的時候，請考慮選項的數量和類型，以及是否有任何明確的默認值。

下表總結了這些常用交互組件的差異點，該表出自尼爾森諾曼集團的官方文件當中，又是英文又是中文，是小編的翻譯軟件造成的，請各位看官別太介意，英文好的可自行搜索原文。

六、文末小結

開關組件這個小玩意兒能講的點不多，但是小而麻煩的，其實不太好用。小編查閱當下世界級的三類設計語言，其中對于開關組件的應用規則與特點描述其實都存在打架的情況，只有在移動端認知還算比較統一。

所以我們作為交互設計師在工作中使用到開關組件時一定要深思熟慮，多加小心才方為上策。

作者：月亮與六便士；公眾號：月亮體驗設計坊

本文由 @月亮與六便士 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Pexels，基于CC0協議。