يضغط المستخدم على الزر وينقل لقطة الشاشة للخطأ ويرسله لي دون تثبيت أي شيء

هناك لحظة في حياة كل تطبيق ويب حيث يواجه المستخدم شيئا معطلا. زر لا يفعل شيئا عند النقر عليه. تخطيط ينهار على حجم شاشة معين. نموذج يبتلع رسالة خطأه الخاصة. ينظر المستخدم إلى الشاشة، مرتبكا، ثم يفعل واحدة من اثنتين. يغادر معظمهم وأبدا لا يعودون. قلة نادرة تستغرق الوقت لكتابة رسالة من قبيل "هناك شيء خاطئ مع موقعك." تصل تلك الرسالة بدون سياق، بدون وصف لما حدث، بدون أي إشارة إلى المتصفح أو الجهاز المعني، والتأكيد بدون لقطة شاشة تظهر المشكلة الفعلية. يقرأ المطور تلك الرسالة، ويحاول إعادة إنتاج المشكلة، ويفشل، والخطأ لا يتم إصلاحه حتى يعض المستخدم التالي. تتكرر هذه الدورة بلا نهاية عبر الإنترنت، والسبب الجذري ليس كسل المستخدم. السبب الجذري هو الاحتكاك.

التقاط لقطة شاشة على الكمبيوتر يتطلب معرفة اختصار لوحة المفاتيح الصحيح، والذي يختلف حسب نظام التشغيل. في Windows قد يكون مفتاح الطباعة، أو Alt بالإضافة إلى مفتاح الطباعة للنافذة النشطة، أو مفتاح Windows بالإضافة إلى Shift بالإضافة إلى S لأداة القص. على جهاز Mac إنه Command بالإضافة إلى Shift بالإضافة إلى 3، أو 4، أو 5، ينتج كل منها نتائج مختلفة قليلا. على الهاتف، تتضمن الحركة الضغط على زرين فيزيائيين في نفس الوقت، وهو ما يؤدي في نصف الوقت إلى قفل الشاشة عن طريق الخطأ. بعد التقاط لقطة الشاشة، تحتاج إلى تحديد موقعها في نظام الملفات، وإرسالها بالبريد الإلكتروني أو لصقها في نموذج الدعم، وإرسالها. كل واحدة من تلك الخطوات هي نقطة أخرى حيث يستسلم المستخدم ويقرر أن الخطأ لا يستحق الإبلاغ عنه. والنتيجة هي أن المطورين يتلقون ما يقرب من تقرير واحد لكل مائة خطأ يواجهه المستخدمون فعليا.

الحل الذي ظهر من هذا الإحباط محرج من البساطة. يظهر زر صغير على الصفحة. عندما يضغط عليه المستخدم، يلتقط الخادم لقطة شاشة للصفحة بالضبط التي يعرضها المستخدم ويرفقها بتقرير. لا توجد ملحقات المتصفح المطلوبة. لا اختصار لوحة المفاتيح للتذكر. لا يوجد ملف للبحث عنه وتحميله. نقرة واحدة، لقطة شاشة واحدة، تقرير واحد. يضيف المستخدم جملة أو اثنتين تصف ما حدث خطأ، والمطور يتلقى صورة واضحة تماما للصفحة المعطلة جنبا إلى جنب مع الوصف. هذا هو سير العمل بأكمله، وقد غيرت الطريقة التي تصل بها تقارير الأخطاء.

لماذا لم تحل ملحقات المتصفح هذه المشكلة أبدا

رد الفعل الواضح الأول هو أن ملحقات المتصفح موجودة بالفعل لهذا الغرض. هناك العشرات من أدوات التقاط الشاشة المتاحة كملحقات Chrome، وإضافات Firefox، وملحقات Safari. بعضها جيد تماما، مع ميزات التعليقات التوضيحية والرفع الآلي والتكامل مع منصات إدارة المشاريع. لكنهم جميعا يشتركون في نفس العيب الأساسي. يتطلبون من المستخدم تثبيت شيء ما قبل حدوث الخطأ. لا أحد يثبت ملحق الإبلاغ عن الأخطاء بشكل استباقي على احتمال أن موقع ويب معين قد يزوره غدا سيكون له تخطيط معطل. تحل الملحقات المشكلة لفرق ضمان الجودة والمختبرين الداخليين الذين يمكن إخبارهم بتثبيت أدوات محددة. إنها لا تفعل شيئا على الإطلاق للجمهور العام الذي يواجه خطأ لأول مرة على موقع قد لا يزوره مرة أخرى.

