En bruker klikker en knapp, tar et skjermbilde av feilen og sender det uten å installere noe

Det er et øyeblikk i livet til enhver nettapplikasjon der en bruker møter noe som er ødelagt. En knapp som ikke gjør noe når den klikkes på. En layout som kollapser på en bestemt skjermstørrelse. Et skjema som sluker sin egen feilmelding. Brukeren stirrer på skjermen, forvirret, og gjør deretter en av to ting. De fleste forlater ganske enkelt og kommer aldri tilbake. Få ta seg tid til å komponere en melding i tråd med "noe er galt med nettstedet ditt." Meldingen kommer uten kontekst, uten beskrivelse av hva som skjedde, uten indikasjon på hvilken nettleser eller enhet som var involvert, og helt sikkert uten et skjermbilde som viser det faktiske problemet. Utvikleren leser meldingen, prøver å gjenskape problemet, feiler, og feilen blir ikke fikset før det rammer neste bruker. Denne syklusen gjentar seg endeløst på hele Internett, og hovedårsaken er ikke bruker latskap. Hovedårsaken er friksjon.

Å ta et skjermbilde på en datamaskin krever å kjenne den rette tastatursnarveien, som varierer etter operativsystem. I Windows kan det være Print Screen, eller Alt plus Print Screen for det aktive vinduet, eller Windows-tasten pluss Shift pluss S for verktøyet for utsnittsbilde. På en Mac er det Command pluss Shift pluss 3, eller 4, eller 5, hver med litt ulike resultater. På en telefon innebærer gesten å trykke på to fysiske knapper samtidig, noe som halvparten av tiden ved et uhell låser skjermen i stedet. Etter at skjermbildet er tatt, må det finnes i filsystemet, vedlegges en e-post eller limes inn i et støtteskjema og sendes. Hvert av disse trinnene er nok et punkt der brukeren gir opp og bestemmer at feilen ikke er verdt å rapportere. Resultatet er at utviklere mottar omtrent en rapport for hver hundre feil som brukere faktisk møter.

Løsningen som oppsto fra denne frustrasjonen, er skamelig enkel. En liten knapp vises på siden. Når brukeren klikker den, tar serveren et skjermbilde av nøyaktig siden brukeren ser og legger den ved en rapport. Ingen nettlesertillegg påkrevd. Ingen tastatursnarveien å huske. Ingen fil å finne og laste opp. Én klikk, ett skjermbilde, én rapport. Brukeren legger til en setning eller to som beskriver hva som gikk galt, og utvikleren mottar et perfekt klart bilde av den ødelagte siden sammen med beskrivelsen. Det er hele arbeidsflyten, og det har endret måten bugraporter ankommer.

Hvorfor nettlesertillegg aldri løste dette problemet

Den åpenbare første reaksjonen er at nettlesertillegg allerede eksisterer for dette formålet. Det er dusinvis av skjermbildeverktøy tilgjengelig som Chrome-utvidelser, Firefox-tillegg og Safari-plugins. Noen av dem er ganske gode, med annoteringsfunksjoner, automatisk opplasting og integrering med prosjektstyringsplattformer. Men de deler alle samme grunnleggende feil. De krever at brukeren installerer noe før feilen oppstår. Ingen installerer på forhånd et bugrappporteringstillegg i tilfelle et nettsted de besøker i morgen har en ødelagt layout. Tillegg løser problemet for QA-team og interne testere som kan få beskjed om å installere spesifikke verktøy. De gjør absolutt ingenting for allmennheten som møter en feil for første gang på et nettsted de kanskje aldri besøker igjen.

