Gutenberg: قم بتحسين أدوات اختيار الكتل الأبوية / الأبناء

تعجبني فكرة فتات الخبز. (في الواقع ، اقترحت شيئًا مشابهًا جدًا في # 6459 في أبريل.) ماذا سيحدث لمسارات التنقل عند تمكين شريط الأدوات الموحد؟

أعتقد أيضًا أن فكرة النقر إلى الظهور جيدة أيضًا ، وهي مستخدمة بالفعل على الهاتف المحمول ، لذا فهي تضيف الاتساق. ومع ذلك ، لست متأكدًا من فكرة العبور ؛ أتخيل أن هذا قد يسبب ارتباكًا بسبب السلوكيات المختلفة عبر الكتل.

أنا أحب فتات الخبز ولكني أحب أيضًا شريط الأدوات الموحد. هل يمكننا إيجاد موضع آخر لمسار التنقل :)

أيضًا ، أنا شخصياً لا أحب الحدود حول المبنى الرئيسي. ولكن إذا احتفظنا بها ، فكيف نتعامل مع الاختيار المتعدد :). هل يجب أن نظهر حدودًا حول أصل الكتل المتعددة المختارة؟

أنا أحب خيار النقر. سيتطلب هذا بعض العمل الإضافي على كتلة "العبور" (لذلك لا يتم اعتبار كل "عمود" فردي طبقة يمكن النقر عليها ، على سبيل المثال) ولكنني أعتقد أن ذلك منطقي للغاية.

ماذا سيحدث لمسارات التنقل عند تمكين شريط الأدوات الموحد؟
أنا أحب فتات الخبز ولكني أحب أيضًا شريط الأدوات الموحد. هل يمكننا إيجاد موضع آخر لمسار التنقل :)

سؤال جيد. نموذج بالحجم الطبيعي السريع والقذر:

نعم ، أرى التحدي المتمثل في الرمز المكرر للمحول. أعتقد أنه من الجيد الاستمرار في التفكير في هذا الأمر. لاحظ أيضًا كيف يغفل هذا التصميم مخطط المستند ، المحظور في # 4287.

أيضًا ، أنا شخصياً لا أحب الحدود حول المبنى الرئيسي. ولكن إذا احتفظنا بها ، فكيف نتعامل مع الاختيار المتعدد :). هل يجب أن نظهر حدودًا حول أصل الكتل المتعددة المختارة؟

أعتقد أنه من المهم إظهارها على أنها تشير إلى أن الكتل الداخلية جزء من المجموعة الأم. هم _ anchor_ الكتل الداخلية.

الآن هذه هي الطريقة التي يعمل بها التحديد المتعدد:

وهذا ما يحدث عند تحديد كتلتين فرعيتين:

بمعنى آخر ، في المستوى الرئيسي ، لدينا نوعًا ما الحد الأصل بالفعل ، _ و_ نخفيه عند التحديد المتعدد للكتل الفرعية. أعتقد في الواقع أن إظهار الحدود الأصلية دائمًا ، حتى في التحديدات المتعددة ، أمر منطقي _عندما تحدد فقط الكتل الفرعية_. ولكن ربما يتعين علينا أن نجعل الاختيار المتعدد مختلفًا عندما يتم اختيار الكتلة _الأب _ بشكل متعدد. لذا بدلاً من إبراز كل كتلة فرعية بتأثيرات طبقة مضافة ، فإننا _ فقط_ نبرز الكتلة الأصلية. هل هذا العمل؟

أنا أحب خيار النقر. سيتطلب هذا بعض العمل الإضافي على كتلة "العبور" (لذلك لا يتم اعتبار كل "عمود" فردي طبقة يمكن النقر عليها ، على سبيل المثال) ولكنني أعتقد أن ذلك منطقي للغاية.

نعم ، في الوقت الحالي ، تقدم الكتلة الفرعية _column_ بعض تحديات واجهة المستخدم. على سبيل المثال ، لا يمكنك إدراج كتلة قبلها ، فلماذا يمكنك تحديدها؟ إنه تحد تقني صعب للغاية ، وأنا أفهم التحديات التي ينطوي عليها. لذلك لا أقترح أن هذا سهل.

عندما كنت أعمل على https://github.com/WordPress/gutenberg/pull/9653 ، أدركت أن التنقل باستخدام مفتاح السهم الموجود لدينا بالفعل للتنقل في التسلسل الهرمي (استخدم مفتاح السهم لأعلى عند تحديد عمود لتحديد الأصل ، أي كتلة الأعمدة) تعمل بشكل جيد. حسنًا في الواقع ، ربما يكون مجرد عرض هذه الميزة كزر "أعلى" ، على غرار "الانتقال إلى المجلد الرئيسي" في مستكشف ملفات Windows ، قد يكون كافيًا بدلاً من مسارات التنقل الكاملة.

إليك كيف يمكن أن يبدو ذلك. شريط الأدوات العلوي:

شريط أدوات الحظر:

CC: youknowriad

بعض الأفكار

فتات الخبز

يعجبني حل مسار التنقل ، لكنه يعاني من الغموض ، ويمكن أن تكون واجهة الأيقونة فقط مشكلة ويمكنني أن أرى نفسي أحوم فوق الرموز لأرى ما هي عليه ، أو مربكًا في فتات التنقل لشريط أدوات من الخيارات بدلاً من فتات التنقل.

لذلك ربما لا يكون شريط الأدوات العلوي هو أفضل مكان لعرضه ، وربما تساعد بعض الإشارات من فتات الخبز في أماكن أخرى. على سبيل المثال ، شريط أدوات التسلسل الهرمي في PHPStorm الذي يعرض الملف -> class -> الطريقة / الوظيفة التي تعمل بها حاليًا ، أو شريط أدوات المجلد في MacOS Finder و Windows Explorer؟

انقر من خلال

سيكون النقر فوق واجهة مستخدم مخفية ، يمكنني رؤية الكثير من سوء الفهم والارتباك حيث يتوقع الناس تحديد كتلة صورة فقط للعثور على كتلة العمود المحتوية محددة. عادةً ما يكون النقر فوق واجهة المستخدم في برنامج Adobe أمرًا مربكًا لأنه يقدم أوضاعًا ، ومن الصعب معرفة مكانك وكيفية الخروج منه ، خاصةً إذا كان هناك تداخل. على سبيل المثال ، إذا نقرت نقرًا مزدوجًا لإدخال كتلة فرعية ، كيف يمكنك العودة إلى الكتلة الأصلية وكيف تشير واجهة المستخدم إلى أنك داخل كتلة؟

هناك الكثير من الأبحاث والإرشادات حول الأوضاع ، ولا ينبغي اعتبار شيء ما جيدًا لأنه موجود في Illustrator أو Photoshop ، هناك الكثير من العمل الذي يجب القيام به بدلاً من النقر فقط قبل أن يصبح حلاً مناسبًا.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

هذا يتجاهل جميع عوامل إمكانية الوصول التي يعبث بها هذا أيضًا.

الزر العلوي

فكرة الزر العلوي جميلة. ما يقلقني هو أنه يعني أنه إذا ضغطت عليه ، فسيظهر زر لأسفل وستتحرك الكتلة لأعلى ، فهي غامضة وتعاني من نفس المشكلات التي واجهتها كتلة فتات الخبز

