你真的了解這些交互控件嗎?
交互控件的名稱和定義在學術界并沒有統(tǒng)一的標準,也許在說某一個名字的時候你并沒有理解它的意思,本文主要是讓大家來見識一下那些常用的交互控件,一起來看看~
曾幾何時,對于剛入圈的交互設計師遇到一些具有國際視野的產品經理時,也會出現(xiàn)上圖中的情形。亦或許在某個不經意的瞬間,你也曾犯過下圖的錯誤。那我們今天來認識一下那些常用的交互控件~
按照功能劃分
其實關于交互控件的名稱和定義在學術界并沒有統(tǒng)一的標準,但是目前市場主流的OS廠商都有自己的標準定義,分為:Apple的Human Interface Guidelines 和 Google的Material Design。
可以看到:在Apple的Human Interface Guidelines中apple將交互控件歸入視圖(Views)中,而Google的Material Design將交互控件歸入組件(Components)中。
在這里我不會嚴格按照兩家給出的標準對每一個控件都做詳盡的贅述,我將把工作中常用的組件按照功能來劃分一下并參考iOS和Google對于這些組件的描述,來向大家簡單梳理一下他們的定義和用法。
模態(tài)與非模態(tài)
在正式開始之前,我先簡單介紹一下模態(tài)與非模態(tài)。下面是維基百科關于模態(tài)窗口(Modal window)的標準解釋。其含義就是:模態(tài)窗口下,用戶被強制必須先與當前視窗進行交互才能回到主窗口,此時用戶的行為是線性的。由于其會打斷用戶操作并且強制用戶進行交互,因此模態(tài)控件的使用必須謹慎。
反之,非模態(tài)即用戶不被強制先與當前視窗進行交互也可以與主窗口直接進行交互,用戶行為是非線性的,擁有更多主動權。
收納+引導
這類控件包括Popup(或者叫Popover)、Action views、Action sheets/ Sheets_bottom、Dropdown menu,其共同特點是由用戶主動觸發(fā)(默認隱藏)、輕量化、指向性較強、包含操作、不會自動消失。
這類控件多用于屏幕空間的移動設備,作為低頻但重要的操作入口(Dropdown menu在PC的應用場景同樣很多)。這一類控件既包含模態(tài)又包含非模態(tài)。
1. Popup(Popover)&Dropdown menu
iOS的Popup(Popover)與Android的Dropdown menu的使用場景和展現(xiàn)形式基本類似,主要用于收納一些默認不展示的低頻選項, 不過值得注意的是:Popup和Dropdown menu出現(xiàn)的位置和方式與其入口的位置是有很大關系的,特別當入口按鈕是位于屏幕邊緣的時候尤其需要注意。
此外,Popup(Popover)自帶箭頭的強指示性,同樣適用于展示隱藏操作或新功能上線后的用戶教育。
2. Action views&Action sheets
不同于Popup(Popover)和Dropdown menu幾乎可以出現(xiàn)在屏幕的任何位置,Action views和Action sheets/ Sheets_bottom一般出現(xiàn)在屏幕底部。同樣,他們也是用于容納并展示低頻但重要的操作。
提示+引導
這類控件包括Toast、Snackbars、HUD,其共同特點是:不一定由用戶主動觸發(fā)、輕量化且一般不包含操作,展示時間較短(一般在3秒以內)且會自動消失,這類控件多用于系統(tǒng)狀態(tài)或者用戶操作結果的展示。同樣,這類控件基本都是非模態(tài)的。
1. Toast
根據(jù)維基和android開發(fā)者指南的解釋:Toast是一種小巧的作為操作反饋的信息窗口,并且會自動消失。
有意思的是,據(jù)說一位微軟前員工在開發(fā)MSN Messenger時,覺得MSN彈出通知方式很像烤面包(Toast)烤熟時從烤面包機(Toaster)里彈出來一樣,因此把這種提示方式命名為Toast,后來這位微軟前員工帶著這一習慣命名跳槽去了Google。
其實,在實際應用中,Toast的應用延伸較多,除了作為操作反饋的信息展示窗口,還常常被用來作為系統(tǒng)狀態(tài)更新時的提示,并且在出現(xiàn)的位置上,也沒有非常嚴格的定義。
2. Snackbars
按照使用場景和元素來說,Snackbars可以簡單理解為Toast的升級版本,但根據(jù)Google Material Design的定義,我們可以發(fā)現(xiàn):Snackbars與Toast的主要差別在于前者可以包含一個操作按鈕,而后者不包含。
在實際應用中,Snackbars的應用范圍其實比較廣,我們會發(fā)現(xiàn):Snackbars主要被用在展示一些對用戶很重要的操作結果,比如:刪除文件或者快速引導。
3. HUD
HUD全稱叫做UIProgressHUD,其實在iOS Human Interface Guidelines中并沒有Toast和Snackbars這樣的定義,但是與之對應的是UIProgressHUD(直譯為界面進程浮層),這種控件是iOS系統(tǒng)私有的,在App Store上線的app原則上是不能直接獲取的,所以出現(xiàn)了許多模仿的第三方控件(主要是app開放者用以與iOS的UI風格保持一致的嵌入式組件)。
4. Toast& Snackbars& HUD小結
其實,我們這樣理解這三者之間的關系更加簡單明了:Google的Toast≈iOS的HUD,Snackbars=Toast+操作按鈕,Toast+Snackbars+HUD都是用來展示app或者系統(tǒng)內的狀態(tài)信息。
提示+操作
這類控件主要是Dialogs/ Alerts,嚴格意義上來說,其實Alerts(警告型對話框)也是屬于Dialogs中的一種。Google的Material Design將Dialogs分為:Alert Dialog、Simple Dialog、Communication Dialog和Full-screen Dialog,但是在iOS中并沒有定義Dialogs這種控件,而只是對Alerts做了定義。
對話框的精髓在于讓用戶聚焦,它一般有兩種使用場景:
- 系統(tǒng)的關鍵狀態(tài)提示,并且如果不處理當前狀態(tài)會影響到用戶的下一步操作,如:系統(tǒng)錯誤或者電量過低。
- 需要用戶特別注意的關鍵信息處理,如:刪除文件、支付確認Google Material Design關于對話框的定義。
1. Alert Dialog
由于警示型對話框出現(xiàn)的形式非常直接(包含用戶主動觸發(fā)與系統(tǒng)自動觸發(fā)),且常常會打斷用戶當前操作行為(強打擾性),因此絕大部分的警示型對話框被用在關鍵信息處理或者關鍵狀態(tài)提示上,
如:
- 文件操作場景 — 刪除文件,放棄編輯;
- 支付場景 — 支付二次確認,余額不足提示;
- 重要狀態(tài)改變場景 — 手機電量低,版本更新。
值得注意的是:在警示型對話框中的按鈕文案使用一定要避免歧義,不要讓用戶做選擇變成一道哲學命題。
Google Material Design總結了一些Alert Dialog按鈕文案的一些基本規(guī)則:
(1)文案要釋義操作行為,比如:當問題為“您是否要放棄編輯當前的郵件”相比于用簡單的“是”或“否”,使用“放棄編輯”和“繼續(xù)編輯”用戶更能清楚操作后的預期效果。
(2)從用戶習慣來說,對于當前提問的肯定回答應置于右側,而否定回答應置于左側 。
同樣接著上一個例子,當問及“您是否要放棄編輯當前的郵件”時,“放棄編輯”應該置于右側,而“繼續(xù)編輯”應該置于左側。
(3)對于APP內或系統(tǒng)重要狀態(tài)的提示,不要給多余的按鈕而讓用戶費解。
(4)最好不要在警示型對話框中放置諸如“了解更多”等第三個按鈕,因為它會將用戶引導至其他內容而導致用戶中斷/忘記當前對話框的操作。
2. Simple Dialog
簡易對話框用以展示用戶做即時決斷的選項,選項本身既是信息又是按鈕,不包含單獨的文案按鈕。
一般用于多選其一且不用二次確認的場景,如:地區(qū)選擇、語言選擇、郵箱地址選擇等。
3. Confirmation Dialog
確認對話框用于需要用戶進行選擇并手動確認的場景,不同于簡易對話框,用戶可以選擇一項或者多項,并且包含確認和取消按鈕。
4. Full-screen Dialog
全屏對話框包含一些列的操作任務,這些操作任務可能需要用到鍵盤輸入并且還可能包含子對話框,典型的使用場景如:填寫表單、設置日程等。
附上參考文獻的原文鏈接:
Google Material Design — https://material.io/design/components/dialogs.html#usage
Android Developers —?https://developer.android.com/guide/topics/ui/notifiers/toasts
Modal window —?https://en.wikipedia.org/wiki/Modal_window
UIProgressHUD —?http://iphonedevwiki.net/index.php/UIProgressHUD
Toast(computing) — https://en.wikipedia.org/w/index.php?title=Toast_(computing)&oldid=459336160
本文由 @?johnnylhj 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載
題圖作者提供
好像確實是這樣,仔細閱讀了百科,美團發(fā)紅包對話框應該是屬于模態(tài)窗口的,里面有寫lightbox設計,它應該是屬于模態(tài)窗口的一種優(yōu)化形式。
謝謝留言和指正~
不明白為什么第一個美團紅包的彈層不屬于模態(tài)彈層,首先,這個并不能通過點擊蒙層關閉,第二,即使通過點擊蒙層或“btn-取消”關閉了,也是需要用戶對其進行了相應的操作才能進行之后的動作的
而模態(tài)的定義不是說“在用戶想要對對話框以外的應用程序進行操作時,必須首先對該對話框進行響應”,點擊蒙層或者“btn-取消”不就是對對話框進行響應了么?
1.美團紅包的對話框 你點擊蒙層區(qū)域是可以關閉的,并且它會有一個常住入口在旁邊
2.不發(fā)紅包一樣可以繼續(xù)點餐
你應該沒有仔細體驗這個流程
發(fā)紅包實際上是一個app內的運營功能,如果一個運營功能做成干擾度這么強的模態(tài)彈窗,強迫用戶每次點完餐都必須先處理對話框才能進行下一步操作,這個體驗肯定是不好的,因為它不是用戶的一個剛需`~
可是你并沒有回答我的問題…
對于我第二段里寫的模態(tài)的定義,即使我點擊蒙層關閉了對話框,我還是個對它響應了
模態(tài)應該是不影響用戶操作,類似toast和snackbar一樣的東西,我不需要對他操作,toast出現(xiàn)了就消失了,snackbar就在那待著,我不點就不點了,而美團這個,我不點擊蒙層或者按鈕,我就什么都干不了了
如維基所說“It creates a mode that DISABLES THE MAIN WINDOW, but keeps it visible with the modal window as a child window in front of it.
USER MUST INTERACT WITH THE MODAL WINDOW BEFORE THEY CAN RETURN TO THE PARENT APPLICATION.”
你點擊蒙層區(qū)域是與模態(tài)彈框本身發(fā)生交互?
modal window指的是這整個窗口,也就是蒙層和對話框在一起的整個層,而不是僅指對話框
什么叫做disables the main window? 就是鎖死主窗口,除了與模態(tài)彈框以內的區(qū)域發(fā)生交互可以解鎖,其他情況下是不可以的。
那在美團那個頁里,當前狀態(tài)下,主窗口是不是被鎖死了?
并沒有的,舉個例子吧,比如說你第一次使用朋友圈的掃一掃功能,微信會彈框問你是否允許訪問相機,你只能點擊允許或者不允許,允許→可以使用掃一掃,不允許→不可以使用掃一掃+下次打開重復彈出詢問彈窗,這個是線性的;但是美團發(fā)紅包,你可以選擇:1. 點擊蒙層不理會這個彈框→可以接著點餐,并且下次點完餐還會觸發(fā)這個詢問彈框;2. 點擊取消,不理會這個彈框→可以接著點餐,并且下次點完餐還會觸發(fā)這個詢問彈框;3.點擊發(fā)紅包,觸發(fā)分享邏輯,并且下次點完餐還會觸發(fā)這個詢問彈框; 這個是多線性的
模態(tài)跟線性非線性沒有關系啊…線性非線性是指的用戶任務流程,而模態(tài)指的是當前頁面的狀態(tài),跟任務流沒有關系
不鎖死的情況下,點擊“btn-取消訂單”或者“btn-返回”位置應該能觸發(fā)對應的功能,而現(xiàn)在對話框存在,我是不可以觸發(fā)對應功能的呀
如果按照單線性和多線性的理解,把蒙層看成是一個大號的關閉按鈕,那你的觀點是正確的,謝謝反饋和建議~
??
大神
你好,交個朋友吧