編輯導讀：一些剛入行的設計師，對tab和按鈕、單選框、菜單的區分有些疑惑。它們之間到底有什麼關系？本文作者以一個案例作為切入，對此進行了分析，希望對你有幫助。

一、問題起源

這篇文章讨論的話題來自于我自己工作中一個長久存在的疑惑。

我們用一個例子開場：你運營着一個視頻網站，這個網站會給付費高級用戶提供3種權益：跳過廣告、免費音樂會員、積分折扣。那麼你将會員權益頁設計成這樣：

這個時候就有一個充滿疑惑的用戶站出來了：這個頁面的意思是說“我作為一個高級會員，同時享有3個權益，隻是這個頁面展示不下了，所以我隻能通過切換頁面的形式查看我的3個權益”，還是說“優質大會員可以按下對應的按鈕，從3個權益裡挑選一個享受”？轉換成我們設計的語言來說，也就是“這到底是一個tab，還是一組互斥的按鈕？”

為什麼我們要把這兩個東西做得那麼像？他們應該長這麼像嗎？tab和按鈕、單選框、菜單之間到底有什麼關系？這些問題雖然聽起來基礎，但深究起來縱橫50年來控件的發展史，是一個很值得研究品味的小細節。

二、信息與行為，事物與事件

tab和按鈕，信息展示控件和選擇器之間的差異，根本上來說是“信息”與“行為”、“事物”（thing）和“事件”（event）之間的差異。前者獨立于用戶的意圖和行為之外客觀存在，即使用戶永遠不去看、不去使用這些東西，它們仍然存在。而“事件”則需要事物加上人的操作行為才能完成。

就比如說房間裡有一箱子蘋果，這是一個客觀事實，蘋果也是一樣“事物”。而人中午肚子餓了，走過去拿起一個蘋果吃了，那麼“食用蘋果”就是一個事件，這個流程需要“蘋果”這個事物，也需要人拿起來咀嚼、吞咽的動作，這兩個要素共同組成了“食用蘋果”這個事實。

在現實生活中“事物”和“事件”完全是兩個不同的概念，不會有人把這兩個事情混淆。“事物”就好像名詞，而“事件”就是包含動詞的主謂賓短語，前者看得見、摸得着，能夠被穩定觀測，而後者不一定。比如要是有人告訴你“桌上有一個蘋果”，那麼你一扭頭就看得見蘋果的确在桌上，因此這個事實是确鑿無誤的；但假如有小朋友跟你告狀“報告老師，小明剛才打我”，就不那麼容易取證。然而在人機交互中，“動作”和“行為”逐漸區分得不是那麼清晰。

三、命令行時代

人機交互發展之初，“信息”與“行為”、“事物”和“事件”可以很容易地區分。

在用戶還得使用命令行操作電腦的時代，查看某個客觀存在的事物、進行一項行為，共用了一個動作：輸入指令。用戶需要使用這樣的方式來告訴機器我想去看什麼、做什麼，因此用戶可以閱讀文本，從語句字面意思判斷事物和事件、信息和行為。

從一開始的案例來講，比如用戶想要查看所有權益，就鍵入“查看權益”，看看打印出來的權益都有什麼。假如系統要求用戶選擇某個權益，則用戶輸入權益代表的編号或者權益名字。

但命令行界面這種交互形式畢竟效率太低，也并不利于形成用戶對于系統完整穩健的心智模型，因此随着電腦作為家用生産力工具的地位不斷提升、新的操作設備“鼠标”的普及，圖形化用戶界面（GUI）應運而生。

在命令行向圖形化用戶界面過渡的階段，兩種新的交互樣式首先出現：菜單和輸入框。早期的菜單與輸入框的樣式非常粗糙，與傳統命令行界面差異很小，因此計算機從業者将早期隻能展示字符而無法展示圖形、所以隻能用菜單、文本輸入框作為主要交互形式的計算機帶點嘲諷地稱為“熒光屏打字機”（Glass Teletypes）。

