En användare klickar på en knapp, tar en skärmbild av buggen och skickar den utan att installera något

Det finns ett ögonblick i varje webbapplikations liv när en användare stöter på något som är bruten. En knapp som inte gör något när man klickar på den. En layout som kollapsar på en viss skärmstorlek. Ett formulär som sväljer sitt eget felmeddelande. Användaren tittar på skärmen, förvirrad, och gör sedan ett av två saker. De flesta lämnar helt enkelt och kommer aldrig tillbaka. En sällsynt få tar sig tid att skriva ett meddelande i stil med "något är fel med din webbplats." Det meddelandet kommer utan sammanhang, utan beskrivning av vad som hände, utan någon indikation på vilken webbläsare eller enhet som användes, och säkerligen utan en skärmbild som visar det faktiska problemet. Utvecklaren läser meddelandet, försöker återskapa problemet, misslyckas, och buggen förblir orättad tills den biter nästa användare. Denna cykel upprepas utan slut över Internet, och rotorsaken är inte användares lathet. Rotorsaken är friktion.

Att ta en skärmbild på en dator kräver att man vet rätt tangentbordsgenväg, vilket varierar beroende på operativsystem. På Windows kan det vara Print Screen, eller Alt plus Print Screen för det aktiva fönstret, eller Windows-tangent plus Shift plus S för snippverktyget. På en Mac är det Command plus Shift plus 3, eller 4, eller 5, var och en producerar något olika resultat. På en telefon innebär gesten att man trycker på två fysiska knappar samtidigt, vilket hälften av tiden av misstag låser skärmen istället. Efter att skärmdumpen är tagen måste den hittas i filsystemet, bifogas ett e-postmeddelande eller klistras in i ett supportformulär och skickas. Var och en av dessa steg är en annan punkt där användaren ger upp och beslutar att buggen inte är värd att rapportera. Resultatet är att utvecklare får ungefär en rapport för varje hundra buggar som användare faktiskt stöter på.

Lösningen som kom ur denna frustration är skamligt enkel. En liten knapp visas på sidan. När användaren klickar på den, fångar servern en skärmbild av exakt sidan som användaren visar och bifogar den till en rapport. Ingen webbläsartillägg krävs. Ingen tangentbordsgenväg att komma ihåg. Ingen fil att hitta och ladda upp. En klick, en skärmbild, en rapport. Användaren lägger till en mening eller två som beskriver vad som gick fel, och utvecklaren får en perfekt tydlig bild av den bruten sidan tillsammans med beskrivningen. Det är hela arbetsflödet, och det har förändrat hur buggrappporter anländer.

Varför webbläsartillägg aldrig löste detta problem

Den uppenbara första reaktionen är att webbläsartillägg redan finns för detta ändamål. Det finns dussintals screenshotverktyg tillgängliga som Chrome-tillägg, Firefox-tillägg och Safari-insticksprogram. Några av dem är ganska bra, med anteckningsfunktioner, automatiska uppladdningar och integrering med projekthanteringsplattformar. Men de delar alla samma grundläggande fel. De kräver att användaren installerar något innan buggen inträffar. Ingen installerar ett bugrapporteringstillägg förebyggande på chansen att någon webbplats de besöker i morgon kommer att ha en bruten layout. Tillägg löser problemet för QA-team och interna testare som kan instrueras att installera specifika verktyg. De gör absolut ingenting för allmänheten som stöter på en bugg för första gången på en plats de kanske aldrig besöker igen.

Det finns också frågan om tillit. Att fråga en användare att installera ett webbläsartillägg för att rapportera en bugg introducerar en skarp förskjutning i interaktionen. Användaren kom till webbplatsen för att göra något, upptäckte att den var bruten, och nu blir han/hon ombedd att installera tredjepartsprogramvara. Den begäran kommer med rätta att väcka misstankar hos många användare, och även de som är villiga att följa med möter omkostnader för att navigera i tilläggsbutiker, ge behörigheter och ta reda på hur verktyget fungerar. När tillägget väl är installerat kanske den ursprungliga buggen inte längre är återproducerbar, eller så har användaren helt enkelt fortsatt till en konkurrent. Fönstret för att fånga en bugrapport är smalt, och allt som utökar gapet mellan "något är fel" och "rapport skickad" betyder att rapporten aldrig skickas.

JavaScript-bibliotek för screenshotning på klientsidan som html2canvas har försökt lösa detta från en annan vinkel. Dessa JavaScript-bibliotek renderar DOM till ett canvas-element, vilket effektivt skapar en skärmbild utan någon serverinvolvering. De fungerar ganska bra för enkla layouter men bryter snabbt med komplex CSS, inbäddade iframes, bilder från olika ursprung, canvas-element och anpassade typsnitt. Den resulterande bilden ser ofta inte ut som det användaren faktiskt ser, vilket förslår syftet helt och hållet. En bugrapport innehållande en skärmbild som inte matchar den verkliga sidan är värre än ingen skärmbild alls, eftersom den skickar utvecklaren jaga ett visuellt problem som inte existerar medan det verkliga problemet förblir dolt.

Serversidesscreenshots och hur de fångar det användaren ser

Tillvagagångssättet bakom screenshots.yeb.to tar en helt annan väg. Istället för att försöka rekonstruera sidan på klientsidan mottar servern URL:en och renderar den med en verklig webbläsarmotor som körs i en kontrollerad miljö. Skärmdumpen tas av en faktisk Chromium-instans som laddar sidan, kör JavaScript, tillämpar CSS, renderar typsnitt och fångar resultatet som en pixelperfekt bild. Detta betyder att skärmdumpen ser exakt ut som vad en verklig webbläsare visar, eftersom det är vad en verklig webbläsare visar.

