Tot nu toe verscheen er een pop-upvenster wanneer een gebruiker een site bezocht die om 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 toestemmingen uitproberen op onze demosite permission.site .)
De telemetriegegevens van Chrome bewijzen dat veel toestemmingsprompts worden genegeerd. U kunt de gegevens over toestemmingen voor meldingen in het Chrome UX-rapport zelf bekijken. Bekijk eerst de onderstaande tabel die laat zien hoe Windows-gebruikers in totaal reageerden op de meldingsprompt op websites, waarbij geolocatieprompts een vergelijkbaar gedrag vertoonden bij het negeren of negeren ervan.
Gezien het negeer- en afwijzingspercentage van ongeveer 85%, en vooral gezien de mate waarin de prompt opvalt en gebruikers ertoe aanzet direct een beslissing te nemen, is er een conflict tussen de mate van urgentie die de browser aanneemt en de voorkeur van de gebruiker om te wachten met een beslissing. Dit wekt de indruk dat het "irritant" 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 cookietoestemming, aanmeldingen voor nieuwsbrieven, enzovoort.
Nieuw ontwerp
Vanaf Chrome 98 hebben we daarom een geanimeerde chip-UI geïntroduceerd die naast het slotje verschijnt wanneer er toestemming wordt gevraagd. Deze bestaat uit een pictogram en een label dat de gevraagde toestemming beschrijft. Ons doel was om de surfervaring te verbeteren en tegelijkertijd toestemmingsverzoeken te vermijden die over het algemeen onnodig zijn voor de overgrote meerderheid van de gebruikers en vaak worden genegeerd of genegeerd.
De bestaande promptbubbel wordt weergegeven wanneer op de aanvraagchip wordt geklikt (indien deze nog niet wordt weergegeven). De aanvraag-UI wordt vervolgens automatisch aangevuld met de aanvraagbubbel op basis van de volgende heuristiek:
- De toestemming werd geactiveerd door een gebaar van de gebruiker tijdens interactie met de site zelf, en niet automatisch door de site zelf.
- De toestemming wordt als essentieel beschouwd en is over het algemeen niet-spammend. Dit geldt voor camera, microfoon en camera gekoppeld aan microfoon.
Het nieuwe ontwerp afdwingen
Omdat dit een gefaseerde uitrol is, kunt u het nieuwe ontwerp afdwingen 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 tot de inhoud van de site en dringt 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 aanvraagchip automatisch inklappen tot een geblokkeerd pictogram (om aan te geven dat de toestemming tijdelijk is geblokkeerd), voordat deze volledig wordt verwijderd. Het doel is om gebruikers die ervoor kiezen om geen beslissing te nemen en hen dit zonder interactie te laten doen, te ontlopen.
Verwachte impact op korte termijn
Op de korte termijn, en totdat gebruikers gewend zijn aan de nieuwe gebruikersinterface, zullen website-eigenaren waarschijnlijk lagere toestemmingspercentages voor websites zien, vooral voor websites die automatisch toestemming vragen zonder gebruikers te primen of een gebaar te eisen (wat sowieso als een slechte gewoonte wordt beschouwd). Dit erkende nadeel wordt ruimschoots gecompenseerd door de minder verstorende ervaring.
Beste praktijken
Het is aan de site om ervoor te zorgen dat de benodigde context wordt geboden en alleen op het juiste en verwachte moment om toestemming wordt gevraagd. Toestemmingen die tijdelijk zijn geblokkeerd – doordat een gebruiker het verzoek negeert of de prompt negeert – kunnen binnen dezelfde sessie opnieuw om toestemming vragen. Doe dit alleen als de toestemming essentieel is voor de werking van de site of functie, anders bestaat het risico dat gebruikers geïrriteerd raken en automatisch worden geblokkeerd. In die gevallen tonen we de stille berichten die in Chrome 80 zijn geïntroduceerd. Zie Permission UX voor meer algemene richtlijnen.
Vooruitzichten en conclusies
Er zijn plannen voor verdere verbeteringen aan de gebruikersinterface en gebruikerservaring. Het Chrome-team werkt er al aan en onderzoekt mogelijk agressievere automatische blokkering van toestemmingen op basis van eerder gedrag. U leest hier meer over zodra deze plannen zijn uitgewerkt.
Concluderend vermindert de nieuwe gebruikersinterface de waargenomen aandrang op een beslissing en verbetert het de browse-ervaring. Omdat de meeste toestemmingsvragen worden geblokkeerd of genegeerd, was het doel om de algehele browse-ervaring te verbeteren zonder de gebruikersstromen te verstoren bij het weergeven van een toestemmingsvraag, met name in situaties waarin toestemming vereist is om een use case te voltooien.
Dankbetuigingen
Dit document is beoordeeld door Joe Medley .