مرحبًا بك.
لقد قرأت عدة مواضيع هنا حول تنظيم الفئات والوسوم، لكنني لم أستطع التوصل إلى هيكلية تناسب احتياجاتي.
في الأساس، هذا منتدى دعم يغطي العديد من المنتجات. قد يكون هناك ما بين 50 إلى 100 منتج مختلف، وهي مجمعة في حوالي 5 إلى 10 “إدارات”.
لكنني أود أيضًا التمييز بين صلاحيات العملاء وغير العملاء. وهذا يعني أن غير العملاء سيكون لديهم حق الوصول للقراءة والكتابة فقط إلى “الدعم القياسي”، وحق الوصول للقراءة فقط إلى “دعم VIP”، بينما سيكون للعملاء حق الوصول للقراءة والكتابة إلى كليهما.
أيضًا، أود استخدام نظام التصويت لإنشاء آلية “طلب ميزات” تسمح للمستخدمين بطلب ميزات جديدة والتصويت عليها (لكل منتج على حدة). مرة أخرى، فقط العملاء سيكونون قادرين على طلب الميزات والتصويت؛ بينما يجب أن يتمكن المستخدمون العاديون فقط من التصويت على طلبات الميزات وليس على المواضيع الأخرى، وبالطبع يجب أن يتمكن الجميع (الموظفون والمستخدمون) من رؤية الميزات الأكثر طلبًا بسهولة.
ما هو الخيار الأفضل؟ في البداية، فكرت في استخدام عدد هائل من الفئات:
الإدارة أ
المنتج 1
طلبات الميزات
VIP
المنتج 2
طلبات الميزات
VIP
الإدارة ب
المنتج 3
طلبات الميزات
VIP
المنتج 4
طلبات الميزات
VIP
لكن يبدو أن هذا عدد كبير جدًا من الفئات.
يبدو أن الوسوم قد تساعد في هذه الحالة، لكن كيف يمكن استخدامها وفرضها وتصفيتها وتطبيق الصلاحيات عليها؟
أحد العيوب الرئيسية التي أراها في الوسوم (بغض النظر عن مسألة الصلاحيات) هو أن كل منتدى Discourse أزوره والذي يُعتبر “مثالًا” على استخدام الوسوم (مثل منتدى Car Talking، لكن هناك آخرين)، في النهاية يبدو أن الوسوم ببساطة لا تُستخدم. فقليل جدًا من المواضيع تُوسم، وكل شيء ينتهي في نفس المكان.
لست متأكدًا مما إذا كان هذا سيلبي احتياجاتك، لكنني سأشاركه على أمل أن يكون هناك شيء مفيد لك.
نقلنا مؤخرًا مجتمعنا الذي عمره 16 عامًا من SMF إلى Discourse. كان مستخدمونا راضين جدًا عن طبقات الفئات والفئات الفرعية واللوحات الفرعية الكثيرة. كان عدد هذه اللوحات سخيفًا حقًا. كان المستخدمون الجدد يضيعون بسهولة في هذا المتاهة.
منذ الانتقال إلى Discourse، أصبح لدينا الآن فئة > فئة فرعية > وسوم. وقد حلت الوسوم محل اللوحات الفرعية البالغ عددها 9172816 التي كانت لدينا سابقًا.
جعلت استخدام وسم إلزاميًا عند إنشاء موضوع، ولا يمكن للمستخدم اختيار سوى الوسوم التي أنشأتها لكل فئة.
اضبط إعداد الفئة على “الحد الأدنى لعدد الوسوم المطلوبة في الموضوع: 1”.
أنشئ مجموعات وسوم لكل فئة، ثم ألغِ تحديد خيار “السماح أيضًا بوسوم أخرى” في إعدادات الفئة:
فتحنا الأبواب في رأس السنة الجديدة، لذا لا يزال العمل قيد التقدم، ولكن يمكنك هنا رؤية تجميعات الوسوم الخاصة بي: the Lettuce Craft Forums
في عملية إنشاء الموضوع، يُطلب من المستخدم اختيار وسم واحد على الأقل/أقصى حد. قمت بتخصيص الصياغة لتصبح “الآن اختر وسمًا واحدًا (فئة فرعية)”. أنا أدرك أن الوسم ليس في الواقع فئة فرعية، لكن هذه هي الصياغة التي نحتاج إلى استخدامها لتعليم مجتمعنا القديم على تقنيات جديدة مؤقتًا.
لقد جعلتما هذا الموضوع يبدو كبداية لدليل تعليمي بفضل منشوراتكما الواضحة والمفيدة.
لقد كتبتُ ردًا طويلاً لأنني كنت أفكر في كيفية تصميم منتديات جديدة. لذا، فكرتُ في تجربة مشكلتكم لأرى ما إذا كان بإمكاني إعداد شيء عملي وما إذا وجدتم ذلك مفيدًا.
أتفق مع فكرة استخدام الوسوم (Tags) بدلاً من وضع كل شيء في الفئات (Categories)، وهو ما أفعله شخصيًا في بعض المنتديات الخاصة. ولكن يجب أن تكونوا على علم بأن هناك ميزتين واضحتين للفئات في الوقت الحالي:
الفئات ضرورية للتحكم في الوصول.
الإضافات (Plugins) تتيح تخصيصًا أكبر بكثير للفئات.
المشكلة الرئيسية هنا هي تحديد أي من متطلباتكم يجب التعامل معها كفئات بدلاً من وسوم. لكننا لسنا مضطرين للقرار من البداية. نصمم الفئات التي تعتبر ميزات رئيسية، ثم ننظر إلى ما يمكن تحويله إلى وسوم.
عملية اتخاذ القرار
هناك أكثر من طريقة للبدء في تصميم فئاتكم. عندما لا نعتبر الوسوم الآلية الأساسية، فسأعتمد الخطوات التالية:
ما هي الفئات المطلوبة؟
ما هي الفئات التي تتطلب ضوابط وصول منفصلة للمستخدمين؟
هل أحتاج الآن إلى الفئات الافتراضية؟
هنا مسار مختلف عن المسار المعتاد لأنكم ترون الحد الأدنى من الفئات الافتراضية التي قد تتيح لكم القيام بكل شيء آخر باستخدام الوسوم.
هل أحتاج إلى الفئات الافتراضية؟
ما هي الفئات التي تتطلب ضوابط وصول منفصلة للمستخدمين؟
ما هي الفئات الأخرى المطلوبة التي لا تتطلب ضوابط وصول للمستخدمين؟
أ. ما هو المتطلب الشامل؟
أولاً، ما هو المبرر المجتمعي الذي سيُستخدم لتطوير هيكل المنتدى؟ المجتمع والمنتجوان مختلفان.
من منشوركم الأول، أستنتج أن لديكم المتطلبات التالية لمجتمعكم:
الغرض الرئيسي هو الدعم.
الدعم مدفوع بـ المنتج، أي أنه لا يوجد منتج يعني لا يوجد عملاء ولا حاجة للدعم.
الدعم مقسم حسب حالة العميل، أي عميل مقابل غير عميل.
المنتج له طلب إضافي لـ طلب ميزة - من العملاء وغير العملاء.
المتطلبات الإضافية للمنتدى هي أن:
القسم يدير المنتج - لكن العميل/المستخدم يتفاعل من خلال المنتج.
ملاحظات:
قد يُدار الدعم من قبل الأقسام، لكن العملاء/المستخدمين على الأرجح يرتبطون بالمنتجات التي يستخدمونها. لذلك، لن أتعقّد المنتدى بإدخال هيكل تنظيمكم ما لم تكن أقسامكم هي علامات تجارية أو شركات تابعة يتعرف عليها العملاء والمستخدمون تقريبًا حصريًا في تعاملاتهم العادية.
أستخدم مصطلح عميل هنا لأنه يجب أن يكون هناك تحذير بشأن استخدام مصطلح VIP (عميل مميز). فهو يلغي خيار إنشاء مجموعة فرعية من العملاء VIP لاحقًا. لقد رأيتُ هذه المشكلة من قبل في منتدى للمحترفين المجتمعيين، لذا سأحتفظ بـ VIP للتقسيم الإضافي.
ب. ما هي الحد الأدنى من الفئات لتحقيق المتطلب الشامل؟
1. هل أحتاج إلى الفئات الافتراضية؟
أعتبر جميع الفئات الافتراضية ضرورية، لكنكم قد لا تحتاجون إليها. فقط كونوا على علم بأن الافتراضيات وضعت بعد الكثير من التفكير لمتطلبات مالك المنتدى العادي ومستخدمي المنتدى:
#lounge (الصالة)
افتراضيًا، هذه مخصصة لمستخدمي مستوى الثقة 3 (TL3). أقترح الاحتفاظ بها كـ ميزة لأكثر غير العملاء نشاطًا. قد يغركم استخدامها لفئة الـ VIP الخاصة بكم عن طريق إعادة تسميتها وتقليل الحد الأدنى لمستوى TL للوصول إليها. لا تفعلوا ذلك: احتفظوا بمجموعة الـ VIP وفئتها منفصلتين عن المجموعات والفئات الافتراضية.
Contribute > Site feedback (المساهمة: ملاحظات الموقع)
لجميع المستخدمين لاقتراح تحسينات أو الإشارة إلى مشكلات في منتداكم.
#staff (الموظفون)
للمشرفين والمسؤولين، لذا غير مرئية لمعظم المستخدمين.
Uncategorized (غير مصنف)
الإعداد الافتراضي هو السماح بالمواضيع غير المصنفة.
قد ترغبون في تعطيل إعداد كتم شارة غير المصنف لجعل هذه المواضيع أكثر وضوحًا في قوائم المواضيع، مما يزيد من احتمالية تعيينها إلى فئة أكثر صلة.
هذا يتطلب عملًا إضافيًا قليلاً للمشرفين ومستخدمي مستوى الثقة العالي، لكنه يسهل الأمر كثيرًا على المستخدمين الجدد الذين لا يستطيعون الحسم في اختيار الفئة.
هذه الفئة هي فئة المسودات المشتركة الافتراضية، وهو سبب آخر للاحتفاظ بها.
مثال
في هذه المرحلة، ستكون الحد الأدنى من فئاتكم هو:
الصالة (Lounge)
ملاحظات الموقع (Site Feedback)
الموظفون (Staff)
غير مصنف (Uncategorized)
2. ما هي الفئات التي تحتاج إلى ضوابط وصول للمستخدمين؟
المتطلب الوحيد المؤكد هو أن:
الدعم مقسم حسب حالة العميل، أي عميل مقابل غير عميل.
تريدون فصل المستخدمين عن العملاء، لذا يجب استخدام الفئات لهذا الغرض. أي طريقة أخرى ستكون مؤلمة للغاية.
هذا يعني أنكم تحتاجون إلى مجموعات عملاء وغير عملاء منفصلة، مع وجود فئة على الأقل حيث:
يمتلك العملاء صلاحية (CRS) (إنشاء، قراءة، رؤية).
يمتلك غير العملاء صلاحية (S) (رؤية) فقط.
مثال
في هذه المرحلة، ستكون الحد الأدنى من فئاتكم هو:
عميل
الصالة
ملاحظات الموقع
الموظفون
غير مصنف
3. ما هي الفئات الأخرى المطلوبة التي لا تتطلب ضوابط وصول للمستخدمين؟
متطلباتكم هي:
الدعم مدفوع بـ المنتج.
المنتج له طلب إضافي لـ طلب ميزة.
حتى بدون متطلباتكم، يبدو الهيكل الحالي غير كافٍ بشكل واضح لأنه ليس من الواضح أين يتم وضع طلبات دعم المنتج. لذا، تحتاجون على الأقل إلى فئة دعم للمنتج، والتي تتطلب بدورها فئة فرعية عميل. سأترك فئة عميل على مستوى عالٍ كمكان لمعالجة القضايا التي تشارك فقط مع العملاء وربما تكون مرئية لهم فقط.
يمكنكم ترتيب طلبات ميزة المنتج باستخدام إضافة ترتيب الميزات. تعمل هذه الإضافة عن طريق ترتيب المواضيع في فئة، لذا تحتاجون على الأقل إلى فئة واحدة. ثم قد يكون لديكم خياران لعرض الترتيبات حسب المنتج:
فئة واحدة مع عروض مرشحة حسب وسم المنتج. بحسبي، هذا قد يكون عائقًا حاليًا لكنني لم أجربه.
فئة فرعية واحدة طلب ميزة لكل فئة منتج.
بغض النظر عن الخيار المختار، سيكون من الأسهل وضع مواضيع طلب الميزة في فئة فرعية.
مثال بدون فئات منتج فردية
في هذه المرحلة، ستكون الحد الأدنى من فئاتكم هو:
عميل
الصالة
ملاحظات الموقع
الموظفون
الدعم
عميل
طلب ميزة
غير مصنف
مثال مع فئات منتج فردية
في هذه المرحلة، ستكون الحد الأدنى من فئاتكم هو:
عميل
الصالة
المنتج 1
عميل
طلب ميزة
…
المنتج 100
عميل
طلب ميزة
ملاحظات الموقع
الموظفون
غير مصنف
الآن يأتي سؤال العلاقة بين المنتجات وأولئك الذين يستخدمونها.
المسألة
فئة واحدة لـ الدعم
فئة واحدة لكل منتج
هل يستخدم معظم/كل العملاء معظم/كل المنتجات؟
نعم
لا
هل يرتبط معظم/كل العملاء بمنتجات فردية
لا
نعم
أيهما يدعمه Discourse الأساسي بشكل أفضل
الوسوم أكثر محدودية
الفئات لديها دعم أفضل
أيهما يدعمه الإضافات بشكل أفضل
الوسوم أكثر محدودية
الفئات لديها دعم أفضل
سهولة إدارة الفئات
نعم
لا
سهولة إدارة العرض والتقارير
لا
نعم
السهولة لمستخدم Discourse الجديد
لا
نعم
بشكل عام، أعتقد أنكم يجب أن تذهبوا مع فئات فردية لكل منتج، لأنها ستعمل، والعيوب الرئيسية هي عرض الفئات الطويل وفترة مملة تقضونها في إعداد تفاصيل الفئات والفئات الفرعية ووصول المجموعات.
مثال مع فئات منتج فردية (كما هو موضح أعلاه)
في هذه المرحلة، ستكون الحد الأدنى من فئاتكم هو:
عميل
الصالة
المنتج 1
عميل
طلب ميزة
…
المنتج 100
عميل
طلب ميزة
ملاحظات الموقع
غير مصنف
4. ما هي الفئات الأخرى التي قد تكون مفيدة؟
أنا متأكد من أنكم تدركون فئات أخرى قد ترغبون فيها ولم تحدديها هنا، مثل:
وثائق الشركة، مثل الشروط والأحكام العامة عبر جميع العملاء والمنتجات.
وثائق المنتج، مثل الوثائق المتعلقة بالمنتج.
التنزيلات، مثل البرامج المتعلقة بالمنتج، مثل الإصدارات القديمة من برنامج المنتج نفسه.
دروس “كيف نفعل”.
الأسئلة الشائعة (FAQs).
ج. ما هي الميزات التي يجب أن تكون وسومًا؟
بالنسبة إلى الوسوم التي يجب استخدامها، أحتاج إلى مزيد من المعلومات، مثلاً حول كيفية إدارة الأقسام للدعم.
في البداية، سأترك القسم خارج منتداكم لأنكم يمكنكم تطوير التقارير بناءً على المنتج مع ملخصات حسب القسم التي لن تحتاج إلى أي وسم مرئي.
أشير إليكم بالمواضيع الموجودة هنا لإعطائكم لمحة عما يمكن فعله بالوسوم في منتدى دعم. هذه المواضيع مرتبة من الأحدث إلى الأقدم:
شكرًا لكما يا @soraiden و@Remah على الإجابات المفصلة للغاية. نقدر ذلك حقًا.
لكنني لم أقرر بعد. الأمر صعب جدًا.
يبدو أن اقتراحات @Remah أكثر ملاءمة لحالتي، لكن عندما تقول: “عندها ستحصل على وثائق، وكيفية الاستخدام، والأسئلة الشائعة، وما إلى ذلك” - ألا ترتبط هذه أيضًا بالمنتجات؟
هذا يعزز الشعور بأن المنتجات يجب أن تكون وسومًا، وإلا سأضطر إلى تكرار الفئات الفرعية في كل مكان (مثل “العملاء” و"طلبات الميزات" المقترحة).
من ناحية أخرى، من المرغوب فيه أن يكون لكل عميل وصول مختلف حسب المنتج، فمثلًا، قد يكون العميل1 قد سجل المنتج أ، بينما قد يكون العميل1 قد سجل المنتج ب، وهما مختلفان. رغم أنني يمكن أن أعيش بدون هذه الميزة إذا لزم الأمر حقًا.
أنا أيضًا أخشى من إعداد الأشياء القائمة على الوسوم فقط لأكتشف لاحقًا أن بعض الميزات الرئيسية متاحة للفئات فقط وليس للوسوم…
شيء لم أفهمه من اقتراح @Remah: لماذا أحتاج إلى فئة عليا “عملاء” ثم فئة فرعية “عملاء” داخل كل منتج؟
ولكن مرة أخرى، شكرًا جزيلاً لك على الإجابة المفصلة والمنظمة للغاية.
ما هو الوقت المتوقع لبدء تشغيل هذا المنتدى؟ إذا كان الوقت قصيرًا ومحدودًا، فقد لا تتاح لك فرصة تجربة الوسوم.
بالمناسبة، أثناء التجربة، يمكنك إعداد الوسوم والفئات جنبًا إلى جنب. لا يهم إذا كانت هيكلية الوسوم تتطابق مع هيكلية الفئات. إذا استخدمت الفئات، فلن تكون هناك حاجة لاستخدام الوسوم، وبالتالي لن تظهر لأنها لن تُستخدم من قبل أحد.
هذه هي المشكلة التي تقلقني أيضًا. قلبي يقول جرب الوسوم، لكن عقلي يقول إنها ليست جاهزة تمامًا بعد. لقد حددت بالفعل عائقًا محتملًا مع الوسوم - وهو علامة في منشوري السابق حول عدم عمل التصفية حسب الوسوم مع إضافة Feature Ranking. ومع ذلك، فإن فريق Discourse متحمس لتمكين الاستخدام المكثف للوسوم، لذا قد يرون فرصًا لتطوير ميزات جديدة للمساعدة.
يمكنك البدء في تطوير هيكلية المنتدى باستخدام الوسوم بدلاً من الفئات. إذا لم تتمكن من تحقيق ما تريده في الوقت الحالي، فسيكون بديلك هو إنشاء جميع فئات المنتجات والفئات الفرعية.
تأكد من تدوين كل ما لا يمكنك فعله وما لا تفهمه. ثم عد إلى هذا المنتدى مع هذه القضايا واسأل عن الحلول.
الفئات مرئية جدًا وتوجد بشكل مستقل عن المواضيع، بينما هيكلية الوسوم ليست واضحة بنفس القدر، والوسوم توجد فقط عندما تكون هناك مواضيع تستخدمها. لذا، لكي تملأ المنتدى بالوسوم التي تريد استخدامها، ستحتاج إلى وجود مواضيع “مثال” تستخدمها، مثل موضوع قائمة المنتجات.
ميزة إضافية للوسوم هي أنه يمكنك إنشاء مجموعات وسوم، بحيث يمكن تجميع منتجاتك تحت مجموعات الوسوم الخاصة بإداراتك. لن تكون هناك حاجة لإضافة مجموعات الوسوم الإدارية إلى المواضيع، لأن إضافة وسم المنتج إلى موضوع ما سيربط مجموعة الوسوم بذلك الموضوع بشكل غير مباشر. لذا، ستقدم الوسوم بعض الخيارات الفريدة التي لن تتمكن من تطبيقها باستخدام الفئات.
نعم، سأقول إن ذلك مرجح جدًا. لكن يجب أن تمر بعملية تحديد إيجابيات وسلبيات كل خيار.
إذا كان لديك فئة فرعية عميل لكل منتج، فأين ستضع المواضيع التي تتعلق بجميع العملاء ولكن ليس جميع المستخدمين؟ لا يجب أن تكون فئة منفصلة، لكن من الجدير التفكير في ما قد تحتاجه أو ما يمكنك استغلاله للقيام بأشياء جديدة.
المنتدى الجديد يمثل فرصة لتبني طرق جديدة للقيام بالأشياء.
بحسبي، هذا