彈框，一個讓設(shè)計(jì)師和用戶又愛又恨的控件。產(chǎn)品需要彈框傳遞信息，用戶需要彈框接受反饋。但不經(jīng)推敲，胡亂增添彈框設(shè)計(jì)，用戶心流（Mental flow）頻頻被打斷，很容易讓用戶產(chǎn)生沮喪情緒。

我們在日常設(shè)計(jì)工作中，該如何設(shè)計(jì)合理的彈框？怎樣的彈框設(shè)計(jì)是優(yōu)秀的，而為什么有些彈框設(shè)計(jì)會讓用戶感到惱火？

我將分兩期來總結(jié)一下彈框的規(guī)范和進(jìn)階使用方法，歡迎持續(xù)跟進(jìn)。第一期我們先梳理一下平臺規(guī)范下的彈框究竟有哪些？

彈框的分類

在「彈框」的概念被泛化的當(dāng)下，我相信很多設(shè)計(jì)師都已經(jīng)開始分不清彈框的具體分類了。好像任何情況下彈出的窗口都被統(tǒng)稱為「彈框」，并且對于使用手法十分模糊。

實(shí)際上，縱觀 iOS 人機(jī)交互規(guī)范和 Material Design，我們可以將彈框分為兩大類：模態(tài)框和非模態(tài)框。

模態(tài)框

模態(tài)框（Modal Dialog）指代需要中斷用戶，用戶必須完成對話框內(nèi)任務(wù)（或主動關(guān)閉后）才能夠繼續(xù)主面板操作的彈框?！阜悄B(tài)」就是和「模態(tài)」對立的概念，指不需要中斷用戶操作的彈框。

良性的模態(tài)框其實(shí)可以輔助用戶順利完成任務(wù)，所以設(shè)計(jì)師務(wù)必要了解模態(tài)框究竟有哪些類型，以及它們的使用守則。

1. iOS - Alert 與 Material Design - Dialogs（對話框）

對話框的使用場合最為廣泛，也是最容易打斷用戶心流的彈框，因?yàn)樗苯映霈F(xiàn)在屏幕中心，所以雙平臺都明確提醒設(shè)計(jì)者要盡量克制對話框的使用頻次。

正是因?yàn)閷υ捒蚍浅Ｈ菀撰@取用戶注意力，所以一般用于承載非常重要的附加操作或警示信息。

關(guān)于對話框值得一提的是：因?yàn)楫a(chǎn)品設(shè)計(jì)過程中可以直接調(diào)用系統(tǒng)原生的對話框控件，所以許多設(shè)計(jì)師常常會忘記提醒開發(fā)人員配置引導(dǎo)用戶操作的高亮選項(xiàng)，導(dǎo)致我們經(jīng)常看到一些與產(chǎn)品設(shè)計(jì)意愿相違背的對話框。

例如為了激活沉睡用戶或采集一些用戶個性化信息，產(chǎn)品往往是希望獲取到用戶提醒、訪問等權(quán)限的，所以彈框中的操作引導(dǎo)通常應(yīng)該是正向的。但我們總是能看到一些啼笑皆非的案例。

所以設(shè)計(jì)者為了方便或者出于其他兼容性問題，而不得不調(diào)用原生對話框控件時，也不要疏忽對細(xì)節(jié)的把控。有時一個疏忽很可能會導(dǎo)致用戶和用戶體驗(yàn)的流失。

2. iOS - Action Sheet（動作面板）

Action Sheet 是 iOS 規(guī)范下的控件，近些年來也在慢慢被安卓化。

Action Sheet 是一個響應(yīng)控件，一般需要用戶執(zhí)行了某個操作才會彈出（某些危險(xiǎn)情況下，不需要用戶操作就直接彈出的模態(tài)框應(yīng)該使用 Alert/Dialog），并顯示一組與當(dāng)前操作有關(guān)的兩個或多個選項(xiàng)。Action Sheet 的出現(xiàn)方式是從屏幕底部向上滑出。

iOS 人機(jī)交互規(guī)范提醒設(shè)計(jì)者在使用 Action Sheet 時應(yīng)注意以下幾點(diǎn)：