نمط الكتل القابلة لإعادة الاستخدام

في الوقت الحالي ، تحتوي الكتل القابلة لإعادة الاستخدام بالفعل على نمط واجهة مستخدم يضيف الكروم إلى واجهة الكتلة غير المرئية في الواجهة الأمامية. ألا تستطيع الأعمدة أن تفعل الشيء نفسه؟

أو نموذج بالحجم الطبيعي للقمامة لما أعنيه

وبالتالي ، فإن الكروم الخاص بكتلة الأعمدة هو ما يتم استخدامه لتحديده ، ويوفر شيئًا مرئيًا لتوجيه الماوس إليه.

أحد أنماط UX المحتملة التي يمكننا استخدامها هنا والتي تتناسب مع نموذج شريط الأدوات لدينا هو زر اجتياز مجلد OS X: https://cld.wthms.co/avtQLO

أود أن أشير إلى أنني أعتقد أن المستخدمين يتوقعون أن يكونوا قادرين على تحديد كتل الأطفال / الوالدين بشكل مرئي من خلال النقر والاختيار ، ولكن من الواضح أن هناك الكثير من التعقيد في الحصول على هذا الحق. قد يكون نمط الاجتياز أعلاه خطوة أولى جيدة ويمكننا الغوص بشكل أعمق في تطوير حل أكثر أناقة في المرحلة 2.

أنا _أدوري_ هذا المفهوم Alexis ، خاصة بالنسبة للكتل الأكثر تعقيدًا كما ذكرت. أحبه كثيرًا ، فقد جريت معه على الفور وأعدت خلط بعض النماذج بالأحجام الطبيعية لتوضيح فكرتك.

لا اختيار:

تم تحديد الكتلة:

كتلة متداخلة داخل المحدد:

تم فتح النافذة المنبثقة لزر اجتياز المجلد:

☝️ أنا مغرم بهذا المفهوم نوعًا ما ، يبدو أنه يذوب معًا كل الأفكار والتعليقات التي تمت مشاركتها على هذا الموضوع ، مما يجعله خطًا أساسيًا صلبًا للتكرار منه. شكرا جزيلا لجلب هذا المنظور الجديد!

أحب القائمة المنسدلة مع الشجرة المرئية ، يعتقد جزء مني أن رؤية المستند بأكمله بهذا التنسيق سيكون مفيدًا أيضًا ، بل إنه يوفر طريقة مفيدة لإعادة ترتيب الأشياء.

ومع ذلك ، عند إجراء مزيد من التفكير ، تم تذكيرنا بأن لدينا بالفعل آلية اختيار مثل هذه ، ومخطط مستند في لوحة المعلومات:

يمكن تحسين هذا من خلال التصميم في النموذج الخاص بك ، ويكون بمثابة دلالة اختيار إضافية. في الوقت الحالي ، يعرض فقط العناوين ، ولكن سيكون الإصدار مع شجرة الكتل الكاملة ، ومؤشر التحديد مفيدًا للغاية

تأملي الوحيد هو رمز شريط الأدوات نفسه. إنه رمز لغز آخر به سهم ، وهو زر غير موجود في Finder على نظام MacOS افتراضيًا إلا إذا قمت بتخصيص شريط الأدوات. بالنسبة لأولئك الذين يعانون من عمى الأيقونات وغير قادرين على التمييز بين الرموز بسهولة ، فإن الأمر يمثل مشكلة

مع تسمية النص ، يكون الأمر أكثر وضوحًا ، لكن بدونه لن يعرف معظم الناس ما فعلته دون النقر فوقه:

يبدو جيدًا :) هل يمكننا محاولة تبسيط الرمز قليلاً لوضوح أفضل؟ ربما 3 أسطر مع تباعد أكثر قليلاً بدلاً من 4؟

مع تسمية النص ، يكون الأمر أكثر وضوحًا ، لكن بدونه لن يعرف معظم الناس ما فعلته دون النقر فوقه.

سيكون هناك تلميح أداة أيضًا.

في رد: تعليق tomjn ، أعتقد أيضًا أنه سيكون من المفيد استكشاف ما إذا كان من الممكن دمج ذلك في شجرة المستندات الإجمالية بدلاً من إنشاء مكان منفصل. يكمن التحدي في الحفاظ على بساطة الشجرة وإمكانية مسحها ضوئيًا مع استيعاب المزيد من مستويات الأشياء. ولكن ربما يمكن أن يصبح ذلك أشبه بلوحة الطبقات في Sketch أو Photoshop (في الوظيفة ، وليس التصميم!) ، حيث يكون المصدر الوحيد للحقيقة لبنية الصفحة بأكملها. من الصعب القيام بعمل جيد ، ولكن ربما يستحق الاستكشاف؟

مرة أخرى ، من المحتمل أن يكون هذا شيئًا نكرره ، فما هو أفضل لاعب يمكن أن يتطور إلى شيء أكثر تعقيدًا؟

سيكون هناك تلميح أداة أيضًا.

لا أعتقد أن هذا كافٍ ، لكنني أعتقد أن هذه مناقشة منفصلة وطلب ميزة ، سأفتح تذكرة جديدة

هل يمكننا محاولة تبسيط الرمز قليلاً لوضوح أفضل؟ ربما 3 أسطر مع تباعد أكثر قليلاً بدلاً من 4؟

أحب ذلك:

ومع ذلك ، عند إجراء مزيد من التفكير ، تم تذكيرنا بأن لدينا بالفعل آلية اختيار مثل هذه ، ومخطط مستند في لوحة المعلومات:

أعتقد أيضًا أنه سيكون من المفيد استكشاف ما إذا كان من الممكن دمج ذلك في شجرة المستندات الكلية بدلاً من إنشاء مكان منفصل.

