iOS和Android規范解析——確認彈框、全屏彈框和模態視圖

5 評論 27874 瀏覽 176 收藏 11 分鐘

今天介紹三個控件,前兩個是Material Design(簡稱MD,下同)規范中的確認彈框(Confirmation Dialog)和全屏彈框(Full-screen Dialog),后一個是iOS規范中的模態視圖(Modal View)。下面先說MD中的兩個。

Google Material Design Guideline

確認彈框,是需要用戶明確地選擇一個選項的彈窗。比如設定手機鈴聲時,會需要你選擇一個鈴聲,如下圖:

確認彈框示例

如果點擊“取消”按鈕,或者點擊安卓系統的“返回”按鈕,則該彈框消失,并且修改的內容不會保存;只有點擊“好的(OK)”,才會保存修改的內容。因為有這個保存修改內容的功能,所以“取消”按鈕就顯得尤為重要:如果不加“取消”按鈕,則用戶會不清楚修改的內容是否被保存,比如下面這個反例:

這個彈框只有一個“完成”按鈕。這使得安卓系統的“返回”按鈕的功能變得模糊:“返回”按鈕是“取消”的作用呢?還是“確認”修改的意思呢?

另外有一點需要格外注意:在確認彈框里,不要設計會彈出簡易彈框或者簡易菜單的按鈕,因為這會增加它的復雜度。如果一定需要使用這些彈框,則請考慮使用全屏彈框(下面會介紹到)。

確認彈框的形式,除了剛剛提到的設定鈴聲的列表,還可以有很多樣式:

所有的確認彈框都share一個共同點:彈框里只專注選擇一個值。比如上圖左側的日期選擇器,只選擇日期,而不是既選擇日期又選擇時間。

上面是MD中對確認彈框的介紹。下面說說全屏彈框。

全屏彈框示例

全屏彈框承載了一組任務,這些任務在用戶點擊“保存”或者“取消”之前,都不會獨自生效(對,就是捆綁式銷售的意思 )。在全屏彈框里,各種彈框都可以彈彈彈。全屏彈框是所有彈框中,唯一允許彈框上面有彈框的情況;一般情況下,除非是警告框,否則所有彈框都不能在別的彈框之上出現。

至于何時使用全屏彈框,有以下幾個判斷標準:

  • 所需彈框包含需要輸型入操作的入口,比如輸入框,或者日期選擇期;
  • 改動不是實時保存的,而是點擊“保存”按鈕之后一起打包保存;
  • 應用里沒有實時保存草稿的功能;
  • 當需要進行一系列操作或設置,然后再提交它們時(其實和第二條比較相似)。

關于全屏彈框,有一個需要注意的點:頂部操作欄。頂部的操作欄,左上角一定要放置表達“取消”含義的按鈕,而不是“返回”;右上角一定要放置表達“保存”的意思,而不是“關閉”。

先說左上角,下面的例子很好地說明了原因 :

既然用戶的操作不是立馬生效,所以當點擊左上角的“X”號,如果用戶已經進行了一些操作,則應該彈出警告框提示用戶:

當用戶已經設置了一些選項,則點擊X號時,彈出警告框提示用戶將丟棄所做的更改

全屏彈框右上角表達“保存”含義的按鈕,可根據場景選擇不同的文案,但最好使用動詞,比如“保存,發送,分享,更新,創建”等。不要使用模糊的詞匯,像“完成”、“好的”(在確認彈框可以用,全屏彈框不能用)、“關閉”。下面是個反例:

右上角的“關閉”按鈕對操作的結果表意模糊

關于全屏彈框的標題,MD也給出了建議:標題要簡短。如果想要使用隨使用場景變化而變化的文案作為標題(例如創建活動時“活動的名稱”作為標題),那么如果不斷變化的文案會出現長度很長的情況,則考慮把變化的文案放在全屏彈框的內容部分,比如下面這個例子:

左邊的例子,把很長的文案“車輛責任保險”,移到了內容部分。PS:沒想到MD規范中竟然出現了德語!之前在德國待了三年,竟然在這用上了德語!

左邊是正確的例子,標題使用的是“新的預約”;而右邊是錯誤的情況,因為標題使用的是“車輛責任保險”,是具體一個預約的名稱,這個名稱會隨著不同預約而改變。在這個例子中,名稱長度太長,因此放在下面內容區域更為妥當。

以上是MD中關于全屏彈框的內容。

iOS Human Interface Guideline

在iOS中,蘋果使用“模態視圖”來指那些在當前頁插入的“浮層頁面”。模態視圖有下面幾種形式:

模式視圖的幾種形式

模態視圖的典型案例,是iOS中日歷應用中右上角的“+”號:“創建新事件”。點擊后,從下向上出現如下頁面:

一般來說,模態視圖包括一個“完成”按鈕和“取消”按鈕,但也不是100%一定。

關于模態視圖,iOS規范中說有以下幾點需要注意:

  1. 提供明顯且安全的出口。保證用戶明白他們在模態視圖中的操作引起的結果是什么。
  2. 讓你的模態視圖中的任務簡單、簡短、聚焦。如果要在模態視圖中創建帶有多層級關系的任務,一定要慎重!因為用戶很容易忘記它們操作的來龍去脈。
  3. 為你的任務在模態視圖中展示一個標題??梢栽跇祟}欄的地方,也可以在別的地方。總之,可以清楚描述任務就好。
  4. 只在展示很重要的提示信息時,才考慮使用警告框。最理想的情況是,警告框可以讓用戶采取行動。警告框比較打擾用戶,所以有必要讓用戶覺得這種打擾是值得的。

以上是iOS設計規范中對模態視圖的解釋。其實,“模態”是個挺有趣兒的概念。下次的文章會跟大家來介紹一下(先賣個關子,嘻嘻嘻嘻)。

小結

總結一下,今天的文章,對比了MD中的確認彈框(提供選擇單一值的彈框)和全屏彈框(可讓用戶完成一組任務,彈框上面可以出現別的彈框),以及iOS中的模態視圖(讓用戶完成有聚焦的任務,或者提供一些列選項,比如全屏播放器中從側邊展開的操作欄)。

歡迎留言討論。討論會讓我們更清楚這些控件。

相關閱讀

iOS和Android規范解析——提示框(Toast)對比

iOS和Android規范解析——警告框(Alerts)對比

iOS和Android規范解析——底部浮層(上)

iOS和Android規范解析——底部浮層(下)

iOS和Android規范解析——簡易菜單、簡易對話框和彈出框

#專欄作家#

沐風,微信公眾號:“沐風與體驗設計”。人人都是產品經理專欄作家,2017年度作家評選最佳人氣獎。愛奇藝Phone和PC端交互團隊負責人。留德海龜,曾任職騰訊微生活、網易、宜信。6年交互設計經驗,專注設計領域,歡迎關注。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感覺看的一臉懵逼的……有的東西第一次注意到……

    來自四川 回復
    1. 規范的東西還是需要學習一下。加油騷年~

      來自北京 回復
  2. 謝謝!

    回復
  3. 支持下

    來自廣東 回復
    1. 感謝支持! 多交流 ??

      來自北京 回復