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

До сих пор, когда пользователь посещал сайт, запрашивающий разрешение, всплывал пузырь, предлагающий пользователю принять решение. Например, вы можете увидеть запрос на разрешение геолокации, реализованный в 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 уже работает над ними и исследует потенциально более агрессивную автоматическую блокировку разрешений на основе предыдущего поведения. Вы узнаете о новостях здесь, как только эти планы созреют.

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

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

Этот документ был проверен Джо Медли .