الحظر المخصّص: أفضل الممارسات

على مرّ السنين، تعلّم فريق Bluely وBlockly Games العديد من الدروس التي يمكن أن تنطبق على المطوّرين الذين يطوّرون التطبيقات المستندة إلى Openly. في ما يلي مجموعة من الأخطاء التي ارتكبناها أو الأخطاء التي يشيع ارتكابها الآخرون.

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

1- نمط الحد

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

يتّضح من المثال السابق على خمس قطع من الترميز (من scriptr.io) أهمية استخدام هذه "الزخارف القديمة" في التفريق بين القطع المتصلة ذات اللون نفسه.

اقتراح: لا تدع أزياء اليوم تحطم تطبيقك، إذا كنت تريد تغيير مظهره.

2. تضمين المكدسات الفرعية

لا تحتوي القوالب على شكل حرف C على موصِّل من الداخل من الداخل، إلا أنّ بعض البيئات تحتوي أيضًا على موصِّل من الداخل (على سبيل المثال، Wonder Workshop) بينما لا تحتوي القطع الأخرى على موصِّل (على سبيل المثال،Blockly وScratch). نظرًا لأن معظم كتل العبارات تحتوي على موصل علوي وسفلي، فلا يرى بعض المستخدمين على الفور أن العبارات ستكون مناسبة داخل حرف "C" لا يحتوي على موصل سفلي.

بمجرد أن يكتشف المستخدمون أن كتلة عبارة واحدة تناسب داخل حرف "C"، يحتاجون بعد ذلك إلى معرفة أن أكثر من عبارة واحدة ستناسب أيضًا. تدمج بعض البيئات الاتصال السفلي للعبارة الأولى أسفل "C" (على سبيل المثال، Wonder Workshop وScratch) بينما هناك مساحات أخرى تترك فجوة صغيرة (على سبيل المثال، Blockly). لا يترك التداخل المريح أي إشارة إلى إمكانية تكديس المزيد من القوالب.

تتفاعل هاتان المشكلتان بشكل سيئ مع بعضهما البعض. في حالة وجود موصل داخلي سفلي (ورشة عمل Wonder Workshop)، يصبح اتصال البيان الأولي أكثر وضوحًا، ولكن على حساب القدرة على اكتشاف التجميع. إذا لم يكن هناك موصل داخلي في الأسفل (Blockly)، يكون اتصال العبارة الأولية غير واضح، ولكن يكون التجميع قابلاً للاكتشاف. إنّ عدم توفُّر موصل داخلي ودمج الموصّل السفلي الخاص بالعبارة (Scratch) كان أسوأ ما يمكن العثور عليه عند اختباره باستخدام تطبيق Blockly.

كانت تجربتنا أن اتصال البيان الأولي يمثل تحديًا أقل للمستخدمين من اكتشاف التكديس. وبمجرد اكتشافنا، لا تُنسى الأولى أبدًا، في حين أن الثانية تحتاج إلى المطالبة. جربت قناة بلوغ كل من منهج Wonder Workshop ونهج Scratch حتى حدث خطأ في العرض في أحد الأيام، ما أدى إلى زيادة هذه الفجوة الصغيرة. لاحظنا تحسُّنًا ملحوظًا في دراسات المستخدمين التي أجرتها Bblockly بسبب هذا الخطأ (أصبحت الآن "ميزة" نفخر بها).

اقتراح: في حال إعادة صقل واجهة المستخدم الحالية، اترك واجهة المستخدم المكدّسة الحالية.

3. الروابط المتماثلة

هناك نوعان مختلفان من الاتصال في لعبةBlockly: أشكال الألغاز الأفقية وشقوق التنضيد العمودية. يجب أن تسعى واجهة المستخدم الجيدة إلى تقليل عدد عناصر التصميم. وفقًا لذلك، يحاول العديد من المصممين جعل كلا نوعي الاتصال يبدوان متشابهين (كما هو موضح أدناه).

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

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

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

4. أسماء المتغيرات والدوال