أعتقد أن هذا يمكن أن ينجح. لقد اقترحت سابقًا أنه يمكن إعادة كتابة العنصر كمكوِّن إضافي بحيث يظهر على اليمين (انظر # 4287). لكني معجب بإعادة تخصيص هذا لشجرة المستندات.

فيما يتعلق بالتسمية ، أحب الملصقات ، لكن خيار إرساء شريط أدوات الكتلة في الأعلى يحتاج إلى النظر فيه في ضوء ذلك.

يذكرني هذا النقاش بـ # 9053 (CC:westonruter) - أعتقد أنك قد تعجبك اقتراح Alexis كما هو موضح في https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989.

من الرائع رؤية هذا يتقدم وشكرًا على مفهومalexislloyd. jasmussen أنا أحب هذه

إذن ما هو أفضل لاعب يمكن أن يتطور إلى شيء أكثر تعقيدًا؟

أود أن أقول إن إنشاء هذا كعنصر تحكم اجتياز أبسط ، والنظر لاحقًا لمعرفة ما إذا كان من المنطقي الدمج مع مربع محتوى المستند بناءً على التحديد.

حسب المناقشة في # 10767 ، إعادة فتح هذا للتكرار.

راجع أيضًا الأفكار الإضافية المقترحة في # 11159.

تتمثل إحدى الأفكار الإضافية لتسهيل العمل مع الكتل المعقدة في تذكر أن _ الكتلة غير المحددة عبارة عن معاينة _ ويمكن للكتلة المحددة أن تعرض عناصر تحكم إضافية في التحرير_.

يمكننا الاستفادة من هذه الفكرة لتسهيل تحديد عناصر كتلة الأعمدة. على سبيل المثال ، عند تحديد كتلة أعمدة ، أو أي فرع منها ، يتم تحريك الحشوة الموجودة على الحاوية لإفساح المجال لتحديد العناصر الفرعية. سيؤدي هذا أيضًا إلى تسهيل الوصول إلى واجهة المستخدم الجانبية. نرغب في إظهار حد حول الكتلة الأصلية - تلك ذات المساحة المتروكة - على سبيل المثال خط متقطع.

يبدو أن هذا سيكون تافهًا نسبيًا للتنفيذ ، إذا استعدنا فئة .is-selected في كتلة المستوى الأعلى حتى عند اختيار طفل. لقد فعلنا هذا باستخدام خاصية hasSelectedInnerBlocks منذ فترة.

هذا ما نراه عند التمرير فوق خلية في كتلة عمود:

التمرير فوق خلية في كتلة الوسائط والنص.

يرى المرء الكتلة الداخلية والكتلة الخارجية.
مثل العمود -> فقرة. العمود -> يوتيوب. الوسائط والنص -> YouTube

سيكون من الجيد جعل معلومات فتات الخبز (الكتل الداخلية والخارجية) في معلومات التمرير قابلة للنقر. انقر فوق العمود لتحديد الأصل أو انقر فوق فقرة لتحديد الطفل.

بتجربة هذا الآن ، هناك شيء واحد لاحظته هو أن أبسط طريقة لتحديد كتلة عمود أصل هي استخدام منطقة النتائج غير المرئية الإضافية التي نقدمها على يمين / يسار الكتلة الأصلية:

منطقة الإصابة الإضافية هذه غير متوفرة في الجزء العلوي والسفلي من الكتلة ، مما يجعل تحديد هذه الطريقة أكثر صعوبة.

تتمثل إحدى الأفكار الإضافية لتسهيل العمل مع الكتل المعقدة في تذكر أن الكتلة غير المحددة عبارة عن معاينة ، ويمكن للكتلة المحددة إظهار عناصر تحكم إضافية في التحرير

يمكننا الاستفادة من هذه الفكرة لتسهيل تحديد عناصر كتلة الأعمدة. على سبيل المثال ، عند تحديد كتلة أعمدة ، أو أي فرع منها ، يتم تحريك الحشوة الموجودة على الحاوية لإفساح المجال لتحديد العناصر الفرعية. سيؤدي هذا أيضًا إلى تسهيل الوصول إلى واجهة المستخدم الجانبية. نرغب في إظهار حد حول الكتلة الأصلية - تلك ذات المساحة المتروكة - على سبيل المثال خط متقطع.

لست متأكدًا بنسبة 100٪ مما إذا كان هذا هو ما يقترحهjasmussen أعلاه ، ولكن إضافة بعض الحشو + مؤشر مرئي

عندما يخرج شخص ما من الكتلة ، يمكن أن تختفي تلك الحشوة الإضافية لإظهار تمثيل أكثر دقة للكتلة.

منطقة الإصابة الإضافية هذه غير متوفرة في الجزء العلوي والسفلي من الكتلة ، مما يجعل تحديد هذه الطريقة أكثر صعوبة.

كان بإمكاني أن أتحدث عن وجود تذكرة حول هذه المشكلة ، والتي تتعلق بكيفية عمل أداة إدراج الأخوة أيضًا. لا يمكنني العثور عليه الآن ، لكنني أعتقد أن هذه المشكلة يجب أن تكون قابلة للحل. aduth رنين أي أجراس ، يمكنني أن أقسم أنك كنت في التعليقات؟

لست متأكدًا بنسبة 100٪ مما إذا كان هذا هو ما يقترحهjasmussen أعلاه ، ولكن إضافة بعض الحشو + مؤشر مرئي

هذا هو بالضبط ما قصدته بشكل أو بآخر ، فقط تصوريه بشكل أكثر جمالًا مما أستطيع.

إليك رسمًا إضافيًا لقلم تلوين لتوضيح ما أعنيه. كتلة الأعمدة:

في الأساس ما لديك ، Kjell - ربما مع كون الخط المتقطع أغمق قليلاً. أيضًا ، اعتمادًا على مدى التطوير الإضافي لكتلة الأعمدة ، تذكر أن هناك أيضًا كتل عمود. أي أن التسلسل الهرمي حاليًا هو _Columns → Column → Image_. نحن نستخدم معالجات CSS الشرسة لجعل المستوى الثاني غير مرئي أكثر أو أقل ، ولكن في حالة رغبتك في تحديد ذلك في المستقبل ، على سبيل المثال ، لتطبيق فئة CSS عليه أو أي خيارات أخرى قد نحتاجها للأعمدة الفردية ، هذا يستحق النظر.

كتلة عرض الشرائح:

لكي نكون واضحين: لم يتم التخطيط لأي كتلة لعرض الشرائح. هذا رسم خربش بحت لتوضيح نقطة يمكن أن تكون فيها أوضاع المعاينة والتحرير للكتلة مختلفة تمامًا. من السهل جدًا وغير المثير للدهشة التبديل بين الوضعين عن طريق اختيار وإلغاء تحديد الكتل ببساطة ، بحيث يجب أن نسمح لأنفسنا بالاستناد إليها والإبداع في الفرص.

في حالة كتلة عرض الشرائح ، بحكم التعريف تقريبًا ، سيكون المحتوى غير مرئي خارج الشاشة / الكتلة. لكن لا يجب أن يكون الأمر كذلك أثناء تحريره. ما عليك سوى تحديد الكتلة لمشاهدة الصور المصغرة ذات التسميات التوضيحية القابلة للتعديل. ثم قم بإلغاء تحديد الكتلة لمعاينة النتيجة.

كان بإمكاني أن أتحدث عن وجود تذكرة حول هذه المشكلة ، والتي تتعلق بكيفية عمل أداة إدراج الأخوة أيضًا. لا يمكنني العثور عليه الآن ، لكنني أعتقد أن هذه المشكلة يجب أن تكون قابلة للحل. aduth رنين أي أجراس ، يمكنني أن أقسم أنك كنت في التعليقات؟

أعتقد أن أقرب شيء قد يكون واحدًا من # 8883 ، # 8881 ، # 5180؟

على الرغم من أن شجرة المستندات مفيدة ، إلا أنها لا تزال تتطلب مني تغيير التركيز عما أحاول التلاعب به. أرغب حقًا في طريقة أفضل للنقر عبر الكتل الفعلية والكتل المتداخلة مباشرةً. أعتقد أن طريقة النقر الموضحة أعلاه بواسطة jasmussen تستحق استكشاف المزيد.

هذه هي المشكلة التي أواجهها عادة:

بصفتي مستخدمًا ، سأقاتل مع هذا لمدة دقيقة على الأقل قبل إيجاد حل آخر موجود في مكان آخر على الشاشة. 😉

* _عندما أضفت هذا التعليق ظهرت مجموعة من التعليقات الأخرى. قد لا يكون الأمر ذا صلة الآن ، لكني أحتفظ به هنا لتوثيق النضال.

ولكن إضافة بعض المساحة المتروكة + مؤشر مرئي للكتلة الرئيسية أثناء وجودك في وضع التحرير قد يكون مفيدًا هنا. بهذه الطريقة ، هناك إشارة واضحة للمكان الذي يجب أن تنقر فيه إذا كنت تريد تحديد الوالد:

ما يشغلني بهذا الحل هو كيفية عمل الحشو فيما يتعلق بالكتل المحيطة:

1. هل الحشو في الكتلة الأصلية ينعكس على الواجهة الأمامية؟ أو مجرد مزيد من المساحة المتروكة في المحرر؟

2. هل تتم إضافة الحشو ديناميكيًا عند تحديد الكتلة ، مثل هذا؟

1. أو ربما يظهر الوالد المبطن فوق الكتل المحيطة به ، هكذا؟

مجرد محاولة التعمق في هذا المفهوم. سوف أحب بعض الأفكار حول ذلك.

شكرًا aduth ، لقد جعلتني أجد تذكرة على الأقل تسير في الاتجاه الصحيح. يوضح GIF في # 9229 المشكلة: المنطقة الصفراء في ملف GIF هذا "محجوزة" لمصمم الأخوة. هذا هو ما يمنعك من تحديد الكتلة بالنقر فوق المساحة المتروكة أعلى أو أسفل الكتلة. هذا هو الرد على تعليق kjellr :

منطقة الإصابة الإضافية هذه غير متوفرة في الجزء العلوي والسفلي من الكتلة ، مما يجعل تحديد هذه الطريقة أكثر صعوبة.

لمزيد من التوضيح ، هذه المنطقة الصفراء موجودة فقط لجعل زر إدراج الأخوة مرئيًا. لذلك كل ما نحتاج إلى اعتراضه ، حقًا ، هو إجراء التمرير. سيكون من الرائع أن تنتشر نقرة عبر هذا الشريط الأصفر وتتيح لك تحديد الكتلة أدناه.

على الرغم من أن شجرة المستندات مفيدة ، إلا أنها لا تزال تتطلب مني تغيير التركيز عما أحاول التلاعب به. أرغب حقًا في طريقة أفضل للنقر عبر الكتل الفعلية والكتل المتداخلة مباشرةً. أعتقد أن طريقة النقر الموضحة أعلاه بواسطة jasmussen تستحق استكشاف المزيد.

يمكنك بالفعل اختبار هذا الآن ، حتى لو كان التنفيذ الحالي نصف مخبوز قليلاً.

• قم بتشغيل Gutenberg ، أي إصدار.
• أدخل كتلة أعمدة مع المحتوى.
• قم بتغيير حجم النافذة إلى أقل من 600 بكسل ، ثم حدد.

يتم تنفيذ هذا للجوال ، بمعنى آخر ، للسماح لك بتحديد الكتلة الأصلية بسهولة أكبر.

GIF:

تكمن مشكلة التنفيذ الآن في إعادة تعيين "الحالة" بمجرد الانتقال إلى المستوى الأعمق. لذلك فهي أعمدة> عمود> فقرة ، أعمدة> عمود> فقرة ، حتى لو كنت تحدد نفس الفقرة مرتين. الحل الواضح لهذه المشكلة التي يجب تجربتها هو جعلها بحيث بمجرد أن "تنتقل" إلى المستوى الذي تريده ، تبقى في هذا المستوى حتى تقوم بإلغاء تحديد الكتلة مرة أخرى. أي أعمدة> عمود> فقرة ، فقرة ، فقرة ، إلغاء التحديد ، الترجيع ، إلخ.

أعتقد أيضًا أنه بالنسبة لبعض الكتل ، ستكون طريقة النقر هذه مهمة للغاية. خاصة عندما نبدأ في إلقاء نظرة على قوالب الصفحات التي قد تتضمن جميع أنواع المحتوى المتداخل.

يمكن أيضًا تجربة مصدر إلهام لكيفية عمل النقر عندما يكون رائعًا في Keynote. أدخل بعض الأشكال ويمكنك النقر فوقها مباشرة. بمجرد تجميع شكلين ، يصبحان شكلاً جديدًا يسهل تحريكهما. لكن لتحرير محتوى المجموعة ، عليك النقر نقرًا مزدوجًا.

للإجابة على أسئلتك الجيدة في https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172:

هل الحشو في الكتلة الأصلية ينعكس على الواجهة الأمامية؟ أو مجرد مزيد من المساحة المتروكة في المحرر؟

لا ، هذه المساحة المتروكة موجودة فقط في المحرر وفقط عند تحديد _block_. يعتمد هذا على الكتلة هي مبدأ

• الكتلة غير المحددة هي المعاينة. يجب أن تبدو الواجهة الأمامية قدر الإمكان
• الكتلة المحددة هي أساسًا "وضع تحرير الكتلة" ، ويمكن للكتلة إخراج عناصر تحكم إضافية وحتى تبدو مختلفة تمامًا ، في هذه الحالة.

هذا ما حاولت تسليط الضوء عليه باستخدام المثال أعلاه لكتلة عرض الشرائح: عندما تكون كتلة عرض الشرائح غير محددة ، يكون عرض الشرائح. عند تحديده ، تكون في _ وضع تحرير عرض الشرائح_ وترى شبكة مصغرة لكل شريحة ، بحيث يمكنك بسهولة تعديل التسميات التوضيحية وإعادة الترتيب وما إلى ذلك.

هل تتم إضافة الحشو ديناميكيًا عند تحديد الكتلة ، مثل هذا؟

نعم أكثر أو أقل.

أعتقد أن هذا قد يستحق وضع نماذج أولية لشرحها بشكل أفضل والتعرف عليها.

في النهاية ، يجب أن تكون هذه الميزة على الأرجح دعامة على الكتلة نفسها ، شيء يمكن للكتلة الاشتراك في استخدامه. على سبيل المثال ، من المحتمل ألا يستخدم اقتباس الكتلة الذي يحتوي على فقرات متداخلة هذه الواجهة - ولكن عند تحرير الأعمدة ، قد يكون نوعًا ما مثاليًا.

إليك نموذجًا أوليًا سريعًا لرمز الشفرة: https://codepen.io/joen/pen/exmMQv؟

إنه ثابت نوعًا ما ، لكن نأمل أن يحصل على هذه النقطة.

إليك نموذجًا أوليًا سريعًا لرمز الشفرة: https://codepen.io/joen/pen/exmMQv؟

إنه ثابت نوعًا ما ، لكن نأمل أن يحصل على هذه النقطة.

هذا يساعد حقًا في إيصال النقطة. لقد أجريت تعديلاً طفيفًا ، حتى نتمكن من رؤية كيفية ظهور هذه الحدود المتقطعة عند النقر:

https://codepen.io/kjellr/pen/jdEJQb؟editors=0110

هذا مثالي ، شكرا لك كجيل! هذا بالضبط ما أعنيه. أعتقد أننا ربما نرغب في ضبط بعض الجوانب في التنفيذ ، ومعالجة كيف يبدو الأمر عندما يكون الوالد المباشر (العمود المفرد) هو الذي يحصل على الحشو. لكن هذا رائع! أعتقد أنه يمكن أن يعمل.

أنا حقا أحب هذا.
هل يجب أن ننتقل إلى إنشاء علاقات عامة للاختبار مع المزيد من الكتل والمحتوى؟
هل نحتاج إلى تحديد الكتل التي ستؤثر؟

أنا أحفره أيضًا.

من المحتمل أن نتمكن من وضع نموذج أولي لهذا على كتلة الأعمدة في الوقت الحالي ، ولكن من أجل الهبوط ، ربما نحتاج إلى أن تكون هذه الطريقة عامة ، لذا يمكن للكتل الأخرى (كما تقول) استخدام هذا ، ولكن أيضًا دعامة حتى يمكن للكتلة اختر الاشتراك في هذا. من المحتمل أن يكون هذا الأمر مزعجًا لكتلة عرض الأسعار ، بمجرد أن تتلقى الكتل المتداخلة.

gziolo أي أفكار؟ لا سيما على النهج الذي رسمه كجيل في https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415

gziolo أي أفكار؟ لا سيما على النهج الذي رسمه Kjell في # 9628 (تعليق)

تبدو رائعة. سيجعل من الممكن أخيرًا تحديد الكتلة الأصلية بسهولة عند الحاجة. سؤالي الوحيد هو كيف ستشعر حيال جعل عرض العمود أقرب إلى الحجم الأصلي على حساب جعل الأعمدة الأخرى أضيق. في الوقت الحالي ، تتقلص جميع الأعمدة عندما يتم تحديد أحدها مما قد يكون تجربة دون المستوى الأمثل عند وجود أكثر من 3 أعمدة. jasmussen هل لديك أسئلة أخرى ، يجب أن أجيب؟

سؤالي الوحيد هو كيف ستشعر حيال جعل عرض العمود أقرب إلى الحجم الأصلي على حساب جعل الأعمدة الأخرى أضيق.

أميل إلى الموافقة على أن هذا شيء يجب أن نضبطه ونوازنه ، ربما في التنفيذ. يمكننا أيضًا النظر في توسيع عرض / ارتفاع الوالد ، حتى لا يتم تقليل حجم الطفل ، على الرغم من أن هذا قد يكون أكثر صعوبة من الناحية الفنية.

هل لديك أسئلة أخرى يجب أن أجيب عليها؟

الواجهة التي نناقشها هنا بشكل أساسي هي: إضافة حشوة إلى الكتلة الأصلية عند تحديد الكتلة الفرعية ، لتسهيل التحديد . يبدو هذا جيدًا في نموذج Kjell الأولي لكتلة الأعمدة. من المحتمل أن يكون موضع ترحيب كبير في الكتل الأخرى ، مثل كتل القسم ، أو العديد من الكتل الأخرى حيث من المحتمل أن يملأ المحتوى التابع كل المساحة المتاحة بالداخل. ولكن من المحتمل ألا يكون هذا لطيفًا بالنسبة لشيء مثل مجموعة الاقتباس ، والتي من المسلم به أنها لا تستخدم التعشيش حتى الآن ولكن من المحتمل أن تفعل ذلك في المستقبل.

لذلك سيكون من الجيد بناء واجهة تحديد الوالدين هذه بطريقة كانت _ Generic_ لجميع الكتل ، _ off افتراضيًا_ ، ولكن شيئًا ما يمكن للكتلة الاشتراك فيه باستخدام prop.

هل لديك أي اقتراحات حول أفضل طريقة للتعامل مع ذلك؟

جميع الكتل التي تحتوي على كتل متداخلة (الأعمدة والوسائط والنص في الوقت الحالي) تجعل هذا المكون InnerBlocks الذي يعرض فئة .editor-inner-blocks :
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
قد يساعد هذا في التوصل إلى حل عام يعمل مع جميع الكتل المتداخلة. ومع ذلك ، قد يكون الأمر صعبًا حيث يتم تطبيق .is-selected في أحد العناصر الفرعية.

Edit: إذا لم يعمل مع CSS حصريًا. يمكننا دائمًا العثور على طريقة لتحديث حالة الأصل لفضح المعلومات التي تم تحديد إحدى الكتل المتداخلة فيها. قد يكون لدى jorgefilipecosta و aduth المزيد من الأفكار حول ذلك حيث أمضوا الكثير من الوقت مع الكتل المتداخلة :)

