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

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

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

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

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

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

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