 Hi, I'm PJ, and this talk is about getting permission, patterns for making fluid permission requests. The web is expanding in exciting new directions and as a platform. With powerful apps like G Suite, Google Earth, or AutoCAD, all running in the web browser, more is possible with the modern web than ever before. For example, we have location access, camera, mic, push notifications, offline, web assembly. These are just a few examples of modern capabilities that have arrived on the web in the last few years. And there's a lot more coming, too. But this new power often relies on underlying device capabilities. The web is a sandbox that's designed to let users safely run untrusted code on their computer, enabling users to quickly and safely use websites and web apps from untrusted sources with the tap of a finger or click of a mouse in the browser and without downloading and installing software is one of the web's superpowers. The W3C developed a set of ethical principles for the web, and there's two that especially apply to powerful web capabilities and permissions. First, the principle that security and privacy are essential and second, that the web must enhance the user's control and power. It's tricky to balance the trade-offs between user empowerment and safety. Access must be controlled from the web sandbox to any feature that could be used to violate the user's security and privacy. But browsers must give users control and power to allow access when it's safe to do so and in ways that facilitate their goals. Many advanced web capabilities are effectively letting users open up gateways in and out of the sandbox. To adhere to the W3C principles, browsers need to err on the side of user safety. But browsers can't know what a web app will want to do with a given permission. So browser UI, for permissions, is context-free by necessity. Web developers need to help users understand what access their application is requesting and what it will be used for to help users make empowered decisions. First, only ask for permission you really need. Trust and fluency are everything in the modern digital world. If a user doesn't understand why you're asking for permission, you've risked your trust with that user. Worse, you may have interrupted their workflow with a prompt, increasing their cognitive load, distraction, and the chances that they won't get value out of your offering. Second, be clear and specific about what you need and why in advance of prompting. Don't assume that your users know what your brand is or what your app does. Explain to them clearly or make sure the usage is fully aligned to the user's gesture. Third, prompt at a contextually relevant moment in the user's journey. Don't ask for permissions up front. Fourth, degrade gracefully. If a user ignores or blocks a permission, make sure your experience still works. Fifth, if a block or ignored permission is needed to use a feature of your app, make this obvious to your users, but don't get in the way of other features that don't need that permission to work. These principles will not only make your user's journey more pleasant. They'll contribute to better business metrics as well. Users hate being interrupted, and they hate getting broken experiences. Keeping these principles in mind in your app design makes for a better user journey. Let's do this by example. Don't ask the user if they want to allow push notifications as soon as they land on your website. In the future, Chrome will minify the push permission prompt for sites with very low push accept rates. You can already test this feature out in Chrome Canary by enabling the quieter notification permission prompt flag. Please do prompt for notification permission when there is a clear benefit and a context to the user. Don't prompt for location permission without user context. For example, users may not know why they're being asked for their location. If there's no map or location UI visible in the page or if it's below the fold, please do prompt for location permission after an explicit user action. Please don't prompt for mic or camera access without explicitly indicating how it's going to be used in advance. Do make use of mic and video permissions where appropriate. Either explain the upcoming prompt in advance or associate the permission prompt with obvious context, such as following a user gesture to start a video or chat session. Please don't fail silently if a user ignored or blocked necessary access for a feature they're trying to use. But do explain why your feature won't work without access and let your users know they'll need to enable access if they want to use that feature. To recap, these are the principles of good permissions request UX. First, only ask for access you really need. Second, be clear and specific. Third, prompt at a contextually relevant moment. Fourth, degrade gracefully. And fifth, when a block to ignore permission is needed, make that obvious. Thank you so much for listening. If you have any feedback or questions, please reach out to me on Twitter at B1T or 0T.