移動端設(shè)計中有三個名字經(jīng)常被提到：Dialog、Toast 和 Snackbar，大部分同學從 Google 設(shè)計規(guī)范中第一次了解它們。
原本無論作為系統(tǒng)規(guī)范還是應(yīng)用組件它們都已足夠成熟，我也自以為對它們有足夠的了解。但最近工作、交流中發(fā)現(xiàn)對這三者尤其 Snackbar 的了解非常淺，所以花了一點時間重新學習了一下。
我并非專業(yè)工程師，更多僅從設(shè)計師角度來闡述自己的心得。
作為應(yīng)用中承擔“操作反饋”和“信息傳遞”的組件，Dialog、Toast 和 Snackbar 三者很相似但又各有不同。尤其從 Snackbar 被提出之后，網(wǎng)絡(luò)上有很多文章討論它們?nèi)叩膽?yīng)用場景和使用方法。
Toast 翻譯過來叫“吐司”，非常形象的一小片;Snackbar 則是“快餐店”，聽起來就比吐司要牛逼一點。
眾所周知，iOS 規(guī)范中是沒有 Toast/Snackbar 這兩個名字的，但由于設(shè)計“跟隨操作且超輕量”的反饋交互比較困難，所以直接將文字、icon 在操作后甩到用戶臉上成為了一種簡單、有效的做法。
理想的反饋是發(fā)生在操作空間自身，如 Twitter 的 Favorite 按鈕，觸發(fā)與否都用動畫來表達。第一做到了操作與反饋一體，第二避免了 按鈕被反復點擊觸發(fā)多個 Toasts 所引起的壞體驗。
最初我想當然的以為，那些出現(xiàn)在屏幕正中間、黑色半透明底色，顯示文字或圖案的東西叫做 Toast;而那些自帶操作項，可以滑動或點擊刪除消息的東西則是 Snackbar。但實際上，通過位置、顏色、是否帶操作和如何消失都無法準確定義它們。
首先，來復習一下 Material Design 的官方說明。(值得注意的是，現(xiàn)在 Snackbar 和 Toast 在同一個文檔中，但誰能告訴我為什么這兩個單詞要用復數(shù)?)
contain a single line of text directly related to the operation performed. They may contain a text action, but no icons.
Only one snackbar may be displayed at a time. Each snackbar may contain a single action, neither of which may be “Dismiss” or “Cancel.”
Snackbars animate upwards from the bottom edge of the screen.
譯文：
1. Snackbar 包含一條簡單的、與操作行為相關(guān)的文字消息，它也可以包含一個文字操作項目，但不能包含 icon。
2. 同一時間只能出現(xiàn)一個 Snackbar，每個 Snackbar 可以包含。
3. Snackbar 從屏幕底部向上移動出現(xiàn)。
Toasts (Android only) are primarily used for system messaging. They also display at the bottom of the screen, but may not be swiped off-screen.
譯文：
Toast(Android only?顯然已經(jīng)不是了…)主要用于傳遞系統(tǒng)消息，展示于屏幕底部并且不能滑動消除。
可以看到，官方設(shè)計規(guī)范對 Toast 的描述已經(jīng)很少了，似乎更傾向于讓大家使用 Snackbar，而且它們的定義也非常含糊，顯然大多數(shù) App 都不是這么設(shè)計的……
從代碼層面我們可以看到關(guān)于它們更多的特性 [1]。
首先，與 Dialog不同，Toast 和 Snackbar 都不屬于模態(tài)。這意味著它們不獲取當前屏幕焦點，用戶依然可以操作屏幕中的其他內(nèi)容，這也正是所謂的“輕量化信息和反饋”。當設(shè)計者不希望用戶任務(wù)被打斷時，使用它們比 Dialog 更輕量。
其次，Toast 默認是展示在當前屏幕內(nèi)所有控件之外，Snackbar 則是在控件的最頂層。從我的角度來看，似乎 Snackbar 更像應(yīng)用的一部分而 Toast 則更接近系統(tǒng)消息。這可能就是官方所謂的“Toast are primarily used for system messaging”。
實際效果上，Toast 不會改變已有控件的布局，而 Snackbar 常常把懸浮按鈕往上推。
再次，很多人會問，這兩個消息顯示多長時間比較合適?雖然設(shè)計規(guī)范中沒有給出具體的時間建議，但代碼卻已經(jīng)告訴我們。
在 Toast 和 Snackbar 的參數(shù)中，有 LENGTH_SHORT 和 LENGTH_LONG 兩個狀態(tài)，測試后分別為約1.8s和3s [2]。所以，即便可以自己想辦法設(shè)置時間，不如遵從官方1.8s/3s的建議比較合理。
然后，顏色、位置、操作和帶不帶 icon 真的很嚴格嗎?答案是否定的。為了應(yīng)對變態(tài)且任性的需求，有兩篇文章 [3][4] 詳細介紹了如何花式使用 Toast 和 Snackbar，簡而言之就是技術(shù)上要做到給它們換個底色、加個 icon、換個位置都是很容易的。
比如你想要的話，可以做到這樣：
但是，設(shè)計師還是要有基本的節(jié)操，在追求最流暢用戶體驗的時代，不要輕易給用戶太多的干擾。
1. 關(guān)于差別。從用戶感知層面，Toast 和 Snackbar 的最核心區(qū)別在于后者可以帶一個操作項，并且可以主動消除。這樣看來 Toast 似乎沒有什么優(yōu)點了，完全可以用 Snackbar 取代。當然，大部分用戶對 Toast 更加熟悉，認知成本會更低。
2. 它們真的只是給你展示輕量級信息的。我見過有人在 Toast 里寫小作文的，大概三四十個字。如果真的有這么多事要說明，真的應(yīng)該考慮一下是否可以從流程上來解決交互問題，而不是單純靠文字來說明操作反饋?；蛘呷绻匾?，請使用 Dialog，不然用戶真的來不及看，也顯得消息并不重要。
3. 關(guān)于時間。能直接通過動畫交互反饋的請不要使用 Toast 或 Snackbar，如成功加入購物車、成功收藏、成功發(fā)送消息等。如果要用，請將時間控制在1.8s或3s，我覺得1.8s就足夠了。
4. 規(guī)范只是建議。技術(shù)層面上大概可以做到你想要的一切改變，不過作為設(shè)計師還是要慎重。畢竟 Google 的設(shè)計規(guī)范是經(jīng)過大量用戶測試和試驗確定的，除非你自認為你的設(shè)計更加合理。
5. 才疏學淺，歡迎大家批評指導，也歡迎指出錯別字和語病。
以上就是上海網(wǎng)站制作公司——海淘科技為你推出《最常見的網(wǎng)頁交互控件怎么用》的全部內(nèi)容。想看更多的內(nèi)容，可點擊：營銷市場分析，于此同時，海淘科技還提供了網(wǎng)站建設(shè)案例，可點擊：高端建材網(wǎng)站制作成功案例
