概述：無論是否使用彈出窗口，大多數(shù)窗口疊加都出現(xiàn)在錯誤的時間组砚，在進行關(guān)鍵任務時中斷用戶峻呕，使用不良語言利职，并導致用戶迷失方向。
通過進行數(shù)十年的用戶研究瘦癌，我們知道人們不喜歡彈出窗口和彈出框猪贪。在最近的一次可用性研究中，我想起了這一事實讯私。在嘗試完成任務時热押，一名參與者在連續(xù)遇到多個彈出窗口后將他的手機扔到了桌子上。令人沮喪的是斤寇，他放棄了任務桶癣，離開了網(wǎng)站，給組織留下了非常壞的印象娘锁。其他幾個用戶也有類似的看法牙寞，盡管他們沒有扔掉他們的手機。
彈出窗口（也稱為疊加或彈出）是覆蓋在頁面內(nèi)容上部（層）顯示的窗口或?qū)υ捒颉棾龃翱诳梢愿鶕?jù)兩個維度進行分類：
- 用戶是否可以與頁面的其余部分進行交互：
- 模態(tài)框（Modal）：在用戶明確地與疊加層交互之前间雀，頁面上的內(nèi)容將被禁用悔详。
- 非模態(tài)框（nonmodal）：用戶仍然可以與背景內(nèi)容進行交互（例如，通過選擇鏈接或點擊按鈕）惹挟，同時覆蓋疊加仍然可見茄螃。
- 背景是否變暗：
- 如果背景變暗，則彈出窗口稱為lightbox连锯。
- 當背景內(nèi)容沒有視覺上的變暗時归苍，沒有特殊名稱。
雖然在許多情況下lightbox屬于模態(tài)框（Modal）运怖，但并非總是如此拼弃。
在彈出窗口的定義中吗购，模態(tài)框（Modal）禁用所有背景內(nèi)容医男，非模態(tài)框（nonmodal）疊加保留用戶與背景內(nèi)容交互的能力，lightbox使背景內(nèi)容變暗捻勉。
幾個星期以來镀梭，我捕獲了在網(wǎng)站和移動應用程序中遇到的每個彈出窗口的屏幕截圖：平均每周 25 個彈出窗口，這比任何人能夠忍受的都要多（但非常能代表今天的互聯(lián)網(wǎng)用戶體驗）踱启。 這個實驗連同我的可用性研究一起出現(xiàn)了無數(shù)糟糕的實踐报账，并證明疊加已經(jīng)遠遠被過度使用了。 我們已經(jīng)接近網(wǎng)站濫用這些元素的程度埠偿，以至于有問題的實例遠遠超過彈出窗口仍然是一種有用的設計策略的情況透罢。在本文中，我將概述我觀察到的問題并討論要考慮的關(guān)鍵因素冠蒋，以及彈出窗口的實際替代方案羽圃，以遵循組織的意圖和用戶體驗。
彈出窗口的時機：在交互之前或關(guān)鍵任務期間不要提示
1.在加載主頁內(nèi)容之前顯示彈出窗口：無論使用何種變體抖剿，在用戶可以從你的網(wǎng)站或應用程序中收集有價值的內(nèi)容之前朽寞，切勿顯示彈出窗口。這種趨勢是非常具有侵入性的斩郎，因為用戶的任務在他們登陸頁面之前就被打斷了脑融。人們已經(jīng)習慣于在網(wǎng)站上看到過早的彈出窗口并且通常忽略它們或者立即尋找最快的方式來關(guān)閉彈出窗口返回任務。在頁面加載之前出現(xiàn)的彈出窗口使網(wǎng)站看起來很不舒服缩宜，用戶體驗感讓人抓狂肘迎。此外，未能識別這些事實的網(wǎng)站在搜索引擎結(jié)果中排名很低 [Google懲罰網(wǎng)站]（https://webmasters.googleblog.com/2016/08/helping-users-easily-access-content-on.html）的做法是使用戶無法訪問內(nèi)容，特別是在移動設備上膜宋。
替代方案：等待彈出窗口中的內(nèi)容窿侈，直到它與用戶的上下文相關(guān)。使用互惠原則：在向他們詢問任何內(nèi)容之前給予訪問者有價值的內(nèi)容秋茫，無論是請求電子郵件地址，還是取消彈出窗口的操作乃秀。運行用戶測試以確定適合計劃在彈出窗口中顯示的任何內(nèi)容的上下文肛著，并找出顯示該內(nèi)容的最佳方式; 在許多情況下，它不會在彈出窗口中跺讯。在頁面內(nèi)容加載之前顯示任何類型的彈出窗口是可接受的唯一用例是枢贿，當你的網(wǎng)站有法律義務要求用戶同意接受使用cookie或驗證其年齡時。
2.在用戶登錄后立即顯示彈出窗口：用戶登錄后顯示的彈出窗口與頁面內(nèi)容加載前顯示的彈出窗口一樣令人煩惱耀态。當用戶登錄帳戶時，他們會考慮下一步或后續(xù)任務暂雹，否則他們?yōu)槭裁磿卿浭鬃埃浚×⒓闯霈F(xiàn)任何類型的彈出窗口會分散注意力并妨礙他們完成下一步杭跪。因為他們專注于下一步仙逻，所以用戶可能不會關(guān)注彈出窗口或突然關(guān)閉彈出窗口。不僅如此涧尿，他們可能會因為中斷以及關(guān)閉彈出窗口或移動它所需的額外時間和交互成本而感到沮喪系奉。
替代方案：在登錄帳戶后，為用戶提供一些時間和空間來完成任務姑廉，并且不會立即顯示彈出窗口缺亮。在經(jīng)過一段時間后，最終提供有用的庄蹋、可以接受的帳戶提示瞬内、指南或新功能是，但前提是用戶的任務得到顯示的內(nèi)容或新功能的增強或進一步支持限书。在這些情況下虫蝶，總是傾向于使用較少侵入性的方法（如工具提示和小型非模態(tài)框疊加層）來傳達這些元素。
3.在交互之前詢問電子郵件地址：許多網(wǎng)站和應用程序在有機會與內(nèi)容交互之前使用彈出窗口來詢問用戶的電子郵件地址。電子商務粉铐，新聞網(wǎng)站和應用程序以及博客是此類別中最大的違規(guī)者疼约。這種方法存在問題，因為人們不僅會因為彈出窗口蝙泼、其彈出時機以及網(wǎng)站過早要求電子郵件地址這一事實感到惱火程剥，而且他們還會認為該網(wǎng)站會向他們發(fā)送垃圾郵件。
例如汤踏，登陸 Uncommon Goods 網(wǎng)站的一個用戶在受到模態(tài)框（Modal）的問候時感到不滿织鲸，其要求輸入她的電子郵件地址才可以訪問秘密銷售。她說溪胶，“當我在網(wǎng)站上做其他事情之前搂擦，這樣的東西突然出現(xiàn)，真讓我惱火哗脖。如果我第一次來到這個網(wǎng)站瀑踢，我怎么知道我是否想成為電子郵件訂閱者？我希望稍后再說才避〕髫玻“
在詢問用戶的電子郵件地址時，需要考慮許多權(quán)衡因素肢娘。網(wǎng)站和應用程序通常使用過早的模態(tài)框（Modal）呈础，因為它們產(chǎn)生的指標會在短期內(nèi)上升。然而橱健，短期指標通常會以使許多用戶感到沮喪為代價而钞，而這些用戶并非出于任意激勵，例如秘密銷售拘荡。
替代方案：與其在早期顯示電子郵件彈出窗口臼节，不如考慮用戶何時最愿意與您共享其電子郵件地址。他們是否正在瀏覽具有適用促銷代碼的類別珊皿？或許他們只是閱讀（或掃描）了整篇博文网缝。這些動作可能是最小侵入性非模態(tài)疊加的適當觸發(fā)器，可能出現(xiàn)在靠近右上角或右下角的位置蟋定，使用合理數(shù)量的屏幕空間粉臊。向用戶提供有價值的和有形的內(nèi)容，以換取他們的電子郵件地址; 不要只是指望他們主動交出來驶兜。
4.在人們做了任何有意義的事情之前要求反饋：接收用戶的反饋非常重要屠凶，但當用戶在你的網(wǎng)站上做任何事情之前驰后，不應該向他們發(fā)送反饋提示。網(wǎng)站和應用程序傾向于立即向用戶提供反饋彈出窗口矗愧，希望他們能夠給予高度評價并繼續(xù)他們的任務灶芝。但是這種情況很少發(fā)生; 更常見的是，用戶迅速關(guān)閉彈出窗口唉韭，無意再次尋找它监署。
在體驗中的適當位置從用戶那里獲得有意義的反饋，可以深入了解他們面臨的挑戰(zhàn)和障礙纽哥。 但是如果你過早地要求反饋，你可能會在最重要的時候沒有得到任何反饋栖秕。例如春塌，當一名研究參與者試圖在ATT.com上支付電話賬單時，對出現(xiàn)的反饋模式感到沮喪簇捍。她說只壳，“嗯，我付賬單后會給出反饋暑塑，但現(xiàn)在我很沮喪吼句，因為我還沒有做任何事情就讓我給出反饋∈赂瘢”
替代方案：要求用戶在完成您網(wǎng)站上的頂級任務后立即提供反饋。此方法可以最大限度地減少中斷并確保反饋基于實際的互動逢捺。例如谁鳍，視頻會議軟件 BlueJeans 在會議結(jié)束后要求用戶提供反饋。此請求未提前顯示劫瞳，但在上下文相關(guān)且適當?shù)臅r間出現(xiàn)了倘潜。
5.在關(guān)鍵任務期間中斷用戶請求反饋：用戶討厭被打斷恨憎，但是在完成關(guān)鍵任務的過程中蕊退，大量網(wǎng)站和應用程序通過反饋彈出窗口干擾用戶郊楣。大多數(shù)情況下，提供反饋并不是用戶訪問網(wǎng)站的首要原因瓤荔，因此也不要在關(guān)鍵任務中使用彈出窗口來擾亂人們净蚤。
替代方案：除了要求用戶僅在完成關(guān)鍵任務后提供反饋之外输硝，還提供靜態(tài)的今瀑、非侵入性的方式，以便隨時提供反饋点把。屏幕一側(cè)的選項卡橘荠，頁腳中的鏈接或?qū)Ш街械逆溄佣际瞧茐男阅B(tài)框的可接受替代方案，并讓用戶在準備就緒時能夠分享他們的觀點郎逃。
6.逐個顯示多個彈出窗口：在彼此上方顯示多個彈出窗口會使你的網(wǎng)站看起來不專業(yè)贮懈、絕望和雜亂無章。它還會壓倒用戶并迫使他們花費精力來關(guān)閉每個窗口优训。如果你的站點使用許多不同類型的彈出窗口朵你，測試實施以避免一次向用戶顯示多個彈出窗口。
替代方案：如果你必須在彈出窗口中顯示關(guān)鍵信息（例如重要警告以防止或糾正錯誤）揣非，請確保一次只顯示一個抡医。更妙的是，不要在彈出窗口中顯示關(guān)鍵信息早敬，因為人們傾向于在沒有閱讀的情況下關(guān)閉它們忌傻。相反，使用視覺上不同的元素并將其直接放在頁面上搁嗓，其中消息提示最適合上下文芯勘。確保副本清楚、準確地傳達用戶需要做些什么來糾正問題并繼續(xù)前進腺逛。
彈出上下文：不妨礙內(nèi)容的轉(zhuǎn)換或訪問
7.在用戶移動到新的子域或外部站點之前顯示模態(tài)框覆蓋：某些公司網(wǎng)站會鏈接到位于子域和外部站點上的內(nèi)容或應用程序荐类。在用戶離開主站點之前，會出現(xiàn)一個模態(tài)框疊加圖茁帽，提醒用戶即將發(fā)生的轉(zhuǎn)換玉罐。這種類型的彈出窗口是有問題的屈嗤，因為它過分強調(diào)了過渡，使用戶感到迷茫和困惑吊输，特別是如果子站點是在新的瀏覽器選項卡中打開時饶号。
在我們的一次可用性測試會議期間，一位在HSBC網(wǎng)站上尋找工作的參與者在嘗試基本上分為3個不同網(wǎng)站的任務時遇到了兩種不同的過渡模式季蚂。他說茫船，“哇，它一直把我?guī)У狡渌W(wǎng)站扭屁，我甚至不知道我在哪里了算谈。如果他們的工作申請流程如此復雜和脫節(jié)，我真的不認為這是一個好的工作地方料滥。無論這個網(wǎng)站看起來多么漂亮然眼，這似乎都是一團糟】梗”
替代方案：將用戶鏈接到外部屬性時浴井，刪除模態(tài)框，最小化站點之間的過渡霉撵，并始終保留回主站點的導航磺浙。如果你的用戶確實需要在離開你的網(wǎng)站時收到警告，使用較少侵入性的選項（例如鏈接上的工具提示）以淡化過渡轉(zhuǎn)換徒坡。
8.通過模態(tài)框疊加中斷對內(nèi)容的訪問：在用戶加載文章或其他長篇內(nèi)容（例如通常在網(wǎng)站的關(guān)于我們或新聞部分中找到的內(nèi)容）之后立即出現(xiàn)的模態(tài)對話框伦泥，使其看起來好像網(wǎng)站在限制對該內(nèi)容的訪問。這種環(huán)境是一個特別不好的表現(xiàn)锦溪，因為它會降低網(wǎng)站的可信度不脯。CNN移動應用程序中的一個用戶在登陸他想閱讀的文章后立即遇到郵件訂閱模態(tài)框時感到沮喪。他說刻诊，“這導致我對CNN的懷疑達到頂峰防楷。不要要求我填寫電子郵件或立即注冊任何內(nèi)容≡蜓模”
替代方案：允許用戶在不中斷的情況下直接使用內(nèi)容亿昏。將彈出窗口替換為頁面頂部的易于關(guān)閉的橫幅峦剔。彈出窗口的替代方案將允許用戶如果想要訂閱時事通訊時可以自行訂閱，而不會阻斷他們收看信息的主要任務龙优。
彈出內(nèi)容：不要假設模態(tài)框疊加將傳遞消息
9.使用模態(tài)框疊加來進行GDPR和cookie通知：用戶已經(jīng)匆忙關(guān)閉了模態(tài)框疊加野舶，因為他們認為沒有任何好處。為了傳達與GDPR和cookie的使用相關(guān)的重要信息宰衙，請不要使用模態(tài)框疊加平道。
替代方案：最好放置在頁面底部或側(cè)面的非模態(tài)框疊加。這些功能的侵入性要小得多供炼，并且允許用戶繼續(xù)執(zhí)行任務一屋。確保提供有關(guān)如何收集和使用用戶個人數(shù)據(jù)的足夠信息。
10.鼓勵模態(tài)疊加中的頻道轉(zhuǎn)換，而不傳達特定的好處：經(jīng)车芮蹋可以看到鼓勵用戶從移動網(wǎng)站過渡到相關(guān)移動應用程序的模式虫腋，尤其是在電子商務或新聞網(wǎng)站上。在許多情況下稀余，這些疊加是破壞性的并且存在問題：通常悦冀，網(wǎng)絡用戶是一次性用戶，他們沒有興趣為臨時任務下載應用程序睛琳。
可以理解的是盒蟆，組織希望鼓勵應用程序下載，但模式覆蓋不是宣傳你的移動應用程序的正確方法师骗。即使是手機上有應用程序的用戶也可能不愿意切換頻道茁影，因為害怕重新開始他們的流程。模態(tài)框疊加只會困擾他們丧凤。
替代方案：為組織的移動應用程序創(chuàng)建意識募闲，但不以侵入用戶當前任務為代價。偏向于低調(diào)的方法愿待，例如標準的頂部橫幅浩螺，并概述了使用該應用程序來簡化人們向該頻道過渡的好處靴患。
總結(jié)
鑒于這個總體結(jié)論或颊，你可能想知道何時可以使用彈出窗口; 答案是：謹慎使用。 抵制跟隨人群的沖動传于，不要因為中斷而淹沒用戶以支持短期指標囱挑。探索尊重用戶需求的替代方法，并保持組織收集反饋的意圖沼溜，通知用戶數(shù)據(jù)收集平挑，獲取電子郵件地址或鼓勵頻道轉(zhuǎn)換。
保留使用模態(tài)框疊加系草，以便僅在適當?shù)臅r間提供關(guān)鍵信息通熄。不要通過大量的侵入式彈出窗口中斷基本任務或阻止相關(guān)內(nèi)容。進行可用性測試找都，以確保你的彈出窗口不會讓你的用戶感到沮喪唇辨，并且作為額外的好處，你將獲得真正的意見反饋能耻，以幫助你改善整體體驗助泽。
（編譯完）
英文原文：地址
原文作者：Anna Kaley
原文譯者：Linkedin / 微博 / Twitter
以上譯文僅代表原作者觀點。如需轉(zhuǎn)載請遵循CC版權(quán)協(xié)議正確標明出處嚎京。
