在交互設計稿中Toast是其中很常用的一種用戶回饋手段， 但是作者卻發現在iOS中根本沒有toast這種部件， 那麼在設計該如何處理呢？一起來看看作者的解讀。
交互設計師在設計交互稿的時候， 時常需要一些回饋手段， 以提示用戶操作的結果。 Toast是其中很常用的一種：它簡單、小巧、對用戶的打擾小。 然而現在很多應用中， 存在對於toast過度使用的情況， 並且常常出現Android樣式的toast出現在iOS應用中（反之亦然）的情形。 在研究了iOS和Android的規範之後， 筆者驚人地發現iOS中其實是沒有toast這種部件的。 到底我們在設計的時候應該如何處理這種部件呢？且看下麵的分解。
Google Material Design Guideline
Google的Material Design規範中， 將toast和snackbars歸為一類。 下面是規範中對snackbars的定義：
Snackbars包含一行與進行的操作直接相關的文案（文案前不可有icon）。 它可以包含一個操作。
Snackbar示例
規範中對toast的定義：
Toast優先適用於系統提示。 它也在螢幕下方出現， 但是不能被劃出螢幕外（而被清除）。
Toast示例
Snackbars/toast該如何使用呢？以下幾點是從Google MD規範中歸納出來的：
行為：Snackbars/toast從螢幕底部向上出現， 經過設定的秒數後消失， 或者用戶進行了別的操作它們也會消失。
Snackbar出現和消失
簡潔：提示的文案要簡短， 包含的操作按鈕最多只有一個， 或者沒有。 （注意， snackbar不能包含使其消失的“取消”按鈕！）
左邊是正確的， 右邊是錯誤的（因為多了“取消”按鈕）
不可重疊：snackbar與floating action button不能重疊
snackbar與floating action button不能重疊
一次只出現一個：如果出現了一個snackbar，
反例：不能同時出現兩個snackbars
以上是Google Material Design中對於snackbars和toast的介紹。
iOS Human Interface Guideline
對於iOS系統， 在研究了iOS的規範之後， 筆者有個驚人的發現：嚴格地說， iOS規範中沒有Toast這個部件。 筆者找遍了iOS的人機交互設計規範，都沒有找到對於Toast這種部件的介紹，在iOS系統中，與toast功能相似的是“HUD”（透明指示層）。
iOS系統中的HUD彈窗
將iOS的HUD與Android的Toast經過對比，它們的區別有以下4點：
HUD出現在螢幕的中央，Toast在底部；HUD可以由icon，Toast不能有icon，只能用文字；HUD一般是毛玻璃透明，Toast一般是灰黑或者黑色半透明；HUD中內容可以變化（如調節音量時），Toast中內容不可變化。另外，在iOS的設計規範，與toast關係最緊密的“feedback（回饋）”一節中，也沒有提到Toast或者HUD。筆者分析後認為，蘋果對於Toast這種形式，是比較謹慎的，也就是不鼓勵大量使用這種元件。在介紹“回饋”原則時，蘋果提到：
潛移默化地將狀態改變或者其它類型的回饋放進你的介面中。理想的情況是：用戶可以不用進行操作或者被打擾，就能得知重要的資訊。
Unobtrusively integrate status and other types of feedback into your interface.Ideally, users can get important information without taking action or being interrupted.
並且還祭出了蘋果自家郵件應用的例子：
該應用在更新狀態後的回饋，是在應用的底部操作欄，展示了當前郵件的狀態：“剛剛更新，2封未讀”。這正是符合蘋果“不操作、不打擾”的原則。相比之下，在螢幕中間出現HUD，雖然也不用操作，但是打擾的程度卻嚴重了許多。
因此，在對iOS的應用進行設計的時候，操作的回饋最好是這種打擾程度比較小的，或者通過操作本身就能看到結果的，比如下面這個例子：
用戶進行刪除操作之後，短信就消失了，這時候就不需要再彈出HUD提示“已刪除”。
以上對比了iOS和Android設計規範中對Toast這類提示框的用法說明。有一點還想提醒大家：規範是官方給出的最標準的做法，但是具體的運用還是要看場景的需要。很喜歡初中老師說過的一句話：“學數學要會‘死去活來’，要死死地掌握住公式，然後靈活運用”。對於規範，也是這個道理。
嘔心瀝血寫了這篇，真心希望聽到大家的想法。歡迎留言交流。讓我們在討論中共同成長。
本文由 @新設計青年 原創發佈于人人都是產品經理。未經許可，禁止轉載。
筆者找遍了iOS的人機交互設計規範，都沒有找到對於Toast這種部件的介紹，在iOS系統中，與toast功能相似的是“HUD”（透明指示層）。iOS系統中的HUD彈窗
將iOS的HUD與Android的Toast經過對比，它們的區別有以下4點：
HUD出現在螢幕的中央，Toast在底部；HUD可以由icon，Toast不能有icon，只能用文字；HUD一般是毛玻璃透明，Toast一般是灰黑或者黑色半透明；HUD中內容可以變化（如調節音量時），Toast中內容不可變化。另外，在iOS的設計規範，與toast關係最緊密的“feedback（回饋）”一節中，也沒有提到Toast或者HUD。筆者分析後認為，蘋果對於Toast這種形式，是比較謹慎的，也就是不鼓勵大量使用這種元件。在介紹“回饋”原則時，蘋果提到：
潛移默化地將狀態改變或者其它類型的回饋放進你的介面中。理想的情況是：用戶可以不用進行操作或者被打擾，就能得知重要的資訊。
Unobtrusively integrate status and other types of feedback into your interface.Ideally, users can get important information without taking action or being interrupted.
並且還祭出了蘋果自家郵件應用的例子：
該應用在更新狀態後的回饋，是在應用的底部操作欄，展示了當前郵件的狀態：“剛剛更新，2封未讀”。這正是符合蘋果“不操作、不打擾”的原則。相比之下，在螢幕中間出現HUD，雖然也不用操作，但是打擾的程度卻嚴重了許多。
因此，在對iOS的應用進行設計的時候，操作的回饋最好是這種打擾程度比較小的，或者通過操作本身就能看到結果的，比如下面這個例子：
用戶進行刪除操作之後，短信就消失了，這時候就不需要再彈出HUD提示“已刪除”。
以上對比了iOS和Android設計規範中對Toast這類提示框的用法說明。有一點還想提醒大家：規範是官方給出的最標準的做法，但是具體的運用還是要看場景的需要。很喜歡初中老師說過的一句話：“學數學要會‘死去活來’，要死死地掌握住公式，然後靈活運用”。對於規範，也是這個道理。
嘔心瀝血寫了這篇，真心希望聽到大家的想法。歡迎留言交流。讓我們在討論中共同成長。
本文由 @新設計青年 原創發佈于人人都是產品經理。未經許可，禁止轉載。