Un Utilizator Face Clic pe un Buton Face Captura de Ecran a Bug-ului și Îl Trimite Fără a Instala Nimic

Există un moment în viața fiecărei aplicații web în care un utilizator întâlnește ceva stricat. Un buton care nu face nimic atunci când este apăsat. O dipoziție care se prăbușește pe o anumită dimensiune de ecran. Un formular care înghite propriul mesaj de eroare. Utilizatorul se uită la ecran, confuz, și apoi face una din două lucruri. Majoritatea pur și simplu pleacă și nu se mai întorc. Puțini și rari dedică timp pentru a redacta un mesaj în linia "ceva nu merge cu site-ul vostru." Mesajul ajunge fără context, fără o descriere a ce s-a întâmplat, fără vreo indicație a browserului sau dispozitivului implicat, și cu siguranță fără o captură de ecran care să arate problema reală. Dezvoltatorul citește mesajul, încearcă să reproducă problema, eșuează, și bug-ul rămâne nerezolvat până când rănește utilizatorul următor. Acest ciclu se repetă nesfârșit pe internet, și cauza rădăcinară nu este lenezia utilizatorului. Cauza rădăcinară este fricțiunea.

Realizarea unei capturi de ecran pe un computer necesită cunoașterea combinației corecte de taste, care variază în funcție de sistemul de operare. Pe Windows ar putea fi Print Screen, sau Alt plus Print Screen pentru fereastra activă, sau tasta Windows plus Shift plus S pentru instrumentul snipping. Pe un Mac este Command plus Shift plus 3, sau 4, sau 5, fiecare producând rezultate ușor diferite. Pe un telefon gestul implică apăsarea simultană a două butoane fizice, care jumătate din timp blocheaza accidental ecranul în loc de asta. După ce captura de ecran este realizată, trebuie să fie localizată în sistemul de fișiere, atașată la un email sau lipită într-un formular de asistență, și trimisă. Fiecare din acești pași este un alt punct în care utilizatorul renunță și decide că bug-ul nu merită raportarea. Rezultatul este că dezvoltatorii primesc aproximativ o raportare pentru fiecare o sută de bug-uri pe care utilizatorii le întâlnesc de fapt.

Soluția care a apărut din această frustrare este jenanta de simplă. Un mic buton apare pe pagină. Când utilizatorul îl apasă, serverul capturează o captură de ecran a paginii exacte pe care o privește utilizatorul și o atașează la o raportare. Nu este necesară nicio extensie de browser. Nu este nevoie să memoreze nicio combinație de taste. Nu este niciun fișier de găsit și încărcat. Un clic, o captură de ecran, o raportare. Utilizatorul adaugă o frază sau două care descriu ce a mers prost, și dezvoltatorul primește o imagine perfect clară a paginii rupte împreună cu descrierea. Aceasta este întreaga flux de lucru, și a schimbat modul în care ajung rapoartele de bug-uri.

De Ce Extensiile de Browser Nu Au Rezolvat Niciodată Această Problemă

Reacția evidentă inițială este că extensiile de browser deja există pentru acest scop. Există zeci de instrumente de captură de ecran disponibile ca extensii Chrome, add-on-uri Firefox, și plugin-uri Safari. Unele dintre ele sunt destul de bune, cu caracteristici de adnotare, încărcări automate, și integrare cu platforme de gestionare a proiectelor. Dar toate împart același defect fundamental. Necesită utilizatorului să instaleze ceva înainte ca bug-ul să se întâmple. Nimeni nu instalează în mod preventiv o extensie de raportare a bug-urilor în cazul în care un site web pe care îl vor vizita mâine va avea o dipoziție ruptă. Extensiile rezolvă problema pentru echipele QA și testatorii interni care pot fi instruiți să instaleze instrumente specifice. Nu fac absolut nimic pentru publicul larg care întâlnește un bug pentru prima dată pe un site pe care este posibil să nu îl mai viziteze niciodată.

