Pengguna Klik Butang, Tangkap Skrin Bug, dan Hantar Kepada Saya Tanpa Pasang Apa-apa

Ada satu detik dalam kehidupan setiap aplikasi web di mana pengguna menghadapi sesuatu yang rosak. Satu butang yang tidak melakukan apa-apa apabila diklik. Tata letak yang runtuh pada saiz skrin tertentu. Satu bentuk yang menelan pesanannya sendiri. Pengguna menatap skrin, keliru, dan kemudian melakukan satu daripada dua perkara. Kebanyakan mereka hanya pergi dan tidak pernah kembali. Segelintir orang mengambil masa untuk menulis mesej seperti "sesuatu salah dengan laman anda." Mesej itu tiba tanpa konteks, tanpa penerangan apa yang berlaku, tanpa sebarang petunjuk apa browser atau peranti yang terlibat, dan pastinya tanpa skrin yang menunjukkan masalah sebenar. Pembangun membaca mesej itu, cuba ulang masalah, gagal, dan bug itu tidak diperbaiki sehingga ia menyerang pengguna seterusnya. Kitaran ini berulang tanpa henti di seluruh internet, dan punca asalnya bukan kemalasan pengguna. Punca asalnya adalah geseran.

Mengambil skrin di komputer memerlukan pengetahuan pintasan papan kunci yang tepat, yang berbeza mengikut sistem operasi. Di Windows ia mungkin Print Screen, atau Alt plus Print Screen untuk tetingkap aktif, atau kunci Windows plus Shift plus S untuk alat potongan. Pada Mac ia adalah Command plus Shift plus 3, atau 4, atau 5, setiap satu menghasilkan hasil yang sedikit berbeza. Di telefon, geraknya melibatkan menekan dua butang fizikal secara serentak, yang setengah masa secara tidak sengaja mengunci skrin. Selepas skrin ditangkap, ia perlu ditemui dalam sistem fail, dilampirkan pada e-mel atau ditampal ke bentuk sokongan, dan dihantar. Setiap satu daripada langkah-langkah tersebut adalah titik lain di mana pengguna menyerah dan memutuskan bug itu tidak bernilai dilaporkan. Hasilnya ialah pembangun menerima kira-kira satu laporan untuk setiap seratus bug yang sebenarnya dialami pengguna.

Penyelesaian yang muncul daripada kekecewaan ini sangat mudah. Satu butang kecil muncul di halaman. Apabila pengguna mengkliknya, pelayan menangkap skrin halaman tepat yang dilihat pengguna dan melampirkannya pada laporan. Tiada sambungan pelayar diperlukan. Tiada pintasan papan kunci untuk diingati. Tiada fail untuk dicari dan dimuat naik. Satu klik, satu skrin, satu laporan. Pengguna menambah satu atau dua ayat yang menerangkan apa yang salah, dan pembangun menerima imej yang sangat jelas bagi halaman yang rosak bersama penerangan. Itulah seluruh aliran kerja, dan ia telah mengubah cara laporan bug tiba.

Mengapa Sambungan Pelayar Tidak Pernah Menyelesaikan Masalah Ini

Tindak balas pertama yang jelas ialah sambungan pelayar sudah wujud untuk tujuan ini. Ada puluhan alat tangkap skrin tersedia sebagai sambungan Chrome, penambahan Firefox, dan pemalam Safari. Sesetengahnya agak bagus, dengan ciri anotasi, muat naik automatik, dan penyepaduan dengan platform pengurusan projek. Tetapi mereka semua berkongsi kelemahan asas yang sama. Mereka memerlukan pengguna memasang sesuatu sebelum bug itu berlaku. Tiada siapa yang memasang sambungan pelapor bug secara preemptif atas kemungkinan bahawa beberapa laman web yang mereka kunjungi esok akan mengalami tata letak yang rosak. Sambungan menyelesaikan masalah bagi pasukan QA dan penguji dalaman yang boleh diberitahu untuk memasang alat tertentu. Mereka tidak melakukan apa-apa untuk orang awam yang menghadapi bug buat kali pertama di laman yang mungkin tidak mereka kunjungi lagi.

