2016-10-8 濤濤
某日和iOS開發聊天，說到iOS規范里沒有安卓中的Toast形式的提示。我有點驚訝，仔細回憶iOS的交互規范，似乎是有。后來找來書確認了下，竟然是沒有。遂把這個框架整理了下，在文中同時也強調下Android的交互規范的差異。在對比這兩個差異的同時也能更好的了解這個框架的設計思想。
描述
用戶操作后，在APP執行操作前以模態方式讓用戶確認操作，或在操作告知操作結果。
（ps.非模態形式反饋暫不在討論范圍）
一、構成元素
標題
文字
按鈕
二、使用前提
case1：會造成嚴重破壞
case2：存在誤操作可能性，并且會造成嚴重后果或不便
case3：會造成嚴重破壞，并且可撤銷
case4：進一步對所做的操作進行確定和執行
三、表現形式
1.Toast
Toast.jpgAndroid中的Toast是一種簡易的消息提示框。
告知用戶任務狀態，操作結果，例如：發送成功，加載中，刪除成功。
Toast會在屏幕所有層的最上方。
顯示時間有限，1s+左右消失
考慮到顯示的時間，容易被用戶忽略，不適合承載過多的文字和重要信息。
這么一來，其實這個功能似乎有點雞肋，怪不得在iOS中建議，設計一種引人注目但又和你的 app 的樣式相協調的方式去展示信息。很多APP中也是這么做的，脈脈的刷新成功，花瓣的上傳成功。
也有的如支付寶使用的方框形式。
但要注意，Toast的出現與用戶的操作行為緊密相關，所以其出現的位置與用戶的操作最好能聯系在一起，如上圖中今日頭條下拉刷新后的提示，支付寶轉賬成功的位置。
Toast一般有簡短文字或者簡單易懂的圖標，如刪除成功字樣或者簡單易懂的圖標
Android 對Toast的作用介紹是，主要用于提示系統消息，但實際運用不僅限于此。
可以看到，是否把Toast融合于界面之中，其實影響的提示框架的一個特點，顯示層級最高，打斷用戶的其他操作，讓用戶專心于提示框架顯示的信息。而Toast的信息剛好踩在了這個臨界點上，不太重要的信息是否需要打斷用戶的操作。這個就要看各個產品對這個信息傳達的重要性的判斷了。
2.Snackbars
在Android出的Material Design中又提出了一個與Toast類似的Snackbars。
Snackbar 是一種針對操作的輕量級反饋機制，通常出現在手機屏幕或者桌面端左下方，以浮動彈出框的形式存在。
與Toast相同，Snackbar也會出現屏幕所有層的最上方，包括浮動操作按鈕；短暫出現后，會主動消失。
但Snackbar帶有一定的交互性，用戶觸摸屏幕其他地方后自動消失，也可以在屏幕上滑動關閉。
而且Snackbar有時候可以帶有一個操作，如撤銷。對于一些可能會有不好后果的操作，并且可撤銷，可以以Snackbars 的形式告知并提供撤銷按鈕。
clipboar.png
3.Alert
在用戶進行操作后，APP執行操作前，如果用戶的操作的結果會帶來比較嚴重的后果，如不可撤銷的數據刪除，金錢交易，退出登錄等。出現模態的提示框，包括說明性的標題、文字和進一步確定按鈕（1-N）。
Alert使用Alert時必須傳達出清楚且可操作的信息。和其他的模態提示一樣，Alert會打斷用戶的操作，要求用戶集中精力來處理其傳達的信息，并需要一次點擊才能結束，因此要讓用戶明確知道警告框出現的合理性和必要性。并且Alert的出現必須非?？酥?，這樣用戶才不會因為頻繁的點擊確定而導致不必要的損失。所以其中每個元素的設計都要經過細致的考慮，如下文。
3.1標題
iOS要求標題的文字必須簡潔易懂，快速傳達當前的情境和對應的解決方案。
最好使用短句，偏于理解。
恰當的使用標點，是一個短句或一個簡單但又不是問句的句子，句末不需要句號。如果是一個問句，句末使用問話。
android中提示框的標題是可選的，用于說明提示的類型?？梢允桥c之相關的程序名，或者是選擇后會影響到的內容。例如：設置，音量等。
3.2文字
在iOS中推薦使用標題，只有在標題無法簡短清晰的傳遞意思才再補充文字說明。
對正文的要求與標題類似，一個簡短、完整的句子。同時盡量讓文字足夠簡短以便能在一兩行之間顯示。不要讓警告框出現滾動條，這絕對不是好的體驗。如果必須出現，則需要有足夠的視覺線索。
不需要在文字中說明每個按鈕的意思和結果，讓按鈕本身的文本來顯示其對應的操作和結果。
不要用長句
不要用倒裝
不要用否定
不要有歧義
要提供給用戶足夠決策的信息
3.3按鈕
在iOS中推薦使用兩個按鈕的警告框，如果更多可以考慮使用下文的操作欄?！皟蓚€按鈕的Alert通常是最有用的，因為對人們來說在兩個按鈕之間做選擇最容易。單個按鈕的Alert就不那么有用，因為它通常只是提示用戶，并沒有賦予用戶任何對當前狀況的控制能力。包含三個或三個以上按鈕的Alert明顯比雙按鈕Alert復雜，應該盡可能避免使用。”
在android中倒沒這個要求，android的Alert同時起到了iOS里Alert和操作欄的警告，通知和選擇作用。如果各自遵守交互規范倒是沒有太多的好壞之分。
在各個APP中最常見的也是2個按鈕的Alert，所以前段時間也看見知乎上一個帖子在討論確定和取消按鈕的左右問題。
這里的“確定”代表的是確定執行操作按鈕，按鈕名稱可以刪除，繼續，退出等等。而“取消”代表的是放棄這個操作，比如不保存，取消退出等。
在iOS中，明確這兩個之后再考慮一個前提，確定操作如果誤點不會帶來比較嚴重的后果，而且是用戶比較有可能的操作，那應該放在右邊，同時可以柔和的顏色提示按鈕的安全性；取消按鈕則放在左側。
如果確定按鈕誤點會帶來比較嚴重的后果，且是用戶比較有可能的操作，那比較適合放在左側，并且可以用醒目的顏色（紅）作為警示。
如果取消按鈕誤點會帶來比較嚴重的后果，且不是用戶比較有可能的操作，那適合放在左側。
如果沒有按鈕誤點會帶來比較嚴重的后果，那。。。就不要用Alert~另外，Alert中的按鈕要與其上的文本對應，不要用爛大街的確定，取消，要用明確告知操作后果的文字，如保存，刪除，轉賬等。用戶已經養成了看見確定就點確定的習慣，所以要用明確的動作來提示。
在android中比較簡單，確定類事件都放在右側，取消類事件就放在左側。個人比較喜歡iOS的設計規范，更人性化一點，產品人員考慮的更多一點，用戶就可以少考慮一點。
在android中Alert還起到選擇的作用，所以多個選擇的情況剛常見，這時候起到的有點類似iOS的操作欄，進一步確定和選擇所要的操作。
4.操作欄
在iOS中，用戶操作后，需要進行確認和操作的按鈕大于3個，會推薦使用操作欄的形式。
不帶標題，可能有文字介紹，具體要求與Alert文字類似。
顯示兩個或兩個以上的按鈕。
使用紅色和靠近操作列表頂部來提醒用戶注意那些執行潛在破壞性操作的按鈕。
取消按鈕放在最下的位置并與其他按鈕做一定的區分。
操作欄如果選擇按鈕太多，可以參考下圖的形式組織按鈕和滾動顯示，但要留有足夠的視覺線索。
微信
四、位置：
可以發現，操作欄的位置一般是從頁面底部跳出，然后停留在頁面底部的地方；而Alert一般是出現頁面的中間；
Toast則比較多變，和用戶前置操作的位置，信息的重要性，Toast的形態相關。
主要有頂部；內容區上方，導航下方（如下拉刷新）；頁面中間（整體性，比較重要的信息提示）；頁面下方，菜單欄上方（最常見）；頁面底部；與操作按鈕融合等。這么一算，就沒不能放的地方。除了一個點，不要在模態的界面上再出現一個模態框架，這樣會導致層級的復雜化和提示框任務的簡單明確。
五、注意：
要注意隨時提供一個明顯而安全的退出模態框架的方式，這種方式一般是等同于點擊“取消”，如點擊空白區域，安卓的虛擬鍵等。
提示框架如非必要不要出現，尤其Alert形式，出現得少會有助于用戶對其認真對待。
回想下自己在pc端刪除東西時點擊確認的毫不猶豫，就要相信用戶在警告框出現的時候的點擊“確認”更多的是下意識的，所以注意不要完全寄希望與提示框架。要靠比用戶想的更多更完善來避免提示框架的出現。
作者：靜默之思
原文鏈接：http://www.jianshu.com/p/7f9be62c9ead#