Det er også spørsmålet om tillit. Å be en bruker installere et nettlesertillegg for å rapportere en feil introduserer en sjokkerende endring i interaksjonen. Brukeren kom til siden for å oppnå noe, oppdaget at det var ødelagt, og blir nå bedt om å installere tredjepartsprogramvare. Denne forespørselen vil med rette vekke mistenksomhet hos mange brukere, og selv de som er villige til å samarbeide, står overfor overhead ved å navigere i tilleggsbutikker, gi tillatelser og finne ut hvordan verktøyet fungerer. På det tidspunktet tillegget er installert, kan den opprinnelige feilen ikke lenger være gjengivelig, eller brukeren har ganske enkelt gått videre til en konkurrent. Vinduet for å fange en bugraport er smalt, og alt som utvider gapet mellom "noe er galt" og "rapport sendt" betyr at rapporten aldri blir sendt.

Klientsidebiblioteker på skjermbildet som html2canvas har forsøkt å løse dette fra en annen vinkel. Disse JavaScript-bibliotekene gir DOM-en til et lerret, og skaper effektivt et skjermbilde uten serverinvolvering. De fungerer ganske godt for enkle layouter, men kollapser raskt med kompleks CSS, innebygde iframes, kryssoversidebilder, lerretulementer og egendefinerte skrifttyper. Det resulterende bildet ser ofte ikke ut som det brukeren faktisk ser, noe som helt ødelegger formålet. En bugraport som inneholder et skjermbilde som ikke samsvarer med den virkelige siden, er verre enn ingen skjermbilde i det hele tatt, fordi det sender utvikleren jakt på et visuelt problem som ikke eksisterer, mens det virkelige problemet forblir skjult.

Skjermbilder på serversiden og hvordan de fanger det brukeren ser

Tilnærmingen bak screenshots.yeb.to tar en helt annen vei. I stedet for å prøve å rekonstruere siden på klientsiden, mottar serveren URL-en og gjengir den ved hjelp av en riktig nettlesermotor som kjører i et kontrollert miljø. Skjermbildet tas av en faktisk Chromium-forekomst som laster siden, kjører JavaScript, bruker CSS, gjengir skrifttyper og fanger resultatet som et pikselperfekt bilde. Dette betyr at skjermbildet ser nøyaktig ut som det en riktig nettleser viser, fordi det er det.

Når en bruker klikker på feilrapporteringsknappen, sendes gjeldende side-URL til serveren sammen med metadata om brukerens visningsportsstørrelse, enhetspikselforhold og relevante statusparametere. Serveren starter en hodet nettlesersesjon konfigurert til å stemme så nær som mulig. Den laster siden, venter på at alle eiendeler skal ferdigrendre og fanger skjermbildet. Resultatet lagres og kobles til feilrapporten, noe som gir utvikleren en nøyaktig visuell oversikt over siden på det tidspunktet brukeren klikket på knappen. Hele prosessen tar noen få sekunder, noe som er raskt nok til at brukeren kan legge til beskrivelsen mens skjermbildet genereres i bakgrunnen.

Det er nyanser som er verdt å erkjenne. Et skjermbilde på serversiden fanger siden slik den vises for serveren, ikke nødvendigvis de nøyaktige pikslene på brukerens skjerm. Hvis feilen er forårsaket av nettlesersspesifikke gjengivelseskunstigheter, bufret innhold eller lokalt lagret status, kan serveroppgaven kanskje ikke gjenskape det nøyaktige visuelle artefaktet. Men i praksis er det store flertallet av feil som brukere rapporterer layoutproblemer, ødelagte bilder, manglende innhold eller funksjonale feil som er konsistente uavhengig av hvem som laster siden. For disse tilfellene er et skjermbilde på serversiden ikke til å skille fra et på klientsiden, og den massive reduksjonen i friksjon gjør avgjørelsen verdt det.

Innebygd knappen uten å endre programmet

