編輯導(dǎo)語：在日常生活中，我們經(jīng)常會使用到手機。每當(dāng)我們打開一個APP時，總能夠發(fā)現(xiàn)在APP底部彈出的控件，你是否有注意到它們之間有何區(qū)別？怎樣的彈出控件設(shè)計才是令人喜歡的？作者分享了一些關(guān)于APP底部彈出控件的交互規(guī)則，我們一起來看看吧。

APP中從底部彈出的控件，因其自定義用法十分靈活，已經(jīng)逐漸成為控件庫中重要的基礎(chǔ)建設(shè)。不過，面對市場上各式各樣的用法，我們應(yīng)該編寫一套什么樣的規(guī)則，能夠更好的駕馭這些控件，讓它們的體驗更一致、使用更清晰呢？本文和大家分享我的思考過程。

一、常見的“自定義”用法

現(xiàn)在“底部彈出控件”的自定義用法很豐富，并且一些新用法和其使用場景有著很高的契合度。

基于大體量APP呈現(xiàn)出的“界面元素、功能過飽和”現(xiàn)狀，我們的設(shè)計并沒有一味拘泥于iOS/安卓的使用建議，而是充分發(fā)揮了“底部彈出控件”的靈活性。

不過“靈活”的另一面，是給控件用法的統(tǒng)一帶來了難度。以下歸類主要覆蓋了“自定義”用法使用率較高的5種情形。

1. 收納

收納是最常見的場景，因為涵蓋的情況難以用一種歸類完全承載，所以我分別按照使用目的、交互形式和生效機制進行了歸類。

下面配合一些線上例子，來呈現(xiàn)這些用法（“動作菜單”與“數(shù)據(jù)項菜單”會在后文中詳述，此處略過）。

（1）收納信息

這個用法很好理解，但是同時我們也發(fā)現(xiàn)，底部面板的退出方式，3家產(chǎn)品已經(jīng)存在3種不同的規(guī)則：點擊“完成”、左側(cè)點擊“關(guān)閉”、右側(cè)點擊“關(guān)閉”。關(guān)于如何保持一致的問題，在后面“模態(tài)的退出方式”中會展開詳述。

（2）收納服務(wù)

該用法最早源于對iOS中“Activiy View”的自定義，現(xiàn)在根據(jù)各業(yè)務(wù)不同訴求，運用的越來越成熟。乍看上去樣式五花八門，本質(zhì)上都是對當(dāng)前場景所提供服務(wù)的一種收納。

用法并不復(fù)雜，做好主次層級的劃分、保證每個功能的合理去向，以及兼顧全端的一致性即可。

（3）常駐于底部、由界面元素觸發(fā)

（4）即時生效、非即時生效

關(guān)于生效機制，剛好可以在飛書中分別找到對應(yīng)的案例，這樣我們可以更直觀理解它們的不同之處。

即時生效：進行操作→面板收起→操作生效

有一種情況面板不會自動收起，即面板中的操作選項較多、且每個選項對應(yīng)不同的界面效果，如果次次點擊都收起面板反而效率很低。這種情況下，可以讓用戶自行決定關(guān)閉面板的時機。

非即時生效：所有操作需要點擊“確認”/“完成”才可生效

• 操作單一：常用于篩選、提交申請、確認支付等場景。
• 操作多元：常用于編輯、設(shè)置等場景，操作類型除了數(shù)據(jù)的勾選和輸入，一般還會涉及添加、刪除、排序等。

2. 響應(yīng)、詢問

（1）即時響應(yīng)

移動設(shè)備中的即時型反饋，一般使用 Toast 和 Snackbar 就夠用了。不過有些情況，需要底部面板來幫忙：在圖表/工具類場景中，存在這樣一種交互形式，即隨著手指完成操作、離開屏幕，會觸發(fā)

某個控件的彈出。比如案例中的k線圖場景（下圖左一），手指完成2個位置的點擊后，底部面板隨即彈出。用戶可以邊對照k線圖、邊查看面板中的數(shù)據(jù)，操作完成后點擊關(guān)閉退出“區(qū)間統(tǒng)計”。

（2）主動詢問

現(xiàn)在我們都知道，在一個任務(wù)完成的節(jié)點提供反饋是必要的。不過還可以再進一步，如果該反饋節(jié)點存在一些關(guān)聯(lián)性很強的功能，我們可以通過“底部彈出控件”進行自然的銜接和有效的聚合。

銜接：

例①：在“高德地圖”完成一個訂單的支付后，APP會立即彈出面板，以主動詢問的方式，收集某個問題的用戶反饋。由于該設(shè)計有助于提升乘客的打車體驗，通常參與度比較高（下圖左二）。

