重新複習 Toast 和 Snackbar

移動端設計中有三個名字經常被提到：Dialog、Toast 和 Snackbar，大部分同學從 Google 設計規範中第一次了解它們。

原本無論作為系統規範還是應用組件它們都已足夠成熟，我也自以為對它們有足夠的了解。但最近工作、交流中發現對這三者尤其 Snackbar 的了解非常淺，所以花了一點時間重新學習了一下。

//我並非專業工程師，更多僅從設計師角度來闡述自己的心得。

作為應用中承擔「操作反饋」和「信息傳遞」的組件，Dialog、Toast 和 Snackbar 三者很相似但又各有不同。尤其從 Snackbar 被提出之後，網路上有很多文章討論它們三者的應用場景和使用方法。

Toast 翻譯過來叫「吐司」，非常形象的一小片；Snackbar 則是「快餐店」，聽起來就比吐司要牛逼一點......

眾所周知，iOS 規範中是沒有 Toast/Snackbar 這兩個名字的，但由於設計「跟隨操作且超輕量」的反饋交互比較困難，所以直接將文字、icon 在操作後甩到用戶臉上成為了一種簡單、有效的做法。

理想的反饋是發生在操作空間自身，如 Twitter 的 Favorite 按鈕，觸發與否都用動畫來表達。第一做到了操作與反饋一體，第二避免了 按鈕被反覆點擊觸發多個 Toasts 所引起的壞體驗。

最初我想當然的以為，那些出現在屏幕正中間、黑色半透明底色，顯示文字或圖案的東西叫做 Toast；而那些自帶操作項，可以滑動或點擊刪除消息的東西則是 Snackbar。但實際上，通過位置、顏色、是否帶操作和如何消失都無法準確定義它們。

首先，來複習一下 Material Design 的官方說明。（值得注意的是，現在 Snackbar 和 Toast 在同一個文檔中，但誰能告訴我為什麼這兩個單詞要用複數？）

Snackbars

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 包含一條簡單的、與操作行為相關的文字消息，它也可以包含一個文字操作項目，但不能包含 icon。

2、同一時間只能出現一個 Snackbar，每個 Snackbar 可以包含。

3、Snackbar 從屏幕底部向上移動出現。

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？顯然已經不是了...）主要用於傳遞系統消息，展示於屏幕底部並且不能滑動消除。

可以看到，官方設計規範對 Toast 的描述已經很少了，似乎更傾向於讓大家使用 Snackbar，而且它們的定義也非常含糊，顯然大多數 App 都不是這麼設計的......

從代碼層面我們可以看到關於它們更多的特性 [1]。

Toast.makeText(context, "things happened", Toast.LENGTH_SHORT).show();nnSnackbar.make(view, "data deleted",Snackbar.LENGTH_LONG)n .setAction("Undo", new View.OnClickListener(){ @Overriden public void onClick(View v) {n }n })n .show();n

首先，與 Dialog不同，Toast 和 Snackbar 都不屬於模態。這意味這它們不獲取當前屏幕焦點，用戶依然可以操作屏幕中的其他內容，這也正是所謂的「輕量化信息和反饋」。當設計者不希望用戶任務被打斷時，使用它們比 Dialog 更輕量。

其次，Toast 默認是展示在當前屏幕內所有控制項之外，Snackbar 則是在控制項的最頂層。從我的角度來看，似乎 Snackbar 更像應用的一部分而 Toast 則更接近系統消息。這可能就是官方所謂的「Toast are primarily used for system messaging」。

實際效果上，Toast 不會改變已有控制項的布局，而 Snackbar 常常把懸浮按鈕往上推。

再次，很多人會問，這兩個消息顯示多長時間比較合適？雖然設計規範中沒有給出具體的時間建議，但代碼卻已經告訴我們。

在 Toast 和 Snackbar 的參數中，有 LENGTH_SHORT 和 LENGTH_LONG 兩個狀態，測試後分別為約1.8s和3s [2]。所以，即便可以自己想辦法設置時間，不如遵從官方1.8s/3s的建議比較合理。

然後，顏色、位置、操作和帶不帶 icon 真的很嚴格嗎？答案是否定的。為了應對變態且任性的需求，有兩篇文章 [3][4] 詳細介紹了如何花式使用 Toast 和 Snackbar，簡而言之就是技術上要做到給它們換個底色、加個 icon、換個位置都是很容易的。

比如你想要的話，可以做到這樣：

但是，設計師還是要有基本的節操，在追求最流暢用戶體驗的時代，不要輕易給用戶太多的干擾。

最後，總結一下我的想法。

1、關於差別。從用戶感知層面，Toast 和 Snackbar 的最核心區別在於後者可以帶一個操作項，並且可以主動消除。這樣看來 Toast 似乎沒有什麼優點了，完全可以用 Snackbar 取代。當然，大部分用戶對 Toast 更加熟悉，認知成本會更低。

2、它們真的只是給你展示輕量級信息的。我見過有人在 Toast 里寫小作文的，大概三四十個字。如果真的有這麼多事要說明，真的應該考慮一下是否可以從流程上來解決交互問題，而不是單純靠文字來說明操作反饋。或者如果必要，請使用 Dialog，不然用戶真的來不及看，也顯得消息並不重要。

3、關於時間。能直接通過動畫交互反饋的請不要使用 Toast 或 Snackbar，如成功加入購物車、成功收藏、成功發送消息等。如果要用，請將時間控制在1.8s或3s，我覺得1.8s就足夠了。

4、規範只是建議。技術層面上大概可以做到你想要的一切改變，不過作為設計師還是要慎重。畢竟 Google 的設計規範是經過大量用戶測試和試驗確定的，除非你自認為你的設計更加合理。

參考文獻：

[1]郭霖，「Android提醒微技巧，你真的了解Dialog、Toast和Snackbar嗎？」，csdn blog，2016.07.26；

[2]自導自演的機器人，「Design庫-SnackBar屬性詳解」，簡書，2016.06.08。

[3]簡名，「沒時間解釋了，快使用Snackbar!——Android Snackbar花式使用指南」，簡書，2016.05.05；

[4]簡名，「你見過這樣的Toast嗎？——Android Toast自定義使用」，簡書，2016.08.12。