APP提示框架詳解:Toast提示、Snackbars和Alert

22 評論 246121 瀏覽 829 收藏 13 分鐘

某日和iOS開發(fā)聊天,說到iOS規(guī)范里沒有安卓中的Toast形式的提示。我有點驚訝,仔細回憶iOS的交互規(guī)范,似乎是有。后來找來書確認了下,竟然是沒有。遂把這個框架整理了下,在文中同時也強調(diào)下Android的交互規(guī)范的差異。在對比這兩個差異的同時也能更好的了解這個框架的設計思想。

描述

用戶操作后,在APP執(zhí)行操作前以模態(tài)方式讓用戶確認操作,或在操作告知操作結(jié)果。(ps.非模態(tài)形式反饋暫不在討論范圍)

一、構(gòu)成元素

  • 標題
  • 文字
  • 按鈕

二、使用前提

  • case1:會造成嚴重破壞
  • case2:存在誤操作可能性,并且會造成嚴重后果或不便
  • case3:會造成嚴重破壞,并且可撤銷
  • case4:進一步對所做的操作進行確定和執(zhí)行

三、表現(xiàn)形式

1.Toast

1

Toast.jpg

Android中的Toast是一種簡易的消息提示框。

告知用戶任務狀態(tài),操作結(jié)果,例如:發(fā)送成功,加載中,刪除成功。

Toast會在屏幕所有層的最上方。

顯示時間有限,1s+左右消失

考慮到顯示的時間,容易被用戶忽略,不適合承載過多的文字和重要信息。

這么一來,其實這個功能似乎有點雞肋,怪不得在iOS中建議,設計一種引人注目但又和你的 app 的樣式相協(xié)調(diào)的方式去展示信息。很多APP中也是這么做的,脈脈的刷新成功,花瓣的上傳成功。

2

也有的如支付寶使用的方框形式。

3

但要注意,Toast的出現(xiàn)與用戶的操作行為緊密相關,所以其出現(xiàn)的位置與用戶的操作最好能聯(lián)系在一起,如上圖中今日頭條下拉刷新后的提示,支付寶轉(zhuǎn)賬成功的位置。

Toast一般有簡短文字或者簡單易懂的圖標,如刪除成功字樣或者簡單易懂的圖標

4

Android 對Toast的作用介紹是,主要用于提示系統(tǒng)消息,但實際運用不僅限于此。

可以看到,是否把Toast融合于界面之中,其實影響的提示框架的一個特點,顯示層級最高,打斷用戶的其他操作,讓用戶專心于提示框架顯示的信息。而Toast的信息剛好踩在了這個臨界點上,不太重要的信息是否需要打斷用戶的操作。這個就要看各個產(chǎn)品對這個信息傳達的重要性的判斷了。

2.Snackbars

在Android出的Material Design中又提出了一個與Toast類似的Snackbars。

Snackbar 是一種針對操作的輕量級反饋機制,通常出現(xiàn)在手機屏幕或者桌面端左下方,以浮動彈出框的形式存在。

與Toast相同,Snackbar也會出現(xiàn)屏幕所有層的最上方,包括浮動操作按鈕;短暫出現(xiàn)后,會主動消失。

但Snackbar帶有一定的交互性,用戶觸摸屏幕其他地方后自動消失,也可以在屏幕上滑動關閉。

而且Snackbar有時候可以帶有一個操作,如撤銷。對于一些可能會有不好后果的操作,并且可撤銷,可以以Snackbars 的形式告知并提供撤銷按鈕。

5

clipboar.png

3.Alert

在用戶進行操作后,APP執(zhí)行操作前,如果用戶的操作的結(jié)果會帶來比較嚴重的后果,如不可撤銷的數(shù)據(jù)刪除,金錢交易,退出登錄等。出現(xiàn)模態(tài)的提示框,包括說明性的標題、文字和進一步確定按鈕(1-N)。

6

Alert

使用Alert時必須傳達出清楚且可操作的信息。和其他的模態(tài)提示一樣,Alert會打斷用戶的操作,要求用戶集中精力來處理其傳達的信息,并需要一次點擊才能結(jié)束,因此要讓用戶明確知道警告框出現(xiàn)的合理性和必要性。并且Alert的出現(xiàn)必須非??酥?,這樣用戶才不會因為頻繁的點擊確定而導致不必要的損失。所以其中每個元素的設計都要經(jīng)過細致的考慮,如下文。

