هذه خطوة إلى الوراء مقارنة بالإضافة الأصلية للوثائق في رأيي.
أنا أختلف بشدة هنا. إنها تمنحنا مرونة أكبر بكثير في كيفية ظهور مستنداتنا. علاوة على ذلك، يجعل هذا أيضًا من الممكن الارتباط بصفحات في فئات أخرى، وحتى الروابط الخارجية.
إعجاب واحد (1)
ولكن مع وجود آلاف المستندات وإضافة مستندات جديدة بشكل متكرر، فإن هذا يجعلها مهمة يدوية للغاية.
إعجابَين (2)
أتفق، لا أعرف ما إذا كنت سأتمكن من إدارة وثائق من 1000 صفحة باستخدام Discourse. أستطيع أن أرى نفسي أفعل ذلك على الرغم من وجود حلول وثائق أكثر تخصصًا.. 1000 صفحة بدون git تبدو.. مؤلمة أيضًا 
لماذا لا؟ إنه يعمل بشكل جيد جدًا مع المستندات الأصلية. على سبيل المثال، لدينا مواضيع في فئة “المكتبة” تحتوي على ملف PDF واحد أو أكثر أو مرفقات أخرى بالإضافة إلى نص المنشور. كل موضوع مُصنف أيضًا على أنه قابل للتطبيق، لذا فإن العثور على الأشياء سهل جدًا باستخدام البحث وتصفية العلامات.
ربما يكون الأمر متعلقًا بحالة استخدام. ربما تنمو فيه نتيجة لاستخدام Discourse كوثائق في وقت مبكر، ولكن في مجالي (التوثيق الفني/المستخدم)، سأحتاج إلى فهرسة يدوية على أي حال.
لقد وجدت أنه من السهل جدًا على القائم بالصيانة البحث عن المنشورات والعثور عليها.
ولكن من وجهة نظر المستخدم الذي لا يعرف منتجك أو جديد في الموضوع، قد لا يعرف ما الذي يبحث عنه، وفي هذه الحالة يكون الهيكلة منطقية جدًا (حسب تجربتي) أو يضيع المستخدمون في متاهة الوثائق. يمكنك اختبار هذا بنفسك، فكر في 5 إلى 10 وثائق عشوائية ضمن علامات تصنيف مختلفة تتوقع أن يقرأها المستخدمون لديك إلى حد ما. ثم حاول العثور عليها بمجرد النقر على موقعك، إذا واجهت صعوبة في العثور عليها بنفسك، يمكنك تخيل كيف ستكون تجربة المستخدم.
إعجابَين (2)
العثور على الأشياء سهل مع التصفية. لنفترض أنك تريد تعليمات تركيب المحرك لطراز طائرة جلاستار. أنت لا تعرف بالضبط ما الذي تبحث عنه، ولكن المفاهيم سهلة البحث والتصفية عنها:
مع المستندات القديمة، تتم إضافة أي شيء أضعه في فئة المكتبة تلقائيًا إلى المستندات. لا يوجد صيانة يدوية لفهرس منفصل، وهذا ما أعترض عليه.
إعجاب واحد (1)
أوافق على أن التصميم الحالي ليس مثاليًا.
لقد احتجنا إلى المرونة وتحملنا ديون التصميم للحصول عليها. إنه السبب الرئيسي الذي يجعلنا نعتبر Discourse Doc Categories لا يزال #تجريبيًا.
إن نيتنا هي تصميم وبناء شيء أفضل هنا يومًا ما، ولكنه ليس أولوية حاليًا.
5 إعجابات
أعتقد أن المشكلة هي أن المكون الإضافي الأصلي الذي تبنته العديد من المواقع وطبقته على نطاق واسع تم وضع علامة عليه الآن كـ end-of-life على الرغم من عدم تقديمه جسرًا عمليًا إلى الجديد.
لقد قمت للتو بتطبيق بعض KM على موقع يستخدم المكون الإضافي الجديد، لذا فإن التجربة لا تزال حاضرة في ذهني. الاضطرار إلى تنسيق موضوع فهرس لرؤية أي شيء في عرض المستندات يبدو غير أنيق حقًا. كان تطبيق المكون الإضافي القديم سلسًا نسبيًا، مما يوفر وجود تصنيف علامات لائق.
أتفهم أن الاحتياجات الجديدة دفعت إلى إنشاء فئات مستندات Discourse ولكن باعترافك الخاص، نحن عالقون بين مكون إضافي experimental لا يلبي الاحتياجات الحالية والمكون الإضافي القديم الذي له عمر محدود.
7 إعجابات
أتفق تمامًا مع ستيفن.
أتساءل لماذا تم التعامل مع هذا الأمر على أنه إضافة جديدة تمامًا بدلاً من تطور للإضافة الأصلية. يمكن أن تكون الثورات في البرمجيات قوية - لكنها تعمل بشكل أفضل عندما تكون سريعة وحاسمة.
3 إعجابات
في الواقع، أنا لا أستخدم إضافة Docs لإدارة الوثائق — أحتاج فقط إلى واجهة مستخدم بسيطة لـ تصفية المواضيع حسب فئات متعددة وعلامات متعددة في وقت واحد، كل ذلك على نفس الصفحة.
تتطلب واجهة Discourse الافتراضية المرور عبر البحث المتقدم، وهو مخفي للغاية ويتضمن العديد من عوامل التصفية التي لا أحتاجها (مثل المؤلف أو التاريخ). أنا أبحث عن تجربة أكثر تركيزًا ومباشرة.
تساعدني إضافة Docs القديمة في تحقيق هذه التصفية متعددة الفئات ومتعددة العلامات، لكنها لا تزال تحتوي على قيد واحد:
عندما أختار فئة رئيسية، فإنها تعرض فقط المواضيع الموجودة مباشرة داخل تلك الفئة الرئيسية — فهي لا تشمل المواضيع من فئاتها الفرعية.
على النقيض من ذلك، يعرض عرض الفئة الافتراضي مواضيع الفئة الرئيسية والفئات الفرعية.
لهذا السبب ما زلت أستخدم الإضافة، على الرغم من أنها ليست مثالية.
إليك طلبي السابق المتعلق بهذا: Multi menu select Group tags
شكرًا مرة أخرى لجميع من أخذوا وقتًا لمناقشة هذا الأمر والمساعدة في تحسينه — دعمكم ورؤيتكم محل تقدير عميق.
إعجابَين (2)