لذلك سيكون من الجيد إنشاء واجهة تحديد الوالدين هذه بطريقة عامة لجميع الكتل ، بشكل افتراضي ، ولكن يمكن للكتلة أن تختار استخدام الدعامة.

ما الكتل التي تعتبرها لهذا النهج والتي لا تستخدم التعشيش؟ جعلني هذا أفكر لماذا لا يستخدمون التعشيش في المقام الأول؟ تخيل أننا قمنا بتحويل المعرض إلى حاوية بها كتل صور متداخلة. سنحصل على هذا السلوك مجانًا ولكن يتم التصنيف أيضًا كمكافأة.

ما الكتل التي تعتبرها لهذا النهج والتي لا تستخدم التعشيش؟

المعرض مثير للاهتمام.

بصراحة ، أفكر في الغالب في كتل تخطيط أكثر تقدمًا ، مثل كتل تخطيط الشبكة ، أو كتل Tabgroup ، أو كتل أخرى مشابهة لـ "إنشاء الصفحات". من المحتمل ألا يستخدم أي شيء خاص بالمحتوى هذه الواجهة.

بصراحة ، أفكر في الغالب في كتل تخطيط أكثر تقدمًا ، مثل كتل تخطيط الشبكة ، أو كتل Tabgroup ، أو كتل أخرى مشابهة لـ "إنشاء الصفحات". من المحتمل ألا يستخدم أي شيء خاص بالمحتوى هذه الواجهة.

