工作中我們常常會聽到或在撰寫交互說明時提到“從底部向上出現(xiàn)彈層”、“出現(xiàn)浮層”、展示“對話框”、彈出“彈框”、“出現(xiàn)對話框”諸如此類的話術(shù)。我相信大家對“浮層、彈層、彈框、對話框……”等稱呼常常也會感到困惑。到底什么時候應(yīng)該稱呼為“對話框，什么時候稱呼彈框”，此類相似的組件又是如何分類的，應(yīng)該如何應(yīng)用、如何設(shè)計。

恰好筆者近期在設(shè)計彈出層組件，本篇文章將結(jié)合自己的實戰(zhàn)經(jīng)歷，自己對彈出層組件的理解和設(shè)計經(jīng)驗分享給大家，希望幫助大家對彈出層組件有更清晰的認知和理解。

彈出層組件的定義

首先我們看一下彈出層組件的定義：當觸發(fā)某項操作時，在頁面上方展示的彈出層容器，容器內(nèi)可展示文本、按鈕、列表、標簽、表單項等內(nèi)容，英文名稱定義為 Popup。

△ 彈出層組件的構(gòu)成

根據(jù)彈出位置的不同，我們又可以將 Popup 組件細分為如下 5 種樣式。

△彈出層組件的 5 種樣式

看到彈出層組件的樣式，想必大家已經(jīng)聯(lián)想到日常用的比較多的組件了，比如“Alert 確認框，picker 選擇器、基于場景的篩選組件”等。彈出層組件是十分基礎(chǔ)的組件，基于該組件我們可以開發(fā)通用性組件以及場景組件。從“形式”角度來看，“浮層、彈層、彈框、對話框……”本質(zhì)上都是彈出層。

“浮層、彈層、彈框”是泛指的稱呼，兩大官方平臺也都根據(jù)自身的規(guī)范對相關(guān)組件進行命名。Material Design 和 iOS 官方規(guī)范中的彈出層組件如下圖所示，并且筆者從“功能”角度出發(fā)整理了組件之間的對應(yīng)關(guān)系。后文會詳述每種組件的定義及應(yīng)用。

△MD 和 iOS 規(guī)范中的彈出層組件

在詳述組件之前，還需要向大家傳達一個概念“模態(tài)”，即平時我們常說的“模態(tài)彈框”（彈框可理解為是彈出層的一種樣式）。并非有一種組件的分類被稱作是“模態(tài)彈框”，而是當彈框采用了“模態(tài)”的設(shè)計手法時，我們將其簡稱為“模態(tài)彈窗”。

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”

翻譯過來即：模態(tài)是一種設(shè)計手法，它使用一種臨時性的模式將用戶之前看到的內(nèi)容與當前看到的內(nèi)容進行區(qū)分，并且需要通過明確的操作才能退出該模式。模態(tài)呈現(xiàn)的內(nèi)容可以：

幫助用戶專注于一個獨立的任務(wù)或一組緊密相關(guān)的選項，確保用戶收到關(guān)鍵信息，并在必要時采取行動

由此可見，彈層是否為模態(tài)彈層可以根據(jù)具體的使用場景進行定義。在 iOS 官方中定義的模態(tài)彈層通常包括：Alerts, Activity Views ,Share sheets, and Action Sheets .iOS 13 及后續(xù)的系統(tǒng)中將 Fullsreen 也作為模態(tài)彈層進行使用。MD 中的 Dialogs 組件均為模態(tài)，而 sheets 組件不采用模態(tài)設(shè)計手法。

彈出層組件的分類與應(yīng)用

1. 警示型彈框

警示型彈框均采用從頁面中間進行彈層的方式，MD 和 iOS 中組件的樣式略有不同，但其使用場景和功能相同。都是在重要信息提示、需要用戶確認的操作、以及破壞性操作之前進行提示，警示型彈窗會中斷用戶的任務(wù)流程，影響用戶體驗，因此需注意其使用頻率。

△警示型彈框 Alert Dialog

