Użytkownik kliknie przycisk, zrobi zrzut ekranu błędu i wyśle go bez niczego instalowania

Jest taki moment w życiu każdej aplikacji internetowej, w którym użytkownik napotyka coś złamanego. Przycisk, który nic nie robi po kliknięciu. Układ, który się zawalił na określonym rozmiarze ekranu. Formularz, który pochłania własny komunikat o błędzie. Użytkownik wpatruje się w ekran, zdezorientowany, a następnie robi jedną z dwóch rzeczy. Większość po prostu opuszcza i nigdy nie wraca. Nieliczni poświęcają czas na sformułowanie wiadomości w stylu "coś nie tak z twoją stroną." Ta wiadomość dociera bez kontekstu, bez opisu tego, co się stało, bez wskazania, która przeglądarka lub urządzenie było zaangażowane, i na pewno bez zrzutu ekranu pokazującego rzeczywisty problem. Deweloper czyta tę wiadomość, próbuje odtworzyć problem, ulegą porażce, a błąd pozostaje nienaprawiony, dopóki nie uderzy w następnego użytkownika. Ten cykl powtarza się nieskończenie w Internecie, a główna przyczyna nie jest lenistwem użytkownika. Główną przyczyną jest tarcie.

Zrobienie zrzutu ekranu na komputerze wymaga znajomości właściwego skrótu klawiaturowego, który różni się w zależności od systemu operacyjnego. W systemie Windows może to być Print Screen, lub Alt plus Print Screen dla aktywnego okna, lub klawisz Windows plus Shift plus S dla narzędzia przycięcia. Na Macu jest to Command plus Shift plus 3, lub 4, lub 5, każde dające nieco inne wyniki. Na telefonie gest polega na jednoczesnym naciśnięciu dwóch fizycznych przycisków, co w połowie czasu przypadkowo blokuje ekran zamiast tego. Po wykonaniu zrzutu ekranu musi on być zlokalizowany w systemie plików, dołączony do wiadomości e-mail lub wklejony do formularza wsparcia i wysłany. Każdy z tych kroków to kolejny punkt, w którym użytkownik się poddaje i decyduje, że błąd nie jest wart zgłoszenia. Wynikiem jest to, że deweloperzy otrzymują mniej więcej jeden raport na każde sto błędów, które naprawdę napotykają użytkownicy.

Rozwiązanie, które wyłoniło się z tej frustracji, jest wstydzące proste. Na stronie pojawia się mały przycisk. Gdy użytkownik go kliknie, serwer przechwytuje zrzut ekranu dokładnej strony, którą użytkownik przegląda i dołącza go do raportu. Nie wymagane rozszerzenie przeglądarki. Nie wymaga zapamiętywania skrótu klawiaturowego. Nie ma pliku do zlokalizowania i przesłania. Jeden klik, jeden zrzut ekranu, jeden raport. Użytkownik dodaje zdanie lub dwa opisujące, co poszło nie tak, a deweloper otrzymuje krystalicznie czysty obraz zepsutej strony wraz z opisem. To cały przepływ pracy, i zmienił sposób, w jaki przychodzą raporty o błędach.

Dlaczego rozszerzenia przeglądarki nigdy nie rozwiązały tego problemu

Oczywista pierwsza reakcja to że rozszerzenia przeglądarki już istnieją w tym celu. Dostępnych jest kilkadziesiąt narzędzi do zrzutów ekranu jako rozszerzenia Chrome, dodatki do Firefoksa i wtyczki Safari. Niektóre z nich są całkiem dobre, z funkcjami adnotacji, automatycznym przesyłaniem i integracją z platformami zarządzania projektami. Ale wszystkie mają tę samą fundamentalną wadę. Wymagają zainstalowania czegoś zanim błąd się pojawi. Nikt nie instaluje proaktywnie rozszerzenia do zgłaszania błędów na wypadek, gdyby witryna, którą odwiedzisz jutro, miała złamany układ. Rozszerzenia rozwiązują problem dla zespołów QA i wewnętrznych testerów, którym można powiedzieć, aby zainstalowali określone narzędzia. Robią absolutnie nic dla ogółu społeczeństwa napotykającego błąd po raz pierwszy na stronie, którą mogą nigdy więcej nie odwiedzić.