لا يتوقّع المبرمجون المبتدئون أن يكون location_X وlocation_x متغيّرَين مختلفَين. نتيجةً لذلك، يتبع تطبيقBlockly قيادة BASIC وHTML من خلال جعل المتغيرات والدوال غير حساسة لحالة الأحرف. وتستخدم لغة Scratch منهجًا أكثر دقة (كما هو موضّح على اليسار) وهي حساسة لحالة الأحرف لأسماء المتغيرات وليس مع عمليات التحقق من المساواة.

بالإضافة إلى ذلك، لا يتطلب تطبيق Blockly أن تتوافق المتغيرات والدوال مع مخطط [_A-Za-z][_A-Za-z0-9]* النموذجي. إذا أراد أحدهم تسمية متغيّر List of zip codes أو רשימת מיקודים، هذا مناسب تمامًا.

اقتراح: تجاهل حالة الأحرف والسماح بأي أسماء

5. المتغيّرات العمومية

يواجه المبرمجون المبتدئون أيضًا صعوبات في فهم النطاق. نتيجةً لذلك، يتبع تطبيقBlockly مسار Scratch من خلال جعل كل المتغيرات عمومية. الجانب السلبي الوحيد للمتغيرات العمومية هو أنّ التكرار أصعب (على المرء دفع المتغيرات وجعلها بارزة في قائمة)، ولكن هذا أسلوب برمجة خارج نطاق المستخدمين المستهدفين لدى Bluely.

اقتراح: النطاق خارج النطاق، واتركه لوقت لاحق.

6. التعليمات

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

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

اقتراح: يجب أن تكون التعليمات قصيرة وثابتة، ولكن ليست مزعجة.

7. ملكية الرمز

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

تصميم تمارين حرة تعلم نفس المفاهيم أكثر صعوبة. أحد الأساليب التي أثبتت نجاحها هو استخدام الحل الخاص بالطالب لتمرين واحد كنقطة بداية للتمرين التالي.

اقتراح: لا تكتب رمزًا برمجيًا للمستخدم.

8. تنسيق Workspace

هناك طريقتان معقولتان لتخطيط الشاشة من اليسار إلى اليمين. تبدأ إحدى الطرق بشريط الأدوات على اليسار ومساحة العمل في المنتصف وتصور الناتج على اليمين. يتم استخدام هذا التخطيط في الإصدار 1 من Scratch وكذلك Made with Code.

الطريقة الأخرى تبدأ مع تصور الإخراج على اليسار وشريط الأدوات في المنتصف ومساحة العمل على اليمين. ويُستخدَم هذا التنسيق في الإصدار الثاني من Scratch بالإضافة إلى معظم تطبيقات Openly.

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

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

وبالطبع، يجب قلب الأمر بأكمله بالنسبة للترجمات إلى العربية والعبرية.

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

اقتراح: ضَع العرض المرئي للبرنامج بجانب شريط الأدوات.

9. الخروج من الاستراتيجية

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

وبالنظر إلى ذلك، يجب أن تكون بيئات البرمجة القائمة على الكتل المستخدمة لتدريس البرمجة طريقة منحدرة لطلابها. تعتمد لعبة Bluely Games أربع استراتيجيات وهي:

  1. تكون جميع النصوص في القوالب (مثل "if" و" while") صغيرة لمطابقة لغات البرمجة النصية.
  2. يتم دائمًا عرض نسخة JavaScript من رمز الطالب بعد كل مستوى لزيادة الإلمام بها.
  3. في اللعبة ما قبل الأخيرة، يتم استبدال نص الكتلة بلغة JavaScript الفعلية (كما هو موضّح على اليسار). في هذه المرحلة، يدرس الطالب البرمجة باستخدام JavaScript.
  4. في اللعبة المثالية، يتم استبدال محرِّر القوالب بمحرِّر النصوص.

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

الاقتراح: يجب مراعاة الأهداف النهائية للمستخدم والتصميم المناسب لها.