突出破壞性選項(xiàng)：對于用戶執(zhí)行破壞性或危險(xiǎn)性操作的按鈕，應(yīng)當(dāng)使用紅色高亮顯示，并且放置在 Action Sheet 的頂部。

「取消」按鈕應(yīng)始終存在于動作面板的底部：雖然用戶可以點(diǎn)擊屏幕任意空白區(qū)域取消 Action Sheet，但「取消」按鈕可以在用戶不想執(zhí)行任何操作時，給予用戶明確的操作指向，所以不應(yīng)移除「取消」按鈕。

避免出現(xiàn)縱向滾動：滾動意味著操作項(xiàng)已經(jīng)多到溢出控件可視區(qū)域，用戶需要額外的時間來進(jìn)行選擇操作。但因?yàn)?Action Sheet 中每一個操作的橫向熱區(qū)都非常大，在滑動的過程當(dāng)中很容易發(fā)生誤觸。這個時候選擇使用 Activity Views 會更加合理。

3. iOS - Activity Views（活動試圖）

Activity Views 是 iOS 10 引進(jìn)的新規(guī)范控件。它的誕生是為了解決 Action Sheet 的滾動問題，所以也常被稱作是 Action Sheet 的宮格模式。

眾所周知，國內(nèi)最常見的 Activity Views 使用場景就是在分享或者使用第三方 App 打開文件時。

Activity Views 支持橫向滑動。相較于 Action Sheet 選項(xiàng)的熱區(qū)而言，Activity Views 的選項(xiàng)都被放置在一個只有 70px*70px 的色塊中，點(diǎn)擊熱區(qū)相對較小，適宜承載更多選項(xiàng)且不容易被用戶誤觸。

但我發(fā)現(xiàn)，目前調(diào)用 iOS 原生的 Activity Views 控件已經(jīng)可以融合宮格+列表的形式了，并且有一些 APP 已經(jīng)開始運(yùn)用。

個人認(rèn)為可能是因?yàn)槌休d的選項(xiàng)實(shí)在過多時，導(dǎo)致部分選項(xiàng)過于置后，用戶橫向滑動的時間過長，反而會讓用戶難以找到需要的操作。

iOS 既然支持組件的組合出現(xiàn)，想必也是考慮到了此類極端情況，所以具體的使用方法還是要設(shè)計(jì)師根據(jù)具體的場景隨機(jī)應(yīng)變。

4. iOS - Popovers（氣泡彈框）與 Material Design - Menus（情景菜單）

Popovers 通常是由一個指向其出現(xiàn)位置的三角箭頭和彈出窗口組成。iOS 規(guī)范中規(guī)定，Popovers 只適用于 iPad 中，但我們不難發(fā)現(xiàn)，跨平臺使用 Popovers 的場景早已屢見不鮮。

各類 APP 中最常見的 Popovers 使用場景就是信息提示與情景菜單，所以這是為什么我要把 iOS Popovers 與 MD Menus 歸為一類的原因。

MD - Menus 與 iOS - Popovers 實(shí)際上沒有太大的區(qū)別，只是沒有三角指向。但我個人認(rèn)為，有三角指向更容易讓用戶明確當(dāng)前彈框所包含的內(nèi)容與什么操作有關(guān)，其實(shí)對于用戶更加友好。

但 MD - Menus 畢竟是原生控件，樣式已不支持修改。所以在設(shè)計(jì)師設(shè)計(jì)個性化氣泡彈框的時候，可以多加改良。

非模態(tài)框

非模態(tài)框相較于模態(tài)框更不容易干擾到用戶操作，因?yàn)樵诜悄B(tài)框彈出時，用戶依然可以繼續(xù)操作主面板中的內(nèi)容。但非模態(tài)框也有它的缺點(diǎn)：出現(xiàn)時間短，不容易引發(fā)用戶關(guān)注；有時用戶還來不及閱讀完非模態(tài)框中的信息，它可能就已經(jīng)消失了。

iOS 和 MD 規(guī)范中定義的非模態(tài)框有以下幾種。

1. Material Design - Toast（吐司彈框）