Există, de asemenea, chestiunea încrederii. Solicitarea unui utilizator să instaleze o extensie de browser pentru a raporta un bug introduce o schimbare bruscă în interacțiune. Utilizatorul a venit la site pentru a realiza ceva, a descoperit că era stricat, și acum i se cere să instaleze software de terță parte. Această cerere va ridica în mod justificat suspiciune pentru mulți utilizatori, și chiar și cei dispuși să se conformeze se confruntă cu costul de navigare a magazinelor de extensii, acordarea permisiunilor, și descoperirea modului în care funcționează instrumentul. Până la instalarea extensiei, bug-ul original ar putea să nu mai fie reproducibil, sau utilizatorul a pur și simplu trecut la un concurent. Fereastra pentru capturarea unei raportări de bug este îngustă, și orice care o lărgește golul dintre "ceva merge prost" și "raportul a fost trimis" înseamnă că raportul nu este niciodată trimis.

Bibliotecile de captură de ecran pe latura clientului, cum ar fi html2canvas, au încercat să rezolve acest lucru dintr-un unghi diferit. Aceste biblioteci JavaScript redă DOM-ul într-un element canvas, creând efectiv o captură de ecran fără niciun implicare a serverului. Funcționează rezonabil bine pentru dipoziții simple, dar eșuează rapid cu CSS complex, iframe-uri încorporate, imagini cross-origin, elemente canvas, și fonte personalizate. Imaginea rezultată adesea nu seamănă cu nimic cu ceea ce utilizatorul de fapt vede, ceea ce anulează în întregime scopul. O raportare de bug care conține o captură de ecran care nu se potrivește cu pagina reală este mai rău decât nicio captură de ecran, pentru că trimite dezvoltatorul după o problemă vizuală care nu există în timp ce problema reală rămâne ascunsă.

Capturi de Ecran la Nivel de Server și Cum Capturează Ceea Ce Vede Utilizatorul

Abordarea din spatele screenshots.yeb.to ia o cale complet diferită. În loc să încerce să reconstruiască pagina pe latura clientului, serverul primește URL-ul și îl redă utilizând un motor de browser real care funcționează într-un mediu controlat. Captura de ecran este realizată de o instanță Chromium reală care încarcă pagina, execută JavaScript, aplică CSS, randează font-uri, și capturează rezultatul ca o imagine perfectă. Aceasta înseamnă că captura de ecran arată exact cum afișează un browser real, pentru că este ceea ce afișează un browser real.

Când un utilizator apasă butonul de raportare a bug-ului, URL-ul curent al paginii este trimis serverului împreună cu metadate despre dimensiunea vizualizării utilizatorului, raportul pixel al dispozitivului, și orice parametri de stare relevanți. Serverul lansează o sesiune de browser headless configurată pentru a se potrivi cât mai bine cu acești parametri. Încarcă pagina, așteaptă ca toate resursele să termine randarea, și capturează captura de ecran. Rezultatul este stocat și legat de raportarea bug-ului, oferindu-i dezvoltatorului o înregistrare vizuală precisă a paginii în momentul în care utilizatorul a apăsat butonul. Întregul proces durează câteva secunde, care este suficient de rapid pentru ca utilizatorul să adauge descrierea sa în timp ce captura de ecran este generată în fundal.

Există nuanțe care merită să fie recunoscute. O captură de ecran la nivel de server capturează pagina așa cum apare pe server, nu neapărat pixelii exact pe ecranul utilizatorului. Dacă bug-ul este cauzat de ciudățenii de redare specifice browserului, conținut cached, sau stare stocată local, captura serverului s-ar putea să nu reproducă artefactul vizual exact. Dar în practică, marea majoritate a bug-urilor pe care le raportează utilizatorii sunt probleme de dipoziție, imagini rupte, conținut lipsă, sau defecte funcționale care sunt consistente indiferent de cine încarcă pagina. Pentru aceste cazuri, o captură de ecran la nivel de server este indistincta de cea pe latura clientului, și reducerea masivă a fricțiunii face compromisul să merite.

Încorporarea Butonului Fără a Schimba Aplicația