例②：在“豆瓣”收藏內(nèi)容成功后，底部面板除了提供反饋，以主動詢問的方式，提醒用戶填寫本次收藏的理由、以免遺忘。該設(shè)計對于幫助用戶管理雜亂的收藏，是很有效的（下圖左三）。

聚合：

例如在“天天基金”進行截屏操作時，會觸發(fā)APP立即彈出面板，詢問用戶當(dāng)前是想對截屏內(nèi)容進行分享、還是意見反饋、或帶著截圖發(fā)帖至社區(qū)。這幾項功能的關(guān)聯(lián)與聚合，都達到了快捷、有效的目的（下圖左四）。

3. 連續(xù)

使用“底部彈出控件”來承載一系列連續(xù)的動作、或者一個流程簡單的小任務(wù)，已逐漸形成趨勢。其最大的好處就是保證了步驟間的連續(xù)性。

試想在一個流程中，一會兒彈Alert、一會兒打開新頁面、一會兒左/右呼出抽屜，和全部使用“底部彈出控件”的順滑體驗相比，在“連續(xù)性”上相差還是比較大的。

連續(xù)，意味著開始出現(xiàn)多個層級。我在這里試著給出2個使用判斷上的建議，供大家討論、參考。

判斷1：在層級較深的頁面，承載多項任務(wù)

像微信這樣同時兼顧“工具”與“內(nèi)容”的超級App，用戶經(jīng)常會被帶到層級較深的頁面、臨時跳出當(dāng)前場景完成一些任務(wù)。比如在支付場景去“添加新銀行卡”、在閱讀場景去“分享到朋友圈”、在發(fā)布場景“選擇可見范圍”等。

微信中大量使用“底部彈出控件”，通過一致、連續(xù)的交互，來降低用戶“離開當(dāng)下”的感受，讓用戶感覺他仍在此處、掌控著一切。信息結(jié)構(gòu)的復(fù)雜并沒有消失，它只是被設(shè)計者巧妙的“分解”了。

如上圖中的“設(shè)置備注和標(biāo)簽”功能，微信在“新建標(biāo)簽”的控件上做了獨到的改造，幫助用戶專注眼前任務(wù)，提高效率。相比較常見的Alert/Dialog（上圖右一），使用“底部彈出控件”的連續(xù)性會好一些。

判斷2：在沉浸型場景，承載多個功能

每類產(chǎn)品的沉浸場景不同，但是他們對功能呼出方式的訴求是一致的，即盡量不離開當(dāng)下、盡量連續(xù)。無論是股票產(chǎn)品的行情場景（下圖左側(cè)）還是音樂產(chǎn)品的播放場景（下圖右側(cè)），除了必要的跳轉(zhuǎn)，都會見到大量“底部彈出控件”的使用。

內(nèi)容社交型產(chǎn)品Instagram也是如此，內(nèi)容流和個人主頁是它的主要分發(fā)陣地，使用“底部彈出控件”來安置這些常規(guī)功能，滿足了“不離開當(dāng)下、繼續(xù)瀏覽”的需求。

4. 并行

如果我們把移動設(shè)備的屏幕比作一個有限的容器、把屏幕上流動的內(nèi)容比作一張紙的話，那么就會出現(xiàn)：

這張紙的長度有時會很長，而同時瀏覽紙上內(nèi)容的人又想邊瀏覽、邊參與討論或者看點其他內(nèi)容。如果空間允許，采用左右結(jié)構(gòu)當(dāng)然最為理想。

但是移動設(shè)備，我們只能在Y軸上做文章。如果將這張紙的尾部內(nèi)容裁剪下來，制作出“第二張紙”，并把它固定在容器底部、給它加上可以滑動的軌道，是不是問題就迎刃而解了？

在“豆瓣”的案例中（下圖左側(cè)），使用從底部拖出的面板來承載互動相關(guān)的需求，就好像容器中的“第二張紙”，在y軸上創(chuàng)造出比擬z軸的空間。券商類產(chǎn)品“長橋”（下圖右側(cè)）也嘗試將自選股的最新動態(tài)放入“第二張紙”中，與自選股列表緊密的粘合在一起。

兩張紙理論上都可以承載無限的內(nèi)容，如此便完美的實現(xiàn)了在一個場景中、兩個需求的“并行”。

5. 定制

除了以上幾種存在共性的“自定義”，還有一些被各業(yè)務(wù)定制出來的用法。比如下圖中的股票快捷下單、外賣點餐、編輯圖片、發(fā)送彈幕等，各業(yè)務(wù)場景下的“自定義”都需要具體問題具體分析。確保交互的合理、體驗感受的順暢即可，本文在此不做展開。

