أود تشغيل مثيل واحد من Discourse لبرنامج جامعي، حيث تتوافق الفئات العليا المختلفة مع دورات مختلفة، ويتم إدارة الوصول إليها بواسطة مجموعات. لكي يتمكن المدربون والمتعلمون من الحصول على انطباع متماسك عن الدورة التدريبية، أود توفير شعور بالعزلة للدورات المختلفة. لذلك، أود أن يقدم مثيلي تجربة تنقل مشابهة لـ Teams/Slack/Mattermost، حيث توجد فرق معزولة نسبيًا، ويحتاج المستخدمون إلى التبديل من فريق إلى آخر. بالنسبة لمثيلي، سيعني ذلك أن واجهة المستخدم تؤكد على البيانات المتعلقة بالدورة المحددة حاليًا. على سبيل المثال، يقضي المستخدمون معظم وقتهم في إحدى الفئات العليا، ويؤدي تحديد إحداها إلى تصفية الفئات الفرعية وقنوات الدردشة التي يمكنهم رؤيتها بسهولة.
تنشأ حاجة مماثلة في مثيل حيث تتوافق الفئات المختلفة مع مجموعات بحثية مختلفة (أود تشغيل واحد كهذا أيضًا).
ما هي الأدوات الموجودة التي يمكن أن تساعد في تحقيق ذلك؟
أنا في الواقع لا أريد كتمها: من المحتمل أن يتابع الطالب عدة دورات في وقت واحد، والإشعارات من جميعها لا بأس بها. بل أريد أن أعطي انطباعًا أوضح عن “الآن أنا أنظر إلى الدورة التدريبية X”.
يبدو أن المجموعة الأساسية = المنزل المحدد، أليس كذلك؟ تحتاج إلى تمكين user_selected_primary_groups حتى يتمكن المستخدمون من تغيير مجموعتهم الأساسية في صفحة تفضيلات حساباتهم.
بشكل مثالي، أرغب في شيء أكثر زوالاً وأقل وضوحًا للعامة. ومع ذلك، أتخيل أنه إذا لم أستخدم العنوان والتوهج، فإن مكون واجهة مستخدم يقوم بتبديل المجموعة الأساسية سيعمل كمحدد فريق.
شيء مثل محدد الشريط الجانبي الإضافي الذي تم تشغيله هنا كتجربة قبل بضعة أيام سيكون رائعًا لذلك.
يمكنك فعل ذلك. يمكنك أيضًا تغيير شعار الموقع بناءً على مجموعتهم الأساسية؛ لقد فعلت ذلك لموقع تشترك فيه جامعات متعددة في مثيل واحد. ربما سيكون لديك مكون سمة مع قائمة منسدلة في الشريط العلوي تسمح لهم باختيار مجموعتهم الأساسية (وربما تقول “فئة” بدلاً من “مجموعة”).
@Anton_Akhmerov هل تأمل في القيام بذلك بنفسك أم ستكون على استعداد لدفع لشخص ما للقيام بذلك نيابة عنك؟ دعني أعرف!
إذا كنت ترغب في القيام بذلك بنفسك، أود نقله إلى Dev حتى تتمكن من العمل عليه هناك وتقديم تقرير إلى المجتمع والحصول على مدخلات من زملائك الأعضاء. دعنا ننقل هذا إلى Dev.
إذا كنت ترغب في دفع لشخص ما، فسوف أنقله إلى Marketplace.
أعتقد أنه قد يكون من الأفضل نقل هذا إلى Community ومناقشة المزيد حول حالة الاستخدام الخاصة بك، وكيفية تلبية احتياجاتك على أفضل وجه اليوم، وإفساح المجال للآخرين الذين ربما كانت لديهم احتياجات مماثلة قد تم حلها.
بعد ذلك، إذا تم تحديد فجوات منتج محددة تعتقد أنها مهمة بما يكفي لبنائها بنفسك أو للدعوة إليها، فيمكننا إنشاء مواضيع منفصلة في Feature و/أو Dev لهذه الأفكار.
هل يبدو هذا متوافقًا مع تفكيرك هنا؟ أم أنك بالفعل في مرحلة “أنا مستعد لبناء الأجزاء المفقودة”؟
متابعةً لذلك، إليك كيف أتخيل تلبية احتياجاتك على أفضل وجه باستخدام الميزات الجاهزة لـ Discourse. قد لا يكون هذا بالضبط ما يدور في ذهنك، ولكني أعتقد أنه يستحق النظر فيه كنقطة انطلاق للنقاش.
أولاً، سأضع بعض الافتراضات، والتي قد تكون صحيحة أو لا. يرجى إخباري أين أخطئ:
سيكون هناك العديد من الدورات (عشرات، ربما مئات)
سيتم إعداد الدورات بشكل دوري، في دفعات كبيرة، في بداية كل فصل دراسي (2-4 مرات في السنة)
سيكون للدورات نهاية حياة
يحتاج الأشخاص الذين يديرون الدورات إلى بعض القدرة على إعدادها بأنفسهم
سيكون لدى الأشخاص الذين يديرون الدورات خبرة محدودة أو معدومة في إدارة موقع Discourse.
يحتاج الأشخاص الذين يديرون الدورات فقط إلى رؤية دوراتهم الخاصة. قد يرغبون في رؤية دورات أخرى من حين لآخر كأمثلة، ولكن لا يحتاجون إلى المشاركة المستمرة فيها.
^ نفس الشيء بالنسبة للأشخاص الذين يأخذون الدورات
يوجد فريق صغير جدًا يدير النظام ككل
لا تحتاج الدورات حقًا إلى فئات فرعية؛ سيكون استخدام العلامات لتنظيم المحتوى داخل الدورات كافياً.
بالنظر إلى أن هذه النقاط قريبة، إليك ما أقترحه، أولاً على مستوى عالٍ:
إنشاء عدد قليل من الفئات الرئيسية: واحدة لـ “الدورات الحالية”، وواحدة لـ “الدورات السابقة”، وواحدة لـ “الدورات القادمة”، وواحدة أو أكثر للأمور الأكثر عمومية حول النظام نفسه (مثل كيفية استخدام الموقع).
تعيين نمط الصفحة الرئيسية ليكون “مربعات مع فئات” لعرضها بشكل بارز.
استخدام فئات فرعية لكل دورة.
إنشاؤها في “الدورات القادمة”.
نقلها إلى “الدورات الحالية” عند بدء الفصل الدراسي.
عند انتهاء الدورة، انقلها من “الدورات الحالية” إلى “الدورات السابقة”.
التحكم في الوصول إلى الدورات باستخدام المجموعات (مزيد من التفاصيل أدناه).
التحكم في الوصول:
لكل دورة، قم بإنشاء مجموعة من المجموعات التالية، على سبيل المثال: foo_interested، foo_enrolled، foo_admin.
إنشاء مجموعتين إضافيتين: “browse_courses” و “browse_past_courses”.
تعيين الفئات في “الدورات القادمة” و “الدورات الحالية” لتكون متاحة فقط للأشخاص في مجموعات الدورة المحددة والأشخاص في مجموعة “browse_courses”.
تعيين الفئات في “الدورات السابقة” لتكون متاحة فقط للأشخاص في مجموعات الدورة المحددة والأشخاص في مجموعة “browse_past_courses”.
تجربة المستخدم للمجموعات والدورات:
قم بتثبيت موضوع في الفئة الرئيسية لـ “الدورات القادمة” يشرح كيفية تصفح الدورات، مع آلية سهلة للأشخاص للانضمام إلى مجموعة “browse_courses”.
^ نفس الشيء لـ “الدورات الحالية”.
^ نفس الشيء لـ “الدورات السابقة”.
بالنسبة للدورات الفردية، قم بتثبيت موضوع في الفئة يشرح كيفية الانضمام إلى الدورة:
الانضمام إلى مجموعة “foo_interested” و/أو “foo_enrolled”.
إضافة الدورة إلى الشريط الجانبي الخاص بك.
ستكون الإدارة كثيفة العمالة في البداية، حيث سيحتاج كل دورة جديدة إلى شخص يتمتع بصلاحيات مناسبة إلى:
إنشاء الفئة.
إنشاء المجموعات.
إنشاء الموضوع المثبت.
إضافة الأشخاص إلى مجموعة _admins.
تزويدهم بالمستندات التي يحتاجونها لإدارة دوراتهم الخاصة.
يمكن أتمتة بعض ذلك باستخدام أدوات خفيفة الوزن. اعتمادًا على من هو فريق الإدارة الرئيسي، قد يكون من المنطقي البدء بشيء خارج النطاق الزمني يضرب واجهة برمجة التطبيقات (API). أو ربما تحتاج إلى شيء يعتمد على واجهة المستخدم (UI) مدمج في Discourse كمكون سمة أو إضافة. ولكني أقترح البدء ببساطة هنا، والتركيز أولاً على تحديد عملية تعمل، ثم تصميم الأدوات حولها.
يعد توسيع نطاق الفئات مصدر قلق محتمل هنا. لدى Discourse بعض المشكلات في الأداء وتجربة المستخدم عندما يصبح عدد الفئات كبيرًا جدًا (مئات أو آلاف). سيشعر المستخدمون الذين لديهم وصول إلى فئات متعددة بتأثير ذلك، بينما لن يشعر أولئك الذين لديهم وصول محدود بذلك. هذا جزء من الدافع وراء تقييد الوصول إلى الفئات كما أوضحت.
مهتم جدًا بسماع أي ملاحظات أو أسئلة لديك حول ما سبق.
مرحباً @mcwumbly، شكراً على الوصف المفصل والمدروس.
ما تصفه قريب بالفعل مما يدور في ذهني، مع بعض الاختلافات.
من خلال تشغيل مثيل واحد لدورة تدريبية على مدى 5 سنوات تقريبًا، أدركت أن إخفاء أو نقل المناقشات القديمة يتطلب جهدًا أقل بكثير من إعادة إنشاء مثيل دورة تدريبية من الصفر. لذا، في الممارسة العملية، تكون مساحة النقاش للدورة التدريبية ثابتة، ولكن معظم الموضوعات لها نهاية عمر.
أتخيل في الغالب أن فرق الدورات التدريبية ستحتاج إلى إدارة دورة تدريبية بدلاً من إعدادها.
دوراتنا تضم حوالي 200 طالب وفريق دورة تدريبية مكون من حوالي 10 أشخاص بما في ذلك مساعدي التدريس. هذا يستدعي وجود عدة فئات على الأقل:
أسئلة وأجوبة المحتوى (يطرحها الطلاب، يجيب عليها فريق الدورة التدريبية)
تنظيم الدورة (نفس الشيء أعلاه، ولكن فقط الأمور التنظيمية)
الإعلانات (ينشرها فريق الدورة التدريبية، قد يرد عليها الطلاب)
مناقشة فريق الدورة التدريبية (مرئية فقط لفريق الدورة التدريبية)
أعتقد أن استخدام الفئات الفرعية سيغطي هذه الحاجة.
أدرك أنه يمكن إنشاء تجميع على مستوى المثيل للفئات المذكورة أعلاه، على غرار ما تصفه، ولكن يبدو من المنطقي أكثر وضع كل هذه في فئة واحدة.
بشكل عام، أعتقد أن قدرات Discourse الحالية تناسب حالة الاستخدام هذه جيدًا، باستثناء ميزة الواجهة الأمامية البحتة المتمثلة في الحاجة إلى توفير شعور لعضو فريق الدورة التدريبية أو طالب بأنه ينظر إلى دورة تدريبية واحدة، بدلاً من النظر إلى جميع الدورات مرة واحدة.
مكون سمة التوثيق مشابه إلى حد ما في أنه يسمح للمستخدم بـ “الدخول” إلى فئة، ولكنه لا يسمح له بـ “البقاء” بسهولة داخل فئة.
نعم، نقل المواضيع بشكل جماعي يمثل مشكلة بعض الشيء، ولكن إعادة تعيين فئة بأكملها من “الدورات الحالية” إلى “الدورات السابقة” سيكون سهلاً للغاية، على ما أعتقد.
تتمثل فوائد القيام بذلك في أن كل فصل دراسي يمكن أن يبدأ بشكل جديد.
قد يكون هذا عيبًا مع ذلك، اعتمادًا على ما إذا كنت تعتقد أن المحتوى من الفصول الدراسية السابقة قيّم أو ضار، ومقدار الجهد الذي يتطلبه فريقك لإنشاء فئات جديدة لكل فصل دراسي.
إن وجود فئات تدوم إلى أجل غير مسمى يقلل بالتأكيد من هذا الجهد. إذا كان ذلك قابلاً للتطبيق، فيبدو رائعًا.
وإذا أصبح من الصعب الاحتفاظ بالمحتوى القديم إلى الأبد، فربما تكون هذه “مشكلة جيدة”، لا ينبغي أن يكون من الصعب التحول إلى النموذج الذي اقترحته لاحقًا.
أعتقد أن نظريتك هنا سليمة.
يبدو وجود فئات فرعية لكل من هذه الأنشطة ضمن كل فئة دورة تدريبية منطقيًا.
أعتقد أنه يعتمد مرة أخرى قليلاً على مدى ثقتك في أن التعقيد الإضافي مبرر، وإذا كان الأمر كذلك، فهل هذا هو الشكل الصحيح.
يمكنك استخدام علامة مقيدة للإعلانات بدلاً من ذلك، والتي لها بعض الفوائد.
يمكن التعامل مع الاثنين الأخيرين عبر رسائل خاصة للمجموعات بدلاً من فئة.
أعتقد أن كلا الخيارين يستحقان النظر. هناك بعض المقايضات بينهما.
كلما تعمقت في إعداد الأشياء، استمر في طرح الأسئلة عندما تواجهها.
وبغض النظر عن الاتجاه الذي تختاره للبدء به، أود أن أسمع تحديثات عرضية حول كيفية سير الأمور!
يمكن لمكون سمة، على سبيل المثال، تغيير الأيقونة وجعلها تنتقل إلى الصفحة الرئيسية للدورة التدريبية بدلاً من الصفحة الرئيسية العامة.
بدأت في استخدام discourse لتدريس دورات تكنولوجيا التعليم عندما كنت أستاذًا في التعليم.
استخدمت فئة لمواد الدورة التدريبية وجعلت الطلاب يردون كرابط موضوع لتقديم أعمالهم (في الفئات العامة). في موضوع على مستوى الفصل الدراسي، كان المنهج الدراسي يشير إلى مواد الدورة التدريبية القياسية مع تحديد متى يجب القيام بكل شيء. ثم استخدمت مجموعة من العلامات للإشارة إلى الموضوعات التي سيتم تقييمها وكتبت نصًا برمجيًا يرى ما إذا كنت أحببت موضوعًا للإشارة إلى ما إذا كنت قد وافقت على العمل.
كتبت نصًا برمجيًا يقوم بتحديث ملف CSV من نظام إدارة التعلم بالجامعة لتسهيل تحميل الدرجات هناك.
الشيء الذي أعتقد أنني أحببته أكثر، وربما كنت سأكتب عنه لو كنت أكاديميًا أفضل (ولم أترك تلك الوظيفة) هو أنني كنت أقوم بتحديث الواجبات أثناء الدورة التدريبية لإصلاح الأشياء التي كانت غير واضحة، بدلاً من الانتظار حتى العام المقبل لإجراء تحسينات. وبما أن جميع التعديلات كانت متاحة في السجل، كان الطلاب أحرارًا في القيام بأي إصدار من الواجب يريدونه (أو قاموا به قبل أن أقوم بالتعديل). ما زلت أعتقد أن تحسين الدورة التدريبية أثناء التنقل بدلاً من الانتظار لمدة عام والأمل في تذكر المشكلات كان فكرة رائعة.
