يرفع المتعلم ملف الواجب ويغادر الصفحة معتقدًا أنه سلمه، بينما يراه المدرس مسودة. وجود الملف في التخزين ليس دائمًا إقرارًا بأن العمل جاهز للتقييم. عند تسليم منصة LMS، ينبغي أن يتفق الفريق التعليمي والتقني على معنى الحفظ والتسليم وإعادة الفتح، ثم يختبروا هذه الحالات من الحسابين.
اقرأ إعداد زر التسليم
توضح وثائق إعدادات الواجب في Moodle 5.2 أن تفعيل Require students click submit button يتيح رفع مسودات قبل الإرسال النهائي. عند الإرسال لا يستطيع الطالب التعديل حتى يعيده المدرس إلى مسودة وفق المسار المناسب. وعند تعطيل الخيار يختلف سير التعديل؛ لذا لا تفترض وجود خطوة نهائية في كل مقرر.
وثق الإعداد الفعلي للمقرر وإصدار المنصة ونوع التسليم. لا تعمم نتيجة اختبار واجب فردي على واجب جماعي، ولا تجعل رسالة نجاح الرفع تقول «تم التسليم» إذا كانت هناك خطوة إرسال أخرى لم تُنفذ.
جهز رحلة لطالب واحد تجريبي
| الحالة | من جهة الطالب والمدرس |
|---|---|
| رفع ملف وحفظه فقط | حالة مسودة واضحة وفق الإعداد |
| تعديل الملف قبل الإرسال | ظهور النسخة المقصودة دون خلط |
| الضغط على التسليم النهائي | تغير الحالة وتوثيق وقت الإرسال |
| إعادة الواجب إلى مسودة | إمكان التعديل للحساب المخول وفق السياسة |
اختبر الحدود الزمنية والسياسة
في مثال مصطنع، حفظ طالب الملف قبل الموعد ثم حاول إرساله بعده. لا تعتبر هذه النتيجة محسومة باسم زر واحد؛ راجع مواعيد الواجب والقيود والاستثناءات المعتمدة. اجعل الاختبار يجيب هل تقبل المؤسسة هذه الحالة، وكيف تظهر في تقرير المدرس، دون تغيير موعد حقيقي أو بيانات طالب قائم.
راجع كذلك البيان الذي يقر به الطالب إن كان مطلوبًا، وطريقة عرض الخطأ عند فشل الشبكة أثناء الانتقال بين الحالتين. عند إعادة فتح الصفحة ينبغي قراءة الحالة من مصدرها، لا الاحتفاظ برسالة نجاح محلية قديمة.
سلّم دليلًا مفهومًا للمستخدم
ضمن بناء منصة التعلم واختبار القبول سجل إعداد الواجب ونسخة الملف والحالة قبل كل خطوة وبعدها. استخدم ملفات تدريبية بلا بيانات أشخاص. معيار القبول أن يعرف الطالب هل حفظ مسودة أم سلم عملًا، وأن يرى المدرس الحالة نفسها وفق سياسة المؤسسة؛ الإشعار وحده ليس إثباتًا كافيًا للتسليم.
