彈框體系總結:模態彈框和非模態彈框
彈框是一種重要的交互方式,主要用于完成信息傳遞和用戶反饋兩大功能。彈框很常見,但并不見的每一個設計師都可以100%的弄明白彈框這個概念。這篇文章是對彈框體系的一個簡單梳理和總結,希望可以解決大家心中的一些疑惑。
我們日常所說的彈框是一個很籠統的概念。所有的對話框,浮層,提示條我們都習慣性的稱之為彈框,其實彈框我們可以分為兩種:模態彈框和非模態彈框。
模態彈框
模態彈框和非模態彈框最大的區別就是是否強制用戶交互。模態彈框會打斷用戶的當前操作流程,用戶不在彈框上操作的話,其余功能都使用不了。從這方面,我們可以看出來模態彈框的優缺點都十分的明顯:優點是可以很好的獲取的用戶的視覺焦點,缺點是打斷了用戶的當前操作流程。模態彈框屬于一種重量性反饋,一般用于用戶進行重要的操作。常見的模態彈框種類有對話框(Dialog/Alter),動作欄(Actionbar/Actionsheet/ActionView)和浮層(Popover/Popup)。因為現在iOS和Android很多組件都是通用的,所以在接下來的文章里過于相似的組件我只介紹一種。
對話框
對話框一般用于用戶進行一項很重要或者有風險的操作,這時會彈出一個對話框來給用戶提示信息,用戶根據提示來進行判斷。一般會出現在屏幕的中間位置,會對界面的主要內容造成遮擋。
目前來說對話框的設計樣式繁多,用戶可以進行信息錄入,也可以用于營銷宣傳。
動作欄
動作欄在我看來可以看成是對話框的一個加強版,因為無論是alert還是dialog一般都只有兩個按鈕。而動作欄可以提供多個功能按鈕,而且展示的樣式比較多變。
但是也有例外,有的動作欄只有兩個選項。以網易云音樂為例,你要刪除歌曲時,“確認刪除”提示就是通過動作欄來完成的(如左圖)。其實這里使用對話框也是完全可以的(如右圖),網易云音樂的設計師在這里使用的動作欄的理由我不得而知。但是我的個人猜測是,動作欄位于屏幕下方,相對來說對界面內容的遮蓋會小一點。
浮層
浮層是用戶點擊控件或者界面某一區域浮出的半透明的臨時視圖。浮層的樣式跟動作欄很相似,都可以向用戶展示多個功能選項。但是浮層可以出現屏幕中的任何位置,能夠給用戶更具有指向型的提示。
接下來我們可以做一個小結:在不考慮信息錄入情況下,對話框適用于用戶進行判斷操作,而動作欄和浮層適用于用戶進行選擇操作,而浮層相對于動作欄更具有指向型。
非模態彈框
與模態彈框相比,非模態彈框最大的區別是不強制用戶交互,也不會彈出半透明背景層,非模態彈框停留一段時間后會自己消失。所以相對于模態彈框來說,非模態彈框屬于輕量型反饋,不會對用戶造成太大的干擾。常見的非模態彈框有toast(hud)和snackbar。
Toast
Toast主要用于用戶完成操作以后,告訴用戶操作結果或者狀態的變更。Toast其實是屬于Android的組件,iOS里有一個相類似的是hud,最常見的就是音量調節提示。但是現在iOS和Android的界限不斷被打破,toast現在也被廣泛應用于iOS界面設計中。如果我們去看Android給的設計規范,會發現toast有以下幾個特點:
- 只出現在屏幕底部
- 只能放文字
- 非模態彈框
但是我們會發現現在的一些toast是可以出現在屏幕中任何位置的,而且也可以加icon,所以說教條主義害死人啊。我想起前端跟我說的一句話,“只要你們能設計出來,理論上我們都可以做出來,但是我們可能會砍人?!?/p>
其實真實的toast是可以出現在屏幕的任何位置的,而且可以加icon,甚至連背景層顏色都能變。所以說我覺得設計師不僅要去看那些設計規范,還要花點時間跟開發溝通一下。
Toast的優點是不會打斷用戶當前的操作流程,屬于輕量型的反饋方式。缺點是容易被用戶忽視,而且不適合展示過多的信息,可能在用戶讀完之前就消失了。為了提升信息的可讀性和增加樣式美感,現在toast都會采用文字加icon的組合樣式。
Snackbar
Snackbar一般是由文字和功能按鈕組成的,用戶可以點擊按鈕交互,即使用戶不點擊snackbar也會自動消失,一般位于屏幕下方。通俗意義上,我們可以把snackbar看成是帶有icon的toast。
Snackbar我放在最后說,因為它非常特殊。雖然snackbar屬于非模態彈框,但是它也有模態彈框的一些特點。例如snackbar也有按鈕來供用戶交互;此外snackbar一般會出現在界面下方,這點又和動作欄中的Action sheet很像。
如果上面寫的你看不懂,沒關系。我來給你做一個小結:非模態彈框偏重信息提示,模態彈框既可以信息提示也可以供用戶交互;toast是輕量型的彈框類型,snackbar集眾家之所長,當然你說它四不像我也沒意見。
彈框體系的建立優化
以上我們了解了幾種主要的彈框樣式和用法,接下來我們來考慮的是如何建立一款產品的彈框體系或者如何對現有產品的彈框體系進行優化。其實彈框體系的建立和優化的原則可以用一句話概括:能在界面中展示就不用彈框,能用非模態彈框的就不要用模態彈框。
因為任何彈框都會對用戶造成干擾,即使是最輕量型的toast。從用戶體驗的角度來說,進行一個操作流程所受到的干擾肯定是越少越好。以下圖為例,用戶可能會對“配速區間”和“配速穩定性”這些專業術語不太了解,所以他們會點擊“問號”圖標。
這時候我們有3種的解決方案:
- 通過一個新的界面展示。但是我們可以可以看出,解釋信息并不多,不需要通過一個新的頁面來展示。
- 使用對話框或者浮層,在這里我們不能使用toast,因為toast時間太短,用戶根本讀不完。
- 在當前界面展示。
其實方案2和3這在我看來是不錯的解決方案。但是考慮到減少對用戶的干擾和操作步驟,這里我覺得方案3更佳。
多態按鈕
此外多態按鈕的使用也可以幫助我們解放彈框的壓力。例如,支付寶的支付界面,立即支付按鈕可以跳轉到付款成功的狀態,這時候就沒有必要再用彈框給用戶提示了。
建立優先級
優先級不同的信息應該獲得不同的視覺權重,那么視覺權重最大的模態彈框應該展示重要的內容。所以我們要對需要展示的信息做一個優先級的排布,要讓真正重要的信息才可以使用模態彈框。只有低頻而又合理的使用,用戶才會當回事。過度使用會給用戶產生”狼來了”心理。
總結
因為現在交互設計的很多術語都沒有統一,導致很多人對于彈框的種類很定義都有很大的出入。這篇文章是從我個人角度進行的一個總結,希望可以幫助到大家。各位有什么想法的,歡迎留言或者私信。
#專欄作家#
王M爭(微信公眾號:王M爭),人人都是經理專欄作家,資深互聯網人。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Pexels,基于 CC0 協議
請問彈框需要做成產品層級的管理系統么?還是從技術底層實現管理即可?
棒
寫的非常好,謝謝分享
寫的不錯 支持
文章里模態彈窗里對話框括號內是alert還是alter?
終于知道各種彈窗的學名和區別及用法了,贊一個!
蠻贊不過上面小結有個bug:非模態彈框是一種輕量級反饋,主要傳遞不太重要的少量信息,它不強制用戶交互;而模態彈框要打斷用戶當前操作流,而獲取視覺焦點,所以是一種表現較高重要性信息的反饋。
絕對的干貨,看設計指南上模態視圖的部分很模糊,搞不清彈窗和模態視圖的區別,現在很清晰了
閱讀量這么高,點贊率太低是網站設計的問題,文章是一級棒的。
老師,配速那個環節是不是少了個方案3的圖片 ??
左右的兩張圖是用方案3前后的區別,方案1的跳轉和2的彈窗沒展示
1
mark
受益匪淺! ??