يحاول محرر WYSIWYG الجديد تمثيل ما سيتم عرضه بالضبط في المنشور الفعلي، ولكن في هذه الحالة الواحدة، فإنه يفعل ذلك بشكل جيد للغاية. باختصار، عند كتابة منشور يحتوي على قسم “إخفاء التفاصيل”، فإنك تريد عادةً أن يكون مغلقًا بشكل افتراضي (فهو مخصص لإخفاء التفاصيل في النهاية). ومع ذلك، عند كتابة المسودة أو مراجعتها، ستفتح قسم “إخفاء التفاصيل” بشكل طبيعي لرؤية النص بداخله. المشكلة هي أن هذا ينشر قسم “إخفاء التفاصيل” في الحالة المفتوحة بحيث يكون مفتوحًا بشكل افتراضي. بصراحة، لم أكن أعرف حتى أنه يمكن جعله مفتوحًا بشكل افتراضي ويبدو هذا غير بديهي للغاية لكيفية رغبة معظم المستخدمين في عرض القسم.
خطوات التكرار:
ابدأ مسودة جديدة في وضع محرر النص الغني (RTE)
أنشئ قسمًا جديدًا لـ “إخفاء التفاصيل”
افتح قسم “إخفاء التفاصيل”
أنشئ المنشور
متوقع: في المنشور، يجب أن يكون قسم “إخفاء التفاصيل” مغلقًا بشكل افتراضي لأنه يتطابق مع سنوات من التوقعات من محرر Markdown.
كيف تنشئ تفاصيل مفتوحة باستخدام محرر WYSIWYG إذا لم يكن ذلك عن طريق تركها مفتوحة قبل النشر؟ أليس كون التفاصيل مفتوحة عندما كانت مفتوحة قبل النشر هو بالضبط ذلك؟ تحصل على ما تراه.
نعم، تحصل على ما تراه. وأنا أقول في هذه الحالة أن الحصول على ما تراه أمر غير بديهي ويتعارض مع الغرض من قسم إخفاء التفاصيل. توقع أن يقوم المستخدم بإغلاق كل قسم “إخفاء التفاصيل” يدويًا قبل النشر لن يوفر تجربة مستخدم جيدة.
لا أعتقد أن هذا هو الاستخدام المقصود هنا. يجب أن تكون التفاصيل مغلقة افتراضيًا، ويتم فتحها اختياريًا. الاضطرار إلى تذكر تبديلها يدويًا للإغلاق قبل إنشاء منشور ليس سلسًا للغاية.
إن إزالة “open” في markdown قبل النشر ليست أكثر سهولة في الاستخدام أيضًا. ولكن عندما تريد رؤية ما تكتبه في المعاينة باستخدام محرر markdown، عليك القيام بذلك. هذا هو سير العمل الطبيعي الخاص بي. إنشاء التفاصيل، إضافة “open” حتى أتمكن من رؤية التنسيق في المعاينة أثناء الكتابة، وفي النهاية إزالة “open”.
بالنسبة لي، التبديل إلى أن تكون مغلقة يشبه إزالة “open” في markdown.
لذلك أنا أختلف مع
لأن تجربتي كانت هي نفسها من قبل. اضطررت إلى إزالة تنسيق “open” قبل النشر.
كان هذا هو المنطق أيضًا عند تطوير هذه الميزة وهذا بالضبط ما يحدث، ولكني أتفق على أن السلوك الحالي يبدو غير بديهي لأن نشر قسم تفاصيل open=true يبدو حالة نادرة جدًا بالنسبة لي، وينتهي الأمر بإلحاق الضرر بالتجربة الافتراضية/الأكثر شيوعًا بسبب هذا الدعم.
أعتقد أنه من المعقول افتراض أن معظم الناس ينشئون أقسام التفاصيل بنية إغلاقها عند النشر لتجنب ازدحام أو تكدس منشورهم بمحتوى قد يكون ثانويًا؛ وإلا، فلماذا يتم وضع المحتوى في قسم التفاصيل على الإطلاق؟
ولكن، إذا قمنا افتراضيًا بإغلاق جميع أقسام التفاصيل عند النشر، فإننا نجعل من المستحيل على أي شخص نشر قسم تفاصيل مفتوح دون التبديل إلى وضع Markdown، وهذا يتعارض مع فرضية WYSIWYG. إذا كان مفتوحًا في المحرر، فسيكون مفتوحًا في الموضوع / الرد المنشور.
أتساءل عما إذا كان المحتوى النائب مربكًا - عندما يكون مفتوحًا، نخبرك “سيتم إخفاء هذا النص”:
ليس لدي فكرة واضحة بعد حول كيفية المضي قدمًا في هذا، ولكني أتفق على أن هناك شيئًا ما ليس صحيحًا.
أيضًا، تستضيف المجتمعات التي أستخدمها نوادي كتب، وغالبًا ما تُستخدم أقسام التفاصيل لنشر المفسدين (خاصة عندما يكون هناك الكثير من النصوص واستخدام علامة المفسد غير ملائم). سيكون فتح هذه بشكل افتراضي مشكلة كبيرة. (هذه في الواقع هي الطريقة التي اكتشفت بها المشكلة في المقام الأول.) إذا كانت مفتوحة افتراضيًا، فسوف يفسد العديد من المستخدمين الكتب لمستخدمين آخرين، ولن أتفاجأ إذا عاد الكثيرون إلى ترميز ماركداون لتجنب ذلك.
مرحباً، كنت سأقوم بإنشاء نفس الموضوع. في مجتمعي، يتم استخدامه فقط للمفسدين، والآن أصبح هذا المحرر الجديد مربكًا جدًا لمستخدمينا، فهم لا يعرفون أنه يجب عليهم إغلاقه قبل النشر حتى لا يتعرضوا للتخريب.
نظرًا لأنه كان السلوك الافتراضي لفترة طويلة أن يكون مغلقًا افتراضيًا، فمن الصعب تبرير التغيير للمستخدمين.
أهلاً! أنا من نفس المنتدى الذي يتواجد فيه @seanblue وقد لاحظت هذه المشكلة مع صناديق التفاصيل المفتوحة.
أتفهم أن المحرر يعمل كما هو مقصود على ما يبدو. ومع ذلك، فإنه ليس من الواضح للمستخدم أن هذه هي الطريقة التي يُقصد أن يعمل بها المحرر وصناديق التفاصيل. إذا كان الأمر واضحًا، فسيقوم الجميع بإغلاق صناديق التفاصيل الخاصة بهم يدويًا ولن تكون هناك مشاكل.
لدينا العديد من المستخدمين في المنتدى الذين لم يعتادوا على استخدام Discourse/المنتديات على الإطلاق، ولديهم الكثير من المشاكل في فهم الوظائف الأساسية مثل إضافة الجداول وصناديق التفاصيل إلى مشاركاتهم في المقام الأول؛ وهذا يضيف نقطة أخرى من الارتباك وهي أن صناديق التفاصيل لا تخفي المعلومات، خاصة مع النص الوصفي “سيتم إخفاء هذا النص”.
بالإضافة إلى ذلك، فإن المستخدمين القدامى غير مدركين للتغيير، وفجأة لم تعد صناديق التفاصيل تتصرف كما كانت دائمًا، مما يؤدي إلى فتحها أو إغلاقها بشكل عشوائي لأن المستخدمين لم يدركوا أن هناك تغييرًا. لذا، هذا مربك لكل من مستخدمي Discourse الجدد والمستخدمين القدامى لـ Discourse. لست متأكدًا حقًا من المستفيد هنا.
ثم، هناك أيضًا المشكلة التي ذكرها seanblue وهي أننا نستخدم صناديق التفاصيل بشكل أساسي لإخفاء المفسدين في نوادي الكتب، والآن بعد أنها لم تعد مغلقة افتراضيًا، فعندما تفتح موضوعًا، تكون جميع المفسدين مرئية، وهذا مزعج
نعم، أتفق — شكراً لكل من نشر هنا، التعليقات قيّمة للغاية. سنأخذ هذا الأمر لضمان أن أقسام “إخفاء التفاصيل” ستكون مغلقة افتراضيًا عند النشر من محرر النصوص المنسقة. سأتابع بمجرد معرفة المزيد عن التوقيت.
نواجه مشكلة في علامة [details] على موقعنا، حيث يؤدي فتحها في المعاينة إلى فتح الكتلة افتراضيًا.
يدعم هذا التحقق من BBCode لمنشور، والذي سيحتوي على open مضافًا إلى العلامة (كما في [details="This should remain closed" open]) إذا كانت مفتوحة في المعاينة في وقت إرسال المنشور.
يبدو أن هذا يقوض الغرض من العلامة، خاصة وأننا نستخدمها غالبًا للمحتوى المخفي.