هناك أيضا مسألة الثقة. طلب من المستخدم تثبيت ملحق متصفح لأبلاغ عن خطأ يقدم تحولا جارحا في التفاعل. جاء المستخدم إلى الموقع لإنجاز شيء ما، واكتشف أنه معطل، والآن يُطلب منه تثبيت برنامج تابع لجهة خارجية. سيثير هذا الطلب بحق الريبة لدى العديد من المستخدمين، وحتى أولئك الذين يرغبون في الامتثال يواجهون عبء التنقل في متاجر الملحقات، ومنح الأذونات، واكتشاف كيفية عمل الأداة. بحلول الوقت الذي يتم فيه تثبيت الملحق، قد لا تكون الخطأ الأصلي قابلا للتكرار بعد الآن، أو انتقل المستخدم ببساطة إلى منافس. نافذة التقاط تقرير خطأ ضيقة، وأي شيء يوسع الفجوة بين "هناك شيء خاطئ" و "تم إرسال التقرير" يعني أن التقرير لا يتم إرساله أبدا.

حاولت مكتبات التقاط الشاشة من جانب العميل مثل html2canvas حل هذا من زاوية مختلفة. تعرض هذه مكتبات JavaScript مجلس الإدارة (DOM) في عنصر قماش، مما ينشئ بشكل فعال لقطة شاشة بدون أي اشتراك من جانب الخادم. إنها تعمل بشكل معقول جيد لتخطيطات بسيطة لكنها تنهار بسرعة كبيرة مع CSS المعقد، iframes المضمنة، الصور عبر الأصول، عناصر اللوحة، والخطوط المخصصة. الصورة الناتجة غالبا لا تبدو وكأنها ما يراه المستخدم بالفعل، مما يهزم الغرض تماما. تقرير خطأ يحتوي على لقطة شاشة لا تتطابق مع الصفحة الفعلية أسوأ من عدم وجود لقطة شاشة على الإطلاق، لأنه يرسل المطور في مطاردة مشكلة بصرية لا توجد بينما تبقى المشكلة الحقيقية مخفية.

لقطات الخادم وكيفية التقاط ما يراه المستخدم

يأخذ النهج خلف screenshots.yeb.to مسارا مختلفا تماما. بدلا من محاولة إعادة بناء الصفحة من جانب العميل، يتلقى الخادم عنوان URL ويعرضه باستخدام محرك متصفح حقيقي يعمل في بيئة خاضعة للرقابة. يتم التقاط لقطة الشاشة بواسطة مثيل Chromium فعلي يحمل الصفحة وينفذ JavaScript ويطبق CSS ويعرض الخطوط ويلتقط النتيجة كصورة دقيقة البكسل. هذا يعني أن لقطة الشاشة تبدو تماما كما يعرضها متصفح حقيقي، لأنها ما يعرضه متصفح حقيقي.

عندما ينقر المستخدم على زر الإبلاغ عن الخطأ، يتم إرسال عنوان URL الحالي للصفحة إلى الخادم جنبا إلى جنب مع البيانات الوصفية حول حجم عرض المستخدم ونسبة بكسل الجهاز وأي معاملات حالة ذات صلة. يطلق الخادم جلسة متصفح بدون رأس يتم تكوينها لمطابقة تلك المعاملات قريبة قدر الإمكان. يحمل الصفحة وينتظر انتهاء جميع الأصول من العرض ويلتقط لقطة الشاشة. يتم تخزين النتيجة وربطها بتقرير الخطأ، مما يعطي المطور سجلا بصريا دقيقا للصفحة في اللحظة التي نقر فيها المستخدم على الزر. تأخذ العملية برمتها بضع ثوان، وهو سريع بما يكفي لإضافة المستخدم وصفهم بينما يتم إنشاء لقطة الشاشة في الخلفية.

هناك فروق دقيقة تستحق الاعتراف. تلتقط لقطة شاشة الخادم الصفحة كما تبدو للخادم، وليس بالضرورة البكسل الدقيق على شاشة المستخدم. إذا كان الخطأ ناجما عن سلوكيات عرض خاصة بالمتصفح أو محتوى مخزن مؤقتا أو حالة مخزنة محليا، فقد لا يعيد التقاط من جانب الخادم إنتاج القطعة البصرية الدقيقة. لكن في الممارسة العملية، فإن الغالبية العظمى من الأخطاء التي يبلغ عنها المستخدمون هي مشاكل في التخطيط والصور المعطلة والمحتوى المفقود أو الإخفاقات الوظيفية التي تكون متسقة بغض النظر عمن يحمل الصفحة. بالنسبة لتلك الحالات، فإن لقطة شاشة الخادم لا يمكن تمييزها عن لقطة من جانب العميل، والحد الكبير من الاحتكاك يجعل المقايضة تستحق العناء.

دمج الزر دون تغيير التطبيق

