測試中，有時候會遇到彈窗的問題，有的是瀏覽器彈窗(alert)、有的是自定義彈窗;這節我們主要來討論一下關于瀏覽器彈窗和簡單的自定義彈窗。

一、關于alert彈窗的方法

switch_to_alert(): 定位到alert彈窗，返回一個彈窗的對象

dismiss(): 對彈窗對象的取消操作(相當于點擊彈窗上的取消按鈕)

accept():對彈窗對象的確定操作(相當于點擊彈窗上的確定按鈕)

text:對彈窗對象，獲取彈窗內的文本

send_keys(key):對彈窗對象內的輸入框輸入數據(如果彈窗的格式有輸入框的話可以使用)

authenticate(name, pass):對于身份認證彈窗，輸入用戶名和密碼并自動提交(一般可能會用于本地搭建的一些系統)如圖：

二、alert包的源碼展示

class Alert(object):
"""
Allows to work with alerts.
Use this class to interact with alert prompts.  It contains methods for dismissing,
accepting, inputting, and getting text from alert prompts.
Accepting / Dismissing alert prompts::
Alert(driver).accept()
Alert(driver).dismiss()
Inputting a value into an alert prompt:
name_prompt=Alert(driver)
name_prompt.send_keys("Willian Shakesphere")
name_prompt.accept()
Reading a the text of a prompt for verification:
alert_text=Alert(driver).text
self.assertEqual("Do you wish to quit?", alert_text)
    """
 def __init__(self, driver):
        """
Creates a new Alert.
:Args:
- driver: The WebDriver instance which performs user actions.
 """
self.driver=driver
@property
def text(self):
 """
Gets the text of the Alert.
 """
return self.driver.execute(Command.GET_ALERT_TEXT)["value"]
def dismiss(self):
 """
Dismisses the alert available.
 """
self.driver.execute(Command.DISMISS_ALERT)
def accept(self):
"""
Accepts the alert available.
Usage::
Alert(driver).accept() # Confirm a alert dialog.
"""
self.driver.execute(Command.ACCEPT_ALERT)
def send_keys(self, keysToSend):
"""
Send Keys to the Alert.
:Args:
- keysToSend: The text to be sent to Alert.
"""
if self.driver.w3c:
self.driver.execute(Command.SET_ALERT_VALUE, {'value': keys_to_typing(keysToSend)})
else:
self.driver.execute(Command.SET_ALERT_VALUE, {'text': keysToSend})
 def authenticate(self, username, password):
"""
Send the username / password to an Authenticated dialog (like with Basic HTTP Auth).
Implicitly 'clicks ok'
Usage::
driver.switch_to.alert.authenticate('cheese', 'secretGouda')
:Args:
-username: string to be set in the username section of the dialog
-password: string to be set in the password section of the dialog
"""
self.driver.execute(
 Command.SET_ALERT_CREDENTIALS,
{'username': username, 'password': password})
self.accept()

三、實例：w3c的alert頁面

代碼展示:

解彈窗的類型和可以做到的事情，可以幫助我們在設計中做出更合理的決策，并且有助于我們梳理和規范現有產品框架、制定和完善設計規范。

在設計B端產品時，產品經理和設計師總會為寫一個問題爭執不休：在有限的頁面空間，是否還能放些什么？而彈窗它可大可小，且能在當前二維頁面之外衍生無限的空間，幾乎可以做到所有頁面能做的事，同時對于開發來說隨便在html中加一個<alert>和一句話就能生成一個最簡單的提示彈窗。是的，在產品設計中，彈窗真的太“方便”了！

或許正因如此，彈窗可能是產品設計中最被濫用的一種常用控件了。如果用戶打開一個鏈接或是按鈕后充斥的是一層層的彈窗，用戶會感覺你的產品太復雜太難用！更糟糕的是，有的產品會很粗魯的彈出各種“提示”、“警告”，還需要強制用戶去點擊或關閉——可能設計者以為這種”溫馨提示“是“已用戶為中心”，但很多時候我們完全可以以一種更為溫和的方式來提醒用戶（如toast、懸停浮層、輸入框旁邊的橙色文字等）。了解彈窗有哪些類型、可以做什么，能夠幫助我們在設計時做出更合理的決策。