Ada juga soal kepercayaan. Meminta pengguna memasang sambungan pelayar untuk melaporkan bug memperkenalkan perubahan yang mengecewakan dalam interaksi. Pengguna datang ke laman untuk mencapai sesuatu, menemui ia rosak, dan kini diminta memasang perisian pihak ketiga. Permintaan itu akan berhak membangkitkan syak wasangka bagi banyak pengguna, dan bahkan mereka yang bersedia mematuhi menghadapi beban mengarah ke kedai sambungan, memberikan kebenaran, dan mengetahui cara alat berfungsi. Pada masa sambungan dipasang, bug asal mungkin tidak lagi boleh diulang, atau pengguna hanya telah berpindah ke pesaing. Tingkap untuk merakam laporan bug adalah sempit, dan apa-apa yang meluaskan jurang antara "sesuatu salah" dan "laporan dihantar" bermakna laporan tidak pernah dihantar.

Perpustakaan tangkap skrin sebelah pelanggan seperti html2canvas telah mencuba menyelesaikan ini dari sudut yang berbeza. Perpustakaan JavaScript ini melukis DOM ke dalam elemen kanvas, dengan berkesan mencipta skrin tanpa sebarang penglibatan pelayan. Mereka berfungsi dengan agak baik untuk tata letak mudah tetapi runtuh dengan cepat dengan CSS kompleks, iframe yang tertanam, imej lintas-asal, elemen kanvas, dan fon tersuai. Imej yang terhasil sering kelihatan tidak seperti apa yang sebenarnya dilihat pengguna, yang mengalahkan tujuan sepenuhnya. Laporan bug yang mengandungi skrin yang tidak sepadan dengan halaman sebenar adalah lebih teruk daripada tiada skrin langsung, kerana ia menghantar pembangun mengejar masalah visual yang tidak wujud sementara masalah sebenar tetap tersembunyi.

Skrin Pelayan dan Bagaimana Mereka Menangkap Apa yang Dilihat Pengguna

Pendekatan di sebalik screenshots.yeb.to mengambil jalan yang sama sekali berbeza. Daripada cuba membina semula halaman di sebelah pelanggan, pelayan menerima URL dan melukisnya menggunakan enjin pelayar sebenar yang berjalan dalam persekitaran terkontrol. Skrin ditangkap oleh contoh Chromium sebenar yang memuatkan halaman, melaksanakan JavaScript, menggunakan CSS, melukis fon, dan menangkap hasilnya sebagai imej yang tepat piksel. Ini bermakna skrin kelihatan sama seperti apa yang dipaparkan pelayar sebenar, kerana ia adalah apa yang dipaparkan pelayar sebenar.

Apabila pengguna mengklik butang lapor bug, URL halaman semasa dihantar ke pelayan bersama metadata tentang saiz pandangan pengguna, nisbah piksel peranti, dan sebarang parameter keadaan yang relevan. Pelayan melancarkan sesi pelayar tanpa kepala yang dikonfigurasi untuk memadankan parameter tersebut sedekat mungkin. Ia memuatkan halaman, menunggu semua aset selesai melukis, dan menangkap skrin. Hasilnya disimpan dan dipautkan ke laporan bug, memberikan pembangun rekod visual yang tepat bagi halaman pada saat pengguna mengklik butang. Keseluruhan proses mengambil beberapa saat, yang cukup pantas sehingga pengguna boleh menambah penerangan mereka manakala skrin sedang dijana di latar belakang.

Ada nuansa yang patut diakui. Skrin pelayan menangkap halaman kerana ia kelihatan kepada pelayan, tidak semestinya piksel yang tepat di skrin pengguna. Jika bug disebabkan oleh kebiasaan pelukisan khusus pelayar, kandungan tersimpan dalam cache, atau keadaan yang disimpan secara tempatan, tangkapan pelayan mungkin tidak mengulangi artifak visual yang tepat. Tetapi dalam praktik, sebahagian besar bug yang dilaporkan pengguna adalah isu tata letak, imej yang rosak, kandungan yang hilang, atau kegagalan fungsi yang konsisten tidak kira siapa yang memuatkan halaman. Bagi kes-kes tersebut, skrin pelayan tidak dapat dibezakan daripada yang sebelah pelanggan, dan pengurangan besar geseran menjadikan pertukaran itu berbaloi.

Membenamkan Butang Tanpa Mengubah Aplikasi

