PJ MCLACHLAN: 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, WebAssembly.
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 a tap of a finger
or click of a mouse
in the browser
and without downloading
and installing software
is one of the web 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
a user's control and power.
It's tricky to balance
the trade-off between user
empowerment and safety.
Access must be controlled
from the web sandbox
to any feature that could
be used to violate the user
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 upfront.
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 this 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
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 blocked or
ignored 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 @b1tr0t.
[MUSIC PLAYING]