3.1標題

iOS要求標題的文字必須簡潔易懂,快速傳達當前的情境和對應的解決方案。

最好使用短句,偏于理解。

恰當?shù)氖褂脴它c,是一個短句或一個簡單但又不是問句的句子,句末不需要句號。如果是一個問句,句末使用問話。

android中提示框的標題是可選的,用于說明提示的類型??梢允桥c之相關的程序名,或者是選擇后會影響到的內(nèi)容。例如:設置,音量等。

3.2文字

在iOS中推薦使用標題,只有在標題無法簡短清晰的傳遞意思才再補充文字說明。

對正文的要求與標題類似,一個簡短、完整的句子。同時盡量讓文字足夠簡短以便能在一兩行之間顯示。不要讓警告框出現(xiàn)滾動條,這絕對不是好的體驗。如果必須出現(xiàn),則需要有足夠的視覺線索。

不需要在文字中說明每個按鈕的意思和結(jié)果,讓按鈕本身的文本來顯示其對應的操作和結(jié)果。

不要用長句

不要用倒裝

不要用否定

不要有歧義

要提供給用戶足夠決策的信息

3.3按鈕

在iOS中推薦使用兩個按鈕的警告框,如果更多可以考慮使用下文的操作欄?!皟蓚€按鈕的Alert通常是最有用的,因為對人們來說在兩個按鈕之間做選擇最容易。單個按鈕的Alert就不那么有用,因為它通常只是提示用戶,并沒有賦予用戶任何對當前狀況的控制能力。包含三個或三個以上按鈕的Alert明顯比雙按鈕Alert復雜,應該盡可能避免使用?!?/p>

在android中倒沒這個要求,android的Alert同時起到了iOS里Alert和操作欄的警告,通知和選擇作用。如果各自遵守交互規(guī)范倒是沒有太多的好壞之分。

在各個APP中最常見的也是2個按鈕的Alert,所以前段時間也看見知乎上一個帖子在討論確定和取消按鈕的左右問題。

這里的“確定”代表的是確定執(zhí)行操作按鈕,按鈕名稱可以刪除,繼續(xù),退出等等。而“取消”代表的是放棄這個操作,比如不保存,取消退出等。

在iOS中,明確這兩個之后再考慮一個前提,確定操作如果誤點不會帶來比較嚴重的后果,而且是用戶比較有可能的操作,那應該放在右邊,同時可以柔和的顏色提示按鈕的安全性;取消按鈕則放在左側(cè)。

  • 如果確定按鈕誤點會帶來比較嚴重的后果,且是用戶比較有可能的操作,那比較適合放在左側(cè),并且可以用醒目的顏色(紅)作為警示。
  • 如果取消按鈕誤點會帶來比較嚴重的后果,且不是用戶比較有可能的操作,那適合放在左側(cè)。
  • 如果沒有按鈕誤點會帶來比較嚴重的后果,那。。。就不要用Alert~

另外,Alert中的按鈕要與其上的文本對應,不要用爛大街的確定,取消,要用明確告知操作后果的文字,如保存,刪除,轉(zhuǎn)賬等。用戶已經(jīng)養(yǎng)成了看見確定就點確定的習慣,所以要用明確的動作來提示。

在android中比較簡單,確定類事件都放在右側(cè),取消類事件就放在左側(cè)。個人比較喜歡iOS的設計規(guī)范,更人性化一點,產(chǎn)品人員考慮的更多一點,用戶就可以少考慮一點。

在android中Alert還起到選擇的作用,所以多個選擇的情況剛常見,這時候起到的有點類似iOS的操作欄,進一步確定和選擇所要的操作。

4.操作欄

在iOS中,用戶操作后,需要進行確認和操作的按鈕大于3個,會推薦使用操作欄的形式。

不帶標題,可能有文字介紹,具體要求與Alert文字類似。

顯示兩個或兩個以上的按鈕。

使用紅色和靠近操作列表頂部來提醒用戶注意那些執(zhí)行潛在破壞性操作的按鈕。

