لماذا في إعدادات لوح كانبان لا يمكنني اختيار الفئة من القائمة المنسدلة؟ أحتاج لكتابة الاسم يدويًا.
عندما أعد ذلك، تظهر علامة التبويب اللوح مرة واحدة في صفحة الفئة، ثم تختفي وأحتاج إلى إعادة تكوينها من جديد (أي: حذف الفئة المختارة من القائمة وكتابتها مرة أخرى).
من الممكن ولكن لدينا حالة خاصة تجعل الأمر أكثر تعقيدًا من مجرد إضافة بسيطة. محدد الفئة يسمح فقط بإضافة الفئات الموجودة… ولكننا نسمح حاليًا بإضافة إدخال مخصص @ لتطبيق المكون على عرض “جميع الفئات” على المستوى الأعلى.
سنحتاج إلى فصل ذلك إلى إعداد منفصل وترحيل الإعدادات الحالية لاستخدام القائمة المنسدلة للفئات.
هذه مربكة للغاية. هل يمكنك شرح ما يعنيه “@” وكيفية استخدامه؟ لقد رأيته في واجهة إعدادات كانبان ولم أتمكن من معرفة ما يفعله.
أيضًا، لماذا يجعل وجود “@” مخصص من المستحيل استخدام القائمة المنسدلة؟ فقط أضف إدخال “@” إلى القائمة المنسدلة، ألن يكون ذلك كافيًا؟ والأفضل من ذلك، لماذا تسمّيه “@”؟ قُل “جميع الفئات” في تلك القائمة، ودعها تستخدم “@” من خلف الكواليس. تبين أنه حتى بالنسبة لي، كمطور برمجيات، الذي كان يستخدم Discourse منذ بدايته، الأمر أصبح غامضًا جدًا.
هذا خارج الموضوع بوضوح، ولكن أود أن أضيف رأيي وأقول إن الإحباطات المستمرة مع واجهة مستخدم ديسكورس تجعلني غير ناجح تمامًا في تجنيد شركائي وأصحاب المصلحة في المشروع لاستخدام ديسكورس. كلهم يكرهون واجهة المستخدم، ولا يمكنهم استخدامها لأنها مربكة بكل الوسائل، وهذا العجز عن جعل كانبان أداة مفيدة يضيف إلى إحباط هؤلاء الشركاء الذين أحاول إقناعهم بالانضمام إلى استخدام ديسكورس لإدارة المشاريع. للعودة إلى القضية الفعلية التي نوقشت في هذا الموضوع، كيف يمكنني شرح علامة “@” لمدير يريد فقط فتح لوحة الإعدادات وتكوين قوائم كانبان حسب رغباته؟ كل هذه الأشياء الصغيرة تتراكم وتجعل الناس مرتبكين تمامًا عند دخولهم إلى مساحة ديسكورس، ويحاولون المغادرة فورًا ويطلبون مني عدم التعامل معهم على هذه المنصة بعد الآن لأنها تضيع وقتهم. أنا عاجز عن جعل الناس متحمسين لديسكورس. ولزيادة الأمر سوءًا، لسبب ما، يقوم فريق ديسكورس بتدهور بعض جوانب واجهة المستخدم بدلاً من تحسينها، انظر تحديثًا حديثًا هنا ونقدي له: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
بالمناسبة، إذا أدخلت هناك “@MyCategory” (وهو ما فعلته بشكل حدسي أثناء محاولة فهم ما تفعله علامة “@”)، فإنها لا تخبرني بأي أخطاء في التحقق من الصحة. كيف يُعتبر مقبولاً عدم إخباري بأنني أفعل شيئًا بشكل غير صحيح عندما يكون واضحًا من منظور المبرمج، ويمكن اكتشافه بسهولة عند “حفظ…” قيمة الإعداد المحدثة؟
عذرًا، كان عليّ قول كل هذا خاصة بعد أن رأيت أن شخصًا ما غادر ديسكورس وعاد إلى ديسكورد، مما أكد مخاوفي وإحباطاتي بشأن واجهة المستخدم.
لقد كنت أحاول جاهدًا حقًا، ولكن هناك الكثير من التعقيد. الأمر أشبه بالأيام الخوالي - حروب Android ضد iPhone.
كان Android يسمح لك بتخصيص ما تريده.
كان iPhone محدودًا للغاية، ولكنه… كان يعمل ببساطة.
هذه هي نفس الحالة مع Discourse الآن. أعتقد أننا بحاجة إلى السير على طريق أنطوان دو سانت إكزوبيري بشكل أكبر: “الكمال يتحقق، ليس عندما لا يكون هناك شيء آخر لإضافته، ولكن عندما لا يكون هناك شيء آخر لأخذه”.
هناك الكثير من الارتباك (مثل الرسائل المباشرة مقابل الدردشات الخاصة، لتسمية أول ما يتبادر إلى الذهن) مما يجعل من الصعب جدًا إقناع الناس باستخدامه بحرية. على Discord، هناك احتكاك أقل. نفس الشيء مع Skool. أعتقد أن هذا هو ما يجب أن نسعى إليه، وليس إضافة المزيد من الميزات.
لقد غادر عميل مؤخرًا منصة Discourse لسبب بالضبط كما ذكرت - التعقيد.
ولكن بصراحة، عند النظر إلى بعض خوادم Discord، لا أقول إنها بسيطة على الإطلاق؟ هناك الكثير الذي يمكنك إضافته إلى خادم Discord الآن (بما في ذلك البوتات).
أحد العيوب الكبيرة للتحول إلى Discord أو أي تطبيق مخصص مغلق هو أنك تفقد تحسين محركات البحث، أليس كذلك؟ ربما هذا لا يؤثر عليك.
[اقتباس=“meglio، المنشور:7، الموضوع:366791”]
هل يمكنك شرح ما يعنيه الرمز “@” وكيفية استخدامه؟
[/اقتباس]
اختار من قام بتنفيذه الرمز @ كرمز فريد لتمثيل قوائم المواضيع العليا عندما لا يتم تصفيتها لفئة أو وسم. وهذا يشبه forum.example.com/latest أو forum.example.com/top. لذا تقوم بإدخال @ بشكل منفصل كإدخال خاص به لتطبيق لوحة التفاهم هناك.
أنا أوافق أن هذا يسبب لبسًا، لكنه شيء يمكن تجاهله إلا إذا كنت تريد لوحات كانبان عامة.
[اقتباس=“meglio، المنشور:7، الموضوع:366791”]
أيضا، لماذا وجود “@” مخصص يجعله مستحيلا لاستخدام قائمة الاختيارات المنسدلة؟
[/اقتباس]
هذا لا يمنع، لكنه يعقد الانتقال إلى قائمة الفئة المنسدلة لأنه يلزمنا أيضًا إنشاء ترحيل حتى لا نعيد تعيين الإعدادات في المواقع التي تستخدمه بهذه الطريقة.
إعدادات السمة تتحدد بواسطة واجهات برمجة التطبيقات الأساسية، لذلك عندما نستخدم نوع قائمة الفئة، لا يمكننا توسيعه بخيارات إضافية من السمة نفسها.
ديكوريسك ليست شركة ضخمة، نحن مقيدون بوقت للتركيز على الميزات الأكثر استخدامًا، وإعادة تصميم المكونات (التي تُقدم مجانًا) يمكن أن يكون من الصعب تحديد أولوياته. إذا رغب شخص ما في تمويل تحسينات إعدادات كانبان، فيمكننا بالتأكيد جعلها أولوية أعلى.
[اقتباس=“meglio، المنشور:8، الموضوع:366791”]
آسف لأني اضطررت إلى قول كل ذلك خاصة بعد أن رأيت أن شخصًا ما غادر ديكوريسك وعود إلى ديسكورد، مما أكد مخاوفي وإحباطي مع واجهة المستخدم.
[/اقتباس]
هل لدى ديسكورد ميزة لوحة كانبان متاحة؟ بحثت لكن لم أجد الكثير باستثناء بوت يتكامل مع خدمة كانبان خارجية.
[اقتباس=“merefield، المنشور:10، الموضوع:366791”]
جانب كبير من العيوب عند الانتقال إلى ديسكورد أو أي تطبيق مخصص هو أنك تخسر تحسين محركات البحث، أليس كذلك؟
[/اقتباس]
أنت تخسر السيطرة أيضًا، محتوى المستخدمين هو أيضًا محتوى ديسكورد. عندما يدفع شخص ما مقابل ديسكورد، يكون الربح لديسكورد. هناك مقايضات وتكاليف لكل منصة.
نعم، من غير الواضح متى سنكون في وضع يسمح لنا باستثمار الاهتمام في ميزة كانبان في الوقت الحالي.
هذه شيء أود أن أعيد النظر فيه في مرحلة ما. أعتقد أن اعتماد مكون السمة قد قدم دليلًا على وجود رغبة في المزيد من هذا النوع من الأمور.
لقد كانت هناك فوائد من تنفيذها كمكون سمة — فهي سهلة نسبيًا لأي مسؤول أن يجدها ويثبتها — لكنها تأتي أيضًا مع قيود كبيرة تجعل من الصعب تصميمها بالطريقة التي قد يتوقعها المرء.
إذا ومتى نعيد النظر فيها، أعتقد أن هناك مسارين محتملين يمكننا اتباعهما — يمكننا استخدام مجموعة الميزات المرغوبة للوحة كانبان كسبب لتحسين واجهات برمجة التطبيقات المتاحة لمكونات السمة، أو يمكننا تحويلها إلى ميزة أساسية أو مكون إضافي والحصول على وصول أوسع لواجهة برمجة التطبيقات الخادمة المناسبة التي نحتاجها.
حتى ذلك الحين، أعتقد أنه من المحتمل أن تتلقى فقط تعديلات لمشاكل محددة.
[اقتباس=“merefield، المنشور: 10، الموضوع: 366791”]
tbh، عند النظر إلى بعض خوادم Discord، لن أقول إنهم بسيطون على الإطلاق؟ هناك الكثير مما يمكنك إضافته إلى خادم Discord الآن (بما في ذلك البوتات).
[/اقتباس]
هذا صحيح، ولكن هذا العبء يقع على عاتقنا - الملاك - وليس المستخدمين. يرى المستخدمون الأمر بأبسط شكل ممكن:
اختر قناة → أرسل الرسالة وهذا كل شيء!
لا يوجد كانبان. لا حاجة لفهم الفرق بين مراقبة و تتبع. لا توجد مجموعة من الميزات مثل يا، كم سيكون رائعًا لو استطاع Discourse أيضًا أن يفعل xyz.
كل هذه الميزات رائعة جدًا، بالنسبة لنا - الأفراد التقنيين / الملاك / الإداريين.
ولكن بالنسبة للأشخاص العاديين - فهم يريدون إحساسًا بالمجتمع. يريدون أن يشعروا بأنهم أحرار في التعبير عن أنفسهم وعدم الاضطرار إلى معرفة كل تلك المئات (أعتقد أن هناك العديد) من الخيارات والمصطلحات والأشياء الأخرى.
[اقتباس=“ludwikc، المشاركة:9، الموضوع:366791”]
هناك الكثير من الالتباس (مثل الدردشات الخاصة مقابل الرسائل المباشرة، لذكر أول واحد يظهر) لدرجة أنه من الصعب حقًا إقناع الناس باستخدامه * بحرية *.
[/اقتباس]
هذه هي بالضبط الملاحظات التي أتلقاها من أصحاب المصلحة. يضلون طريقهم بين الدردشات والمواضيع الخاصة.
[اقتباس=“merefield، المشاركة:10، الموضوع:366791”]
لقد ترك مؤخرًا عميل من Discourse لأسباب تحديدًا التي تذكرها - بسبب التعقيد.
[/اقتباس]
في مشروعي الحالي، يستكشف مالك المشروع Basecamp لأنه يقول إنه لا يستطيع استخدام Discourse بعدما جربه. أنا أدافع عن Discourse لأنني أعرف ميزاته وقدراته المتميزة، لكنني لا أستطيع أن أفعل الكثير لأن ضعف قابلية الاستخدام والفوضى في كل من واجهة المستخدم والمصطلحات دائمًا يتفوق على الوظائف. وليس فقط أن ماركداون الذي يكرهه معظم الأشخاص غير التقنيين ولا أستطيع أن أشرح لهم لماذا هو ليس wysiwyg في المقام الأول. الحمد لله أن فريق Discourse أخيرًا يعمل على المحرر الصحيح. معظم الناس يريدون محرر نصوص بسيط يشبه Word مع بعض القدرات فقط: التنسيق، والجداول، والألوان، والصور، وقطاعات الكود. لا يوجد سبب يمنع أن يحصل أي من ذلك في شكل ماركداون من قبل المستخدم العادي. الميزات الأكثر تطورًا مثل الذكاء الاصطناعي تبدو بلا فائدة عندما لا يستطيع المستخدم النهائي فهم لماذا محرر نصوص منشوره مقسم إلى عمودين رأسيًا — هذا هو ما يفكرون فيه، وليس الذكاء الاصطناعي.
لديهم كل البيانات. هذا هو الاتفاق، وأفهم الإحباط الأولي، لكنني أرى العديد من التحسينات على مدى الأشهر الماضية على Discourse.
يمكن للمسؤولين اختيار التوقف عن استخدام الدردشات و/أو الرسائل الخاصة وتبسيط الأمور. يستغرق الأمر وقتًا، وهناك منحنى تعلم يفهمه الجميع بالتأكيد. مزايا وعيوب مثل أي شيء آخر.
أتمنى الأفضل للفريق، وأعتقد أننا حقًا بحاجة إلى المساهمة ومنح الوقت لعملية التطور الطبيعي.
{“translation”: “[اقتباس=«مريفيلد، المنشور:19، الموضوع:366791”]
ليس هو ديناميكية جيدة جدًا لتنظيم المعلومات؟
[/اقتباس]
هذا هو الحال بالضبط حيث لا نواكب المشهد المتغير لطريقة استهلاك أعضاء مجتمعاتنا للمحتوى.
واجهت نفس القرار بالضبط. أن يكون لديك شيء قوي ومنظم جيدًا، مع تحسين محركات البحث بشكل ممتاز، شيء مما يسمح لنا بخلق تركة بسبب طبيعة المحتوى الذي نصنعه.
لكن الناس اليوم (وهذا بالطبع تعميم) لا يشعرون أن مثلاً Slack يسلب شيئًا عندما يقتصر التاريخ على آخر 90 يومًا.
أحد أعضائي قال لي (وهي رائدة أعمال ناجحة جدًا وتقترب من الثلاثين من عمرها) إنه اليوم، إذا كان المعلومات الأقدم من 3 أشهر فهي لا تقرأها، لأن كل شيء يتغير بسرعة، والبحث عن أشياء قديمة مجرد مضيعة للوقت. سواء كان ذلك في مجال الأعمال، العلم أو… حسنًا، الحياة.
وبطبيعة الحال، وجود مواضيع مثل التي نقوم بها هنا بشأن الإضافات التي قد يتم تحديثها بعد عدة أشهر - هو الحالة الصحيحة. ولكن غير ذلك - من حيث “بناء المجتمع”، الأمر يتعلق أكثر بـ “شعور الانتماء” والقدرة على التفاعل مع هذا المجتمع بدون عناء، بدلاً من محاولة فهم جميع الخيارات التي توردنا.
تحدثت عنه في مواضيع سابقة، حيث كنت أستفسر عن نجاح Skool مقارنة بـ Discourse."}
"[quote=“ludwikc، المشاركة: 20، الموضوع: 366791”]
الأمر يتعلق أكثر بـ “مشاعر الانتماء” والقدرة على التفاعل مع هذه المجتمع مع قليل من الاحتكاك أو عدمه، بدلاً من محاولة فهم جميع الخيارات التي تجهدنا.
[/quote]