Integrasjonen er bevisst minimal. Et lite JavaScript-utdrag laster knappekomponenten, som kan utformes for å samsvare med vertsprogrammets designsystem. Knappen flyter i et hjørne av siden, synlig men uintrusive. Når du klikker på den, åpnes et lett overlegg der brukeren kan skrive en kort beskrivelse og eventuelt markere området på siden der problemet oppstod. Bak kulissene sender utdraget gjeldende URL til skjermbildet-APIen, som fanger siden og returnerer bilde-URL-en. Rapporten, som inneholder skjermbildet, beskrivelsen, URL-en og grunnleggende nettlesermetadata, blir deretter videresendt til destinasjonen utvikleren har konfigurert: en e-postadresse, en Slack-webhook, et prosjektstyringsverktøy eller et egendefinert sluttpunkt.

Hele integrasjonen krever ingen endringer i programmets backend. Det er ingen SDK å installere, ingen middleware å konfigurere, ingen databaseskjema å endre. Utdraget fungerer uavhengig, og kommuniserer kun med skjermbilde-API-en og det konfigurerte rapportdestinasjonens. Dette betyr at det kan slippes inn i en WordPress-blogg, et React-applikasjon med enkeltside, et statisk HTML-nettsted eller et eldre PHP-program med like stor letthet. Tiden fra å bestemme seg for å legge til feilrapportering til å ha det live på siden måles i minutter, ikke sprinter.

For utviklere som ønsker dypere integrering, kan API-en kalles direkte fra serverkode. Dette åpner muligheter som automatisk å ta et skjermbilde når en uhåndtert unntak oppstår, eller å ta periodiske skjermbilder av kritiske sider og sammenligne dem med en grunnlinje for å oppdage visuelle regresjoner. Men for grunnbrukstilfellet der du lar brukere rapportere feil med et enkelt klikk, håndterer JavaScript-utdraget alt uten noen serverendringer.

Hva endres når feilrapporter faktisk ankommer

Transformasjonen i feilrapportets kvalitet er dramatisk. Før implementeringen av knappen var den typiske feilrapporten en vag setning i en e-post. "Siden ser rart ut." "Kassen er ødelagt." "Noe skjedde da jeg prøvde å lagre." Disse rapportene krevde flere oppfølgingsspørsmål, hvor brukeren ofte mistet tålmodigheten og sluttet å reagere. Etter implementeringen av knappen ankommer rapporter med et klart skjermbilde av nøyaktig hva som gikk galt, sammen med metadata som identifiserer siden, visningsportstørrelsen og tidsforbrytelsen. En utvikler kan se på skjermbildet og umiddelbart forstå problemet uten noen fram og tilbake.

Mengden rapporter øker også betydelig. Brukere som aldri ville komponere en e-post eller fylle ut et supportskjema, vil klikke på en knapp og skrive tre ord. "Meny overlapper innhold" er ikke den mest detaljerte feilrapporten i verden, men kombinert med et skjermbilde som viser en navigasjonsmeny som overlapper hovedinntektsområdet på en mobil visningsport, forteller den utvikleren alt som trengs for å gjenskape og fikse problemet. Kombinasjonen av mindre friksjon og rikere kontekst betyr at feil rapporteres tidligere, fikses raskere og verifiseres mer pålitelig. Dagene med å oppdage en kritisk layoutfeil tre uker etter at den ble introdusert, er stort sett forbi for enhver applikasjon som distribuerer denne typen tilbakemeldingsmekanisme.

Det er en sekundær fordel som er mindre åpenbar, men like verdifull. Arkivet med skjermbilder blir en visuell historie av programmet. Hver rapport fanger et øyeblikk i tid, og viser nøyaktig hvordan siden så ut da brukeren møtte et problem. Over uker og måneder avslører arkivet mønstre. Kanskje en bestemt side sammenfaller hver gang en ny distribuering kommer ut. Kanskje mobilbrukere rapporterer problemer med en hastighet tre ganger høyere enn skrivebordbrukere. Kanskje en bestemt nettleserversjon produserer konsekvent layoutavvik. Disse mønstrene er usynlige i tekstbaserte feilrapporter, men blir umiddelbar tydelige når du blar gjennom et galleri med tidsmerket skjermbilder.