取消按鈕放在最下的位置并與其他按鈕做一定的區(qū)分。

7

操作欄

如果選擇按鈕太多,可以參考下圖的形式組織按鈕和滾動顯示,但要留有足夠的視覺線索。

8

微信

四、位置

可以發(fā)現(xiàn),操作欄的位置一般是從頁面底部跳出,然后停留在頁面底部的地方;而Alert一般是出現(xiàn)頁面的中間;

Toast則比較多變,和用戶前置操作的位置,信息的重要性,Toast的形態(tài)相關。

主要有頂部;內(nèi)容區(qū)上方,導航下方(如下拉刷新);頁面中間(整體性,比較重要的信息提示);頁面下方,菜單欄上方(最常見);頁面底部;與操作按鈕融合等。這么一算,就沒不能放的地方。除了一個點,不要在模態(tài)的界面上再出現(xiàn)一個模態(tài)框架,這樣會導致層級的復雜化和提示框任務的簡單明確。

五、注意

要注意隨時提供一個明顯而安全的退出模態(tài)框架的方式,這種方式一般是等同于點擊“取消”,如點擊空白區(qū)域,安卓的虛擬鍵等。
提示框架如非必要不要出現(xiàn),尤其Alert形式,出現(xiàn)得少會有助于用戶對其認真對待。

回想下自己在pc端刪除東西時點擊確認的毫不猶豫,就要相信用戶在警告框出現(xiàn)的時候的點擊“確認”更多的是下意識的,所以注意不要完全寄希望與提示框架。要靠比用戶想的更多更完善來避免提示框架的出現(xiàn)。

 

作者@靜默之思

來源@簡書

本文由 @靜默之思?授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理 ,未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 好!

    來自北京 回復
  2. 謝謝分享~

    來自北京 回復
  3. 界面交互反饋應該有: Alert、Toast、dialog、Confirm 、Tooltip、Popover 、Action sheet等。 移動端常用:Toast、Action sheet、DiaLog

    來自北京 回復
  4. toast不是非模態(tài)彈窗嗎?請知道的小伙伴給個正確答案

    來自廣東 回復
  5. 什么叫模態(tài)?

    來自河北 回復
    1. 同問,我也想知道什么叫模態(tài)。

      來自廣東 回復
    2. 模態(tài)能經(jīng)??吹?,如:第一次進入某網(wǎng)站或APP出現(xiàn)的功能引導就是使用的模態(tài)技術,點擊下一步按鈕,跳向下一個功能指引。

      來自山東 回復
    3. 用戶想要對對話框以外的應用程序進行操作時,必須首先對該對話框進行響應

      來自天津 回復
    4. 模態(tài)(Modal)的特征:阻斷式,不處理就不能執(zhí)行余下流程。

      來自北京 回復
    5. 謝謝

      來自浙江 回復
  6. 感謝分享~

    來自北京 回復
  7. 作者寫的alert提示,是否應該叫做dialog提示呢,歡迎討論
    Dialog不會自行消失,必須用戶操作后(點擊確定或關閉)才能消失,會打斷用戶當前任務

    來自香港 回復
    1. ios對話框叫做Alert,安卓叫做Dialog

      來自安徽 回復
    2. alert主要是和confirmation類型的彈窗區(qū)分,alert主要是看看就行,別的需要有一些引導操作

      來自北京 回復
    3. 界面交互反饋應該有: Alert、Toast、dialog、Confirm 、Tooltip、Popover 等。

      來自北京 回復
    4. 還有個 Action sheet

      來自北京 回復
  8. alert不是是讓用戶閱讀完信息確認,然后關閉的么?cnofirm與alert不同的是,是有一個取消按鈕,一個確認按鈕的吧?求賜教~

    來自浙江 回復
  9. 謝謝分享O(∩_∩)O

    來自廣東 回復
  10. 感謝分享~

    來自廣東 回復
  11. 感謝分享!“我有點驚訝,仔細回憶iOS的交互規(guī)范,似乎是有。后來找來書確認了下,竟然是沒有?!闭垎柎颂幍臅鞘裁磿??

    來自浙江 回復
  12. 感謝分享

    來自廣東 回復
  13. 寫得好,感謝樓主分享

    來自北京 回復