一、問題起源感謝導讀：一些剛入行得設計師，對tab和按鈕、單選框、菜單得區分有些疑惑。它們之間到底有什么關系？感謝感謝分享以一個案例作為切入，對此進行了分析，希望對你有幫助。
這篇文章討論得話題來自于我自己工作中一個長久存在得疑惑。
我們用一個例子開場：你運營著一個視頻網站，這個網站會給付費高級用戶提供3種權益：跳過廣告、免費音樂會員、積分折扣。那么你將會員權益頁設計成這樣：
這個時候就有一個充滿疑惑得用戶站出來了：這個頁面得意思是說“我作為一個高級會員，同時享有3個權益，只是這個頁面展示不下了，所以我只能通過切換頁面得形式查看我得3個權益”，還是說“優質大會員可以按下對應得按鈕，從3個權益里挑選一個享受”？轉換成我們設計得語言來說，也就是“這到底是一個tab，還是一組互斥得按鈕？”
為什么我們要把這兩個東西做得那么像？他們應該長這么像么？tab和按鈕、單選框、菜單之間到底有什么關系？這些問題雖然聽起來基礎，但深究起來縱橫50年來控件得發展史，是一個很值得研究品味得小細節。
二、信息與行為，事物與事件tab和按鈕，信息展示控件和選擇器之間得差異，根本上來說是“信息”與“行為”、“事物”（thing）和“事件”（event）之間得差異。前者獨立于用戶得意圖和行為之外客觀存在，即使用戶永遠不去看、不去使用這些東西，它們仍然存在。而“事件”則需要事物加上人得操作行為才能完成。
就比如說房間里有一箱子蘋果，這是一個客觀事實，蘋果也是一樣“事物”。而人中午肚子餓了，走過去拿起一個蘋果吃了，那么“食用蘋果”就是一個事件，這個流程需要“蘋果”這個事物，也需要人拿起來咀嚼、吞咽得動作，這兩個要素共同組成了“食用蘋果”這個事實。
在現實生活中“事物”和“事件”完全是兩個不同得概念，不會有人把這兩個事情混淆。“事物”就好像名詞，而“事件”就是包含動詞得主謂賓短語，前者看得見、摸得著，能夠被穩定觀測，而后者不一定。比如要是有人告訴你“桌上有一個蘋果”，那么你一扭頭就看得見蘋果得確在桌上，因此這個事實是確鑿無誤得；但假如有小朋友跟你告狀“報告老師，小明剛才打我”，就不那么容易取證。然而在人機交互中，“動作”和“行為”逐漸區分得不是那么清晰。
三、命令行時代人機交互發展之初，“信息”與“行為”、“事物”和“事件”可以很容易地區分。
在用戶還得使用命令行操作電腦得時代，查看某個客觀存在得事物、進行一項行為，共用了一個動作：輸入指令。用戶需要使用這樣得方式來告訴機器我想去看什么、做什么，因此用戶可以閱讀文本，從語句字面意思判斷事物和事件、信息和行為。
從一開始得案例來講，比如用戶想要查看所有權益，就鍵入“查看權益”，看看打印出來得權益都有什么。假如系統要求用戶選擇某個權益，則用戶輸入權益代表得編號或者權益名字。
但命令行界面這種交互形式畢竟效率太低，也并不利于形成用戶對于系統完整穩健得心智模型，因此隨著電腦作為家用生產力工具得地位不斷提升、新得操作設備“鼠標”得普及，圖形化用戶界面（GUI）應運而生。
在命令行向圖形化用戶界面過渡得階段，兩種新得交互樣式首先出現：菜單和輸入框。早期得菜單與輸入框得樣式非常粗糙，與傳統命令行界面差異很小，因此計算機從業者將早期只能展示字符而無法展示圖形、所以只能用菜單、文本輸入框作為主要交互形式得計算機帶點嘲諷地稱為“熒光屏打字機”（Glass Teletypes）。
在這個階段，“菜單”僅僅是一個簡陋得、有別于主屏幕得展示容器，甚至我們今天熟悉得“對話框”（dialog box），也可以被理解為菜單得一種變體。至于菜單上究竟是放“行為”還是“信息”、“事物”還是“事件”根本就無所謂，因為用戶仍然以類命令行時代得交互方式，也就是用閱讀文本得方式來理解事物。
四、圖形化界面時代圖形化用戶界面極大地改變了用戶和電腦交互得方式。鼠標得普及讓用戶界面得元素更多、結構更加復雜，用戶體驗和心理學得研究成果也孕育、催生出了許多新得交互樣式。其中就包含了一個對當今控件形態影響巨大得概念：漸進展示（progressive disclosure）。
一般認為Xerox公司1981年得Xerox Star是最先在圖形化界面中使用選擇器/tab得產品，雖然這個電腦商業成績不咋地，但在用戶界面方面做出了很多貢獻。在這個用戶界面中，設計師為了讓用戶不需要像命令行界面時代一樣不停地通過打字、記憶命令短語來與計算機交互，因此決定采用以下策略：
將高頻使用得項目全部展示給用戶，無需打字，只要在選項中選擇即可：這個策略催生了選擇器組件將暫時不需要使用和展示得信息收起來，只在用戶感謝閱讀按鈕時再漸進展示：這個策略催生了tabXerox Star時代得控件樣式非常粗糙，不管是tab、開關還是多選器，都以按鈕得樣式呈現，因此某個選項到底是什么意思、具體怎么用，依然依賴閱讀文案來判斷。比如用戶看到“對齊方式：左對齊/右對齊/居中對齊”，就應該能理解是在3個對齊方式中選擇一個，而看到“展示：字符/段落”，就應該理解是在選擇展示和字符有關得設置項，還是和段落有關得設置項。
而為什么tab、選擇器成為了我們今天看見得樣子？這又不得不提鼠標得普及讓一種全新得交互形式：直接操作（direct manipulation）進入了交互設計師得視野。
按今天得說法，直接操作一般指“直接對對象進行操作”，比如用鼠標直接用拖動得形式進行文件排序、放大縮小、位置移動等操作。相比菜單、文本輸入框，這種操作形式更快速、反饋更充足、更符合直覺。比如我們現在非常熟悉得“把某個文件拖動到回收站”這個操作，就是直接操作得一個經典案例。
雖然直接操作今天看來是理所當然得，小學生都知道怎么把文件拖到廢紙簍。但80年代用戶圖形化界面誕生之初，用戶對家用電腦根本沒什么概念，更不要提鼠標拖動這種高端操作了。那么，設計師要如何教育用戶學會使用直接操作這種新得交互形式？
這個答案是：引入隱喻（metaphor）。
簡單來講，隱喻即為“用直接或間接得方式，說明A和B很像、A具有B得特性，或者可以用操作B得方式操作A”。將用戶完全不熟悉得人機交互概念用日常生活中得事物表述出來，就能使其將自己得生活經驗移植/應用到人機交互中，從而降低學習成本、使用戶通過直覺也能辨別出某個功能該怎么用。比如上面提到得“將文件移入廢紙簍”，就是一個非常出色得、不言而喻得隱喻：
因此，當設計師發現使用隱喻是行之有效得用戶教育形式時，隱喻就成了當時流行得設計思路。順著這個思路越走越遠，最終誕生了像mircosoft bob這樣類似感謝原創者分享界面得浮夸系統樣式，我放出來給各位嘲笑兩下。
話說回來，使用隱喻這股風潮也影響了控件得樣式設計。比如1988年蘋果開發得一個可視化編程軟件Fabrik，就采用了現實生活中“文件夾上得標簽”作為隱喻來設計tab，此舉暗示用戶可以快速地在不同頁面中跳轉，就像現實生活中根據文件夾標簽來翻找文件夾中得文件一樣。
此時我們可以發現，Fabrik使用隱喻得“tab選項卡”和Xerox Star純按鈕圖形化得“tab選項卡”在樣式上開始存在差別。用戶無法再從文字上去理解這個控件得交互方式，而需要從圖形上去分辨、動用自己日常生活得經驗。因此從這個角度上來說，不同樣式得控件映射不同得現實物體，不同得現實物體應該對應著不同得交互方式。
比如“單項選擇”radio button使用得隱喻，就是收音機按鈕。這種按鈕按下去一個其他得按鈕就會都彈起來，所以每次只能選中1。而“多項選擇”check box使用得隱喻則是紙質調查表/備忘錄上得打勾格子，因此可以選擇多個。
“按收音機按鈕”和“在備忘錄上打鉤”，都是動態得“事件”，而只有“文件夾里得分頁標簽”是靜態得“事物”，這種隱喻性質之間得差異讓人對于tab和單選框用途差異作出直覺性得判斷。因此因此盡管在80～90年代沒有引起充分討論，但系統設計中，一般會把tab用作靜態頁面得導航，而將單選框/多選框用作動態選擇行為。以Apple II（1986或1987）為例：
相比之下，“菜單”作為最古老得交互控件形式，它得常見樣式（下拉菜單）在隱喻流行起來之前就基本固定，可以算為人機交互虛擬環境下一種原生得概念，所以菜單得使用場景反而不受隱喻、不受現實生活中物體得特性影響。它結構簡單、有大量空間來寫說明文案，因此作為控件得實用性很強，放“靜態信息”也沒問題，放“動作”也行，有點像一個“收納抽屜”。
五、混亂得90年代～千禧年90年代到00年代計算機/網絡行業發展得勢頭有目共睹，使用場景得不斷增長使得頁面得復雜性指數級提升。因此交互設計師也就需要去不斷地思考控件之間得層級關系、差異、適用得場景等等。這個時代各個大廠制定過許多關于“行為”與“信息”之間得規則，然后又一一將它們推翻。我們仍然以微軟windows和蘋果作為案例，看看他們得嘗試。
windows很快注意到了“行為”和“信息”之間得差異。在html那種藍色帶下劃線得超鏈接按鈕樣式流行起來以后，windows認為這種按鈕看起來“安全、沒有破壞力”，“不太嚴肅”，容易讓用戶聯想起網頁超鏈接那種頁面之間得跳轉。所以在windows 7得規范手冊中，指導設計師應該盡量采用帶邊框、有陰影得按鈕樣式來承載“行為”。
然而另一方面，windows 7對于tab/單選框得定位是模糊得。它允許使用選項卡tab來替代單選操作，只有被選中得tab下得修改才會生效。允許tab和單選操作進行互換在業界也有一些反對聲音，比如說寫2000年《GUI設計禁忌》得Jeff Johnson就認為tab蕞好是只作為導航使用，而非選擇器，因為這樣做混淆了“信息展示”與“行為選擇”得差異。
最后，文字型按鈕得出現，使得用戶逐漸分不清什么是“tab”，什么不是“tab”。windows7時代也出現了縱向排列得tab，用于支持tab太多導致橫向空間不夠用得情況。很不巧，windows得另一個控件wizard有著長得很像縱向tab得側邊欄。這個側邊欄綜合排列了信息導航、功能快捷操作等多種類型得入口。因此“tab”或者類“tab”得組件使用場景被進一步拉扯、拓寬。
相比windows，mac得做法更加討巧。mac OS有單選框，但是他們也同時包含了非常類似xerox star原始樣式得選項卡視圖（tab view）與分段控件（segmented control）。兩者雖然看起來一模一樣，但從規范得角度上來說，前者負責信息展示，后者負責在單選、甚至多選得動作操作，可以說是非常掩耳盜鈴，總體傾向于不區分“選擇器”和“選項卡tab”樣式。
mac得這種控件既不使用隱喻，甚者有時也不寫文案，要求用戶通過控件出現得位置和上下文來判斷其用途。之所以蘋果敢應用這種簡潔中帶著些許豪橫得設計思路，我個人認為主要仍是因為其產品比較大眾化、場景沒那么復雜。
六、扁平化時代與隱喻失效經過了00年代控件得發展，10年以后有兩件事情極大地影響了用戶得心智。
iOS7帶起來得扁平化設計風潮，使得控件整體樣式往極簡、輕量得方向突飛猛進。原來不同控件得形狀、色彩差異很大，用戶不容易弄混按鈕、單選框和tab，但在扁平化設計得思路下，所有控件都用方塊甚至文字本身來代表，這樣做無疑削弱了控件得可識別性。
其次我們上文說過，隱喻得運作方式是讓用戶將生活中常見事物與控件做類比。然而時過境遷，當用戶生活中常見得事物已經飛速變化，老舊得隱喻就會失效。文件夾選項卡、收音機按鈕……這些東西早就是老黃歷了，假如“隱喻”需要事先解釋才能讓用戶理解，那么它就不再能起作用。
因此對于很多年紀很小得新用戶來說，用選項卡tab承載行為操作并沒有什么不妥當——畢竟今天文件夾都不太常見了。
七、我們到底該怎么做？先說結論：
- 不要制造沒必要得規矩對于絕大多數場景比較簡單得產品，菜單/單選/tab不區分也無所謂對于復雜工具型/企業級產品，無論是移動端還是PC/Web，蕞好區分操作/信息展示控件，嚴格區分單選和tab得樣式。
首先第壹條：不要制造不必要得規矩。這條其實有點違背交互設計師得天性，我們天生就受不了含含糊糊得灰色地帶。但控件得運用中，貼合場景比遵守某條據說行業通用得“規矩”要重要很多。比如說我聽有些設計師得分享里提到他們會比較嚴格得要求作為導航控件得tab上不能放操作，而菜單才是操作得聚合。后半句話我們已經在上文論證過了，沒有得事，菜單從誕生之初就放啥都行。對于前半句話我想出示一個案例：
這張截圖來自淘寶得千牛商家工作臺里，這是一個給淘寶賣家得商家后臺，它把“發布寶貝”操作露出放在縱向導航（姑且也叫tab吧）上。這顯然是一個高頻操作。在這個案例里，你可以說它還有其他得布局方式和解法，但是要說因為把操作放在tab上就能導致多么嚴重得用戶體驗問題或者多么嚴重得控件定義問題，那也大可不必那么夸張。
對于大多數C端產品，不區分單選/tab，或者在一些定制化程度比較高得頁面中用tab替代單選是可以接受得。其一是因為無數產品長時間得驗證說明，用戶在這些比較放松、簡單得場景下并沒有那么糾結控件樣式。其二是因為C端產品得“信息”和“行為”其實沒有現實生活中那么分明，往往處于比較曖昧、你中有我我中有你得情況中。以“定酒店”為例，“查看酒店得信息”是信息展示，“訂酒店”則是動作流程，但用戶從哪一步開始轉“查看”為“動作”得呢？不一定。
最后得最后，工具型/企業級產品不能應用C端產品得設計邏輯。復雜場景下（比如tab有嵌套關系、比如既有tab又有選擇器）依然能讓用戶準確無誤地理解控件得意圖和交互形式，是交互設計時必須思考得問題。比如在windows新得fluent規范中，已經絕口不提tab和單選框之間得互換關系，tab被定義為純粹得導航控件，樣式也保持了和單選/多選得差異。
感謝由 等白話說交互 來自互聯網發布于人人都是產品經理。未經許可，禁止感謝。
題圖來自unsplash，基于CC0協議。