在這個階段，“菜單”僅僅是一個簡陋的、有别于主屏幕的展示容器，甚至我們今天熟悉的“對話框”（dialog box），也可以被理解為菜單的一種變體。至于菜單上究竟是放“行為”還是“信息”、“事物”還是“事件”根本就無所謂，因為用戶仍然以類命令行時代的交互方式，也就是用閱讀文本的方式來理解事物。

四、圖形化界面時代

圖形化用戶界面極大地改變了用戶和電腦交互的方式。鼠标的普及讓用戶界面的元素更多、結構更加複雜，用戶體驗和心理學的研究成果也孕育、催生出了許多新的交互樣式。其中就包含了一個對當今控件形态影響巨大的概念：漸進展示（progressive disclosure）。

一般認為Xerox公司1981年的Xerox Star是最先在圖形化界面中使用選擇器/tab的産品，雖然這個電腦商業成績不咋地，但在用戶界面方面做出了很多貢獻。在這個用戶界面中，設計師為了讓用戶不需要像命令行界面時代一樣不停地通過打字、記憶命令短語來與計算機交互，因此決定采用以下策略：

• 将高頻使用的項目全部展示給用戶，無需打字，隻要在選項中選擇即可：這個策略催生了選擇器組件
• 将暫時不需要使用和展示的信息收起來，隻在用戶點擊按鈕時再漸進展示：這個策略催生了tab

Xerox 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承載行為操作并沒有什麼不妥當——畢竟今天文件夾都不太常見了。

七、我們到底該怎麼做？

先說結論：

1. 不要制造沒必要的規矩
2. 對于絕大多數場景比較簡單的産品，菜單/單選/tab不區分也無所謂
3. 對于複雜工具型/企業級産品，無論是移動端還是PC/Web，最好區分操作/信息展示控件，嚴格區分單選和tab的樣式。

首先第一條：不要制造不必要的規矩。這條其實有點違背交互設計師的天性，我們天生就受不了含含糊糊的灰色地帶。但控件的運用中，貼合場景比遵守某條據說行業通用的“規矩”要重要很多。比如說我聽有些設計師的分享裡提到他們會比較嚴格的要求作為導航控件的tab上不能放操作，而菜單才是操作的聚合。後半句話我們已經在上文論證過了，沒有的事，菜單從誕生之初就放啥都行。對于前半句話我想出示一個案例：

這張截圖來自淘寶的千牛商家工作台裡，這是一個給淘寶賣家的商家後台，它把“發布寶貝”操作露出放在縱向導航（姑且也叫tab吧）上。這顯然是一個高頻操作。在這個案例裡，你可以說它還有其他的布局方式和解法，但是要說因為把操作放在tab上就能導緻多麼嚴重的用戶體驗問題或者多麼嚴重的控件定義問題，那也大可不必那麼誇張。

對于大多數C端産品，不區分單選/tab，或者在一些定制化程度比較高的頁面中用tab替代單選是可以接受的。其一是因為無數産品長時間的驗證說明，用戶在這些比較放松、簡單的場景下并沒有那麼糾結控件樣式。其二是因為C端産品的“信息”和“行為”其實沒有現實生活中那麼分明，往往處于比較暧昧、你中有我我中有你的情況中。以“定酒店”為例，“查看酒店的信息”是信息展示，“訂酒店”則是動作流程，但用戶從哪一步開始轉“查看”為“動作”的呢？不一定。

最後的最後，工具型/企業級産品不能應用C端産品的設計邏輯。複雜場景下（比如tab有嵌套關系、比如既有tab又有選擇器）依然能讓用戶準确無誤地理解控件的意圖和交互形式，是交互設計時必須思考的問題。比如在windows新的fluent規範中，已經絕口不提tab和單選框之間的互換關系，tab被定義為純粹的導航控件，樣式也保持了和單選/多選的差異。

本文由 @白話說交互 原創發布于人人都是産品經理。未經許可，禁止轉載。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部