أتوقع أن يكون كل منهم مناسبًا لفئة كتل الحاوية ، مما يعني أنه يجب عليهم استخدام InnerBlocks كتفاصيل تنفيذ وبالتالي يجب أن يتناسب مع هذه الفئة. لا يزال بإمكاننا تقديم إلغاء الاشتراك مشابهًا لكيفية قيامنا بذلك للميزات الأخرى مع مجموعة supports في تعريف الكتلة.

أتوقع أن تكون جميعها مناسبة ضمن فئة كتل الحاوية ، مما يعني أنه يجب عليهم استخدام InnerBlocks كتفاصيل تنفيذ وبالتالي يجب أن يتناسب مع هذه الفئة

ولكن ألن تستخدم كتلة الاقتباس أيضًا الكتل الداخلية إذا / عندما تلقت ميزات متداخلة؟

ولكن ألن تستخدم كتلة الاقتباس أيضًا الكتل الداخلية إذا / عندما تلقت ميزات متداخلة؟

نعم ، اقتباس ، قائمة ، غلاف - تم اعتبار هذه العناصر الثلاثة قد تم تحويلها إلى كتل متداخلة في الماضي.

أحد المخاوف (التي لا ينبغي أن تمنع التجريب ، ولكن جدير بالذكر!) هو أن هناك بالفعل بعض المشكلات مع كتل الأعمدة من حيث مدى ضيقها وكيف يؤثر ذلك على أدوات وضع التحرير. سيؤدي هذا الاقتراح إلى جعل الأعمدة - أضعف - بشكل فعال أثناء تفاعلات التحرير ، مما قد يؤدي إلى ظهور مشاكل ضيق هذه الأعمدة.

