在正确的情境中向用户获取iOS权限.pdfVIP

在正确的情境中向用户获取iOS权限 话说今天这篇文章 ，最近几日看到到处在转 外一版译文 ，相对浓缩一些 ，也挺好看的 ；我学我的 ，我做我的。文中阐述的思路和具体方法 ，值得各位设计伙思考与参考 ；“术”未必对所有的产品都 适用 ，但“道”确是皆通一理。下面进入译文。 Clust er是我设计过的第一个iO S原生应用 ，整个历程让我学习到了很多在过去的Web设计当中不曾 考虑过的东西。在Web世界中 ，你通常只需要创建页面让用户浏览或使用 ，而在iO S上 ，除了引导 用户下载并使用你的应用以外 ，你时常需要向他们索取各方面的权限 ，例如获取地理位置 ，或是访 问通讯录、相机、照片等等。 在设计Clust er的过程中 ，我们在很多细微却充满变数的交互环节里花了不少心思 ，以提升用户的满 意度及信任感 ；其中“怎样向用户索取权限”就是我们关注的重点之一。 关于这一点 ，我们得出的结论可以概括为 ： 除非当前确实需要 ，否则不要向用户索取权限。 索取权限时要让用户明确的了解授权后的好处是什么。 一次性成功获取权限的重要性 对很多应用来说 ，无法成功获取权限便意味着整体功能和体验的大打折扣。例如LBS类的应用 ，如 果在索取权限时遭到用户的拒绝 ，那么该应用基本等同于无用了。 外 ，如果消息推送在你的应用 当中扮演着微妙而重要的作用 ，能使用户保持习惯性的使用 ，那么获取权限时的失败或许会导致用 户的流失。 更坏的是 ，点击“不允许”是很轻松的 ，而要撤销这个决定则不太容易 ，用户至少需要以下五步才能 打开授权 ，而且在应用内部很难为用户列出这些详细的步骤 ，更没法帮他们直接进入相关设置界面 ，用户只能靠自己去摸索。 1.退回到系统 2.进入设置 3.找到“隐私”设置项 4 .进入“照片” 5.找到需要授权的应用并打开权限 换句话说 ，如果用户第一次拒绝了授权 ，使应用无法正常使用 ，那么应用自身几乎没可能向用户解 释怎样修复这一问题。所以我们要尽最大努力确保第一次向用户索取访问权限时用户能点击“好”。 两种常见的设计模式 关于索取访问权限 ，我们通常会见到两种设计模式。 初次加载时即刻索取(不推荐) 大家应该都见过这种模式。你下载好一个应用 ，初次打开 ，界面当中立刻跳出一个提示 ：“我们可以 给你推送消息吗 ？”然后又是一个提示 ：“我们可以访问你的相机吗 ？”接着又是一个“我们可以访问你 的通讯录吗 ？” 除非用户很熟悉或信赖这款产品 ，否则他们更可能去点击“不允许”。这种方式和走在大街上随便拉 一个人过来问“你能和我约会吗 ？”差不多。 我们在第一版的Clust er里使用了这种方法 ，结果只有不到4 0%的用户会同意授权。 让用户了解好处(次佳) 比起没头没脑的向用户索取权限 ，这种方式略好些 ，但有效性依然不高。 如上图所示 ，HeyDay应用在索取权限时会在提示框中对授权之后能得到的好处进行说明。而且 ， 他们是在功能介绍的最后一步向用户索取权限的 ，这使得用户在决定是否授权之前就已经对应用的 功能有了大致的了解(假设用户确实会阅读功能介绍) ，从而更有可能通过授权。 我们的Clust er在采用了这种方式之后 ，一次性通过授权的用户量从4 0%提升到了 %的样子。 对于某些特定的应用 ，如果只能在以上两种方式当中进行选择 ，那么让用户在了解好处之后再决定 是否授权 ，比单纯的提问要有效的多。 我们的探索 我们持续探索着Clust er向用户索取权限的方式 ，并找到了两种方法 ，使权限对话框尽可能的在用户 想要说“好”的时候才出现。 预授权对话框 我们用到了一个小技巧 ，也就是在系统弹出授权对话框之前向用户展示我们自己创建的“预授权”对 话框。 正像前面所说的 ，用户在系统层面拒绝对应用授权是很糟的状况 ，因为要重新打开授权是很麻烦的 。不过如果我们在系统级授权对话框之前预先询问 ，那么即使被用户拒绝 ，我们也仍然有一次机会 能让他们说“好”。 对于Clust er的照片访问授权来说 ，那些在“预授权”对话框里点击“不允许”的用户当中有4 %会在接下 来出现的系统级授权对话框中点击“好”。 实现方式比你想象的要简单。你可以增加一个额外的iO S系统对话框 ，或设计一个定制化的界面 ， 来实现“预授权”。 1.iO S系统风格的预授权对话框 在较早的一个版本中 ，我们尝试了这种方式 ，也就是使用iO S系统风格的对话框询问用户两次 ；其 中第一次的就是我们额外增加的“预授权”对话框 ： 预授权对话框(上图中间的界面)会在应用第一次需要访问照