原文地址:permission-uxgit
译文地址:请求权限的交互github
译者:杨芯芯web
得到 PushSubscription
并将其保存到咱们的服务器以后,就能够触发推送消息了,可是有一件事我以前一笔带过了,那就是向用户请求权限时的用户体验。服务器
使人遗憾的是,不多有网站会考虑他们应该如何向用户请求权限,因此让咱们简单地看看好的和很差的用户体验。post
现有的一些常见模式能够指导并帮助大家决定哪一种作法最适合大家的用户和需求。flex
在好处显而易见时才请求用户订阅推送。网站
举个例子,一个用户恰好在网上商店买了东西并且完成了付款流程。这时网站就能提供以后的物流状态更新。google
此处还有一系列适用的场景:翻译
这些都是用户投资你的服务的要点,启用推送通知对他们来讲有清晰的价值体现。
Owen Campbell-Moore 建立了一个虚拟的航空公司网站演示了这种方法。
在用户预订好一个航班以后,它会询问用户是否须要提供通知来提示可能的延误。
请注意,这是网站自定义的用户界面。
这个 demo 的另外一个优势是,假如用户点击启用通知,该网站会在显示权限提示时,在整个页面上添加半透明层,从而让用户注意到权限提示。
与之相对的,即较差的用户交互,是在用户打开航空公司网站时马上就请求权限。
这种方法没有告诉用户为何他须要通知,或是通知对他是否有用。这种方法也会阻碍用户达成其原有的目标(例如,预订一张机票)。
你也许以为你的网站的推送需求十分明确,所以能够当即向用户索要权限。
例如说即时通信软件或是邮件客户端,在各个平台显示信息或者邮件都是常见的用户体验。
对于这类软件,则更应考虑双重权限模式。
首先显示一个假的权限提示,这个提示由网站本身控制,由两个按钮组成,分别让用户容许或无视权限申请。若是用户点击了容许按钮,就会触发浏览器的权限提示。
经过这个方法,你能够在网站上展现一个自定义的弹窗来请求用户打开通知权限,不管用户如今打开仍是不打开通知权限,你的网站都不会有被永久屏蔽的风险。当用户在自定义弹窗中选择了启用通知,你就能够展现真正的权限请求弹窗,反之,你能够隐藏自定义弹窗而后在其余时机展现。
Slack 就是一个很好的例子。一旦用户登陆,他们就会在页面顶部展现一个弹窗,去请求用户启用通知。
你能够将通知功能放在设置面板中,让用户能够轻松地启用或关闭推送,也可以避免页面 UI 被打乱。
Google I/O's 2016 网页就是一个很好的例子. 当用户首次加载网站时,他们并不向用户请求任何权限,用户能够自由地探索页面。
几回访问后,单击右侧的菜单项会显示一个设置面板,容许用户设置和管理通知。
单击复选框将显示权限弹窗,没有任何隐藏的惊喜。
用户只要选中复选框,授予权限便可。这个用户界面的优势在于用户能够在页面的固定位置启用或关闭通知。
向用户推送消息的最简单的方法之一,是在页面的固定位置——同时贯穿全站的位置,放置一个按钮或开关,让用户能够随时启用或关闭通知。
这不会促使用户启用推送通知,但为用户提供了一种可靠且简单的方式与网站互动。对于拥有常规读者以及高跳出率的博客网站而言,这是一个不二选择,由于它针对的是常规读者,而且不会打扰到路过的新用户。
个人我的网站的页脚就有这样一个打开推送的开关。
这种方法至关不错,对常规用户来讲,想要获取更新的用户能充分地注意到它。一次性访问者则彻底不受影响。
若是用户订阅了推送消息,开关的状态就会在全站更改,并保持打开。
这些是我在网上注意到的一些常见作法,然而并非一些好的尝试。
最差的方法就是在用户进入网站时当即展现权限对话框。
对于收到的权限提示,用户没有任何心理准备。他们可能甚至都不知道你的网站是作什么的,或者提供了什么。他们在此时阻止受权并不罕见,由于这个弹窗阻碍了他们想作的事情。
记住,若是用户阻止了你的权限请求,你的网站就再也没法请求通知权限了。要在被阻止后得到权限,用户须要在浏览器中修改权限,这对用户来讲并不容易、明显或有趣。
不管如何,不要在用户一打开页面时就请求权限。能够考虑其余的用户界面或方法,来激励用户授予权限。
除了考虑用户订阅推送的交互外,请务必考虑用户要取消订阅或推送消息的状况。
使人震惊的是,依然有不少网站在用户进入页面时当即请求权限,而且不提供禁用推送的用户界面。
你的网站应该向用户说明如何禁用推送。不然用户可能会采起极端的方案——永久禁用推送权限。