Platforma internetowa umożliwia użytkownikom udostępnianie ekranu za pomocą interfejsu Screen Capture API. Implementacja getDisplayMedia() w Chrome obejmuje selektor multimediów, za pomocą którego użytkownicy mogą udostępniać dowolną kartę, okno lub ekran. Począwszy od wersji 107 Chrome eksperymentowaliśmy z niewielką modyfikacją tego okna dialogowego, umieszczając karty jako pierwszą opcję, aby zachęcić użytkowników do udostępniania kart, a nie całego ekranu. Jest to oparte na dobrze rozumianej koncepcji, że sposób sformułowania pytania wpływa na rozkład odpowiedzi. Jest to tzw. teoria kija, a dzieci nazywają ją „proszę bardzo”. Po początkowych problemach eksperyment okazał się wielkim sukcesem, dlatego udostępniliśmy tę nową funkcję wszystkim użytkownikom.
Jak omawialiśmy wcześniej, udostępnianie kart jest zwykle lepszą opcją:
- Lepsza ochrona prywatności, ponieważ użytkownicy są znacznie mniej narażeni na ujawnienie prywatnych informacji z innych aplikacji, powiadomień, tapet na pulpicie lub ustawień.
- Lepsze wykorzystanie powierzchni ekranu po stronie odbierającej.
- Lepsze wykorzystanie zasobów sieci dzięki udostępnianiu mniejszej liczby pikseli.
Dlatego jako pierwszą opcję eksperymentowaliśmy z kartami.
Początkowy etap wdrażania eksperymentu wykazał niekorzystny skutek uboczny: umieszczenie kart na początku zwiększyło częstotliwość wybierania przez użytkowników bieżącej karty. W przypadku wielu aplikacji, a być może nawet większości z nich, nie jest to pożądane. Na przykład w przypadku aplikacji do wideokonferencji powoduje to efekt „hali luster”, który dezorientuje uczestników i utrudnia rozmowy. W związku z tym wstrzymaliśmy eksperyment.
Na szczęście w Chrome 107 dostępna jest opcja selfBrowserSurface. Ta opcja umożliwia aplikacji określenie, czy Chrome ma uwzględnić bieżącą kartę na liście kart oferowanych użytkownikowi, czy ją z niej wykluczyć. Ponieważ jest to nowa opcja, zdecydowana większość aplikacji internetowych nie podaje w tym miejscu żadnej wartości. W odnowionym eksperymencie, począwszy od Chrome 108, wartość domyślna została zmieniona z "include" na "exclude". Dzięki temu udało się wyeliminować niepożądany efekt, a jednocześnie umożliwić korzystanie z poprzedniego zachowania w przypadku specjalistycznych aplikacji.
Zmiana wartości domyślnej w ramach eksperymentu przyniosła też pewne korzyści – samozapisywanie zmniejszyło się z około 0,8% sesji zapisywania do prawie 0%, eliminując prawie wszystkie przypadki takiego samosabotażu, które wcześniej dotyczyły prawie 1 z 100 użytkowników.
Eksperyment został wznowiony w Chrome 108. Gdy dotarła do 50% użytkowników, zaobserwowaliśmy te wyniki:
- Udostępnianie kart wzrosło z 16% do 30%.
- Udostępnianie okna zostało zwiększone z 14% do 20%.
- Udostępnianie ekranu zmniejszyło się z 55% do 36%.
- Samochwytywanie (na podstawie karty) zmniejszyło się z 0,8% do 0%.
- Liczba anulowań wzrosła o różną wartość. Więcej informacji znajdziesz poniżej.
- Aktywacje (liczba wywołań funkcji
getDisplayMedia()) wzrosły o zmienną wartość.
Byliśmy bardzo zadowoleni z ograniczenia częstotliwości udostępniania kart, okien i ekranów. Jednak zmiany w anulowaniach i aktywowaniach mogły wzbudzić niepokój.
Po dłuższym prowadzeniu eksperymentu zauważyliśmy, że liczba anulowań w grupie eksperymentalnej zbliżyła się do liczby anulowań w grupie kontrolnej. To potwierdzało naszą teorię, że użytkownicy rezygnowali z gry, gdy tylko zobaczyli nieznaną im rozmowę, a z czasem się do niej przyzwyczajali.
Powyższa teoria może częściowo wyjaśniać wzrost liczby aktywacji, ponieważ liczby nie zgadzają się, a liczba aktywacji w grupie testowej pozostała wyższa. Prawdopodobnym wyjaśnieniem wzrostu liczby aktywacji jest to, że gdy użytkownicy udostępniali cały ekran, nie musieli zatrzymywać i ponownie uruchamiać nagrywania, aby udostępnić coś innego. Teraz, gdy częściej udostępniali karty i okna, częściej musieli ponownie uruchamiać nagrywanie. Mamy nadzieję, że w przyszłości uda nam się wprowadzić dalsze ulepszenia, umożliwiając płynniejsze przejścia między rejestrowaniem różnych powierzchni.