Tot nu toe verscheen er een bel wanneer een gebruiker een site bezocht die toestemming vroeg om de gebruiker te vragen een beslissing te nemen. U kunt bijvoorbeeld de toestemmingsprompt voor geolocatie zien zoals geïmplementeerd in Chrome tot en met versie 96. (U kunt deze en andere machtigingen proberen op onze demosite Permission.site .)
De telemetriegegevens van Chrome bewijzen dat veel toestemmingsprompts worden genegeerd. U kunt zelf de toestemmingsgegevens voor meldingen in het Chrome UX-rapport verkennen. Bekijk voor nu de onderstaande tabel die laat zien hoe Windows-gebruikers op een cumulatieve manier reageerden op de meldingsprompt op sites, waarbij ze opmerkten dat geolocatieprompts een soortgelijk afwijs- of negeergedrag vertoonden.
Gegeven een negeer- en afwijzingspercentage van ongeveer 85%, en vooral gezien de mate waarin de prompt opvalt en erop aandringt dat gebruikers onmiddellijk een beslissing nemen, is er een conflict tussen het urgentieniveau dat door de browser wordt aangenomen en de voorkeur van de gebruiker om te wachten met het maken van een beslissing. een beslissing. Dit creëert de perceptie dat het "vervelend" is voor een site om toestemming te vragen, omdat dit verloren gaat in de potentiële extra dingen waarop gebruikers moeten reageren, zoals banners voor toestemming voor cookies, aanmeldingen voor nieuwsbrieven, enz.
Nieuw ontwerp
Vanaf Chrome 98 hebben we daarom een geanimeerde chip-UI geïntroduceerd die naast het slot verschijnt wanneer er om toestemming wordt gevraagd. Deze bestaat uit een pictogram en label dat de gevraagde toestemming beschrijft. Ons doel was om de ervaring van surfen op het web te verbeteren en tegelijkertijd toestemmingsverzoeken te vermijden die voor de overgrote meerderheid van de gebruikers over het algemeen onnodig zijn en vaak worden genegeerd of afgewezen.
De bestaande promptballon wordt weergegeven wanneer op de verzoekchip wordt geklikt (indien nog niet weergegeven) en de verzoek-UI wordt automatisch uitgebreid met de verzoekballon op basis van de volgende heuristieken:
- De toestemming werd geactiveerd via een gebruikersgebaar bij interactie met de site zelf, in plaats van automatisch geactiveerd door de site.
- De toestemming wordt als essentieel beschouwd en is over het algemeen niet-spammend. Dit omvat camera, microfoon en camera gekoppeld aan microfoon.
Het nieuwe ontwerp forceren
Omdat dit een gefaseerde implementatie is, kun je het nieuwe ontwerp forceren door de volgende vlaggen in of uit te schakelen:
-
chrome://flags/#permission-chip -
chrome://flags/#permission-chip-gesture -
chrome://flags/#permission-chip-request-type
Stroom van het nieuwe ontwerp
Zonder gebruikersgebaar
Voor niet-essentiële toestemmingen die niet door een gebaar worden geactiveerd, dringt de prompt niet langer door in de inhoud van de site en dringt hij niet aan op een onmiddellijke beslissing. De gebruiker kan de verzoekchip negeren totdat hij voldoende informatie heeft om een beslissing te nemen.
Zonder interactie
Zonder interactie en na een korte vertraging zal de verzoekchip automatisch samenvouwen tot slechts een geblokkeerd pictogram (om aan te geven dat de toestemming tijdelijk wordt geblokkeerd), voordat deze volledig wordt afgewezen. Het doel is om gebruikers die ervoor kiezen geen beslissing te nemen uit de weg te gaan, zodat ze dit zonder enige interactie kunnen doen.
Verwachte impact op de korte termijn
Op de korte termijn, en totdat gebruikers gewend raken aan de nieuwe gebruikersinterface, is het waarschijnlijk dat site-eigenaren lagere subsidietarieven voor sites zullen zien, vooral voor sites die automatisch toestemming vragen zonder voorbereiding of een gebruikersgebaar eisen (wat als een slechte zaak wordt beschouwd). toch oefenen ). Dit erkende nadeel wordt ruimschoots gecompenseerd door de minder onderbrekende ervaring.
Beste praktijken
Het is aan de site om ervoor te zorgen dat deze de noodzakelijke context biedt en alleen toestemming vraagt op het juiste en verwachte moment. Machtigingen die tijdelijk zijn geblokkeerd (doordat een gebruiker het verzoek negeert of de prompt afwijst) kunnen binnen dezelfde sessie opnieuw om toestemming vragen. Doe dit alleen als de toestemming essentieel is om de site of functie te laten werken, anders loop je het risico dat gebruikers geïrriteerd raken en automatisch geblokkeerd worden. In die gevallen tonen we de stille berichtgeving die werd geïntroduceerd in Chrome 80. Zie Permission UX voor meer algemene richtlijnen.
Vooruitzichten en conclusies
Er zijn plannen voor verdere UI- en UX-verbeteringen. Het Chrome-team werkt er al aan en onderzoekt mogelijk agressievere automatische blokkering van rechten op basis van eerder gedrag. Zodra deze plannen volwassen zijn, leest u hier meer over het nieuws.
Concluderend kan worden gesteld dat de nieuwe gebruikersinterface de waargenomen aandrang op een beslissing vermindert en de browse-ervaring verbetert. Omdat de meeste toestemmingsprompts worden geblokkeerd of genegeerd, was het bereikte doel het verbeteren van de algemene surfervaring, zonder de gebruikersstromen te onderbreken bij het tonen van een toestemmingsprompt, vooral in situaties waarin toestemming vereist is om een gebruiksscenario te voltooien.
Dankbetuigingen
Dit document is beoordeeld door Joe Medley .