Jest też kwestia zaufania. Prośba od użytkownika do zainstalowania rozszerzenia przeglądarki w celu zgłoszenia błędu wprowadza szokującą zmianę w interakcji. Użytkownik przyszedł na stronę, aby coś osiągnąć, odkrył, że jest zepsute, a teraz zostaje poproszony o zainstalowanie oprogramowania innej firmy. Ta prośba słusznie wzbudzi podejrzenia u wielu użytkowników, a nawet ci, którzy są skłonni do współpracy, stoją w obliczu konieczności nawigowania po sklepach z rozszerzeniami, udzielania uprawnień i dowiedzenia się, jak narzędzie działa. Do czasu zainstalowania rozszerzenia pierwotny błąd może już nie być odtwarzalny, albo użytkownik po prostu przeszedł do konkurenta. Okno na przechwycenie raportu o błędzie jest wąskie, a wszystko, co rozszerza lukę między "coś nie tak" a "raport wysłany", oznacza, że raport nigdy nie zostanie wysłany.

Biblioteki zrzutów ekranu po stronie klienta, takie jak html2canvas, próbowały rozwiązać to z innego kąta. Te biblioteki JavaScript renderują DOM do elementu kanwy, skutecznie tworząc zrzut ekranu bez udziału serwera. Pracują całkiem dobrze dla prostych układów, ale szybko się załamują przy złożonym CSS, osadzonych ramkach, obrazach z różnych źródeł, elementach kanwy i niestandardowych czcionkach. Wynikowy obraz często wygląda zupełnie inaczej niż to, co naprawdę widzi użytkownik, co całkowicie pokonuje cel. Raport o błędzie zawierający zrzut ekranu, który nie odpowiada rzeczywistej stronie, jest gorszy niż brak zrzutu ekranu w ogóle, ponieważ wysyła dewelopera na polowanie na problem wizualny, który nie istnieje, podczas gdy rzeczywisty problem pozostaje ukryty.

Zrzuty ekranu po stronie serwera i jak przechwytują to, co widzi użytkownik

Podejście stojące za screenshots.yeb.to idzie zupełnie inną drogą. Zamiast próbować przebudować stronę po stronie klienta, serwer otrzymuje adres URL i renderuje go za pomocą rzeczywistego silnika przeglądarki działającego w kontrolowanym środowisku. Zrzut ekranu jest wykonywany przez rzeczywistą instancję Chromium, która ładuje stronę, wykonuje JavaScript, stosuje CSS, renderuje czcionki i przechwytuje wynik jako obraz o idealnej czystości pikseli. Oznacza to, że zrzut ekranu wygląda dokładnie jak to, co wyświetla rzeczywista przeglądarka, ponieważ to jest to.

Gdy użytkownik kliknie przycisk raportu o błędzie, bieżący adres URL strony jest wysyłany do serwera wraz z metadanymi dotyczącymi rozmiaru obszaru roboczego użytkownika, stosunku pikseli urządzenia i wszelkich istotnych parametrów stanu. Serwer uruchamia bezgłową sesję przeglądarki skonfigurowaną tak, aby była możliwie najbliska. Ładuje stronę, czeka na pełne wyrenderowanie wszystkich zasobów i przechwytuje zrzut ekranu. Wynik jest przechowywany i połączony z raportem o błędzie, dając deweloperowi dokładny zapis wizualny strony w momencie, w którym użytkownik kliknął przycisk. Cały proces trwa kilka sekund, co jest wystarczająco szybkie, aby użytkownik mógł dodać swój opis podczas gdy zrzut ekranu jest generowany w tle.

Warto dostrzec niuanse. Zrzut ekranu po stronie serwera przechwytuje stronę tak, jak pojawia się dla serwera, niekoniecznie dokładne piksele na ekranie użytkownika. Jeśli błąd jest spowodowany głupotą specyficzną dla przeglądarki, buforowaną zawartością lub lokalnie przechowywanym stanem, zrzut z serwera może nie być w stanie odtworzyć dokładnego artefaktu wizualnego. Ale w praktyce zdecydowana większość błędów, które zgłaszają użytkownicy, to problemy z układem, uszkodzone obrazy, brakująca zawartość lub błędy funkcjonalne, które są konsystentne niezależnie od tego, kto ładuje stronę. W tych przypadkach zrzut ekranu po stronie serwera nie różni się od zrzutu po stronie klienta, a ogromne zmniejszenie tarcia sprawia, że kompromis jest wart.

Osadzenie przycisku bez zmiany aplikacji

