原文地址:permission-uxgit
譯文地址:請求權限的交互github
譯者:楊芯芯web
得到 PushSubscription
並將其保存到咱們的服務器以後,就能夠觸發推送消息了,可是有一件事我以前一筆帶過了,那就是向用戶請求權限時的用戶體驗。服務器
使人遺憾的是,不多有網站會考慮他們應該如何向用戶請求權限,因此讓咱們簡單地看看好的和很差的用戶體驗。post
現有的一些常見模式能夠指導並幫助大家決定哪一種作法最適合大家的用戶和需求。flex
在好處顯而易見時才請求用戶訂閱推送。網站
舉個例子,一個用戶恰好在網上商店買了東西並且完成了付款流程。這時網站就能提供以後的物流狀態更新。google
此處還有一系列適用的場景:翻譯
這些都是用戶投資你的服務的要點,啓用推送通知對他們來講有清晰的價值體現。
Owen Campbell-Moore 建立了一個虛擬的航空公司網站演示了這種方法。
在用戶預訂好一個航班以後,它會詢問用戶是否須要提供通知來提示可能的延誤。
請注意,這是網站自定義的用戶界面。
這個 demo 的另外一個優勢是,假如用戶點擊啓用通知,該網站會在顯示權限提示時,在整個頁面上添加半透明層,從而讓用戶注意到權限提示。
與之相對的,即較差的用戶交互,是在用戶打開航空公司網站時馬上就請求權限。
這種方法沒有告訴用戶爲何他須要通知,或是通知對他是否有用。這種方法也會阻礙用戶達成其原有的目標(例如,預訂一張機票)。
你也許以爲你的網站的推送需求十分明確,所以能夠當即向用戶索要權限。
例如說即時通信軟件或是郵件客戶端,在各個平臺顯示信息或者郵件都是常見的用戶體驗。
對於這類軟件,則更應考慮雙重權限模式。
首先顯示一個假的權限提示,這個提示由網站本身控制,由兩個按鈕組成,分別讓用戶容許或無視權限申請。若是用戶點擊了容許按鈕,就會觸發瀏覽器的權限提示。
經過這個方法,你能夠在網站上展現一個自定義的彈窗來請求用戶打開通知權限,不管用戶如今打開仍是不打開通知權限,你的網站都不會有被永久屏蔽的風險。當用戶在自定義彈窗中選擇了啓用通知,你就能夠展現真正的權限請求彈窗,反之,你能夠隱藏自定義彈窗而後在其餘時機展現。
Slack 就是一個很好的例子。一旦用戶登陸,他們就會在頁面頂部展現一個彈窗,去請求用戶啓用通知。
你能夠將通知功能放在設置面板中,讓用戶能夠輕鬆地啓用或關閉推送,也可以避免頁面 UI 被打亂。
Google I/O's 2016 網頁就是一個很好的例子. 當用戶首次加載網站時,他們並不向用戶請求任何權限,用戶能夠自由地探索頁面。
幾回訪問後,單擊右側的菜單項會顯示一個設置面板,容許用戶設置和管理通知。
單擊複選框將顯示權限彈窗,沒有任何隱藏的驚喜。
用戶只要選中複選框,授予權限便可。這個用戶界面的優勢在於用戶能夠在頁面的固定位置啓用或關閉通知。
向用戶推送消息的最簡單的方法之一,是在頁面的固定位置——同時貫穿全站的位置,放置一個按鈕或開關,讓用戶能夠隨時啓用或關閉通知。
這不會促使用戶啓用推送通知,但爲用戶提供了一種可靠且簡單的方式與網站互動。對於擁有常規讀者以及高跳出率的博客網站而言,這是一個不二選擇,由於它針對的是常規讀者,而且不會打擾到路過的新用戶。
個人我的網站的頁腳就有這樣一個打開推送的開關。
這種方法至關不錯,對常規用戶來講,想要獲取更新的用戶能充分地注意到它。一次性訪問者則徹底不受影響。
若是用戶訂閱了推送消息,開關的狀態就會在全站更改,並保持打開。
這些是我在網上注意到的一些常見作法,然而並非一些好的嘗試。
最差的方法就是在用戶進入網站時當即展現權限對話框。
對於收到的權限提示,用戶沒有任何心理準備。他們可能甚至都不知道你的網站是作什麼的,或者提供了什麼。他們在此時阻止受權並不罕見,由於這個彈窗阻礙了他們想作的事情。
記住,若是用戶阻止了你的權限請求,你的網站就再也沒法請求通知權限了。要在被阻止後得到權限,用戶須要在瀏覽器中修改權限,這對用戶來講並不容易、明顯或有趣。
不管如何,不要在用戶一打開頁面時就請求權限。能夠考慮其餘的用戶界面或方法,來激勵用戶授予權限。
除了考慮用戶訂閱推送的交互外,請務必考慮用戶要取消訂閱或推送消息的狀況。
使人震驚的是,依然有不少網站在用戶進入頁面時當即請求權限,而且不提供禁用推送的用戶界面。
你的網站應該向用戶說明如何禁用推送。不然用戶可能會採起極端的方案——永久禁用推送權限。