Käyttäjä Napsauttaa Painiketta Kuvaaa Virheen ja Lähettää Sen Minulle Asentamatta Mitään

Jokaisen verkkosovelluksen elämässä tulee hetki, jolloin käyttäjä kohtaa jotain rikki menevää. Painike, joka ei tee mitään napsautettaessa. Asettelu, joka romahtaa tietyllä näytön koolla. Lomake, joka nielee oman virheilmoituksensa. Käyttäjä tuijottaa näyttöä, hämmentynyt, ja tekee sitten yhden kahdesta asiasta. Useimmat yksinkertaisesti lähtevät eikä koskaan palaa. Harvat käyttävät aikaa lähettääkseen viestin, jota sanoo "jotain on vialla sivustossasi." Viesti saapuu ilman kontekstia, ilman kuvailua mitä tapahtui, ilman mitään osoitusta mitä selain tai laite oli kyseessä, ja varmasti ilman kuvakaappauksen varsinaisesta ongelmasta. Kehittäjä lukee viestin, yrittää toistaa ongelmaa, epäonnistuu, ja virhe jää korjaamatta kunnes se pitelee seuraavaa käyttäjää. Tämä sykli toistuu loputtomasti internetissä, ja juurisyy ei ole käyttäjän laiskuus. Juurisyy on kitka.

Kuvakaappauksen ottaminen tietokoneella vaatii oikean näppäinyhdistelmän tuntemisen, joka vaihtelee käyttöjärjestelmittäin. Windowsissa se voisi olla Print Screen tai Alt plus Print Screen aktiivisesta ikkunasta tai Windows-näppäin plus Shift plus S leikkauskieille. Macissa se on Command plus Shift plus 3 tai 4 tai 5, joista jokainen tuottaa hieman erilaisia tuloksia. Puhelimessa ele sisältää kahden fyysisen painikkeen painamisen samanaikaisesti, mikä puolet ajasta vahingossa lukitsee näytön. Kuvakaappauksen ottamisen jälkeen se on löydettävä tiedostojärjestelmästä, liitettävä sähköpostiin tai liitettävä tukiformiin ja lähetettävä. Jokainen näistä vaiheista on toinen piste, jossa käyttäjä antaa periksi ja päättää, että virhe ei ole raportoinnin arvoinen. Tuloksena kehittäjät saavat noin yhden raportin jokaisesta sadasta viasta, joita käyttäjät todella kohtaavat.

Ratkaisu, joka syntyi tästä turhautumisesta, on häpeällisen yksinkertainen. Pieni painike näkyy sivulla. Kun käyttäjä napsauttaa sitä, palvelin kuvaaa tarkalleen sivua, jota käyttäjä katsoo ja liittää sen raporttiin. Ei selaimen laajennusta vaadittu. Ei näppäinyhdistelmää muistettavaksi. Ei tiedostoa löydettäväksi ja ladattavaksi. Yksi napsautus, yksi kuvakaappaus, yksi raportti. Käyttäjä lisää lauseen tai kaksi, jossa kuvataan mitä meni vialla, ja kehittäjä saa täysin selkeän kuvan rikkoutuneesta sivusta sekä kuvauksen ohella. Se on koko työnkulku, ja se on muuttanut sitä, miten virheraportit saapuvat.

Miksi Selaimen Laajennukset Eivät Koskaan Ratkaiseet Tätä Ongelmaa

Ilmeinen ensimmäinen reaktio on, että selaimen laajennuksia on jo olemassa tätä tarkoitusta varten. Saatavilla on kymmeniä kuvakaappauksen ottamisen työkaluja Chrome-laajennuksina, Firefox-lisäosina ja Safari-liitännäisinä. Jotkut niistä ovat varsin hyviä, joissa on merkintöjen ominaisuudet, automaattiset lataukset ja integrointi projektinhallintaalustojen kanssa. Mutta ne kaikki jakavat saman perustavanlaatuisen virheen. Ne vaativat käyttäjän asentamaan jotain ennen kuin virhe tapahtuu. Kukaan ei asenna virheraportoinnin laajennusta ennakolta sillä varalta, että jokin sivusto, jota hän käy huomenna, on rikkoutuneella asettelulla. Laajennukset ratkaisevat ongelman QA-tiimeille ja sisäisille testaajille, joille voidaan sanoa asentaa tiettyjä työkaluja. Ne eivät tee mitään yleisölle, joka kohtaa virheen ensimmäistä kertaa sivustolla, jota he eivät ehkä koskaan käy uudelleen.

