前言
该文章翻译自web.dev的Notifications系列文章，本篇文章原文链接点击这里
获取PushSubscription对象之后的下一步需要将该对象保存在服务器，以便后续推送消息使用。但我公然漏掉了一个重要事情——向用户获取消息推送权限时的用户体验。
遗憾的是，很少有网站认真考虑过如何向用户获取权限，所以让我们简短的介绍一下什么是好的UX，什么是坏的UX。
获取权限的常见模式
已经有一些常见的模式，这些模式可以指导和帮助你做出决定，哪些对你的用户和你的网站是最好的。
考虑用户利益
当用户能明显从中获益时，向用户索取权限。例如，一个用户刚刚下单购买了一个商品并完成了支付的流程。网站可以通知物品的发货状态。
类似还有其他场景，可以向用户获取通知权限：
- 商品库存不足，询问是否愿意在库存更新时，收到网站的通知。
- 某个突发新闻后续会有更新，询问是否愿意在有新闻更新时，接收网站的通知。
- 你是出价最高的竞标者，是否愿意在未中标时收到通知。
这些场景都有一个重要的点，就是用户在订阅了你的推送通知后，能从中获益。
我们模拟创建一个订购机票的网站来演示这个方式。当用户订了一张机票之后，询问用户是否接收航班延误的通知。注意上面询问权限提示框的UI是自定义的。
这个例子另外一个优点是当用户点击了启用通知，网站在展示权限提示框的时候添加了一个半透明的遮罩层，它可以很好的吸引用户的注意。
这个例子的另外一个获取权限时糟糕的用户体验是用户一进入你的网站就获取该权限。
这种方式没有提供任何的上下文，为什么要获取通知权限，不仅如此，权限的提示框也妨碍了用户做其他事情，如下单订机票。
二次权限获取模式
你可能觉得我的网站有很明确的消息推送的需求，并在用户一进入网站就向用户请求获取权限。如及时通讯类的应用或者邮件客户端，当新的邮件或者消息到达时显示通知，在各个平台上都是很常见的。
对于这类应用，指得去考虑一下二次获取权限的模式。
首先展示一个假的权限提示框，他可以由你的网站控制，上面显示允许和忽略的按钮，当用户点击允许，我们调用请求权限的代码来触发真正的浏览器权限提示框。
这种展示自定义权限提示框的方式，用户可以选择允许时，展示真正的权限提示框，当用户选择拒绝时，能够避免权限被永久拒绝的风险。（开启通知权限的设置在浏览器中隐藏较深，用户不容易开启），此时我们只需要关闭权限弹框，等待其他合适的时机时再向用户获取权限。
这种模式比较好的例子是，用户登录网站后，展示权限获取提示框，询问是否愿意接收通知。
设置面板
你还可以将通知放入设置面板，这种方式能够使用户更容易的启用或禁用消息推送，这种方式不会让你的UI显得很杂乱。
这种模式比较好的例子是Google I/O网站，你不会被询问任何的权限，用户可以任意的浏览网站，几次访问之后，当用户点击右侧，会打开设置面板。那里可以允许用户设置和管理通知。
点击选择框后会展示权限提示框，没有任何不合理之处。
用户授权之后，选择框被选中，用户可以继续执行其他操作。这种方式的好处是用户可以在网站的单一入口启用或者禁用推送通知。
被动模式
还有一个简单的方式来向用户提供推送功能，在网也的某个位置添加一个按钮或者切换开关，允许用户启用或禁用消息推送，他可以在整个网站中保持一致。
这种模式不会强迫用户启用推送通知，但是提供了一个简单可靠的操作方式。例如一个博客类的网站可能会有一些固定的访问者有比较高的跳出率，这种方式使得这些固定访问者没有被打扰的担忧。
我在我个人博客网站的地步放置了一个消息推送的切换开关。
这个方式比较罕见，但是那些愿意获取最近更新的固定访问者会注意到他，而那些一次性的访问者则完全不会收到影响。如果用户订阅了消息推送，切换开关的状态在整个网站中都会保持开启状态。
糟糕的用户体验
我也注意到很多网站有一些常见做法，遗憾的是，这都是一些糟糕的做法。
最糟糕的例子就是用户刚打开的网站，就展示权限提示框。这没有任何上下文，为什么网站要获取该权限，用户甚至不知道你的网站是干嘛的，或者这个网站能提供什么。这个时候用户会很容易的就拒绝授权。权限提示框也会阻止用户本来要干的事情。
记住，一旦用户拒绝，你的网站无法再次获取该权限。权限被拒绝之后，用户想要更改的话，就必须在浏览器的设置中修改，对用户来说这是很难的。
无论如何，请不要在用户刚打开网站时，就询问获取权限。思考其他能够激励用户允许授权的方式活或者UI。
提供取消订阅的方式
订阅用户另外一个需要考虑的用户体验是如何让用户操作能够取消用户订阅。很多网站在页面一加载就获取该权限，但是却不提供UI来禁用推送通知。你的网站应该向用户解释他们可以在哪里关闭推送，否则用户也可能永久的关闭通知权限。