Чип запроса разрешений

Разрешения UX до сих пор

Когда пользователь посещает сайт, который запрашивает разрешение, появляется всплывающее окно, предлагающее пользователю принять решение. Например, ниже вы можете увидеть запрос на разрешение геолокации, реализованный в Chrome до версии 96. (Вы можете попробовать это и другие разрешения на нашем демонстрационном сайте Permission.site .)

Запрос на разрешение геолокации Chrome

Большинство запросов на разрешение игнорируются или отклоняются.

Данные телеметрии Chrome доказывают, что многие запросы на получение разрешений игнорируются. Вы можете самостоятельно изучить данные о разрешениях на уведомления в отчете Chrome UX. А пока рассмотрим приведенную ниже таблицу, в которой показано, как пользователи Windows реагировали на запросы уведомлений на сайтах в совокупности, отметив при этом, что запросы геолокации имели аналогичное поведение отклонения или игнорирования.

Действие Процент уведомлений
Позволять 6,69%
Блокировать 9,20%
Увольнять 35,76%
игнорировать 47,19%

Учитывая, что уровень игнорирования/отклонения составляет около 85 %, и особенно учитывая, насколько сильно выделяется подсказка и настаивает на немедленном принятии решения пользователями, существует конфликт между уровнем срочности, предполагаемым браузером, и предпочтением пользователя подождать, чтобы принять решение. решение. Это создает впечатление, что сайту «раздражает» запрашивать разрешение, поскольку оно будет потеряно среди потенциальных дополнительных вещей, на которые пользователи должны реагировать, таких как баннеры согласия на использование файлов cookie, подписка на рассылку новостей и т. д.

Новый дизайн

Поэтому, начиная с Chrome 98, мы представили пользовательский интерфейс с анимированным чипом, который появляется рядом с замком всякий раз, когда запрашивается разрешение. Он состоит из значка и метки, описывающих запрашиваемое разрешение. Нашей целью было улучшить удобство просмотра веб-страниц, избегая при этом запросов на разрешения, которые обычно не нужны подавляющему большинству пользователей и часто игнорируются или отклоняются.

Существующий пузырь подсказки будет отображаться при нажатии на чип запроса (если он еще не показан), а пользовательский интерфейс запроса автоматически дополняется пузырьком запроса на основе эвристики, перечисленной ниже:

  • Разрешение активировалось посредством жеста пользователя при взаимодействии с самим сайтом, а не автоматически активировалось сайтом.
  • Разрешение считается необходимым и, как правило, не является спамом. В настоящее время сюда входят камера, микрофон и камера, сопряженная с микрофоном.

Блок-схема перехода от замка к запросу геолокации, который, если его закрыть, приводит к появлению значка «геолокация заблокирована», который после четырехсекундной задержки наконец снова заменяется замком.

Форсирование нового дизайна

Поскольку это поэтапное внедрение, вы можете принудительно использовать новый дизайн, переключая следующие флаги:

  • chrome://flags/#permission-chip
  • chrome://flags/#permission-chip-gesture
  • chrome://flags/#permission-chip-request-type

Поток нового дизайна

Без жестов пользователя

Для второстепенных разрешений, не вызываемых жестом, запрос больше не вторгается в содержимое сайта и не требует немедленного решения. Пользователь может игнорировать чип запроса до тех пор, пока у него не будет достаточно информации для принятия решения.

Без взаимодействия

Без какого-либо взаимодействия и после небольшой задержки чип запроса автоматически превратится в простой значок блокировки (что означает, что разрешение временно заблокировано), а затем будет полностью отклонен. Цель состоит в том, чтобы уйти с дороги пользователей, которые предпочитают не принимать решения, позволяя им делать это без какого-либо взаимодействия.

Блок-схема перехода от замка к ненавязчивому чипу геолокации, который после двенадцатисекундной задержки приводит к появлению значка «геолокация заблокирована», который после четырехсекундной задержки наконец снова заменяется навесным замком.

Ожидаемый краткосрочный эффект

В краткосрочной перспективе, пока пользователи не привыкнут к новому пользовательскому интерфейсу, вполне вероятно, что владельцы сайтов будут наблюдать более низкие ставки предоставления разрешений для сайтов, особенно для тех, которые автоматически запрашивают разрешения без предварительной загрузки или требования жеста пользователя (что считается плохим все равно потренируйся ). Этот признанный недостаток значительно перевешивается менее отвлекающим опытом.

Лучшие практики

Сайт должен гарантировать, что он предоставляет необходимый контекст и запрашивает разрешения только в подходящий и ожидаемый момент. Разрешения, которые были временно заблокированы (из-за того, что пользователь проигнорировал запрос или отклонил приглашение), могут повторно запросить разрешение в рамках того же сеанса. Делайте это только в том случае, если разрешение необходимо для работы сайта или функции, в противном случае существует риск раздражать пользователей и автоматически блокироваться. В таких случаях мы показываем тихий обмен сообщениями , который был представлен в Chrome 80. Более общие рекомендации см. в разделе Permission UX .

Перспективы и выводы

Есть планы по дальнейшим улучшениям пользовательского интерфейса и UX. Команда Chrome уже работает над ними и исследует потенциально более агрессивную автоматическую блокировку разрешений на основе предыдущего поведения. Вы узнаете о новостях здесь, как только эти планы созреют.

В заключение отметим, что новый пользовательский интерфейс уменьшает ощущение настойчивости в принятии решения и улучшает удобство просмотра. Поскольку большинство запросов на получение разрешений блокируются или игнорируются, поставленная цель состояла в том, чтобы улучшить общее впечатление от просмотра, не нарушая при этом потоки пользователей при отображении запроса на разрешение, особенно в ситуациях, когда разрешения необходимы для завершения варианта использования.

Благодарности

Изображение героя, созданное Зигмундом на Unsplash . Эта статья была рассмотрена Джо Медли .