On myös luottamuksen kysymys. Käyttäjää pyydetään asentamaan selaimen laajennus virheen raportoinnin vuoksi esittelee järkyttävän siirtymän vuorovaikutuksessa. Käyttäjä tuli sivustolle jotain saavuttaakseen, löysi sen rikki, ja häntä pyydetään nyt asentamaan kolmannen osapuolen ohjelmisto. Tämä pyyntö herättää oikeutetusti epäily monissa käyttäjissä, ja jopa ne, jotka ovat valmiita noudattamaan, kohtaavat yleiskunnan navigoimisesta, lupien myöntämisestä ja selvittämisestä kuinka työkalu toimii. Siihen mennessä kun laajennus on asennettu, alkuperäinen virhe ei ehkä ole enää toistettavissa, tai käyttäjä on yksinkertaisesti siirtynyt kilpailijalle. Ikkuna virheen raportoinnin tallentamiselle on kapea, ja kaikki mitä laajentaa aukkoa "jotain on vialla" ja "raportti lähetetty" välillä tarkoittaa raportti ei koskaan lähete.

Asiakaspuolen kuvakaappauskirjastot, kuten html2canvas, ovat yrittäneet ratkaista tämän toisesta kulmasta. Nämä JavaScript-kirjastot renderöivät DOM:n canvas-elementiksi, luottaen kuvakaappauksen ilman mitään palvelinpuolen osallistumista. Ne toimivat kohtuullisen hyvin yksinkertaisille asetteluille, mutta romahtavat nopeasti monimutkaisten CSS:n, upotettujen iframen, cross-origin-kuvien, canvas-elementtien ja mukautettujen fonttien kanssa. Tuloksena oleva kuva näyttää usein siltä, mitä käyttäjä todella näkee, mikä kumoaa tarkoituksen kokonaan. Virheraportissa, jossa on kuvakaappaus, joka ei vastaa todellista sivua, on huonompi kuin ei lainkaan kuvakaappaus, koska se lähettää kehittäjän ajamaan visuaalista ongelmaa, jota ei ole olemassa, kun todellinen ongelma jää piiloon.

Palvelinpuolen Kuvakaappaukset ja Kuinka Ne Kuvaavat Mitä Käyttäjä Näkee

screenshots.yeb.to:n takana oleva lähestymistapa vie täysin erilaista polkua. Sen sijaan, että yrittäisimme muodostaa sivun asiakaspuolella uudelleen, palvelin vastaanottaa URL:n ja renderöi sen todellisella selaimella, joka on ohjattu ympäristössä. Kuvakaappaus otetaan todellisen Chromium-instanssin avulla, joka lataa sivun, suorittaa JavaScriptin, soveltaa CSS:ää, renderöi fontit ja ottaa tuloksen pikselitarkaksi kuvakaappaukseksi. Tämä tarkoittaa, että kuvakaappaus näyttää täsmälleen siltä, miltä todellinen selain näyttää, koska se on mitä todellinen selain näyttää.

Kun käyttäjä napsauttaa virheen raportoinnin painiketta, nykyisen sivun URL:n lähettäminen palvelimelle käyttäjän näkymän koon, laitteen pikselisuhdetta ja muita merkityksellisiä tilaparametreja koskevan metatiedon kanssa. Palvelin käynnistää headless-selaimen istunnon, joka on määritetty vastaamaan näitä parametreja mahdollisimman lähellä. Se lataa sivun, odottaa kaiken omaisuuden viimeistelyn, ja ottaa kuvakaappauksen. Tulos tallennetaan ja linkitetään virherapportiin, antamalla kehittäjälle tarkan visuaalisen rekisteröinnin sivusta sillä hetkellä kun käyttäjä napsautti painiketta. Koko prosessi kestää muutaman sekunnin, mikä on riittävän nopea, jotta käyttäjä voi lisätä kuvauksensa kuvakaappauksen ollessa luomista taustalla.

Sielukkuus on arvoista pitää mielessä. Palvelinpuolen kuvakaappaus kuvaa sivun niin kuin se näkyy palvelimelle, ei välttämättä tarkalleen samoja pikseleitä käyttäjän näytöllä. Jos virhe johtuu selaimen-spesifisistä renderöintihäiriöistä, välimuistiin tallennetusta sisällöstä tai paikallisesti tallennetusta tilasta, palvelinkaappaus ei ehkä toista tarkalleen samaa visuaalista virhettä. Mutta käytännössä suurin osa virheistä, joita käyttäjät raportoivat ovat asetteluongelmia, rikkinäisiä kuvia, puuttuvaa sisältöä tai toiminnallisia epäonnistumisia, jotka ovat yhtäläisiä riippumatta siitä kuka lataa sivun. Näille tapauksille palvelinpuolen kuvakaappaus on erottamaton asiakaspuolen kuvakaappauksesta, ja kitkan valtava vähentäminen tekee kompromissista arvoisen.

Painikkeen Upottaminen Ilman Sovelluksen Muuttamista