Penyepaduan itu sengaja minimal. Satu snippet JavaScript kecil memuatkan komponen butang, yang boleh diayakan untuk memadankan sistem reka bentuk aplikasi hos. Butang terapung di sudut halaman, kelihatan tetapi tidak ketara. Apabila diklik, ia membuka lapisan ringan di mana pengguna boleh menaip penerangan pendek dan secara pilihan menyerlahkan kawasan halaman di mana masalah berlaku. Di belakang tabir, snippet menghantar URL halaman semasa ke API tangkap skrin, yang menangkap halaman dan mengembalikan URL imej. Laporan, yang mengandungi skrin, penerangan, URL, dan metadata pelayar asas, kemudian dimajukan ke apa-apa destinasi yang telah dikonfigurasi pembangun: alamat e-mel, webhook Slack, alat pengurusan projek, atau titik akhir tersuai.

Keseluruhan penyepaduan tidak memerlukan sebarang perubahan pada backend aplikasi. Tiada SDK untuk dipasang, tiada perenggan untuk dikonfigurasi, tiada skema pangkalan data untuk diubah suai. Snippet beroperasi secara bebas, berkomunikasi hanya dengan API tangkap skrin dan destinasi laporan yang dikonfigurasi. Ini bermakna ia boleh dijatuhkan ke dalam blog WordPress, satu aplikasi satu halaman React, laman HTML statik, atau aplikasi PHP warisan dengan sama mudah. Masa dari memutuskan untuk menambah pelaporan bug ke memilikinya langsung di laman diukur dalam minit, bukan sprint.

Bagi pembangun yang menginginkan penyepaduan yang lebih dalam, API boleh dipanggil terus daripada kod sebelah pelayan. Ini membuka kemungkinan seperti secara automatik menangkap skrin apabila pengecualian yang tidak dikendalikan berlaku, atau mengambil skrin berkala halaman kritikal dan membezakan mereka dengan garis asas untuk mengesan regresi visual. Tetapi bagi kes asas membenarkan pengguna melaporkan bug dengan satu klik, snippet JavaScript mengendalikan semua tanpa sebarang perubahan sebelah pelayan.

Apa Perubahan Apabila Laporan Bug Benar-benar Tiba

Transformasi dalam kualiti laporan bug adalah dramatik. Sebelum melaksanakan butang, laporan bug biasa adalah ayat yang samar dalam e-mel. "Halaman kelihatan pelik." "Daftar keluar rosak." "Sesuatu berlaku apabila saya mencuba menyimpan." Laporan ini memerlukan pelbagai pusingan soalan susulan, di mana pengguna sering kehilangan kesabaran dan berhenti bertindak balas. Selepas melaksanakan butang, laporan tiba dengan skrin yang jelas menunjukkan tepat apa yang salah, disertai dengan metadata yang mengenal pasti halaman, saiz pandangan, dan masa kejadian. Pembangun boleh melihat skrin dan serta-merta memahami masalah tanpa sebarang perbualan ke belakang.

Jumlah laporan juga meningkat dengan ketara. Pengguna yang tidak akan pernah menulis e-mel atau mengisi bentuk sokongan akan mengklik butang dan menaip tiga perkataan. "Menu bertindih kandungan" bukan laporan bug paling terperinci di dunia, tetapi digabungkan dengan skrin yang menunjukkan menu navigasi yang bertindih dengan kawasan kandungan utama di pandangan bergerak mudah alih, ia memberitahu pembangun segala-galanya yang diperlukan untuk mengulangi dan membetulkan masalah. Kombinasi geseran yang lebih rendah dan konteks yang lebih kaya bermakna bug dilaporkan lebih awal, diperbaiki lebih cepat, dan disahkan lebih boleh dipercayai. Zaman menemui bug tata letak kritikal tiga minggu selepas ia diperkenalkan sebahagian besarnya telah berakhir untuk mana-mana aplikasi yang menggunakan mekanisme maklum balas seperti ini.

Ada manfaat sekunder yang kurang jelas tetapi sama berharga. Arkib skrin menjadi sejarah visual aplikasi. Setiap laporan menangkap satu saat dalam masa, menunjukkan tepat bagaimana halaman kelihatan apabila pengguna menghadapi masalah. Selama berminggu-minggu dan berbulan-bulan, arkib ini menunjukkan corak. Mungkin halaman tertentu rosak setiap kali penggunaan baharu dikeluarkan. Mungkin pengguna mudah alih melaporkan isu pada kadar tiga kali lebih tinggi daripada pengguna desktop. Mungkin versi pelayar tertentu secara konsisten menghasilkan anomali tata letak. Corak ini tidak kelihatan dalam laporan bug teks sahaja tetapi menjadi serta-merta jelas apabila melayari galeri skrin bertanda masa.