يعدل الموظف بيانات عميل داخل نافذة، ثم يضغط زر الإغلاق فيختفي العمل قبل الحفظ. قد تبدو النافذة سليمة في اختبار فتحها وإغلاقها، بينما الخلل في قرار التخلص من المسودة. اكتب أولًا ما الذي ينبغي أن يحدث عند وجود تغيير، وعند فشل الحفظ، وعند رغبة المستخدم في التراجع صراحة.
افصل طلب الإغلاق عن الإغلاق المباشر
توضح وثائق MDN لـrequestClose أن هذه الطريقة تطلق حدث cancel قبل close، ويمكن منع الإغلاق باستدعاء preventDefault داخل معالج cancel. يختلف ذلك عن close المباشر. تظل مراجعة توافق المتصفحات المطلوبة جزءًا من التنفيذ، لأن الأجهزة الأقدم قد لا تدعم الطريقة.
هذه آلية لبناء قرار واضح، وليست حفظًا تلقائيًا. لا تضع استدعاء close في زر مستقل ثم تفترض أنه سيمر دائمًا بمنطق الحماية نفسه. احصر مسارات الإغلاق في تصميم مفهوم، وحدد متى يمكن الإغلاق مباشرة بعد انتهاء الحفظ بالفعل.
اكتب مصفوفة حالة المسودة
| الحالة الافتراضية | نتيجة القبول المقترحة |
|---|---|
| لم يتغير شيء | إغلاق عادي دون تحذير غير ضروري |
| تعديلات لم تُحفظ | قرار صريح بالاستمرار أو التخلص |
| الحفظ جارٍ | سلوك معلن يمنع التباس نجاح الحفظ |
| فشل الحفظ | بقاء البيانات ورسالة تسمح بإعادة المحاولة |
اختبر كل مدخل للإغلاق
راجع زر الإلغاء وعلامة الإغلاق وEscape وأي نقر خارج النافذة يدعمه تصميمك. لا تفترض أن الأحداث متطابقة في كل المتصفحات أو إعدادات dialog. سجل في الاختبار المسار الذي طلب الإغلاق، وحالة المسودة، والقرار النهائي، دون كتابة بيانات العميل داخل سجل عام.
في تجربة مصطنعة، غيّر قيمة ثم اختر الاستمرار في التحرير؛ يجب أن تبقى القيمة والتركيز في موضع مناسب. أعد التجربة واختر التخلص؛ افتح النافذة مجددًا وتحقق أن مصدر البيانات المعتمد عاد، لا نسخة محلية قديمة أخطأت الواجهة في عرضها.
حدد حدود الحماية
منطق dialog لا يحمي وحده من إغلاق المتصفح أو انهيار الجهاز، ولا يغني عن تصميم استعادة المسودات عند الحاجة. ضمن مراجعة تجربة المستخدم وتطوير الويب اختبر المسار البديل في المتصفح غير الداعم، واجعل حفظ البيانات والتخلص منها عمليتين واضحتين. الهدف إثبات قرار صحيح للمسودة، بالإضافة إلى الإتاحة وسلامة التركيز.