Integraatio on tarkoituksella minimaalinen. Pieni JavaScript-katkelma lataa painike-komponentin, jota voidaan muokata sovelluksen suunnittelujärjestelmään. Painike kelluu sivun kulmassa, näkyvä mutta huomaamaton. Napsautettaessa se avaa kevyen pinnan, jossa käyttäjä voi kirjoittaa lyhyen kuvauksen ja halutessaan korostaa sivun aluetta, jossa ongelma esiintyi. Taustalla katkelma lähettää nykyisen URL:n kuvakaappaus-API:lle, joka kuvaaa sivun ja palauttaa kuvan URL:n. Raportti, joka sisältää kuvakaappauksen, kuvauksen, URL:n ja perusselaimen metatiedot, siirretään sitten kehittäjän määrittämälle kohteelle: sähköpostiosoitteelle, Slack-webhookille, projektinhallintatyökalulle tai mukautetulle päätepisteelle.

Koko integraatio ei vaadi muutoksia sovelluksen taustapuoleen. SDK:tä ei tarvitse asentaa, väliohjausta ei tarvitse määrittää, tietokannan skeemaa ei tarvitse muuttaa. Katkelma toimii itsenäisesti, kommunikoidaan vain kuvakaappaus-API:n ja määritetyn raportointikohteen kanssa. Tämä tarkoittaa, että se voidaan pudottaa WordPress-blogiin, React-yksisivuiseen sovellukseen, staattiseen HTML-sivustoon tai perintöiseen PHP-sovellukseen samalla tavalla. Aika, joka kuluu päätöksestä lisätä virheiden raportointi siihen, että se on elävä sivustolla, mitataan minuutteissa, ei sprinteissä.

Kehittäjille, jotka haluavat syvemmän integraation, API voidaan kutsua suoraan palvelinpuolen koodista. Tämä avaa mahdollisuuksia, kuten automaattinen kuvakaappauksen ottaminen aina kun käsittelemätön poikkeus esiintyy, tai määräajoin kuvakaappaukset kriittisistä sivuista ja niiden vertailu lähtötilanteeseen visuaalisten regressioiden havaitsemiseksi. Mutta perustapauksessa, jossa käyttäjät voivat raportoida virheitä yhdellä napsautuksella, JavaScript-katkelma hoitaa kaiken ilman mitään palvelinpuolen muutoksia.

Mitä Muuttuu Kun Virheraportit Todella Saapuvat

Muunnos virheraportointikyvyn laadun muutokseen on dramaattinen. Ennen painikkeen käyttöönottoa, tyypillinen virheraportit oli epämääräinen lause sähköpostissa. "Sivu näyttää oudolta." "Kassasta on rikki." "Jotain tapahtui kun yritin tallentaa." Nämä raportit vaativat useita seurantakysymyksiä, joiden aikana käyttäjä usein menetti kärsivällisyyttä ja lopetti vastaamisen. Painikkeen ottamisen jälkeen raportit saapuvat selkeällä kuvakaappauksella, joka näyttää tarkalleen mitä meni pieleen, sekä metatiedot, jotka tunnistaa sivun, näkymän koon ja tapahtuman ajankohdan. Kehittäjä voi katsoa kuvakaappauksen ja välittömästi ymmärtää ongelman ilman edestakaisin.

Raporttien määrä kasvaa myös merkittävästi. Käyttäjät, jotka eivät koskaan kirjoittaisi sähköpostia tai täyttäisivät tukiformia, napsauttavat painiketta ja kirjoittavat kolme sanaa. "Valikko päällekkäin sisältö" ei ole maailman yksityiskohtaisin virheraportit, mutta liittyy kuvakaappauksella, joka näyttää siirtymisvalikon päällekkäisyydessä pääalueen kanssa mobiililaitteen näkymässä, se kertoo kehittäjälle kaiken mitä tarvitaan ongelman toistamiseksi ja korjaamiseksi. Alemman kitkan ja rikkaan kontekstin yhdistelmä tarkoittaa, että virheet raportoitaan aikaisemmin, korjataan nopeammin ja tarkistetaan luotettavammin. Päivät kriittisen asettelu virheen löytämisestä kolme viikkoa sen jälkeen, kun se otettiin käyttöön, ovat suurelta osin yli mille tahansa sovellukselle, joka ottaa tämänkaltaisen palautemekanismin käyttöön.

On toissijainen etu, joka on vähemmän ilmeinen mutta yhtä arvokas. Kuvakaappausarkisto tulee visuaaliseksi historiaksi sovelluksesta. Jokainen raportti kuvaaa hetkeä ajassa, näyttäen tarkalleen miltä sivu näytti kun käyttäjä kohtasi ongelman. Viikkojen ja kuukausien ajan tämä arkisto paljastaa kuvioita. Ehkä tietty sivu rikkoutuu aina kun uusi käyttöönotto menee ulos. Ehkä mobiililaite käyttäjät raportoivat ongelmia kolme kertaa korkeammalla nopeudella kuin työpöytä käyttäjät. Ehkä tietty selaimen versio yhdenmukaisesti tuottaa asettelun epäjohdonmukaisuuksia. Nämä kuviot ovat näkymättömiä vain tekstiin pohjautuvissa virheraporteissa, mutta tulevat välittömästi näkyviksi selatessa aikaleimattuja kuvakaappausten galleriaa.