使用場景：通常在系統(tǒng)級信息的提示，例如權(quán)限的獲取、系統(tǒng)通知，需要明確告知用戶的信息，以及破壞性操作前使用。

△警示型彈框應(yīng)用

2. 任務(wù)型彈層

根據(jù)用戶在彈層中需要完成的任務(wù)內(nèi)容和任務(wù)數(shù)量，又可分為簡單型和復雜型彈層。

簡單型彈層

常用于在彈層中展示內(nèi)容，需要用戶進行選擇的場景，該場景通常只需要用戶完成一種任務(wù)，比如通過點擊的方式，完成信息的選擇或分享。在 iOS 中采用從底部向上彈層的方式，而安卓平臺多使用在頁面中間彈層的方式。

彈層中是否存在操作按鈕可根據(jù)實際應(yīng)用場景去確定。通常選擇項條目較少或內(nèi)容簡單易于識別時，可不需要「確認」按鈕。而在選擇項條目較多時或需要用戶作短暫的思考才能確認選項時，可增加「確認」按鈕，允許用戶有修改選項的機會。

△簡單型任務(wù)彈層的組件樣式

△簡單型任務(wù)彈層的組件樣式

彈層中信息的呈現(xiàn)方式又可分為“列表”和“網(wǎng)格”兩種，大多種場景下，均可使用列表展示內(nèi)容，更加符合用戶從上到下的閱讀習慣；而在分享場景下多通過網(wǎng)格的方式將分享渠道展示出來，增加屏顯的內(nèi)容，同時提高用戶查看信息的效率，具體樣式可參考上圖。

使用場景：簡單型彈層多用在信息的篩選、排序和信息確認的場景下使用。且在目前市面上的絕大多數(shù)應(yīng)用中，除原生的安卓應(yīng)用外，大部分應(yīng)用都采用從底部向上彈層和從頂部向下彈層的方式。

△簡單型任務(wù)彈層的應(yīng)用

復雜型彈層

復雜型彈層中通常承載的信息量更豐富，包含多種組件，需要用戶完成一系列的任務(wù)。

涉及到信息篩選時，通常采用側(cè)邊彈層組件進行展示，且彈層上的信息僅支持垂直滾動查看，不支持水平滾動查看，且通常采用“非模態(tài)”的手法，方便用戶快速取消當前彈層。在 iOS 中并無“Sheets:side”組件，但是在 iOS 系統(tǒng)中，很多 APP 應(yīng)用在復雜的篩選場景下也都采用側(cè)邊彈層的方式。

全屏彈層會將當前頁面中的全部信息遮擋，更方便用戶聚焦于當前需要完成的任務(wù)，避免用戶的注意力被分散。通常采用模態(tài)的設(shè)計手法，僅當用戶觸發(fā)確認、取消或關(guān)閉操作時，彈層才會消失。一般全屏彈層中需要包含標題、操作按鈕、內(nèi)容區(qū)域。用戶在全屏彈層中需要完成多個任務(wù)，因此內(nèi)容區(qū)域中也會包含多個組件。例如“按鈕、輸入框、標簽、開關(guān)、列表、日期選擇”等。

△復雜型任務(wù)彈層的組件樣式

使用場景：通常用于完成復雜任務(wù)的表單信息填寫、內(nèi)容篩選、搜索和內(nèi)容展示。

△復雜型任務(wù)彈層的應(yīng)用

需要單獨說明氣泡框組件

在 iOS 的官方定義中，氣泡框組件應(yīng)用于 iPad 應(yīng)用程序，在 iPhone 應(yīng)用程序中，通過以全屏模態(tài)視圖而非彈出框形式顯示信息，來利用所有可用的屏幕空間。但是，組件被定義后并不是一成不變的，而是隨實際場景進行應(yīng)用的。例如，在手機端，氣泡框組件更多被用于簡單信息的展示與選擇。

△Popovers 氣泡框的應(yīng)用

小結(jié)：

