أود تشغيل مثيل واحد من 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 بعض المشكلات في الأداء وتجربة المستخدم عندما يصبح عدد الفئات كبيرًا جدًا (مئات أو آلاف). سيشعر المستخدمون الذين لديهم وصول إلى فئات متعددة بتأثير ذلك، بينما لن يشعر أولئك الذين لديهم وصول محدود بذلك. هذا جزء من الدافع وراء تقييد الوصول إلى الفئات كما أوضحت.
مهتم جدًا بسماع أي ملاحظات أو أسئلة لديك حول ما سبق.