彈窗，是一種“展現于頁面之上的一種信息容器”，在x、y軸的平面空間之外擴展了頁面的維度和深度，它是一種比頁面更靈活的信息容器。細分下來會有很多類型，但并沒有一種很明確和統一的叫法。在移動應用流行以前的網頁設計中，有對話框（Dialog）、警示框（Alert）、彈出層、彈框、浮層（popup）、氣泡……現在，因為響應式設計和多平臺統一的趨勢下，甚至也有將android的toast提示、Actionbar，以及ios的透明指示層（HUD）和也算作是“彈窗”的一種。同時，非模態各種浮層和窗口，類型和用法千差萬別；鑒于此，我在這里重點探討我們在B端產品（PC端）中常用的傳統意義上的“彈窗”。

以功能和用途為維度，筆者將彈窗分為三種類型：信息展示、任務、反饋。

一、信息展示

1、解釋或說明

一般由用戶主動觸發的，包含圖文信息，少數會有簡單的操作按鈕，如“確認”、“知道了”等等。

典型場景：歡迎界面、操作說明、幫助、功能引導、取數說明、查看詳情、預覽或查看大圖……

這種彈窗一般用來對頁面內容作補充，用戶通過點擊圖標或文字按鈕，可以在當前頁面展開彈窗。比如業務介紹、圖表的取數說明、操作說明和引導等，這類信息往往與當前頁面緊密相關，且從屬于當前語境，所以并不適合用跳轉頁面、并列tab其或二級頁面的形式來表達，因為這樣無疑會加深頁面層級，增加用戶的認知負擔。尤其是對一些很重要的操作說明或引導，甚至可以在彈窗中使用翻頁或tab頁簽的形式來擴充彈窗的顯示空間。

需要說明的是，很多產品喜歡對那些普通的字段解釋和說明也使用帶遮罩的模態彈窗，并需要用戶點擊才顯示。這是一種很糟糕的設計。這種解釋說明，完全可以用一般的非模態浮層來代替，用戶只需要懸停就可以快速瀏覽，并且快速離開（移開觸發區按鈕或點擊空白區域）（當然，如果內容太多，可能你要考慮設計跳轉到新的頁面而不是使用浮層或彈窗）。

類似這種頁面的補充說明，使用懸停浮層體驗會更好

2、內容拓展

這種類型常見于一些圖表統計頁面、列表頁面。由于頁面布局的限制，以及突出核心需求的原則，我們只會給用戶展示最關心的統計結果和字段，不會也不可能把統計圖表的所有詳細數據和說明展示在當前頁面。而這些內容往往又并未多到需要一個新的頁面來容納（同樣會增加頁面層級），所以這時候就可以用彈窗來呈現。

內容擴展型的彈窗，主要有以下場景：查看詳情、預覽圖片、數據透視、歷史記錄……

對于這種彈窗，模態和非模態并沒有很大的差別。一般來說，如果是內容較少，并不會占用較大的屏幕面積，使用非模態的會更合適。因為用戶只需要掃一眼內容就行，模態的可能會給用戶一種“被打斷”的感覺。而且，使用非模態的可以直接展現在目標旁邊，關聯性更好，同時可允許用戶快速切換查看其它同類彈窗，且不會影響對其他的模塊的操作和瀏覽。

彈窗的擴展樣式——側滑面板

還有一種比較常見的“彈窗”，會以側滑的形式出新，而不是加遮罩層的模態彈窗。這樣做的好處是，用戶在查看彈窗內容的同時，不會失去當前頁面的信息，方便用戶進行對比、參照和檢閱；同時并不會影響用戶對界面其他區域的操作。這種形式一般在表格中出現較多。當然，這里的彈窗并不局限于一般的對話框樣式，我們也可以使用側滑浮層。

而對于那些信息量較大（可能有滾動條、拖拽操作等），甚至會有一些可選的支線任務或擴展操作時，建議最好使用模態的彈窗。這樣可以讓用戶的注意力更為聚焦，且可減少可能產生的誤操作（一些非模態的彈窗允許用戶點擊彈窗范圍外區域關閉彈窗）。

漸進式的展示：

除了彈窗和二級頁面，還有一種信息展示方式——漸進式的策略值得借鑒：即在頁面只展示結構式信息和核心元素，更多細節信息在用戶需要時再作立即呈現。當然這樣造成洞察速度受到一定影響，但你能得到一個更清爽更簡潔的用戶界面。

二、任務

1、復雜任務

這種彈窗在B端產品中也非常常見。當用戶在瀏覽當前頁面時，有一些很常見的場景：“登錄”、“審核”、“申請”、“編輯”……這些相對復雜的任務和操作，它除了標題和文字、說明、操作按鈕之外，通常還會有一些復雜的可編輯表單，以及點擊、選擇、拖動等操作。在移動端，因為屏幕的控件限制，設計師更喜歡用新的頁面來容納這些內容。但在pc上，更常見的是用模態彈窗來設計這種基于當前頁面的、承載用戶明確目標的任務。因為彈窗會讓用戶明確感知到所進行任務是基于當前語境的，且在“提交”或“取消”后可以很自然的自動返回到主頁面。

