彈框，一個(gè)讓設(shè)計(jì)師和用戶又愛又恨的控件。產(chǎn)品需要彈框傳遞信息，用戶需要彈框接受反饋。但如果不經(jīng)推敲，胡亂增添彈框設(shè)計(jì)，用戶心流（Mental flow）頻頻被打斷，很容易讓用戶產(chǎn)生沮喪情緒。我們?cè)谌粘ＴO(shè)計(jì)工作中，該如何設(shè)計(jì)合理的彈框？怎樣的彈框設(shè)計(jì)是優(yōu)秀的，而為什么有些彈框設(shè)計(jì)會(huì)讓用戶感到惱火？本文將為大家揭曉答案。

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

一、彈框的分類

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

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

二、模態(tài)框

模態(tài)框：Modal Dialog。指代需要中斷用戶，用戶必須完成對(duì)話框內(nèi)任務(wù)（或主動(dòng)關(guān)閉后）才能夠繼續(xù)主面板操作的彈框。“非模態(tài)”就是和“模態(tài)”對(duì)立的概念，指不需要中斷用戶操作的彈框。

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

2.1 iOS – Alert 與 Material Design – Dialogs（對(duì)話框）

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

正是因?yàn)閷?duì)話框非常容易獲取用戶注意力，所以一般用于承載非常重要的附加操作或警示信息。

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

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

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

2.2 iOS – Action Sheet（動(dòng)作面板）

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

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

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

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

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

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

2.3 iOS – Activity Views（活動(dòng)試圖）

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

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

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

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

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

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

2.4 iOS – Popovers（氣泡彈框）與 Material Design – Menus（情景菜單）

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

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

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

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

三、非模態(tài)框

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

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

3.1 Material Design – Toast（吐司彈框）

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

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

3.2 iOS – HUD（是否是“Heads Up Display：抬頭顯示”的縮寫還有待考量）

實(shí)際上iOS的HUD彈框并沒有被收錄在平臺(tái)規(guī)范中。但大家一定不會(huì)陌生，例如iOS 13之前控制設(shè)備音量時(shí)出現(xiàn)的彈框就是HUD彈框。但因?yàn)镠UD彈框體積太大，經(jīng)常會(huì)遮擋屏幕信息，在iOS 13之后iOS對(duì)此類彈框進(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早已打破了這個(gè)規(guī)范。我認(rèn)為這個(gè)變化的啟蒙點(diǎn)，就是源自HUD彈框。

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

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

3.3 Material Design – SnakeBars

很有意思的是 SnakeBars 最初被收錄在MD規(guī)范中時(shí)，被打上了 “MD Only”的標(biāo)簽，有一種炫耀設(shè)計(jì)出這個(gè)控件的成就感。因?yàn)镾nakeBars是一個(gè)中和了模態(tài)框與非模態(tài)框?qū)傩缘膹椏颍谄渌脚_(tái)規(guī)范中很鮮見。

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

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

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

四、總結(jié)

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

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

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

作者：UCD耍家；公眾號(hào)：UCD耍家（ID：ucdplayer）

本文由 @UCD耍家 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議