Integrarea este intenționat minimă. Un mic fragment JavaScript încarcă componenta butonului, care poate fi stilizată pentru a se potrivi cu sistemul de design al aplicației gazdă. Butonul plutește într-un colț al paginii, vizibil dar discret. Când este apăsat, deschide o suprapunere ușoară unde utilizatorul poate tasta o descriere scurtă și opțional să evidențieze zona paginii în care a apărut problema. În spatele scenelor, fragmentul trimite URL-ul curent la API-ul de captură de ecran, care capturează pagina și returnează URL-ul imaginii. Raportarea, care conține captura de ecran, descrierea, URL-ul, și metadate de browser de bază, este apoi trimisă oricărui destinație pe care dezvoltatorul a configurat-o: o adresă de email, un webhook Slack, un instrument de gestionare a proiectelor, sau un endpoint personalizat.

Întreaga integrare necesită nicio schimbare în backend-ul aplicației. Nu există SDK de instalat, nu există middleware de configurat, nu există schema de bază de date de modificat. Fragmentul funcționează independent, comunicând doar cu API-ul de captură de ecran și destinația de raportare configurată. Aceasta înseamnă că poate fi scăpat într-un blog WordPress, o aplicație React single page, un site HTML static, sau o aplicație PHP veche cu ușurință egală. Perioada de timp din determinarea de a adăuga raportare de bug-uri la a o avea în viu pe site este măsurată în minute, nu în sprinturi.

Pentru dezvoltatorii care doresc o integrare mai profundă, API-ul poate fi apelat direct din codul pe latura serverului. Aceasta deschide posibilități precum capturarea automată a unei capturi de ecran ori de câte ori apare o excepție nemanipulată, sau luarea de capturi de ecran periodice ale paginilor critice și compararea lor cu o direcție de bază pentru a detecta regresii vizuale. Dar pentru cazul de utilizare de bază al permiterii utilizatorilor să raporteze bug-uri cu un singur clic, fragmentul JavaScript se ocupă de totul fără nicio schimbare pe latura serverului.

Ce Se Schimbă Când Rapoartele de Bug Ajung de Fapt

Transformarea în calitatea raportării de bug este dramatică. Înainte de implementarea butonului, raportarea tipică a bug-ului era o propoziție vag într-un email. "Pagina arată ciudat." "Checkout-ul este stricat." "Ceva s-a întâmplat când am încercat să salvez." Aceste raportări au necesitat multiple runde de întrebări de urmărire, în timpul cărora utilizatorul adesea și-a pierdut răbdarea și a încetat să răspundă. După implementarea butonului, rapoartele ajung cu o captură de ecran clară care arată exact ce a mers prost, împreună cu metadate care identifică pagina, dimensiunea vizualizării, și momentul apariției. Un dezvoltator poate privi captura de ecran și înțelege imediat problema fără vreo discuție înainte și înapoi.

Volumul rapoartelor crește, de asemenea, semnificativ. Utilizatorii care nu ar compune niciodată un email sau nu ar completa un formular de asistență vor apăsa un buton și vor tasta trei cuvinte. "Menu se suprapune cu conținut" nu este cea mai detaliată raportare de bug din lume, dar combinată cu o captură de ecran care arată o meniu de navigare care se suprapune cu zona de conținut principal pe o vizualizare mobilă, spune dezvoltatorului totul de ce are nevoie pentru a reproduce și repara problema. Combinația de fricțiune inferioară și context mai bogat înseamnă că bug-urile sunt raportate mai devreme, reparate mai repede, și verificate mai fiabil. Zilele de descoperire a unei probleme de dipoziție critice trei săptămâni după ce a fost introdusă sunt în mare măură depășite pentru orice aplicație care implementează acest fel de mecanism de feedback.

Există un beneficiu secundar care este mai puțin evident, dar la fel de valoros. Arhiva de capturi de ecran devine o istorie vizuală a aplicației. Fiecare raportare capturează un moment în timp, arătând exact cum arăta pagina când utilizatorul a întâlnit o problemă. În săptămâni și luni, această arhivă dezvăluie modele. Poate că o anumită pagină se rupe de fiecare dată când se face o nouă implementare. Poate că utilizatorii mobili raportează probleme la o rată de trei ori mai mare decât utilizatorii de desktop. Poate că o versiune particulară a browserului produce în mod constant anomalii de dipoziție. Aceste modele sunt invizibile în rapoartele de bug numai din text, dar devin imediat evidente atunci când răsfoiți o galerie de capturi de ecran cu marca de timp.