يكون التكامل مقصودا بحد أدنى. يحمل مقتطف JavaScript صغير مكون الزر، والذي يمكن تصميمه ليطابق نظام التصميم لتطبيق المضيف. يطفو الزر في زاوية الصفحة، مرئي لكن غير واضح. عند النقر عليه، يفتح طبقة خفيفة حيث يمكن للمستخدم كتابة وصف قصير وتسليط الضوء اختياريا على منطقة الصفحة حيث حدثت المشكلة. خلف الكواليس، يرسل المقتطف عنوان URL الحالي للصفحة إلى واجهة برمجة التطبيقات للتقاط الشاشة، والتي تلتقط الصفحة وتعيد عنوان URL للصورة. التقرير، الذي يحتوي على لقطة الشاشة والوصف وعنوان URL والبيانات الوصفية الأساسية للمتصفح، يتم إعادة توجيهه بعد ذلك إلى أي وجهة قام المطور بتكوينها: عنوان بريد إلكتروني أو webhook Slack أو أداة إدارة مشروع أو نقطة نهاية مخصصة.

التكامل بأكمله لا يتطلب أي تغييرات على خلفية التطبيق. لا يوجد SDK للتثبيت، لا توجد برامج وسيطة للتكوين، لا توجد مخطط قاعدة بيانات للتعديل. يعمل المقتطف بشكل مستقل، ويتواصل فقط مع واجهة برمجة تطبيقات التقاط الشاشة ووجهة التقرير المكونة. هذا يعني أنه يمكن إسقاطه في مدونة WordPress أو تطبيق React صفحة واحدة أو موقع HTML ثابت أو تطبيق PHP قديم بسهولة متساوية. الوقت من قرار إضافة الإبلاغ عن الأخطاء إلى وجوده مباشرة على الموقع يقاس بالدقائق، وليس الأسابيع.

بالنسبة للمطورين الذين يريدون تكاملا أعمق، يمكن استدعاء واجهة برمجة التطبيقات مباشرة من الكود من جانب الخادم. هذا يفتح احتمالات مثل التقاط لقطة شاشة تلقائية عند حدوث استثناء لم يتم التعامل معه، أو التقاط لقطات شاشة دورية للصفحات الحرجة والفرق بينها وخط الأساس للكشف عن الانحدار البصري. لكن بالنسبة لحالة الاستخدام الأساسية لتسمح للمستخدمين بالإبلاغ عن الأخطاء برقة واحدة، يتعامل مقتطف JavaScript مع كل شيء دون أي تغييرات من جانب الخادم.

ما يتغير عند وصول تقارير الأخطاء فعليا

التحول في جودة تقرير الخطأ درامي. قبل تنفيذ الزر، كان تقرير الخطأ النموذجي جملة غامضة في بريد إلكتروني. "تبدو الصفحة غريبة." "الخروج معطل." "حدث شيء ما عندما حاولت الحفظ." كانت هذه التقارير تتطلب عدة جولات من أسئلة المتابعة، والتي غالبا ما فقد المستخدم صبره وتوقف عن الرد. بعد تنفيذ الزر، تصل التقارير بلقطة شاشة واضحة تظهر بالضبط ما حدث خطأ، مصحوبة ببيانات وصفية تحدد الصفحة وحجم عرض المنفذ ووقت الحدوث. يمكن للمطور أن ينظر إلى لقطة الشاشة ويفهم الفور المشكلة دون أي ذهاب وإياب.

يزداد حجم التقارير بشكل كبير. سيضغط المستخدمون الذين لن يكتبوا أبدا بريدا إلكترونيا أو يملأ نموذج دعم على زر ويكتبون ثلاث كلمات. "القائمة تتداخل مع المحتوى" ليس أكثر تقرير خطأ مفصل في العالم، لكن مقترن بلقطة شاشة تظهر قائمة الملاحة تتداخل مع منطقة المحتوى الرئيسي على منفذ عرض الهاتف المحمول، فإنه يخبر المطور بكل ما يحتاج إليه لإعادة إنتاج وإصلاح المشكلة. يعني الجمع بين احتكاك أقل وسياق أغنى أن الأخطاء يتم الإبلاغ عنها في وقت مبكر وإصلاحها بسرعة أكبر والتحقق منها بموثوقية أكبر. أنهت أيام اكتشاف خطأ تخطيط حرج ثلاثة أسابيع بعد إدخاله إلى حد كبير بالنسبة لأي تطبيق ينشر هذا النوع من آلية الملاحظات.

هناك فائدة ثانوية أقل وضوحا لكن ذات قيمة متساوية. يصبح أرشيف لقطات الشاشة سجلا بصريا للتطبيق. كل تقرير يلتقط لحظة في الوقت، يظهر بالضبط كيف بدت الصفحة عندما واجه المستخدم مشكلة. على مدار أسابيع وأشهر، يكشف هذا الأرشيف الأنماط. ربما تنهار صفحة معينة في كل مرة يتم نشر نشر جديد. ربما يبلغ مستخدمو الهاتف المحمول عن مشاكل بمعدل ثلاث مرات أعلى من مستخدمي سطح المكتب. ربما تنتج نسخة متصفح معينة باستمرار شذوذ تخطيط. هذه الأنماط غير مرئية في تقارير الأخطاء النصية فقط لكنها تصبح واضحة على الفور عند استعراض معرض لقطات الشاشة المختومة بالوقت.