二、從“模棱兩可”到“使用清晰”

剛剛我們先解決了“什么時候用底部彈出控件”以及“什么場景使用哪類用法”的問題。不過觀察下來發(fā)現(xiàn)，再往下落到一些具體細節(jié)時，仍然存在很多“模糊”地帶。

1. 動作菜單與數(shù)據(jù)項菜單

動作菜單對應(yīng)到原生控件，就是iOS中的Action Sheet和安卓中的Dropdown Menu。顧名思義，動作菜單，承載的選項應(yīng)該是一個操作、或者通過點擊菜單鏈至一個新的去向。比如微信iOS中Action Sheet的一些使用案例。

所以，如果你要收納的菜單不是一個操作或者一個去向，那么他們大概率是用作篩選的數(shù)據(jù)項菜單。數(shù)據(jù)少的時候推薦使用下拉菜單，好處是離觸發(fā)區(qū)近且多端體驗一致；數(shù)據(jù)多的時候可以采用上文提到的自定義底部面板或者右側(cè)彈出抽屜。

2.全屏模態(tài)視圖、模態(tài)面板、向右進入新頁面

“全屏模態(tài)視圖”（Full Screen / Full-screen Dialog）和“向右進入新頁面”在層級的疊加上，成本是一樣的。不過“全屏模態(tài)視圖”除了可以向左回退，在微信中也培養(yǎng)出了可以一直向下關(guān)閉頁面、退出層級的認知。

二者根本的區(qū)別在于，“全屏模態(tài)視圖”可以一鍵退出該任務(wù)流程，而“向右進入新頁面”因為屬于“層級導(dǎo)航”，想退出只能原路返回、一層層的回到起點。

所以我們會看到，在層級較深的位置，不會使用“向右進入新頁面”再展開一個多步驟的任務(wù)，它更多用于進一步呈現(xiàn)詳細、完整的信息。

蘋果在iOS13將“模態(tài)面板”（Modal Sheets）調(diào)整為卡片形式后，至此沒有再更新其用法。除了蘋果自己的系統(tǒng)在廣泛使用這個控件，只有“印象筆記”等個別產(chǎn)品能看到它的集中使用。我認為原因在于，脫離了蘋果系統(tǒng)的使用場景，“模態(tài)面板”在其他App中表現(xiàn)出使用不清晰、通用性不好的問題，微信也干脆沒用，依靠“全屏模態(tài)視圖”完成了大部分多層級的場景。

但是全靠“全屏模態(tài)視圖”去堆疊層級，難免會在一些場景給用戶帶來迷失感。所以更建議大家將“全屏模態(tài)視圖”與上文提到的“自定義底部面板”結(jié)合使用，先保證全端交互的一致性。后續(xù)iOS如有通用性更好的用法，再考慮將其加入控件庫。

3. 模態(tài)的退出方式

① 點擊“遮罩層”退出。除了“全屏模態(tài)視圖”，剩余底部彈出控件都可支持。

② 點擊“關(guān)閉”退出。常用于收納信息。

③ 既可點擊“關(guān)閉”、又可點擊“確定”退出。一般用于“確定”需要被激活的情況，所以同時提供“關(guān)閉”的方式。

④ 點擊按鈕退出模態(tài)。一般有以下3種情況：

• a.“取消”：常用于Action Sheet、Activity View
• b.“確定”或“完成”：常用于單一操作 / 收納信息的底部面板
• c.“取消”+“確定/完成/發(fā)送/提交/…”：常用于Full Screen、非即時生效的底部面板

以上退出方式，無論遵循哪一套規(guī)則，只要使用清晰合理即可。最重要的是保證產(chǎn)品全局上的高度一致。

4. 何時使用拖動手柄

其實拖動手柄收起“底部彈出控件”，也是一種退出模態(tài)的方式。不過大家可以通過上文諸多案例發(fā)現(xiàn)，“拖動手柄”的使用不僅在各家產(chǎn)品中規(guī)則不一樣、在一些產(chǎn)品內(nèi)部也存在著不一致的地方。

豆瓣、釘釘（見下圖）常駐于底部、通過手柄拖入拖出的用法，是現(xiàn)在使用較為明確、清晰的。

豆瓣在最近版本中已經(jīng)將不必要的“拖動手柄”去掉了，只在上圖示意的場景中保留使用。我認為這種變化讓一個控件的使用邊界，更加清晰了。在必要場景合理使用、且不濫用，是控件規(guī)則存在的價值之一。

不過，有一些跑在前面的產(chǎn)品，正在用“拖動”關(guān)閉面板、逐漸代替“點擊按鈕”關(guān)閉面板。