此外，對于一些任務來說，雖然信息量大，但大多數場景下用戶并不需要去編輯所有的字段，而只是修改你其中一兩個。因此，從用戶感知來說，相比二級頁面，使用彈窗會讓他們感覺更快捷、簡單。

大多數情況下，用戶只需要編輯或修改一兩個字段

這里有必要說一下其中比較特殊的彈窗——登錄/注冊界面。雖然以彈窗的形式來呈現目前仍然很常見，但已經有越來越多的產品在用戶點擊“登錄”時會跳轉到新的頁面，這樣做的好處是可以有更大的空間，用來增加產品slogan和場景圖，以達到向用戶介紹產品核心功能、烘托產品氛圍、宣傳品牌理念的目的。

2、簡單任務

如選擇器、輸入驗證碼、高級搜索、分享、操作權限確認、用戶反饋等一些單一、簡單的操作。多數情況下，這些彈窗更多的只是整個任務的一個過渡操作、前提設置，或者你可以把它看做僅僅是一個選擇器。

用懸停浮層來代替

有一些過渡操作，并不一定要使用傳統的模態彈窗，比如下面這種場景：用戶點擊“打印”時，需要用戶來選擇打印樣式（縱向和橫向），最開始我們的設計是讓用戶點擊“打印”后，顯示彈窗讓用戶選擇打印樣式，用戶需要選擇并確認（或直接確認默認選項），才能進入打印預覽界面。這樣看起來符合邏輯和用戶心理模型；但結果發現，對那些使用打印功能頻繁的用戶，每次這樣的彈窗“確認”讓人覺得 “多余”和“愚蠢”：我基本都是“橫向（或縱向）”打印，為什么每次都要讓我選擇？正是因為這樣，我們最終放棄了彈窗，而改用了這種浮層的設計：用戶懸停按鈕時，就即時顯示可選擇的選項，如果用戶不需要切換選項，直接點擊打印就好（這對于絕大多數用戶來說如此）。同時也允許用戶快速切換到其他選項。通過與真實用戶的溝通和觀察，我們發現他們很明顯更喜歡這種交互。

三、反饋

用戶點擊按鈕、完成任務，或系統狀態更新后，需要給用戶一個明確的反饋，這是人機交互中的一個至關重要的部分。如果只有輸入，沒有輸出，很容易造成用戶的不良情緒，如困惑、懷疑、不信任等。告知用戶發生了什么？結果如何？此外，容錯是評價一個產品可用性的重要標志之一，我們要在用戶可能“犯錯”前給予必要的提示、警告。

（1）重要操作確認

確認退出、確認刪除、確認提交……需在彈窗中告知用戶正在進行的操和可能帶來的“危害”，減少用戶犯錯的可能。有的可使用非模態浮層，但最好能顯示在操作觸發區域旁邊，以防止用戶忽略提示。

（2）告知操作結果

告知結果和影響，并引導用戶接下來可進行的任務；

如果只是普通的告知用戶操作成功（如申請成、刪除成功、提交成功……），這里建議使用toast提示即可，讓用戶“了解”即可，而不需要特別用戶關注和點擊關閉。如果是操作失敗，在告知結果同時，還需要告知用戶失敗的原因、需要做什么。

諸如導入等相對復雜、不可控和出錯率較高的任務，在操作失敗時還需要告知用戶具體出錯的位置，幫助用戶快速定位原因并找到解決方案。

（3）頁面異常

斷網、數據出錯、系統崩潰等。

（4）下線通知

頁面登錄超時，強制下線重新登錄；賬號被擠下等。

（5）其他反饋類彈窗

四、小結

在B端web設計中，彈窗的視覺樣式可以是多種多樣的（本文也并未過多涉及這方面），但從功能上來說，無外乎以上所述信息展示、任務、反饋三大類型。一般來說，如果可以替代，我們應慎重和少使用彈窗。但了解彈窗的各種應用場景，可以方便我們更好地權衡設計方案：是否可用彈窗？是否只能用彈窗？用二級頁面、浮層、甚至toast提示是否會更好……從另一個角度來說，了解彈窗的各種功能，對于我們梳理和規范現有產品框架、制定和完善設計交互及視覺規范來說，也是大有裨益的。

日常設計小結，如有不足，歡迎拍磚指正！

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

題圖來自 Unsplash，基于 CC0 協議