2021-3-17 鶴鶴
工作中我們常常會聽到或在撰寫交互說明時提到“從底部向上出現彈層”、“出現浮層”、展示“對話框”、彈出“彈框”、“出現對話框”諸如此類的話術。我相信大家對“浮層、彈層、彈框、對話框……”等稱呼常常也會感到困惑。到底什么時候應該稱呼為“對話框，什么時候稱呼彈框”，此類相似的組件又是如何分類的，應該如何應用、如何設計。
恰好筆者近期在設計彈出層組件，本篇文章將結合自己的實戰經歷，自己對彈出層組件的理解和設計經驗分享給大家，希望幫助大家對彈出層組件有更清晰的認知和理解。
首先我們看一下彈出層組件的定義：當觸發某項操作時，在頁面上方展示的彈出層容器，容器內可展示文本、按鈕、列表、標簽、表單項等內容，英文名稱定義為 Popup。
△ 彈出層組件的構成
根據彈出位置的不同，我們又可以將 Popup 組件細分為如下 5 種樣式。
△彈出層組件的 5 種樣式
看到彈出層組件的樣式，想必大家已經聯想到日常用的比較多的組件了，比如“Alert 確認框，picker 選擇器、基于場景的篩選組件”等。彈出層組件是十分基礎的組件，基于該組件我們可以開發通用性組件以及場景組件。從“形式”角度來看，“浮層、彈層、彈框、對話框……”本質上都是彈出層。
“浮層、彈層、彈框”是泛指的稱呼，兩大官方平臺也都根據自身的規范對相關組件進行命名。Material Design 和 iOS 官方規范中的彈出層組件如下圖所示，并且筆者從“功能”角度出發整理了組件之間的對應關系。后文會詳述每種組件的定義及應用。
△MD 和 iOS 規范中的彈出層組件
在詳述組件之前，還需要向大家傳達一個概念“模態”，即平時我們常說的“模態彈框”（彈框可理解為是彈出層的一種樣式）。并非有一種組件的分類被稱作是“模態彈框”，而是當彈框采用了“模態”的設計手法時，我們將其簡稱為“模態彈窗”。
iOS 官方定義為：
“Modality is a design technique that presents content in a temporary mode that’s separate from the user’s previous current context and requires an explicit action to exit. Presenting content modally can:
Help people focus on a self-contained task or set of closely related options
Ensure that people receive and, if necessary, act on critical information”
翻譯過來即：模態是一種設計手法，它使用一種臨時性的模式將用戶之前看到的內容與當前看到的內容進行區分，并且需要通過明確的操作才能退出該模式。模態呈現的內容可以：
幫助用戶專注于一個獨立的任務或一組緊密相關的選項，確保用戶收到關鍵信息，并在必要時采取行動
由此可見，彈層是否為模態彈層可以根據具體的使用場景進行定義。在 iOS 官方中定義的模態彈層通常包括：Alerts, Activity Views ,Share sheets, and Action Sheets .iOS 13 及后續的系統中將 Fullsreen 也作為模態彈層進行使用。MD 中的 Dialogs 組件均為模態，而 sheets 組件不采用模態設計手法。
警示型彈框均采用從頁面中間進行彈層的方式，MD 和 iOS 中組件的樣式略有不同，但其使用場景和功能相同。都是在重要信息提示、需要用戶確認的操作、以及破壞性操作之前進行提示，警示型彈窗會中斷用戶的任務流程，影響用戶體驗，因此需注意其使用頻率。
△警示型彈框 Alert Dialog
使用場景：通常在系統級信息的提示，例如權限的獲取、系統通知，需要明確告知用戶的信息，以及破壞性操作前使用。
△警示型彈框應用
根據用戶在彈層中需要完成的任務內容和任務數量，又可分為簡單型和復雜型彈層。
簡單型彈層
常用于在彈層中展示內容，需要用戶進行選擇的場景，該場景通常只需要用戶完成一種任務，比如通過點擊的方式，完成信息的選擇或分享。在 iOS 中采用從底部向上彈層的方式，而安卓平臺多使用在頁面中間彈層的方式。
彈層中是否存在操作按鈕可根據實際應用場景去確定。通常選擇項條目較少或內容簡單易于識別時，可不需要「確認」按鈕。而在選擇項條目較多時或需要用戶作短暫的思考才能確認選項時，可增加「確認」按鈕，允許用戶有修改選項的機會。
△簡單型任務彈層的組件樣式
△簡單型任務彈層的組件樣式
彈層中信息的呈現方式又可分為“列表”和“網格”兩種，大多種場景下，均可使用列表展示內容，更加符合用戶從上到下的閱讀習慣；而在分享場景下多通過網格的方式將分享渠道展示出來，增加屏顯的內容，同時提高用戶查看信息的效率，具體樣式可參考上圖。
使用場景：簡單型彈層多用在信息的篩選、排序和信息確認的場景下使用。且在目前市面上的絕大多數應用中，除原生的安卓應用外，大部分應用都采用從底部向上彈層和從頂部向下彈層的方式。
△簡單型任務彈層的應用
復雜型彈層
復雜型彈層中通常承載的信息量更豐富，包含多種組件，需要用戶完成一系列的任務。
涉及到信息篩選時，通常采用側邊彈層組件進行展示，且彈層上的信息僅支持垂直滾動查看，不支持水平滾動查看，且通常采用“非模態”的手法，方便用戶快速取消當前彈層。在 iOS 中并無“Sheets:side”組件，但是在 iOS 系統中，很多 APP 應用在復雜的篩選場景下也都采用側邊彈層的方式。
全屏彈層會將當前頁面中的全部信息遮擋，更方便用戶聚焦于當前需要完成的任務，避免用戶的注意力被分散。通常采用模態的設計手法，僅當用戶觸發確認、取消或關閉操作時，彈層才會消失。一般全屏彈層中需要包含標題、操作按鈕、內容區域。用戶在全屏彈層中需要完成多個任務，因此內容區域中也會包含多個組件。例如“按鈕、輸入框、標簽、開關、列表、日期選擇”等。
△復雜型任務彈層的組件樣式
使用場景：通常用于完成復雜任務的表單信息填寫、內容篩選、搜索和內容展示。
△復雜型任務彈層的應用
需要單獨說明氣泡框組件
在 iOS 的官方定義中，氣泡框組件應用于 iPad 應用程序，在 iPhone 應用程序中，通過以全屏模態視圖而非彈出框形式顯示信息，來利用所有可用的屏幕空間。但是，組件被定義后并不是一成不變的，而是隨實際場景進行應用的。例如，在手機端，氣泡框組件更多被用于簡單信息的展示與選擇。
△Popovers 氣泡框的應用
小結：
筆者按照使用場景、信息的復雜度、功能的相似度等，將彈出層組件歸納為兩大類“警示型和任務型”，并且枚舉了常用的 MD（安卓系統遵循的規范）和 iOS 兩大規范中定義的彈出層組件，方便讀者對彈出層組件有更清晰的了解。需要說明的是，由于業務場景是復雜的、多樣的，各位設計師也需要結合實際的業務場景和設計目標，靈活的使用組件。
△彈出層組件的類型與使用場景
1. 設計目的
首先需要理解我們為什么要設計組件，組件最終設計的目標是什么，筆者從“設計側和技術側”兩方面談談自己的理解。
設計側：規范的組件設計，對內有利于全公司的設計師對組件的使用有統一的認知，明確組件的使用場景，避免誤用和錯用組件，并且方便新人設計師快速學習和上手，提高設計效率。對外也有利于保證設計上線后的一致性和規范性，方便用戶對本公司產品建立統一的心理認知。
技術側：通用的基礎組件，具有可復用性，能夠減少重復開發，大大提高開發效率。
組件設計的最終目標可歸納為保持設計的統一性，提升用戶體驗，同時提高設計和開發的效率。因此，組件設計是非常有必要的，那么到底如何從 0-1 開始設計組件呢，下面我們來看組件設計的詳細思路。
2. 設計思路
其實組件設計的基本思路是通用的，不僅適用于彈出層組件，還適用于其他基礎組件的設計。通常我們會從組件的定義、用法、構成、種類、行為與狀態五個方面進行組件的設計。
△組件設計的思路
回歸到本文所講的移動端彈出層組件，組件設計時需要考慮其“通用性和可復用性”?；诖嗽瓌t，將彈出層組件進行拆解，如下圖所示。它包括：
△彈出層組件的拆解
從上圖中可看出，本文第一部分提出的 Popup 組件是最基本的彈出層組件，基于該組件可進行任何彈層組件的開發。因此，在彈層組件設計時將 Popup 組件抽離出來作為最基礎的組件進行開發， 還可以進一步開發通用的彈層組件和高頻使用的場景組件。由于上文中已講 Popoup 組件的構成與樣式，且由于該組件相對來講比較簡單，因此不過多贅述。下面以通用組件“Picker 選擇器”和篩選場景下的高頻組件“篩選器 Filter”為例進行說明。
1. Picker 選擇器
定義：用于從一組預設數據中進行選擇的控件。
用法：
構成：標題、按鈕、內容（當前選項和其他選項）
△Picker 選擇器組件的構成
種類：根據選項間是否存在級聯關系可將其分為 2 類，普通選擇和級聯選擇。
△Picker 選擇器組件的分類
行為與狀態：狀態，給出單列選項和多列選項的常態頁面以及選項被禁用的狀態頁面。行為，需要定義完整的組件交互邏輯，從入口->彈層出現->選項查看->選擇目標選項->彈層消失的完整邏輯進行說明。
△Picker 選擇器組件的狀態
△Picker 選擇器組件的交互流程與行為說明
當完成以上全部內容的撰寫時，可對本組件開發出的效果進行說明。例如：
2. Filter 篩選器
Filter 組件是基于公司移動端產品均存在的高頻“篩選”場景而總結的場景（業務）組件，其設計思路和上方描述的通用組件的設計思路相同，筆者此處只強調 2 個重點注意事項。
場景組件在設計時遵循“加法”邏輯，從而提升組件的復用率。組件內容分區塊進行封裝，從而增加組件的靈活性。
△篩選器組件
在上圖所示的篩選場景中，單類目和多類目篩選若均為高頻的使用場景，那么單類目和多類目篩選組件均可以抽離成組件并進行開發，且多類目篩選可基于單類目篩選組件進行開發。但是多類目篩選組件是無法覆蓋單類目篩選組件的，組件開發不同于設計稿，設計稿可將多個類目刪除掉只剩余單個類目，但是組件的代碼邏輯不遵循此刪除邏輯。在原有組件的代碼上修改的開發成本要高于重新開發組件。因此，如果要修改多類目篩選組件的邏輯，不如重新開發出單類目篩選的組件。這也是需要我們牢記的，組件設計需要從“原子組件到復雜組件”，遵循由“簡單到復雜”的加法邏輯。
而在組件開發時通過“goup”的形式進行封裝，可使組件更加靈活。例如，當業務場景是需要通過“輸入框”組件輸入篩選條件，只要將 Group 中的內容改為“輸入框組件”，即只需修改該 group 下的代碼即可，篩選器組件的其他邏輯仍然可復用，這就提高了組件的通用性和復用率。
當然，Filter 組件還需要考慮很多設計細節，例如類目名稱是否顯示為當前篩選項名稱、重置的邏輯是什么、確認篩選后頁面信息會如何變化、篩選項支持單選還是多選等等。復雜的場景組件通常是由多個原子組件組合而成，因此組件的邏輯也更為復雜，組件設計的整體流程和交互細節也應考慮的更加全面。
文章來源：優設網 作者：土撥鼠
藍藍設計( m.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務