Integracja jest zamierzone minimalna. Mały fragment JavaScript ładuje komponent przycisk, który można stylizować, aby pasował do systemu projektowania aplikacji hosta. Przycisk unosi się w rogu strony, widoczny, ale nieinwazyjny. Po kliknięciu otwiera lekką nakładkę, w której użytkownik może wpisać krótki opis i opcjonalnie wyróżnić obszar strony, w którym problem się pojawił. Za kulisami fragment wysyła bieżący adres URL do API zrzutów ekranu, które przechwytuje stronę i zwraca adres URL obrazu. Raport, zawierający zrzut ekranu, opis, adres URL i podstawowe metadane przeglądarki, jest następnie przekazywany do celu, który deweloper skonfigurował: adres e-mail, webhook Slacka, narzędzie do zarządzania projektami lub niestandardowy punkt końcowy.

Cała integracja nie wymaga żadnych zmian w backend aplikacji. Nie ma SDK do zainstalowania, nie ma oprogramowania pośredniczącego do skonfigurowania, nie ma schematu bazy danych do zmiany. Fragment działa niezależnie, komunikując się tylko z interfejsem API zrzutów ekranu i skonfigurowanym celem raportu. Oznacza to, że można go wrzucić do bloga WordPress, aplikacji React jednostronicowej, statycznej witryny HTML lub starszej aplikacji PHP z taką samą łatwością. Czas od podjęcia decyzji o dodaniu raportowania błędów do uruchomienia na żywo mierzony jest w minutach, a nie sprintach.

Dla deweloperów, którzy chcą głębszej integracji, interfejs API można wywoływać bezpośrednio z kodu po stronie serwera. To otwiera możliwości, takie jak automatyczne wykonywanie zrzutu ekranu, gdy występuje nieobsługiwany wyjątek, lub okresowe wykonywanie zrzutów ekranu stron krytycznych i porównywanie ich z linią bazową w celu wykrycia regresji wizualnych. Ale do podstawowego przypadku użycia pozwalającego użytkownikom zgłaszać błędy jednym klikiem, fragment JavaScript obsługuje wszystko bez żadnych zmian na serwerze.

Co zmienia się, gdy raporty o błędach faktycznie się pojawią

Transformacja w jakości raportu o błędzie jest dramatyczna. Przed wdrożeniem przycisku typowy raport o błędzie był niejasnym zdaniem w wiadomości e-mail. "Strona wygląda dziwnie." "Kasa jest zepsuta." "Coś się stało, gdy próbowałem zapisać." Te raporty wymagały wielu pytań kontrolnych, podczas których użytkownik często tracił cierpliwość i przestał reagować. Po wdrożeniu przycisku raporty przychodzą z wyraźnym zrzutem ekranu pokazującym dokładnie, co poszło nie tak, wraz z metadanymi identyfikującymi stronę, rozmiar obszaru roboczego i czas wystąpienia. Deweloper może spojrzeć na zrzut ekranu i natychmiast zrozumieć problem bez żadnych dyskusji.

Liczba raportów również znacznie wzrasta. Użytkownicy, którzy nigdy nie sformułowaliby wiadomości e-mail ani nie wypełniliby formularza wsparcia, klikną przycisk i napiszą trzy słowa. "Menu nachodzi na zawartość" nie jest najbardziej szczegółowym raportem o błędzie na świecie, ale w połączeniu ze zrzutem ekranu pokazującym menu nawigacyjne nakładające się na główny obszar zawartości na oknie przeglądarki mobilnej, mówi deweloperowi wszystko, czego potrzeba, aby odtworzyć i naprawić problem. Kombinacja mniejszego tarcia i bogatszego kontekstu oznacza, że błędy są zgłaszane wcześniej, naprawiane szybciej i weryfikowane bardziej niezawodnie. Czasy odkrycia krytycznego błędu układu trzy tygodnie po jego wprowadzeniu są w dużej mierze przeszłością dla każdej aplikacji wdrażającej ten rodzaj mechanizmu opinii.

Istnieje wtórna korzyść, która jest mniej oczywista, ale równie cenna. Archiwum zrzutów ekranu staje się wizualną historią aplikacji. Każdy raport rejestruje moment w czasie, pokazując dokładnie, jak wyglądała strona, gdy użytkownik napotknął problem. Na przestrzeni tygodni i miesięcy to archiwum ujawnia wzorce. Być może konkretna strona zawsze się psuje, gdy wychodzi nowa wdrażanie. Być może użytkownicy mobilni zgłaszają problemy z szybkością trzykrotnie wyższą niż użytkownicy komputerów. Być może konkretna wersja przeglądarki konsekwentnie produkuje anomalie w układzie. Te wzorce są niewidoczne w raportach o błędach zawierających tylko tekst, ale natychmiast stają się widoczne podczas przeglądania galerii zrzutów ekranu z sygnaturą czasową.