När en användare klickar på bugrapportknappen skickas URL:en för den aktuella sidan till servern tillsammans med metadata om användarens visningsruta, enhetspixelförhållande och relevanta tillståndsparametrar. Servern startar en headless-webbläsarsession konfigurerad för att matcha dessa parametrar så nära som möjligt. Den laddar sidan, väntar på att alla tillgångar slutför renderingen och fångar skärmdumpen. Resultatet lagras och länkas till buggrapporten, vilket ger utvecklaren ett korrekt visuellt register över sidan när användaren klickade på knappen. Hela processen tar några sekunder, vilket är tillräckligt snabbt för att användaren kan lägga till sin beskrivning medan skärmdumpen genereras i bakgrunden.

Det finns nyanser värda att erkänna. En serversidesscreenshot fångar sidan som den visas för servern, inte nödvändigtvis de exakta pixlarna på användarens skärm. Om buggen är orsakat av webbläsarspecifika renderingsegenheter, cachelagrat innehål eller lokalt lagrad tillstånd, kanske serverinfångningen inte återger den exakta visuella artefakten. Men i praktiken är den stora majoriteten av buggar som användare rapporterar layoutproblem, bruten bilder, saknat innehål eller funktionella fel som är konsekventa oavsett vem som laddar sidan. För dessa fall är en serversidesscreenshot omöjlig att skilja från en klientsidescreenshot, och den massiva minskningen av friktion gör avvägningen värd.

Bädda in knappen utan att ändra applikationen

Integreringen är avsiktligt minimal. Ett litet JavaScript-kodsnippet laddar knappkomponenten, som kan utformas för att matcha värdapplikationens designsystem. Knappen flyter i ett hörn av sidan, synlig men diskret. När man klickar på den öppnas ett lättvägt överlägg där användaren kan skriva en kort beskrivning och eventuellt markera området på sidan där problemet uppstod. I bakgrunden skickar kodstycket den aktuella URL:en till screenshot-API:et, som fångar sidan och returnerar bildadressen. Rapporten, innehållande skärmdumpen, beskrivningen, URL:en och grundläggande webbläsarmetadata, vidarebefordras sedan till vad utvecklaren än har konfigurerat: en e-postadress, en Slack-webhook, ett projekthanteringsverktyg eller en anpassad slutpunkt.

Hela integreringen kräver inga ändringar av applikationens backend. Det finns ingen SDK att installera, ingen middleware att konfigurera, inget databasschema att ändra. Kodstycket fungerar oberoende, kommunicerar endast med screenshot-API:et och den konfigurerade rapportdestinationen. Detta betyder att det kan släppas in i en WordPress-blogg, en React-ensidaapplikation, en statisk HTML-webbplats eller en äldre PHP-applikation med samma lätthet. Tiden från att besluta att lägga till felrapportering till att ha den live på webbplatsen mäts i minuter, inte sprintar.

För utvecklare som vill ha djupare integrering kan API:et anropas direkt från serverskodning. Detta öppnar möjligheter som automatisk fångning av en skärmbild när ett ohanterat undantag inträffar, eller att ta periodiska skärmdumpar av kritiska sidor och jämföra dem mot en utgångspunkt för att detektera visuella regressioner. Men för grundfallet med att låta användare rapportera buggar med ett enda klick hanterar JavaScript-kodstycket allt utan några ändringar på serverns sida.

Vad förändras när buggrappporter faktiskt anländer

Omvandlingen i rapportens kvalitet är dramatisk. Innan knappen implementerades var den typiska bugrapporten en vag mening i ett e-postmeddelande. "Sidan ser konstigt ut." "Kassan är bruten." "Något hände när jag försökte spara." Dessa rapporter krävde flera rundor av uppföljningsfrågor, under vilka användaren ofta förlorade tålamod och slutade svara. Efter implementeringen av knappen anländer rapporter med en tydlig skärmbild som visar exakt vad som gick fel, tillsammans med metadata som identifierar sidan, visningsrutans storlek och förekomsttid. En utvecklare kan titta på skärmdumpen och omedelbar förstå problemet utan några fram och tillbaka.

Mängden rapporter ökar också betydligt. Användare som aldrig skulle komponera ett e-postmeddelande eller fylla i ett supportformulär kommer att klicka på en knapp och skriva tre ord. "Meny överlappar innehål" är inte den mest detaljerade bugrapporten i världen, men tillsammans med en skärmbild som visar en navigationsmeny som överlappar huvudinnehållsområdet på en mobil visningsruta talar det till utvecklaren allt som behövs för att återskapa och åtgärda problemet. Kombinationen av lägre friktion och rikare sammanhang betyder att buggar rapporteras tidigare, åtgärdas snabbare och verifieras mer tillförlitligt. Dagarna med att upptäcka en kritisk layoutbugg tre veckor efter att den introducerades är i stort sett över för alla applikationer som distribuerar denna typ av återkopplingsmekanism.

Det finns en sekundär fördel som är mindre uppenbar men lika värdefull. Skärmdumparkivet blir en visuell historia av applikationen. Varje rapport fångar ett ögonblick i tiden, som visar exakt hur sidan såg ut när användaren stötte på ett problem. Under veckor och månader avslöjar detta arkiv mönster. Kanske en viss sida går sönder varje gång en ny distribution går ut. Kanske mobila användare rapporterar problem med en hastighet tre gånger högre än skrivbordets användare. Kanske en viss webbläsarversion konsekvent producerar layoutanomalier. Dessa mönster är osynliga i textbaserade buggrapporer men blir omedelbar uppenbar när man bläddrar genom ett galleri med tidsstämplade skärmdumpar.