كما أنه يدفع أكثر من تكافؤ تعديل / عرض 1 إلى 1 ، والذي قد يكون مصدر قلق أو لا. من المسلم به أنني أفعل شيئًا مشابهًا لهذا (الحشو الإضافي عند التحديد) على كتلة مخصصة باستخدام InnerBlocks ، وهي تعمل بشكل جيد - ولكنها تعني أن عرض التحرير ليس دقيقًا تمامًا.

لذلك سيكون من الجيد إنشاء واجهة تحديد الوالدين هذه بطريقة عامة لجميع الكتل ، بشكل افتراضي ، ولكن يمكن للكتلة أن تختار استخدام الدعامة.

قد تكون القدرة على الاشتراك في شيء مثل هذا أمرًا رائعًا عند إنشاء كتلة Jetpack Form.

كما أنه يدفع أكثر من تكافؤ تعديل / عرض 1 إلى 1 ، والذي قد يكون مصدر قلق أو لا.

أعتقد أنه من الجيد إجراء بعض التغييرات بين الحالات المحددة وغير المحددة ، خاصةً إذا كان ذلك يجعل تجربة المستخدم أفضل ... على الرغم من أنه يمكن مناقشة هذا فيما يتعلق بالكتل الداخلية الآن.

ماذا يحدث أيضًا عندما يكون لدي كتل متداخلة بعمق 3؟ هل يمتد خيار الحشو إلى المستوى الثاني إذا كان المستوى الثاني عبارة عن كتلة رئيسية أيضًا؟

mapk

ماذا يحدث أيضًا عندما يكون لدي كتل متداخلة بعمق 3؟ هل يمتد خيار الحشو إلى المستوى الثاني إذا كان المستوى الثاني عبارة عن كتلة رئيسية أيضًا؟

يبدو أن الحشو لجميع مستويات التداخل المتأثر يبدو وكأنه قد يتسبب في زيادة الحجم الكبير والنقصان عند اختيار الكتل المتداخلة بعمق ، على سبيل المثال فقرة في اقتباس في عمود في صف في قسم. من الناحية المثالية ، لا ينبغي أن يؤدي اختيار كتلة إلى تغيير مظهر كل كتلة أخرى بشكل جذري ، لذا فإن مجرد تغيير التباعد بين والدها المباشر يبدو كافيًا بالنسبة لي.

طالما أنه يمكنك تحديد الوالد المباشر ، فستتمكن من شق طريقك في التسلسل الهرمي ، لأن اختيار الوالد سيؤدي إلى جعل والده قابلاً للتحديد بسهولة ، وهكذا. يمكن استخدام قائمة Block Navigation للوصول بشكل أسرع ، وكما اقترح البعض من قبل ، يمكن تحويلها إلى شريط جانبي قابل للربط بحيث يمكن الوصول إليه بسرعة. (انظر # 11408 و # 11688.)

أود أن أقترح في أي وقت أن يؤثر تغيير الحشو على الكتلة المحددة والأحفاد المباشرة.

فقط في حالة تأثير هذا على هذا العمل ، من فضلك هل يمكنني أن أوضح سريعًا أن العمل الذي آمل أن يهبط لإضافة محاذاة رأسية إلى كتلة الأعمدة يجعل الأعمدة _ الفردية_ قابلة للتحديد (لم تكن قابلة للتحديد في السابق)

https://github.com/WordPress/gutenberg/pull/13899

العمل الذي آمل في الوصول إليه لإضافة محاذاة رأسية إلى كتلة الأعمدة يجعل الأعمدة الفردية قابلة للتحديد (في السابق لم تكن قابلة للتحديد)

شكرا لملاحظة ذلك هنا. هذا سبب إضافي لتنظيف هذا التفاعل عاجلاً وليس آجلاً.

أردت فقط مشاركة شيء ناقشته مع jasmussen في وقت سابق اليوم ، بخصوص حدود الكتلة.

يظهر هذا قليلاً في بعض النماذج بالأحجام الطبيعية أعلاه ، ولكن من الجدير بالذكر صراحةً: بالإضافة إلى الحشو الإضافي الذي نناقشه هنا ، أعتقد أن التنقل الداخلي بالكتلة + التحديد سيكون أسهل بكثير إذا كنا واضحين بشأن بنية الكتل بشكل عام. تحقيقا لهذه الغاية ، أعتقد أن اعتماد مستويين من التسلسل الهرمي للحدود سيكون ممتازًا. فمثلا:

في هذا المثال ، أستخدم حدًا غامقًا للحالة المركزة. إذا كانت الكتلة عبارة عن كتلة أصل أو كتلة فرعية ، فقد قمت بتضمين حد خفيف منقط (بالإضافة إلى بعض الحشو الإضافي) حول العناصر الأخرى ذات الصلة. يساعد هذا المستخدمين على تصور مكانهم بوضوح في التسلسل الهرمي للكتل ، مع منحهم أيضًا إحساسًا واضحًا بالمكان الذي يمكنهم النقر عليه لتحديد الكتل المتداخلة الأخرى.

@ kjellr أحب ذلك حقًا. هذا يجعل من الواضح للغاية ما هو الهيكل.

ومع ذلك ... أعتقد أننا واجهنا مرة أخرى مشكلة تتعلق بالتباين على الخط المنقط. لا أستطيع أن أقول على وجه اليقين ولكن شكوكي هو أن إدخال الخط المنقط يعني أنه يحتاج إلى اتباع معايير إمكانية الوصول. وأعتقد أن جعل التباين أعلى بكثير سيؤدي على الأرجح إلى بعض الثقل البصري الذي قد ينفي الفوائد ...

مجرد التفكير بصوت عال قليلا. أحب المظهر حقًا كمستخدم حسن النظر ، ولكن سيكون من الغريب سماع تعليقات 11y لأن رغبتي لا يكفي :)

على شاشتي ، لم أر الخط المنقط في البداية. يبدو غير مرئي عمليًا إذا كانت شاشتي مائلة قليلاً فقط.

ليست هناك حاجة لتقليل التباين كثيرًا إذا كان ذلك سيجعل الوصول إليه أقل. طالما أنه _little_ أخف وزنا ويستخدم border-style مختلفًا أعتقد أنه سيعمل بشكل جيد.

عذرًا - كان يجب أن أكون أكثر وضوحًا في تعليقي الأصلي: لقد أنشأت هذا النموذج بالحجم الطبيعي في بضع دقائق فقط أثناء التحدث إلى Joen. أعتقد أنني فقط اخترت الألوان بشكل عشوائي من بعض الألوان الرمادية التي كانت على شاشتي في ذلك الوقت. 😄 لا يُقصد بالظلال الدقيقة تقديم حل نهائي ، فقط نهج عام.