筆者按照使用場景、信息的復雜度、功能的相似度等，將彈出層組件歸納為兩大類“警示型和任務(wù)型”，并且枚舉了常用的 MD（安卓系統(tǒng)遵循的規(guī)范）和 iOS 兩大規(guī)范中定義的彈出層組件，方便讀者對彈出層組件有更清晰的了解。需要說明的是，由于業(yè)務(wù)場景是復雜的、多樣的，各位設(shè)計師也需要結(jié)合實際的業(yè)務(wù)場景和設(shè)計目標，靈活的使用組件。

△彈出層組件的類型與使用場景

如何設(shè)計彈出層組件

1. 設(shè)計目的

首先需要理解我們?yōu)槭裁匆O(shè)計組件，組件最終設(shè)計的目標是什么，筆者從“設(shè)計側(cè)和技術(shù)側(cè)”兩方面談?wù)勛约旱睦斫狻?

設(shè)計側(cè)：規(guī)范的組件設(shè)計，對內(nèi)有利于全公司的設(shè)計師對組件的使用有統(tǒng)一的認知，明確組件的使用場景，避免誤用和錯用組件，并且方便新人設(shè)計師快速學習和上手，提高設(shè)計效率。對外也有利于保證設(shè)計上線后的一致性和規(guī)范性，方便用戶對本公司產(chǎn)品建立統(tǒng)一的心理認知。

技術(shù)側(cè)：通用的基礎(chǔ)組件，具有可復用性，能夠減少重復開發(fā)，大大提高開發(fā)效率。

組件設(shè)計的最終目標可歸納為保持設(shè)計的統(tǒng)一性，提升用戶體驗，同時提高設(shè)計和開發(fā)的效率。因此，組件設(shè)計是非常有必要的，那么到底如何從 0-1 開始設(shè)計組件呢，下面我們來看組件設(shè)計的詳細思路。

2. 設(shè)計思路

其實組件設(shè)計的基本思路是通用的，不僅適用于彈出層組件，還適用于其他基礎(chǔ)組件的設(shè)計。通常我們會從組件的定義、用法、構(gòu)成、種類、行為與狀態(tài)五個方面進行組件的設(shè)計。

△組件設(shè)計的思路

• 定義：通過精準的話術(shù)描寫組件的內(nèi)容與目的。
• 用法：組件包含的內(nèi)容、出現(xiàn)的位置、信息展示的規(guī)則等。
• 構(gòu)成：通過示意圖展示組件包含的具體信息，例如標題、按鈕、內(nèi)容區(qū)等。
• 種類：根據(jù)一定的規(guī)則對組件進行分類。
• 行為與狀態(tài)：使用組件的整個交互流程與交互邏輯說明；組件的狀態(tài)說明，例如 normal 態(tài)、click 態(tài)，disable 態(tài)，滾動時的頁面狀態(tài)等。

回歸到本文所講的移動端彈出層組件，組件設(shè)計時需要考慮其“通用性和可復用性”?；诖嗽瓌t，將彈出層組件進行拆解，如下圖所示。它包括：

• 遮罩層：覆蓋底部頁面上的內(nèi)容，方便用戶聚焦當前彈層上的信息
• 容器層：承載內(nèi)容的容器
• 內(nèi)容層：容器里的內(nèi)容，不同區(qū)塊的內(nèi)容可單獨封裝

△彈出層組件的拆解

從上圖中可看出，本文第一部分提出的 Popup 組件是最基本的彈出層組件，基于該組件可進行任何彈層組件的開發(fā)。因此，在彈層組件設(shè)計時將 Popup 組件抽離出來作為最基礎(chǔ)的組件進行開發(fā)， 還可以進一步開發(fā)通用的彈層組件和高頻使用的場景組件。由于上文中已講 Popoup 組件的構(gòu)成與樣式，且由于該組件相對來講比較簡單，因此不過多贅述。下面以通用組件“Picker 選擇器”和篩選場景下的高頻組件“篩選器 Filter”為例進行說明。

設(shè)計實戰(zhàn)

1. Picker 選擇器

定義：用于從一組預設(shè)數(shù)據(jù)中進行選擇的控件。

用法：