所以我們在Ins和微牛中看到了處處帶有“拖動手柄”、而不再使用按鈕的設(shè)計。這些走在趨勢前沿的產(chǎn)品，一般設(shè)計團隊話語權(quán)較高、或者產(chǎn)品剛剛完成從0到1，有著較好的實驗土壤。

如果你所在產(chǎn)品不具備這樣的條件，建議還是等趨勢應(yīng)用的成熟了，再判斷是否跟隨。

5. 自定義底部面板中的多層級回退，關(guān)閉還是返回

當(dāng)前任務(wù)中所承載的操作較多元，且有些操作又需要新的去向，如搜索、新建等，使用層層“關(guān)閉”的邏輯完成回退（下圖左側(cè)），體驗較為一氣呵成。

如果當(dāng)前任務(wù)在第一層級即可完成主要操作，第二層級僅承載次要信息，使用“返回”邏輯即可（下圖右側(cè)）。我們每天都在用的“支付寶-密碼支付-選擇銀行卡”功能，就是一個比較經(jīng)典的案例。

三、使用規(guī)則的編寫思路

以上是我在規(guī)則草稿階段，進行觀察、思考和抽象的過程?，F(xiàn)在我們有了“自定義”的主要用法，一些“模棱兩可”的問題也有了清晰的結(jié)論。接下來我們關(guān)注三件事：

1. 先平鋪再合并

對于處在穩(wěn)定迭代周期中的產(chǎn)品，我們先通過走查的方式，將線上的案例一個個收集起來。在有了粗略的歸類整理后，還要繼續(xù)審視當(dāng)前的控件使用類型，是否還有“瘦身”的空間。

因為文檔的使用者通常是產(chǎn)品、UI、研發(fā)、測試等協(xié)作方，如何幫助他們快速、準確的定位到某個控件的使用，是最重要的。

如果有兩種用法，你發(fā)現(xiàn)它們的使用邊界比較模糊，證明其中一個是可以被合并、或者直接刪掉的。分類越集中，越有利于保持一致。

2. 分類框架因地制宜

“底部彈出控件”同時包含了原生和自定義的用法，且落到不同產(chǎn)品中，自定義的歸類方式會存在較大差異。這里以美港股券商為例，以下是我的分類框架。

“基于原生”，指的是直接調(diào)取系統(tǒng)原生控件，在交互上沒有進行自定義改造的基礎(chǔ)用法。它們可能在視覺上有著區(qū)別于原生風(fēng)格的再設(shè)計，但是底層仍可清晰對應(yīng)至某個原生控件。

“自定義”用法在上文中已詳細闡述，以美港股券商為例，目前還沒有遇到“并行”的用法，未來如果出現(xiàn)了對應(yīng)需求，再補充至文檔中即可。

“關(guān)聯(lián)功能”相當(dāng)于這份文檔的落地指引。在完成以上全部用法的編寫后，以篩選、貨幣兌換、日期選擇為具體案例，來說明這份文檔如何使用、以及使用后可以帶來哪些收益。

同時還可以為這些功能的體驗換新，提前做好方案上的儲備。

3. 保持一致

保持一致的重要性無需贅述，它是保證一個產(chǎn)品體驗質(zhì)量的基石。尤其在編寫控件規(guī)則的過程中，每一步都需要反復(fù)確認“一致性”的問題，直到?jīng)]必要的分叉一個個消失，全局的整體性才會逐漸浮現(xiàn)。

四、Q&A

1.“操作確認”類對話框需要從Alert整體調(diào)整為底部彈出控件嗎？

從體驗差別上來說，必要性不大。我目前調(diào)研到的產(chǎn)品，應(yīng)該只有豆瓣、脈脈做了全局上的規(guī)劃和調(diào)整。而這樣的改動，落地成本通常較高，投入產(chǎn)出比較低，不建議盲目推進。

2. 如何讓這類橫向規(guī)則文檔，被真正的使用起來，而不是束之高閣？

非0-1的產(chǎn)品，想依照文檔對老舊設(shè)施進行重建、改造，需要等待大改版這樣的順風(fēng)車時機。除此之外，我們還可以從兩個角度入手，小步推進。

一是在文檔確認、發(fā)布后接到的需求，從設(shè)計內(nèi)部的輸出環(huán)節(jié)開始，使用最新的規(guī)則設(shè)計需求；

二是在接到已上線功能的需求，發(fā)現(xiàn)其涉及到文檔中內(nèi)容，可嘗試與研發(fā)、產(chǎn)品、測試同學(xué)進行溝通，如排期、風(fēng)險可控，可借此機會解決一個單點問題。

本文由 @cony的小書包 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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