استجابةً للمخاوف بشأن إضافة الحشو إلى الكتلة الأصلية التي تتسبب في جعل الكتل الداخلية غير متوافقة مع الواجهة الأمامية (# 14148 # 14169) ، عملت بفكرة أخرى.

سيتطلب هذا مزيدًا من التطوير ، ولكنه قد يكون خيارًا جيدًا.

بشكل أساسي ، عند النقر فوق الكتلة الأصلية ، فإنها تتوسع (تنمو أكبر من الكتل العادية) لتوفير الحشو اللازم للاختيارات السهلة للأطفال / الوالدين. هذا يحافظ على اتساق الكتل الداخلية مع الواجهة الأمامية.

سكرينكاست

نموذج InVision

https://wp.invisionapp.com/share/EGQRWRC8MFT

PROS

1. تظل الكتل الداخلية بالعرض المناسب.
2. تظل الكتل الداخلية متسقة بصريًا مع الواجهة الأمامية.
3. حجم التغيير المحدد للكتلة هو نمط مستخدم بالفعل.

سلبيات

1. يعد توسيع تحديد الكتلة (العرض) إلى ما بعد تحديدات الكتلة العادية نمطًا جديدًا.
2. لست متأكدًا من كيفية عمل ذلك عند تعيين الكتل على العرض الكامل.

بشكل أساسي ، عند النقر فوق الكتلة الأصلية ، فإنها تتوسع (تنمو أكبر من الكتل العادية) لتوفير الحشو اللازم للاختيارات السهلة للأطفال / الوالدين. هذا يحافظ على اتساق الكتل الداخلية مع الواجهة الأمامية.

حفر ذلك. أرغب في أن يظل شريط أدوات الكتلة محاذيًا للحد الأيسر ، ولكن هذه تفاصيل تنفيذية.

سيكون تحديًا على الشاشات الأصغر عندما لا يمكن أن يكبر بالفعل ، ولكن هذا أيضًا يبدو وكأنه شيء قابل للحل.

وتجدر الإشارة إلى أن هذا النهج يمكن أن يتوسع ليشمل أي كتلة تحتوي على كتل داخلية ، حتى كتلة الاقتباس التي تعد كتلة نصية أساسية بحيث يجب ألا يتم إعاقة التحديد قدر الإمكان.

حقًا ، احفر عملك حقًا ، Kjell - ليس فقط يمكنه العمل بشكل غير مرئي مع فكرة Mark ، ولكنه يساعد في إبراز بنية المستند ، - عندما تحتاج إليه - ، ولكن لا يكسر التدفق عندما تريد الكتابة فقط. إنه يبدو وكأنه اتجاه قوي ، وما نحتاجه هو مطور قوي في هذا الاتجاه التالي.

في ملاحظة التنفيذ - يمكن أن يكون للأصل المتقطع من الناحية النظرية نفس لون الكتلة المحددة ، ولكن بحكم كونه متقطعًا فإنه سيظهر ثانويًا. عند تحريك أحد الوالدين ، يمكن أن يصبح المخطط التفصيلي صلبًا ، ويمكننا أيضًا جعل _الطفل _ (الذي حددته أثناء التحويم) متقطعًا ، للمساعدة في توضيح ما سيحدث عند النقر.

في ملاحظة التنفيذ - يمكن أن يكون للأصل المتقطع من الناحية النظرية نفس لون الكتلة المحددة ، ولكن بحكم كونه متقطعًا فإنه سيظهر ثانويًا. عند تحريك أحد الوالدين ، يمكن أن يصبح المخطط التفصيلي صلبًا ، ويمكننا أيضًا جعل _الطفل _ (الذي حددته أثناء التحويم) متقطعًا ، للمساعدة في توضيح ما سيحدث عند النقر.

نعم! أعتقد أن هذا يمكن أن يعمل تمامًا أيضًا. دعونا نرى أين يوجد # 14145 شبكات ، ثم نكتشف العلاج من هناك. 👍

لقد تلاعبت أيضًا بالحدود عندما جعلت الأعمدة الفردية قابلة للتحديد ولكن تمت إزالتها باعتبارها خارج نطاق العلاقات العامة الخاصة بي. بالتأكيد شعرت بتحسن UX. أحب الطريقة التي يسير بها هذا!

مجرد تنبيه: أنا أدور الفكرة أعلاه في قضية منفصلة وموجزة للاستكشاف. تابع هنا:

https://github.com/WordPress/gutenberg/issues/14935

إذا كان بإمكان أي شخص المشاركة في إضافة فئة has-child-selected إلى مجموعات الوالدين عند اختيار طفلهم ، فهذا هو المانع الوحيد لبدء ذلك.

مشكلة ذات صلة اكتشفتها ثم اختبار كتلة المجموعة التي تم تقديمها حديثًا:

الأمر المربك في الوقت الحالي هو أنه عند إدراج كتلة المجموعة ، فإن ما تراه في الواقع هو كتلة الفقرة:

هل يمكننا على الأقل فعل شيء مثل:

أو ما اقترحه mtias في

_ هذه ليست مقترحات تصميم نهائية بأي وسيلة 😃_

gziolo هذه المشكلة يجب حلها بواسطة # 14241. أنا أتفق معك ، راجع للشغل ، لذا سيكون من الرائع شحن ذلك قريبًا :)

gziolo هذه المشكلة يجب حلها بواسطة # 14241. أنا أتفق معك ، راجع للشغل ، لذا سيكون من الرائع شحن ذلك قريبًا :)

حسنًا ، سأقول جزئيًا. عند إدراج فقرة باستخدام أداة الإدخال المخصصة الجديدة هذه ، نعود إلى المربع الأول 🤷‍♂️

أعتقد أن # 14935 سيساعد هنا أيضًا. يجب علينا أيضًا استكشاف بعض الخيارات في الشريط الجانبي للحصول على مزيد من الطرق للتأكد من أن الكتلة المحددة حاليًا متداخلة.

أه نعم. كنت أفكر في إحياء فتات الخبز في الشريط الجانبي ، كما فعلنا هنا:

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

بسيط وأنيق نسبيًا ، وسيساعد هذا الإصدار (9628) أيضًا.

إلقاء تكرار على بعض الأفكار أعلاه:

ماذا لو نقلنا تحويلات / أنماط الكتلة إلى عنصر مخصص خاص بها ، وجعلنا رمز الكتلة في لوحة "Block Tree" الخاصة بها؟

أعتقد أن هذا قد يزيد من وضوح تحويلات / أنماط الكتلة ، بينما يساعد أيضًا الأشخاص في التنقل إلى الكتل المتداخلة الأخرى بشكل أكثر وضوحًا. إليك نموذج بالحجم الطبيعي لمثال أكثر تعقيدًا:

(كلاهما يستخدمان أيضًا الخطوط العريضة / المساحة المتروكة من # 14961)

هذا يبدو مثير جدا للاهتمام Kjell! ثم يتم ربطه بمنطقة Block Navigation مما يخلق تناسقًا بينهما. عندما يتعلم المرء استخدام Block Navigation ، يمكن أن يستمر التعلم نفسه في تحديد الكتل المتداخلة.

يعجبني حقًا النموذج بالحجم الطبيعي على المستوى المفاهيمي ، لكن شيئًا ما عن التنفيذ يبدو كثيفًا بعض الشيء. لا أعلم أن لدي فكرة أفضل بالضرورة ، لكني أتساءل عما إذا كانت هناك طريقة لجعل هذا يبدو أخف قليلاً؟

أعلم أنني كافحت في محاولة العثور على مخطط سريع لبنية الكتلة الخاصة بي ، لذا فإن هذا المفهوم فكرة رائعة لحل هذا.

قلقي هنا يقلد chrisvanpatten . على الرغم من أنه مدروس جيدًا ، إلا أنه يبدو كثيرًا.

1. في بعض الكتل في سياقات معينة ، توجد طرق مختلفة لإظهار القوائم المنسدلة.

أعتقد أن إضافة شيفرون أخرى إلى المزيج (على الرغم من أنه رمادي ويواجه اليمين) قد يضيف المزيد من صعوبة التحليل.

1. مصدر القلق الآخر هو أن شريط الأدوات يزداد طولًا. ربما لا تكون هذه مشكلة كبيرة ، ولكن يمكن أن يحدث ذلك عندما نقوم بتضمين تسميات للرموز https://github.com/WordPress/gutenberg/issues/10524 و https://github.com/WordPress/gutenberg/issues/ 15311.

فقط بعض الأفكار للتأمل أثناء استكشاف هذا. قد يكون هذا هو أبسط نهج ينقل ما يجري.

أتساءل ما إذا كانت هناك طريقة لجعل هذا يبدو أخف قليلاً؟

نعم ، أعتقد أن الأمر يتعلق بنقص التسلسل الهرمي هناك. يجب أن يبدو العنصر الأول في شريط الأدوات أقرب إلى عنصر التأريض ، بينما يجب أن تشعر العناصر الأخرى بأنها خيارات ثانوية للكتلة. هناك حاجة إلى نوع من الانفصال. ليس هذا هو الحل الصحيح ، ولكن من أجل المحادثة فقط ، أعتقد أن هذا يساعد قليلاً:

في بعض الكتل في سياقات معينة ، توجد طرق مختلفة لإظهار القوائم المنسدلة. أعتقد أن إضافة شيفرون أخرى إلى المزيج (على الرغم من أنه رمادي ويواجه اليمين) قد يضيف المزيد من صعوبة التحليل.

قد يكون ذلك. من المحتمل أن تكون هناك طريقة أخرى لتمثيل هذا الأمر لا أفكر فيه أيضًا. بصراحة ، يمكن أن يكون رمز "شجرة كتلة" إضافي أكثر وضوحًا في شريط الأدوات ، يُضاف تلقائيًا لأي عنصر أصلي أو فرعي:

مصدر القلق الآخر هو أن شريط الأدوات يزداد طولًا. ربما لا تكون هذه مشكلة كبيرة ، ولكن يمكن أن يحدث ذلك عندما نقوم بتضمين تسميات للرموز # 10524 و # 15311.

متفق عليه. سواء كان هذا هو الاتجاه أم لا ، سنحتاج إلى إيجاد حل لأشرطة الأدوات الطويلة جدًا على أي حال. أعتقد أن جهودًا مثل https://github.com/WordPress/gutenberg/pull/16557 تساعد في ذلك قليلاً ، كما تفعل عمليات إعادة التفكير الأكثر شمولاً في التسلسل الهرمي لشريط الأدوات مثل https://github.com/WordPress/gutenberg/issues/ 15096.

أحد الأشياء التي لفتت انتباهي حول فكرة شجرة الكتل كزر لشريط الأدوات هو أنها فريدة نوعًا ما في كونها عنصر شريط أدوات كتلة لا يشير إلى أي شيء جوهري حول الكتلة نفسها ، وبدلاً من ذلك حول كيفية ارتباط الكتلة بـ باقي المستند.

يعد هذا تفكيرًا أكثر من أي شيء آخر ، ولكن لاستخدام تشبيه من تطبيقات الرسومات ، فإن هذا النوع من واجهة المستخدم "ذات الطبقات" و "التجميع" عادةً ما يكون (أنا متأكد من أن هناك أمثلة تثبت أنني مخطئ) موجودة فقط على مستوى _document_ بدلاً من الوصول إليها على مستوى الكتلة.

أعلم أن هناك العديد من مشكلات الوصول حول "الفجوة" بين الكتلة وأدوات مستوى المستند ، وقد يؤدي وجودها على مستوى الكتلة إلى تسهيل التنقل.

يعد هذا بمثابة تأمل أكثر من أي شيء آخر ... يبدو أن شيئًا ما بخصوص هذه الأداة يختلف بشكل ملحوظ عن الأدوات الأخرى المتوفرة في شريط الأدوات من حيث كيفية ربط الكتلة بالسياقات الأخرى.

يعد هذا بمثابة تأمل أكثر من أي شيء آخر ... يبدو أن شيئًا ما بخصوص هذه الأداة يختلف بشكل ملحوظ عن الأدوات الأخرى المتوفرة في شريط الأدوات من حيث كيفية ربط الكتلة بالسياقات الأخرى.

نعم ، لدي نفس الشعور.

لقد حصلنا على عنصر التحكم هذا في شريط الأدوات العلوي في الوقت الحالي ، والذي يبدو بعيدًا جدًا عن الكتلة نفسها. ربما الشريط الجانبي هو في الواقع أفضل مكان لذلك؟ يبدو أن عنصر التحكم تقريبًا يجب أن يكون مرتبطًا بالكتلة ، ولكن كشريط أدوات منفصل خاص به ، لكننا بالتأكيد لا نريد إضافة واحد آخر من هؤلاء. 😄

لقد حصلنا على عنصر التحكم هذا في شريط الأدوات العلوي في الوقت الحالي ، والذي يبدو بعيدًا جدًا عن الكتلة نفسها.

أود أيضًا أن أضيف أن هذا صحيح فقط في الإعدادات الافتراضية لـ Gutenberg. إذا قام شخص ما بتحديد خيار شريط الأدوات العلوي لنقل جميع أشرطة أدوات الحظر إلى شريط الأدوات العلوي ، فهذا ليس هو الحال بالتأكيد. ولكن مع ذلك ، أشك في أن غالبية المستخدمين يغيرون هذا الإعداد.

من ناحية أخرى ، أود حقًا أن أرى كيف سيكون رد فعل الأشخاص على إعداد شريط الأدوات العلوي باعتباره الإعداد الافتراضي في جوتنبرج. سيكون متوافقًا بشكل أفضل مع المحرر الكلاسيكي الذي يوفر مزيدًا من الإلمام لمستخدمي Gutenberg الجدد.

لقد تم استكشاف إعداد شريط الأدوات هذا كثيرًا وتم تسوية أفضل إعداد افتراضي بعد قليل من الاختبار. يمكنك قراءة المزيد حول الاستكشافات هنا: https://github.com/WordPress/gutenberg/issues/2983.

أشك في أن غالبية المستخدمين يغيرون هذا الإعداد.

اتضح أن موضع شريط الأدوات هو إعداد شخصي بشكل لا يصدق. لقد جاء ذلك خلال المرحلة الأولى من اختبار أن أولئك الذين بدأوا في استخدام WordPress يفضلون من قبل الكتلة ، أولئك الذين يتمتعون بالخبرة في المقدمة. لقد تعثر شريط الأدوات في كلا المكانين وهذا ما لدينا الآن هو أفضل الخيارات. أيضًا ، ربما يكون هذا هو سبب شعوره بمزيد من التوافق مع المحرر الكلاسيكي. أوصي شخصيًا بعدم تغيير الإعداد الافتراضي.

jasmussen هل يجب إغلاق هذا لصالح # 17088

نعم أعتقد أننا نستطيع. تم استكشاف هذه البطاقة بشكل متباين ، بينما تقوم الأخرى الآن بصقل بعض الأفكار. سيظل من الممكن العثور على هذه التذكرة إذا اتبعت المرجع الموجود على التذكرة الجديدة بفضل رياض.