Toast 是 MD 的規(guī)范控件，平臺規(guī)定 Toast 應(yīng)該出現(xiàn)在屏幕底部，并且只能包含盡量少的文字信息，不應(yīng)出現(xiàn)增加用戶認(rèn)知成本的圖標(biāo)等內(nèi)容。

針對前面說到的非模態(tài)框的缺點(diǎn)之一：有時用戶還來不及閱讀完非模態(tài)框中的信息，彈框就已經(jīng)消失了的情況，業(yè)界對吐司彈框施行了一個潛規(guī)則，認(rèn)為吐司彈框出現(xiàn)的時長最佳是 2 - 3.5 秒（即所謂的短吐司與長吐司）。在這個時間段內(nèi)不容易干擾用戶的同時，也有助于用戶閱讀完完整的提示信息。

2. iOS - HUD

實(shí)際上 iOS 的 HUD 彈框并沒有被收錄在平臺規(guī)范中，但大家一定不會陌生。例如 iOS 13 之前控制設(shè)備音量時出現(xiàn)的彈框就是 HUD 彈框。但因?yàn)?HUD 彈框體積太大，經(jīng)常會遮擋屏幕信息，在iOS 13 之后對此類彈框進(jìn)行了體驗(yàn)優(yōu)化，所以現(xiàn)在 HUD 彈框出現(xiàn)的場合已經(jīng)很少了。

但為什么要把 HUD 彈框單獨(dú)提出來講呢？前面講到 MD 規(guī)定 Toast 中不應(yīng)出現(xiàn)圖標(biāo)等元素，但現(xiàn)在許多 APP 自定義的 Toast 早已打破了這個規(guī)范。我認(rèn)為這個變化的啟蒙點(diǎn)，就是源自 HUD 彈框。

HUD 彈框一直是 iOS 系統(tǒng)私有的，無法被第三方應(yīng)用調(diào)用。所以很多 APP 開始模仿 HUD 彈框的樣式，演變出了如今花樣眾多的 Toast 彈框。

所以如今的 Toast 早已不僅是 MD 當(dāng)初規(guī)定的標(biāo)準(zhǔn) Toast 了，有時產(chǎn)品考慮到用戶情感化需求的場景，還是會加入一些自定義的元素。

3. Material Design - SnackBars

很有意思的是 SnackBars 最初被收錄在 MD 規(guī)范中時，被打上了「MD Only」的標(biāo)簽，有一種炫耀設(shè)計(jì)出這個控件的成就感。因?yàn)?SnackBars 是一個中和了模態(tài)框與非模態(tài)框?qū)傩缘膹椏?，在其他平臺規(guī)范中很鮮見。

常規(guī)的非模態(tài)框不支持操作，會自動消失；模態(tài)框是必須要用戶操作或手動關(guān)閉才會消失。而 SnackBars 是既支持用戶操作，又會自動消失的控件，一般出現(xiàn)在屏幕底部。

SnackBars 支持純文本提示與操作容器兩種模式。

如何辨別它與 Toast 呢？Google 翻譯做了很好的范例，SnakeBars 的彈框長度更長并且顯示時間更長，MD 規(guī)定 SnakeBars 的顯示時間應(yīng)該在 4 - 10 秒，提示內(nèi)容為純文本時時間可以稍短，需要用戶操作時時間應(yīng)該更長。

總結(jié)

模態(tài)框與非模態(tài)框都有各自的優(yōu)勢與不足，恰當(dāng)?shù)厥褂媚B(tài)框可以輔助用戶一步一步完成操作，但頻繁使用可能會讓用戶的操作流程被打擾。如果只從用戶心流的角度切入，非模態(tài)框應(yīng)該更加友好，但并不能承載操作，且有時又容易被用戶忽略。

所以如何找到合適、正確的彈框，是需要設(shè)計(jì)師根據(jù)具體場景進(jìn)行推敲的。

這一期我們主要了解了平臺規(guī)范下的模態(tài)框和非模態(tài)框的控件類型，在深入研究一個控件之前，我們必須先了解每一個控件自己的名稱和使用守則。下一期我會更深入地剖析優(yōu)秀的彈框案例。

往期回顧：

歡迎大家關(guān)注作者微信公眾號：「UCD耍家」