• 選擇器通常顯示在屏幕底部或彈出窗口中。
• 通常包含 2 個操作按鈕“取消和確定”，按鈕名稱支持修改。
• 可自定義設(shè)置是否顯示標題。
• 支持單列選擇和多列選擇，多列選擇一般不超過 4 列，且多列值之間可配置其級聯(lián)關(guān)系。

構(gòu)成：標題、按鈕、內(nèi)容（當前選項和其他選項）

△Picker 選擇器組件的構(gòu)成

種類：根據(jù)選項間是否存在級聯(lián)關(guān)系可將其分為 2 類，普通選擇和級聯(lián)選擇。

△Picker 選擇器組件的分類

行為與狀態(tài)：狀態(tài)，給出單列選項和多列選項的常態(tài)頁面以及選項被禁用的狀態(tài)頁面。行為，需要定義完整的組件交互邏輯，從入口->彈層出現(xiàn)->選項查看->選擇目標選項->彈層消失的完整邏輯進行說明。

△Picker 選擇器組件的狀態(tài)

△Picker 選擇器組件的交互流程與行為說明

當完成以上全部內(nèi)容的撰寫時，可對本組件開發(fā)出的效果進行說明。例如：

• 普通選擇（以單列選擇示例，默認項為第一個選項）
• 普通選擇（以 2 列選擇示例，默認項為每列的第一個選項）
• 多列選擇無級聯(lián)關(guān)系（以日期選擇年、月、日示例，3 列選擇，默認項為當天）
• 多列選擇存在級聯(lián)關(guān)系（以城市選擇為例，3 列選擇，默認項為每列的第一個選項）。如此的說明會讓技術(shù)同學本次組件的產(chǎn)出示例更加清晰，可減少開發(fā)過程中的溝通成本。

2. Filter 篩選器

Filter 組件是基于公司移動端產(chǎn)品均存在的高頻“篩選”場景而總結(jié)的場景（業(yè)務(wù)）組件，其設(shè)計思路和上方描述的通用組件的設(shè)計思路相同，筆者此處只強調(diào) 2 個重點注意事項。

場景組件在設(shè)計時遵循“加法”邏輯，從而提升組件的復用率。組件內(nèi)容分區(qū)塊進行封裝，從而增加組件的靈活性。

△篩選器組件

在上圖所示的篩選場景中，單類目和多類目篩選若均為高頻的使用場景，那么單類目和多類目篩選組件均可以抽離成組件并進行開發(fā)，且多類目篩選可基于單類目篩選組件進行開發(fā)。但是多類目篩選組件是無法覆蓋單類目篩選組件的，組件開發(fā)不同于設(shè)計稿，設(shè)計稿可將多個類目刪除掉只剩余單個類目，但是組件的代碼邏輯不遵循此刪除邏輯。在原有組件的代碼上修改的開發(fā)成本要高于重新開發(fā)組件。因此，如果要修改多類目篩選組件的邏輯，不如重新開發(fā)出單類目篩選的組件。這也是需要我們牢記的，組件設(shè)計需要從“原子組件到復雜組件”，遵循由“簡單到復雜”的加法邏輯。

而在組件開發(fā)時通過“goup”的形式進行封裝，可使組件更加靈活。例如，當業(yè)務(wù)場景是需要通過“輸入框”組件輸入篩選條件，只要將 Group 中的內(nèi)容改為“輸入框組件”，即只需修改該 group 下的代碼即可，篩選器組件的其他邏輯仍然可復用，這就提高了組件的通用性和復用率。

當然，F(xiàn)ilter 組件還需要考慮很多設(shè)計細節(jié)，例如類目名稱是否顯示為當前篩選項名稱、重置的邏輯是什么、確認篩選后頁面信息會如何變化、篩選項支持單選還是多選等等。復雜的場景組件通常是由多個原子組件組合而成，因此組件的邏輯也更為復雜，組件設(shè)計的整體流程和交互細節(jié)也應(yīng)考慮的更加全面。

文章來源：優(yōu)設(shè)網(wǎng)   作者：土撥鼠

藍藍設(shè)計( www.cqzjtgb.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)