通過較為淺顯易懂的方式與大家講清楚了其中的利弊以及一些邏輯上的使用方法，但是在實際工作中，所遇到的問題遠不止文章當中那麼簡單，工作中遇到那麼多複雜的選擇器我應該如何設計？
02篇中我們主要會針對下拉選擇、日期時間選擇的基礎內容進行相應的解析，通過拆解實際工作當中的需求，去了解其背後設計的邏輯。
零、咱們還是老規矩
先科普一個知識點，下拉菜單與選擇器之間的區別
首先，在Ant Design中，它將下拉菜單（Dropdown）與選擇器（Select）完全拆分開，如果單純從視覺樣式上來看，兩者並沒有較大差異，因此在日常的方案溝通中容易產生混淆。
而我總結了一下日常描述此組件時出現的不同名稱，比如：選擇器、下拉選擇、下拉菜單、下拉框、下拉選擇器、選擇框等等...
那到底應該叫什麼？ ！ ！ ！ ！
首先，為了研究名稱的準確性，我查閱了“字典” World Wide Web Consortium （W3C）的cheatsheet文檔，其中只存在有選擇器（Select） 這一名詞，即選擇器。而下拉菜單（Dropdown）是並沒有存在的，結合對文檔的細緻研究，因此總結出使用“選擇器”進行表達是一個較為規範的說法。
而我們回過頭來看，為什麼Ant Deisgn會將同樣的選擇拆分為下拉菜單與選擇器呢？其實在實際功能上兩者會有較大的不同點。
下拉菜單
在Ant Design的解釋中，其描述主要是針對操作進行集合，主要的使用場景是在導航、工具菜單以及部分操作集合裡。但在前端的實際使用中，Dropdown 主要被作為一個下拉容器的入口，他可以在裡面放任意的內容，一張圖片、一句話、甚至一個視頻，都可以在下拉菜單中進行展示。
導航：比如在ＧrowingIO的官網中，通過下拉菜單，他就可以將產品導航進行分組，並且統一放置在一起。
假設我們這時候使用Select 進行展示的話，它的下拉菜單應該是長這樣～（當然，這里肯定不會出現Select 因為它缺少錄入框，這裡只是作為舉例進行假設）
工具菜單：比如在MacOS的全局菜單中，左側工具菜單都是將所有的操作放置榆次，在Figma的軟件那種，通過將頂部的工具欄，通過使用下拉菜單進行呈現。
操作集合：比如我們在表格的操作區域經常會使用下拉菜單將很多操作放到一起。
選擇器
主要是針對選項進行收折，他是必須包含兩個部分，錄入框以及下拉選項。使用場景是在表單的中可選項過多之後，會使用選擇器將所有選項進行整合。比如我們選擇客戶的歸屬人，因為可選擇的成員較多，因此通過選擇器能夠使所有選項進行集中展示。 （圖片在下方）
其次，兩者的混淆，主要是對下拉選項的問題，其實一般對與下拉選項時，大家更通用的表述是下拉菜單，也會因此造成了兩者之間的混淆。
一、下拉選擇的基礎拆解
說到選擇，就不得不提起下拉選擇，因為其“簡單無腦、適應能力強”因而成為新手設計師的使用首選。但在使用的過程中經常會出現很多盲點，比如選項過多、下拉菜單過長、如何排序，這些都會在文章後面與大家進行一一解答。
1.1下拉選擇器的結構
下拉選擇的類型較廣，一般由下拉單選、下拉多選、下拉級聯選擇等...
因此考慮到實際情況，我設計一個較為完整的結構，大家可以根據實際情況進行閱讀拆解。
在結構中，挑選了幾個較為重要的結構來為大家進行講解。
-
選擇錄入框：與文本輸入框類似，擁有一個外邊框，用於提示用戶可操作的熱區範圍。其主要差距是能與下拉菜單進行聯動：
當下拉單選，選擇了一個選項後，下拉菜單會自動收起，並將選擇的值反顯到錄入框內，進行展示
當下拉多選，選擇了一個選項後，下拉菜單會持續展開，並將選項表達為選中狀態，進行展示
-
選擇器的下拉菜單：承載所有可選擇的選項列表，在選項數量過多時會對下拉菜單的高度進行限制，即設置下拉菜單的最大高度，當超過最大高度時，一定會出現滾動條。常見的高度設置一般為：264px （參考Ant Design）
-
右側標識：每個選擇錄入中的右側圖標，都是其“身份”的象徵，因為在後面要講到的成員選擇、日期選擇、時間選擇等，在正常狀態下除了右側圖標的標識意外，你分辨不出其他地方有著較為明顯的差異，也因此在設計的過程中，如何將它們進行合理的區分也是設計需要著重思考的點。
這裡做了一個對應表格，大家可以根據自己的實際情況進行對齊。
-
回顯值：回顯值通常包含有兩種狀態。
在下拉單選時，因為使用的場景有限，一般採取純文本回顯即可。
在下拉多選時，需要同時展示多個選中項，因此在錄入框中只能採取Tag形式，通過Tag將每一個選項進行包裹，並在右側擁有單一選項清除的入口，讓用戶進行點擊刪除，從而使單個選項擁有一個完整的閉環。
-
搜索：下拉選擇的搜索主要是對較多選項的優化設計，目的是為了幫助用戶能夠快速找到相應的選項值。而目前主流搜索的做法主要分為兩種，以大家最常見的Ant Design 與Teambition 進行舉例。
Ant Design在對搜索方式的處理上，採取的是將選擇錄入框看作是一個輸入框，通過點擊過後，將光標首先聚焦在輸入框內，能夠給用戶傳達出可以進行搜索的操作
Teambition則是在輸入框的下方，針對一些特定的場景，他可能會使用到主要是針對於搜索type 下面的一些搜索值，只要滿足用戶在於多選操作的時候多，多選的值特別多，如果沒有一個單獨的區域進行搜索的話，直接在搜索框內進行搜索，會特別的難用。這樣雖然佔用了一定的區域，但能夠保證用戶獨立搜索的操作完整的體驗
-
多層級：在多層級中，主要是針對選項中內容的歸屬關係進行相應的定義，一般是由大到小進行選擇，結構採取3>2>1 ，也就是我們常說的級聯選擇的形式。
-
全部清除：全部清除出現於下拉多選中，這是一個特別重要的功能，大家在設計中很容易忽略（劃重點了！！）。因為在多選時你選擇過多的選項後，不免會有清除所有選項的需求。如果沒有此入口就代表著用戶只有一個一個去刪除，它在整個刪除的過程中便是十分痛苦的。
1.2下拉變種
上面講的只是下拉選擇的基礎結構，而在實際業務中還會遇到各種各樣的下拉選擇，因為不同的業務代表著你需要不同的組件，因此我接著給大家講一講下拉的各種變種。因為是變種，因此其使用場景較為局限，切勿生搬硬套。
-
分組
分組其實是我們遇到信息過載時最先想到的方式，通過不同的設計形式，使用分割線將同一類別的選項進行相應的劃分，這樣在用戶選擇時會思考由大到小的關係邏輯，即從大的分類思考到具體的選項。比如我們需要去選擇某某小學三年四班的李華同學時，如果將全校的所有名字都放在你面前，另一個則是根據班級進行相應的分組，你認為哪一個更清晰？
這其實是人的一個正向思維，當你去尋找時，通過三年級> 四班> 李華這樣由大到小的思考方式會使你檢索效率大大增加，因此在表單中很多信息過多時分組便是一個“常規手段”
分組雖然確定，但他的設計方式也有幾種不同的形式，在下方給大家進行總結
-
T ab分類
Tab 分類其實是一種對於業務特殊的處理方式，其目的是幫助選項進行合理的分類。
因為在許多時候，與其說讓我在幾十個中尋找其中一個選項，不如說在設計本身上就先預設好一定規則的Tab 分類，然後用戶可以根據不同的分類去盡可能縮小他所要選擇項。比如在我之前設計的券商產品中會有選擇不同級別的銷售的場景。
圖中可以看到我們將銷售等級分為三類：初級銷售、中級銷售、高級銷售，為了使用戶在選擇器中不會產生太多違和感，我們將第一個Tab 設定為“全部”，並且按照成員的字母順序進行排列，同時當用戶想要選擇某一類的銷售成員時，可以通過切換Tab 進行快速的分類選擇。
採取Tab 分類一般需要滿足一下幾個條件：
-
選項數量較多，至少為20個選項以上。
-
選項中能夠有3-4個分類類型，通過分類能夠給用戶帶來明確的差異信息。
-
分類與分類之間的關係，一般是相互排斥，要特別留意分類之間的關係。
-
錨點
通過展示選擇器當中分組的組名，在選擇器頂部製作出錨點能夠幫助用戶進行快速跳轉，從而提高用戶的選擇效率。
它與Tab分類十分接近，其二者存在一些“細枝末節”的區別。
錨點是將整個選項都放置在同一個選擇器類型下，只是存在著簡單的分類。而Tab 完全是將選項與選項之間的類型分割開，關係上會更加遠些。
比如在神策數據的LTV分析中，就通過使用選擇器的錨點，可以方便用戶對內容進行快速跳轉，這樣就能完成三年級四班>李華的尋找思路，也更符合用戶的尋找路徑。
-
收折選擇
通過樹狀結構的展示，將選項內容展、收起。看上去似乎與錨點、Tab 分類，兩種較為類似，但是在我工作中，通常會與多選框進行結合，能夠激發很大的魅力。用戶可以通過選擇一級標籤來代表選擇該一級選項下的所有內容，在一些特定的場景中有著意想不到的效果。
比如在一個在線教育的場景中，我們可以通過這類選擇，在一個選擇器中，同時可以選擇班級、同學兩類不同緯度下的選項，這是普通選擇器中無法達到的，並且也正是實際工作中需要的～
-
字母定位
字母定位是一種特別的錨點定位，它默認提供從A - Z 的字母進行排序，通過右側的字母能夠起到很好的快捷跳轉的效果。這種方式最早出現於移動端，在咱們日常使用IM 系統中，通訊錄、好友列表、所有應用大多都會有這種方式，
同時結合著錨點與分組，能夠將給予用戶更為明確的表達形式，而隨著交互形式根深蒂固，B端產品也逐漸演化，開始形成自己的風格形式。
比如在紛享銷客的成員選擇中，因為容器的限制，只能夠使用較小的下拉選擇項進行展示，導致了用戶選擇特定員工變得困難重重，而員工基本信息中都是包含有名字作為基本字段，因此通過字母右側進行定位排序，能夠極為方便進行成員的選擇。但要注意一點的是，這類設計都是針對選擇頻率較低的情況，對於高頻、量大的情況下使用，則需要更為定制化的組件做處理。
1.3下拉的多種狀態
本來下拉的狀態是不打算去講的，想當然覺得又會是一些十分基礎且通用形式，而下拉的狀態其實與咱們之前講到的很多內容有很大的區別。因為下拉選擇是由兩部分組成，錄入框以及下拉菜單，也就導致兩者之間的狀態同樣會存在許多較為複雜的組合，同時在組合中會有不少奇特的問題
-
禁用狀態
錄入框禁用是讓用戶無法進行激活，將錄入框置灰並且直接不讓用戶進行點擊。
在禁用狀態的設計中，一定要將禁用與正常狀態之間拉開差距，因為在體驗過很多下拉選擇時都會遇到此問題，將顏色差距拉大也能夠方便用戶進行快速識別。
-
選項禁用
而選項禁用則代表該選項並不能夠被點擊，但是不影響整個選項的選擇情況。同樣字體置灰，但在選項禁用中是不會有Hover狀態，並且光標會變成Not Allowed 。
-
多選狀態
因為多選，代表其有較大的不可控性，也就意味著在很小的錄入框中，如何展示數量較多的選項，這裡設計出了兩種不同的模式：滾動高度、撐開高度
滾動高度：主要是限制輸入框的高度，在輸入框的右側添加滾動條。這樣能夠將多個選項放置在錄入框容器中，最大的好處是能夠保證整個表單的整齊，讓表單的排布更加通用。但滾動高度帶來的問題是因為高度的限制，你很難完整看到所選擇的全部信息，但滾動高度是最簡單的處理的方式。
撐開高度：通過改變錄入框的整體高度來展示完整的選中信息。撐開高度能在表單中實現一些疏密變化，在撐開的過程中，處理的細節中會有所不同，這裡我簡單做了一個總結：
a.固定最大高度：將錄入框的整體高度進行限制，這樣能夠滿足常見的多選狀態展示。比如我們確定選項整體高度後，我們可以將最大高度設置為選項展示的2.5行，即讓用戶知道可以滾動。
b.選項融合：針對用戶只需要了解選項中的項目個數，而對實際的文字選項內容不做過多了解時，就可以採取選項融合。通過一個統一的選項個數，去展示其共有23 個選項選中，這樣能夠避免了出現一些較為離譜的情況。這種情況主要是針對於有全選功能的多選框時，當你勾結了全選，就會選中非常多的選項（雖然再原則上不允許用戶在選擇器進行全選）
-
空狀態
在錄入框中的空狀態是以佔位符的形式進行表達，一般多為“請選擇”等類似文案進行提醒
-
選項空狀態
選項是不會存在空狀態，其實本質上的下拉菜單的空狀態，這時候基本的處理為空狀態的插畫即可，只是少部分空狀態是有特殊的業務原因，只需要把邏輯講清楚即可。
1.4下拉的樣式
下拉的樣式一共分為五種：標準樣式、分離樣式、圓角邊框、帶圖標、帶圖像，大家看圖認識即可
標準樣式
分離樣式
圓角邊框
圖標選項
圖片選項
二、下拉選擇器的交互邏輯
2.1下拉選擇器與單選框、多選框的對比
下拉選擇器的優點：
包容度高：下拉選擇的出現，代表著它擁有極高的包容度（雖然在極個別場景下使用會顯得比較突兀）。但是只要是“選擇” 的內容，就一定可以採取下拉選擇器進行展示。單選框、多選框、成員選擇、地址選擇等都是可以轉化為下拉選擇器。總結一句，萬物皆可下拉。
擴展性強：它本身採取的是兩個容器組合的概念（即錄入框與下拉菜單組合），代表下拉菜單在表單上是不會有太多的限制，錄入框是在表單中，而下拉菜單是進行呼出，因此下拉菜單的內容可以進行再次設計。比如在我實際工作中使用下拉選擇的頻率會明顯高於單、多選框，而且經常會設計很多特殊的下拉變種，去滿足實際工作中的交互需求。
可更改性強：由於下拉選擇器的結構，導致很多選項都是默認隱藏，因此選項如果有任何的更改，用戶都難以去發現。
熟悉的交互：下拉選擇器是大多數都是用戶十分熟悉的交互形式，因為其本身在Web端設計中就已經廣泛使用。
下拉選擇器的缺點：
內容過載難處理：雖然在下拉的變種中講到許許多多內容過多的處理方式，但是太多選項會造成頻繁的滾動是難以避免的，因此內容過載時就要考慮更為特殊的選擇器：如成員選擇、穿梭框等... 我們會在03中為大家進行剖析。
部分情況效率低：當在一些有特殊規則、或者用戶熟悉的內容時，它的交互效率明顯更低。比如在選擇生日時，明顯輸入要比選擇來的更高。
易誤操作：因為本身交互空間的限制，導致很多人都會存在誤操作的情況，特別是正在滾動時，菜單收起就不得不進行重新選擇。
2.2下拉選擇的排序方式
在下拉選擇中排序是一個特別重要的事，好的排序規則能夠彌補組件設計不足，並且在用戶的使用過程中，能夠體驗到絲般順滑。同時排序是需要作為設計備註寫到整個交互文檔中，也因此學會整個排序方式是必然趨勢。
按字母
按字母排序通常是從A 到Z，這種排序方式最為穩妥。
這類排序方式是通常都是對字母較為敏感，會非常在乎文字字母的順序關係，比如員工姓名、公司名稱等都可以採取按字母的排序方式，同時字母也能兼容中文和英文，使其能滿足更多的條件。在用戶的認知當中，按字母排序也是最為常見的排序方式。
按數值
顧名思義就是按照數字的大小，從小到大的順序進行排列。這種都是一個默認的邏輯，也因此不會存在有太多的問題。
給大家出一個小問題：“在數值排序當中：1、1.1、1.1.1 哪一個在前哪一個在後？”大家可以在電腦中新建三個文件夾進行嘗試～
按使用頻率
使用頻率大家可能會有一些陌生，如果我換一個詞“熱門、猜你喜歡”就可能會喚起大家腦袋中最深層的記憶。
這種方式常見於移動端，主要是針對一些用戶的特定喜好的選項進行推薦。舉一個例子，大家在使用輸入法進行打字時，被候選的漢字是根據你的選擇頻率的上升，將它的優先級進行不斷的提高，從而讓用戶在打字時能夠更方便的進行選擇。
在我們系統中，主要是推薦使用頻率最高的三個選項，並在右側給出常用標籤讓用戶能夠明白這是最為常見的內容。
按用戶預設
用戶自己預設是目前低代碼平台最為流行的做法。將產品的所有功能都交給用戶，其中也包括了選擇器以及下拉菜單裡面的基本順序。作為用戶預設的一部分，顯然從設計層面就難以對其進行把控，比如在清流的產品中，你可以通過最後你會發現，幾乎所有的低代碼產品都採取選擇器而非單選或多選，也正是選擇器的包容度高。
上面所提供的排序方式，所有選項都不是單一維度去執行的，都需要一些組合的邏輯去排列執行，才能夠達到最好的效果，比如說在我們常見的下列選擇中，首先我會預測三個選項作為熱門選項，當用戶選擇的時候會在右側提供一個標籤，顯示常用，並且其他的選擇順序是按按字母從a 到Z 的順序排列，過後是數字，在其次是標點符號
而這些是屬於下拉的一些基本邏輯，我們接下來看一下下列選擇的交互邏輯
2.3鍵盤錄入
在表單的場景中，我不止一次的提起鍵盤錄入的重要性。因為用戶在實際的錄入過程中，是需要一一填寫，在我對很多銷售進行表單錄入的場景中，都會習慣採取tab 鍵來進行錄入框的切換，這樣能夠保證數據錄入的高效性。同樣我們回到下拉選擇的設計當中，用戶可以通過點擊回車鍵進行下拉選擇的展開，同時又可以通過上下鍵來對下拉選項進行相應的切換，完成整個交互步驟，無需借助鼠標，能夠滿足極客用戶對於信息錄入的沉浸體驗。
2.4內容的屬性
一直大家在使用下拉時，都會存在很多問題。因為有很多內容的特性決定了它並不適合使用下拉菜單進行表達，比如我們舉一個很簡單的例子：
在一個購物平台的網站中，它的設計上是通過下拉菜單去選擇購買的數量以及對應的價格，這種小型的下拉使得整個購買流程都變得十分複雜，如果我們採取輸入數量的形式要比下拉菜單快速得多
三、日期與時間選擇的基礎拆解
3.1時間類型
因為時間存在這兩種不同表達方式，將其分為時間段選擇與時間點選擇
-
時間段選擇：選某一個時間範圍，一般包含開始時間與結束時間，比如（2020年10月22日至2021年03月16日）
主要在時間段運用中，是針對數據的篩選，常見於查看上一周銷售的業績、本季度的銷售任務完成情況等。
-
時間點選擇：選擇某一個時間節點，一般是設定好一個點過後去觸發某一件事。比如2021年03月16日19時11分我設置的鬧鐘響起，起床準備寫文章。
在我們拿到需求過後，就需要去明確時間類型，因為不同的時間類型代表著採取的控件、設計的思路也會截然不同。
3.2時間粒度
在明確完成時間類型過後粒度同樣需要考慮，你需要去思考產品類型從而帶來的時間粒度也不會相同。一般時間粒度為年、季、月、週、天、小時、分鐘、秒。
比如在儀錶盤主要針對銷售經理對銷售每天、每週、每月、每季度的業績進行管理，也因此在粒度上同樣需要去涵蓋到此粒度即可。同時對於一些雲產品對時間要求極為苛刻的，使用秒級單位也十分常見。
時間粒度也是大家容易忽略的一個問題，因為粒度的粗細將直接影響你的設計，因此在剛開始前一定要進行明確才行。
3.3時間狀態
在時間維度與粒度之外，還存在另一種狀態靜態與動態。
動態時間：隨著每天日期的更替，進行相應的變化。我舉一個例子，比如我在一個儀錶盤的設計中，我選擇動態時間去查看過去7天的數據情況，而設置完成動態時間過後。不管未來的哪一天，當我進入這個儀錶盤之後，都是過去7天的數據，這就是動態時間最為常見的使用場景。
靜態時間：也就是我們理解的常規意義上的時間，選擇了後不會跟隨變化。
動態時間較為特殊，一般出現的篩選功能、管理後台配置中，主要是方便用戶一次配置，長期使用的效果。
3.4輸入與選擇
首先，在之前在選擇器講到過的內容在日期選擇中同樣生效，在桌面端用戶的操作成本是：輸入>滑動>點擊>拖拽；
因此在日期選擇器中需要同時允許用戶通過點擊選擇時間以及通過輸入日期。
比如在你選擇自己的出生日期時，明顯通過輸入要比自己一個一個進行選擇效率要高，而由於日期格式有不同的格式：“2021/03/16”、“2021-03-16”、“ 2021.03.16”、“20210316”、“2021年03月16日”；
因此在設計一定要進行多方面的思考。當然輸入而言，針對的是一些時間跨度較大、並且是每一個選項之間也有很大的跨度的情況，比如說每個人的出生年月日，從1900 - 2020的年份跨越，並且還需要選擇月份以及日期，如果通過選擇顯然難度頗大，反而可以通過輸入的方式更為高效。
但別忘了一點，因為上面降到日期中有較為明顯的格式差異，我們一定提供一個默認規則，讓用戶知道規則情況，這樣能夠避免在使用的過程中格式不統一，導致系統無端增加的校驗成本
最後對於很多國際化的產品而言，還需要將時間日期的規則進行對應的調整。
3.5快捷選擇
在日期選擇中，快捷選擇也是其中重要的一部分，比如在常規的選擇中，經常加入“此刻、”
今天、本週、本月、30天前、90天前等
因為快捷選擇能夠在一定程度上滿足用戶的日常所需，比如我們來看看神策數據，當我們點擊日期篩選過後，神策數據會在其右側出現一個單獨的區域，用於放置許多快捷選擇項。通過快捷選擇項都會把用戶常用的情況進行覆蓋，只在極少數情況下需要單獨點擊進行選擇。
3.6日期時間段選擇的小迷思
這是我與整個產品組曾經爭論過的問題，雖然最後我被說服，給大家講講當時我們的爭論點以及事後的總結。
在時間段選擇的過程中，一直以來都有著兩種截然不同的交互形式，我簡單將兩個稱為：分體式與連體式（總感覺哪裡怪怪的- -!! ）
-
分體式：將開始時間與結束時間分開，通過兩個樣式相同的日期控件。當用戶選擇完開始時間後，結束時間將會自動展開，提供給用戶進行選擇
-
連體式：開始日期和結束日期使用一個組件展示，通過用戶的兩次點擊來進行決定其時間段關係。
那麼這兩種交互形式如何進行選擇？首先從交互場景上來講：
分體式：用戶通過兩次選擇，選擇明確的起始時間節點，來決定它的時間範圍。這個交互強調的是一個開始與結束時間點，多用於用戶已經明確自己的時間段，而不是一個模糊的時間範圍。比如我們在外出選擇酒店時間時，需要去選擇入住時間與離店時間，絕大多數交互形式都採取開始時間與結束時間進行展示。
連體式：用戶通過一次選擇，來選擇一個模糊的範圍時間段。其交互更強調某一個區域時間段。比如在我們篩選的情況中，是需要選擇是選擇某一段時間，並且需要經常切換，一次點擊能夠帶來更方便的使用。
從認知成本上來講：
分體式：顯然更為簡單，通過簡單描述的開始時間與結束時間，就可以直接進行選擇，不需要過多的思考
連體式：相對而言更加複雜，需要用戶對於整個操作基礎都有著較強的理解，不然需要一定的認知成本。但連體式整體交互明顯更為高效。
從實際運用場景上來講：
分體式：多用於出行、酒旅，比如飛豬、攜程等產品大多采取分體式，因為其用戶使用者水平參差不齊，且用戶都是明確時間段，因此分體式更為合適
連體式：多用於數據的篩選場景中，最主要是因為會選擇更多的是一段時間，且選擇時間段的概念也較為模糊，因此連體式更為合適。
最後，留給大家一個思考題
你知道，為什麼線上許多產品中（明道云、簡道云、ONES...） 呼出下拉菜單後，滾動表單都沒有跟隨錄入框嗎？
歡迎在評論區與我留言，下個文章給你解答~
我是CE青年，一個2 B 行業的2B 設計師～
往期文章推薦
