فكرة مثيرة للاهتمام melchoyce.

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

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

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

قال كل هذا ، أنا لا أقول على الإطلاق أن ما لدينا الآن يجب أن يكون الطريق إلى الأمام. هل أنت مستعد للتكرار وربما استكشاف المزيد؟ أنا حقا أتمنى أن تكون كذلك.

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

منذ ذلك الحين ، قطعنا خطوات واسعة مع واجهة المستخدم الجانبية ، وآخرها في https://github.com/WordPress/gutenberg/pull/6141 ، وقد جعلناها تعمل بشكل جيد في السياقات المتداخلة أيضًا ، على الرغم من ذلك الجانب لا يزال بحاجة إلى بعض الحب.

على الرغم من أن الثوغن ليست جميلة ، فإن الفوائد الرئيسية لوجود واجهة المستخدم هذه على الجانب هي ،

1. يمكن أن تظهر عند المرور فوقها
2. لا يوسعون بصمة الكتلة

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

2 قد يكون مهمًا اعتمادًا على كيفية تعاملنا مع واجهة المستخدم الجانبية في السياقات المتداخلة. نحن الآن نواجه بعض التحديات في https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863 ، وعلى الرغم من أنني متأكد من أننا سنكون قادرين على حلها ، فإن حقيقة أن البصمة لا التغيير يساعد.

كل هذا لا يعني القول "لا يمكن أن تعمل" - يمكن أن تعمل بشكل جيد للغاية. يحتوي نموذج بالحجم الطبيعي القديم على واجهة المستخدم هذه كتراكب في الزاوية:

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

هل الحد يظهر عند النقر أو عند التمرير؟

فقط عند النقر. سيكون Hover مشابهًا لكيفية عمله الآن.

هل أنت مستعد للتكرار وربما استكشاف المزيد؟ أنا حقا أتمنى أن تكون كذلك.

دائما 👍

لا يوسعون بصمة الكتلة

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

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

👍 👍

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

على الرغم من أن الثوغن ليست جميلة ، فإن الفوائد الرئيسية لوجود واجهة المستخدم هذه على الجانب هي ،

1. يمكن أن تظهر عند المرور فوقها
2. لا يوسعون بصمة الكتلة

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

+1 فقط للإشارة إلى أن هذا قد يساعد أيضًا في تحسين ترتيب علامات التبويب لعناصر تحكم واجهة المستخدم حول الكتل. كما هو مذكور في https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531 ، تحتوي واجهة مستخدم الهاتف المحمول على "عناصر التحكم الجانبية" الموضوعة بطريقة أكثر منطقية. شاهد ملف GIF المتحرك الذي يوضح ترتيب علامات التبويب ، يمكنك المقارنة مع GIF السابق مع ترتيب علامات التبويب في عرض سطح المكتب في تعليق سابق https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

أيضا للأخذ في الاعتبار:

3976 يقترح خيارًا ثالثًا لوضع شريط أدوات الكتلة (شريط أدوات التنسيق) أسفل الكتلة ؛ سيكون من الرائع التفكير في تصميم باستخدام كل من شريط أدوات الكتلة _ و_ عناصر التحكم الجانبية الموضوعة أسفل الكتلة لمعرفة ما إذا كان ذلك ممكنًا.

1934 كقضية عامة حول تناسق ترتيب الجدولة

قد يكون لهذا أيضًا تأثير على حل بعض المشكلات التي أثيرت في # 6272.

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

نعم ، هذا ما يحدث مع شريط أدوات التنسيق العلوي أيضًا:

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

نعم ، يمكنني إلقاء نظرة أخرى.

+10 لتجربة هذا.

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

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

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

فكرة اخرى:

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

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

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

فكرة أخرى:

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

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

الكثير من المناقشات الرائعة حول هذا الموضوع ، دعنا نرى ما إذا كان بإمكاني تقديم بعض الملاحظات الموجزة لأعطيك شيئًا للانتقال إلى التكرار معmelchoyce.

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

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

أود أن أرى كيف يتكيف هذا أيضًا مع الأجهزة المختلفة ، وتفكيري هو أن هناك تنوعًا أقل ويمكن أن يكون هذا شيئًا رائعًا.

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

كنت أتجول في # 7211 وفي سياق هذا العمل اكتشفت # 7646 ، وهذا أعادني إلى هذه الفكرة ، التي تبدو حقًا أفضل حل لمجموعة من المشاكل.

ستعمل هذه التذكرة ، بشكل مباشر أو غير مباشر ، على إصلاح مجموعة كاملة من الأشياء:

• # 7646 → مع وجود عناصر التحكم أعلى / أسفل ، لا داعي للقلق بشأن استيعاب واجهة المستخدم الجانبية
• # 7182 ← عناصر تحكم مثل تلك الموجودة في النماذج بالأحجام الطبيعية على هذه البطاقة متصلة مباشرة بالكتلة وسيكون لها واجهة مستخدم متسقة بغض النظر عن مستوى التداخل
• # 6451 → إذا كانت لأشرطة الأدوات العلوية / السفلية خلفية صلبة ، فلا داعي للقلق بشأن معرفة كيفية جعل عناصر التحكم مرئية على الخلفيات المظلمة
• # 7114 / # 6265 ← إذا كنت تستخدم شريط أدوات كامل العرض كما هو الحال في بعض النماذج بالأحجام الطبيعية أعلاه ، فيمكنك استخدام المنطقة الفارغة للسحب / الإفلات

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

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

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

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

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

هذه النقاط تحتاج إلى استكشاف لتحديد المسار من هذه النقطة الواعدة.

karmatosed كنت أستخدم لغة محيرة - كنت أعني عناصر التحكم ، وليس أشرطة الأدوات. أشرطة الأدوات موجودة بالفعل في المقدمة - لا شيء يتغير هناك :)

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

عادي:

عندما يكون الجزء السفلي من الكتلة خارج الشاشة:

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

نظرًا للمشكلات المتعلقة بأدوات الكتلة الموجودة على الجوانب والفوائد العديدة لوجودها في الأسفل ، فأنا الآن مقتنع بأن وضعها في الأسفل هو السبيل للذهاب.

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

chrisvanpatten نعم ، لا أمانع في كلتا الحالتين إذا تم فصل الضوابط أم لا.

فيما يلي بعض النماذج بالأحجام الطبيعية:

يحوم:

يتم تحديده بشريط كامل العرض يشغل مساحة (بدلاً من أن يكون مجرد تراكب) مثل على الهاتف المحمول ويمكن أن يتضاعف كمقبض سحب:

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

أخذت الصور الأولى وأزلت سلة المهملات للحصول على ما أعتقد أنه من الأفضل التقدم به:

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

@ karmatosed لقد قمت بتعديل النموذج الخاص بك لإظهار الشكل الذي سيبدو عليه عندما تحوم فوق كتلة:

وهنا مع تحديد الكتلة وعرض شريط أدوات الكتلة:

(لقد قمت أيضًا بتحديث العنصر النائب لكتلة الصورة لمطابقة العنصر الحالي في Gutenberg.)

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

شيء من هذا القبيل يربكني بشأن عدم وجود حدود عليا على عناصر التحكم: هل لا تزال عناصر التحكم على خلفية بيضاء؟ هل هذا يعني أن الكتلة بأكملها لها خلفية بيضاء خلفها؟

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

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

متفق عليه ، ووجود الخلفية يحل أيضًا رقم 6451.

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

كما هو مقترح سابقًا ، يمكن أن تتضاعف أدوات تحريك الأسهم وعلامات القطع كمقابض سحب ، و / أو يمكن أن يكون عنوان التمرير مقبض سحب. (انظر # 7114.)

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

شيء أدركته للتو عن وجود خلفية بيضاء تظهر خلف الكتل المحددة: ماذا عن الكتل ذات لون النص الأبيض (أو ذو اللون الفاتح) الذي يُقصد رؤيته في منطقة داكنة اللون (يتم توفيرها بواسطة شيء مثل كتلة الحاوية)؟ لن يعمل وجود خلفية بيضاء للكتلة بأكملها في هذه الحالة.

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

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

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

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

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

تضمين التغريدة

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

فكرة رائعة 💡

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

@ karmatosed

أعتقد دعونا نترك المنطقة القابلة للسحب جانبًا وننفذ ذلك.

لست متأكدا تماما ماذا يعني هذا؟ أي جانب؟

سعيد لرؤية هذا سيحدث مجرد تذكير سريع بأن الأمر لا يتعلق فقط بالموضع المرئي. بالنسبة إلى a11y ، يجب أن يتطابق الترتيب المرئي وترتيب علامات التبويب (ترتيب DOM) ، لذا يجب نقل "أدوات الحظر" هذه فعليًا بعد المنطقة القابلة للتحرير في الترميز.

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

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-Points

علق للتو على هذا في # 7500. كنت أتساءل كيف ستبدو الفقرات المتتالية مع هذا التصميم؟ أعتقد أن وجود شريط في الأسفل سيؤدي إلى فجوة كبيرة بين الفقرات.

talldan نقلا عن نفسي من # 7500:

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

هذا يبدو جيدًا حقًا ، أنا أؤيده تمامًا.

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

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

كيف سيرون ما إذا كانت الكتلة الأولى كانت كتلة طويلة حقًا؟

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

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

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

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

hedgefieldchrisvanpatten ربما يمكن أن تتحرك عناصر التحكم في الأسهم / القطع أدناه (أو أعلى) الضوابط التنسيق في حالات أرق الاعراض؟

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

ومع ذلك ، فإن العودة إلى نموذج بالحجم الطبيعي بواسطة hedgefield قد يسمح مثبتة تمامًا مثل أدوات التنسيق دون أن

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

ولا أعرف ما إذا كان من المرغوب فيه حدوث تضارب بين المظهر المرئي وترتيب المصدر

ليس من المرغوب فيه في مرحلة ما أن يكون هناك معيار محدد لنجاح WCAG لذلك:
https://www.w3.org/TR/WCAG21/#focus -order

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

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

كيف سيبدو للكتل العريضة:

كيف سيبدو بالنسبة للكتل الرقيقة:

حتى كتل أرق (فكر في 8 أعمدة أو شيء ما):

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

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

لكن دمج كل شيء في سطر واحد يدمج إجراءات مختلفة في مكان واحد.

للعب دور محامي الشيطان ، أليس هذا ، بالتعريف ، هو الغرض من شريط الأدوات؟

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

karmatosed ماذا عن فصل عناصر التحكم عن طريق اللون؟

SuperGeniusZeb للأسف هذا لا يحل

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

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

@ karmatosed حسنًا إذن. دعنا نعود إلى وجود شريط أدوات التحرير في الأعلى:

(لست متأكدًا مما إذا كان الخط الأزرق فوق الشريط يجب أن يكون موجودًا أم لا.)

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

أيضًا ، خطرت لي فكرة: ماذا لو كان الشريط الموجود في الأسفل شفافًا جزئيًا عند التحويم؟ هل هذا سيجعلها تبدو أخف؟

SuperGeniusZeb لمجرد الحصول على المشاهدات ، هل يمكنني أن أقترح أن يكون لدينا

فقط للحصول على الخطوة التالية وهمية. SuperGeniusZeb كيف

بعض النماذج بالأحجام الطبيعية:

مع وجود حد أعلى شريط الضوابط

بدون حدود أعلى شريط الضوابط

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

أثناء صنع هذه النماذج ، لاحظت شيئًا ما: ما الذي يجب فعله في مثل هذه المواقف؟

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

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

ومرة أخرى ، بدون الحد بين الشريط السفلي ومحتوى الكتلة:

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

SuperGeniusZeb لقد النماذج بالأحجام الطبيعية. شكرا لجعلهم!

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

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

chrisvanpatten جميع

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

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

يقوم Elementor بنفس الشيء تقريبًا.

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

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

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

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

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

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

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

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

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

بعض الملاحظات حول كيفية عمل ذلك:

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

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

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

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

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

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

أعتقد أن هذه مشكلة كبيرة مع السخرية. ماذا يمكن ان يحدث ايضا؟

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

@ karmatosed

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

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

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

حتى في حالات مثل Divi أو Beaver Builder ، حيث يمكنك تحرير النص دون فتح شريط مشروط / جانبي ، لا يزال الشريط الشرطي / الجانبي هو الطريقة الأساسية للتحرير. يُظهر كل من Divi و Beaver Builder ما هو أساسًا نسخة طبق الأصل مثالية للواجهة الأمامية ، دون الحاجة إلى القلق بشأن الحاجة إلى التحسين لأشياء مثل استخدامها كمحرر نصوص أو ضمان إمكانية تحرير غالبية محتوى الكتلة الرئيسية بشكل مضمّن في الكتلة.

بالإضافة إلى ذلك ، في كل من أدوات إنشاء الصفحات وواجهات مستخدم البناء الأخرى ، يميل التداخل إلى أن يكون مشكلة أقل بكثير بسبب القيود المفروضة على ما يمكن تداخله. يحتوي Divi على قسم صارم ← صف (مع أعمدة مدمجة) ← إعداد الوحدة النمطية (وإن كان ذلك مع بعض أقسام التخصص المصممة لبعض مواقع الأعمدة المتداخلة الشائعة). يسمح Beaver Builder فقط بتداخل الأعمدة في الأعمدة ، كما يفعل Elementor. يتحكمون في النوع الوحيد من الكائن الذي يمكن أن يكون له طبقات متعددة من التداخل. كل شيء موجود في قسم بصف واحد بشكل افتراضي. لا توجد طبقات غير محدودة من الكتل المتداخلة مع إمكانية أي مجموعة من الكتل المخصصة التي تستخدم التداخل لأغراض مختلفة وأنماط مختلفة مثل ما يسمح به Gutenberg.

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

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

ما يحاول جوتنبرج القيام به فريد من نوعه. تحاول أن تكون WYSIWYG-except-for-the-selected-block-is-Opt-Enhanced-for-edit page Builder وهو أيضًا محرر نصي كامل ، وكل شيء من الأقسام إلى الأعمدة إلى الأدوات كلها من نفس النوع الكائن: الكتل.

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

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

إضافات / سمات ووردبريس

• أفادا (فيوجن بيلدر)
• BeTheme (صانع الكعك)
• بيفر بيلدر
• ديفي (ديفي بيلدر)
• العنصر
• الأكسجين
• SiteOrigin Page Builder
• ثرايف المهندس المعماري
• الملحن المرئي
• X & Pro من Themeco

بناة مواقع الويب خارج WordPress

• دروبال
• سكوير سبيس
• Weebly
• Wix

الأشياء التي ليست منشئ الصفحات ولكنها تشبه نوعًا ما

• ميل تشيمب
• خيالى

هذا كل ما أعرفه الآن.

توجد مشكلة في أداة إدراج الأخوة: فهي تتداخل دائمًا مع محتوى الكتلة المحددة. تزداد هذه المشكلة سوءًا عندما تحاول التخلص من أشياء مثل الهوامش التلقائية في كل كتلة لجعل Gutenberg أكثر WYSIWYG.

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

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

الفوائد تشمل:

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

نقاط المكافأة إذا تم تغيير أداة إدراج الأخوة لفتح قائمة الواضع مباشرة (كما تمت مناقشته في # 7271) بدلاً من إدراج كتلة فقرة فارغة.

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

أعتقد أن هذا تصميم جيد للمضي قدمًا به. أعتقد أن كل الإيجابيات تفوق السلبيات ، وأعتقد أنها بالتأكيد أفضل مما هو موجود الآن. ماذا الناس يعتقدون؟

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

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

chrisvanpatten كنت أفكر في أن الشريط السفلي

أيضًا ، ربما يجب أن يكون هناك ظل أسفل الشريط السفلي عندما يتداخل مع شيء ما.

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

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

تضمين التغريدة

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

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

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

المشكلة الوحيدة هي أن الشفافية لا تستخدم في أي مكان آخر في Gutenberg UI. هذا لا يعني أنه لا ينبغي استخدامه ... فقط لأنه لا توجد أمثلة حالية عليه ، لذلك يمكننا تقديم عدم تناسق في تصميم واجهة المستخدم.

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

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

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

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

ما زلت واثقًا من وجود حل هنا في مكان ما ... فقط يجب أن تستمر في التكرار!

تضمين التغريدة

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

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

على أي حال ، ماذا عن الشفافية؟

وإذا كنت تريد أن تحلم قليلاً وتتمنى أن يتم تطبيق backdrop-filter في جميع المتصفحات الرئيسية ، فيمكنك إضافة بعض الضبابية:

هذا هو 60٪ عتامة ، بالمناسبة.

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

chrisvanpatten في الواقع ، يبدو الأمر قليلاً مثل الغش ... ولكن ما هي الخيارات الأخرى المتوفرة لدينا؟

لا يمكننا وضع الضوابط على الجانب ، ومن هنا كانت هذه المشكلة موجودة في المقام الأول.

لا يمكننا وضع عناصر التحكم داخل الكتلة ، لأن ذلك من شأنه التستر على المحتوى.

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

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

لتقليل المساحة التي يشغلها الشريط السفلي ، لا يوجد سوى عدد قليل من الأشياء التي يمكننا القيام بها:

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

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

فكرة أخرى: ربما لن يشعر الشيء الشفاف بأنه غش إذا كان كل من شريطي الأدوات شفافين وليس الجزء السفلي فقط.

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

أشرطة أدوات شفافة:

لا شفافية:

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

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

هل يمكن أن يكون هذا؟ هل يمكن أن يكون هذا التكرار جيدًا بما يكفي ليحل محل الإصدار الحالي؟ _ (من فضلك قل "نعم".: stuck_out_tongue :) _

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

شكرا جميعا على المناقشة الممتازة هنا. إنه لمن دواعي السرور والسرور رؤية الشغف الذي يتم من خلاله مواجهة هذا التحدي.

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

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

الخيار الثاني هو العودة إلى طريقة waaaay القديمة بالأحجام الطبيعية ، وهذا:

ربما مع بعض التعديلات ، يمكن أن يكون هذا:

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

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

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

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

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

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

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

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

كيف هذا؟

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

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

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

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

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

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

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

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

كان الدافع الأساسي في كل هذا هو كيفية استجابته وتداخله.

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

فكر في التخطيطات المعقدة ، تلك التي تحتوي على مقاطع فيديو والكثير من الصور. في بنية المعلومات الكثيفة هذه ، لا يصمد ما يُقترح.

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

العودة إلى لوحة الرسم… 🙂

لماذا أعتقد أن نموذجي أفضل من واجهة المستخدم الحالية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هناك ... فكرة أخرى ... ~ Skywalker ~

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

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

ستكون واجهة مستخدم الهاتف المحمول هي نفسها تمامًا كما هي الآن. سيؤثر هذا التغيير فقط على مستخدمي سطح المكتب (وربما الجهاز اللوحي).

ولكن انتظر هناك المزيد!

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

قارن بواجهة المستخدم الحالية حيث لا يتخلص Fix Toolbar to Top من جميع مشكلات التحكم المتداخلة نظرًا لأن واجهة المستخدم الجانبية لا تزال منقسمة بين جانبين ولا تزال مقابض السحب غير المرئية المربكة موجودة ، ولا تزال أدوات إدراج الأشقاء تتداخل في السياقات المتداخلة ، وإلخ.

هل من المؤكد أن كل فقرة في النص هي كتلة منفصلة؟ إذا كان الأمر كذلك ، فإن عرض أدوات الحظر يجب أن يأخذ في الاعتبار تحديد مجموعة نصوص متعددة (أعتقد أنه سيأتي في مرحلة ما).

padraigobeirn هذه نقطة جيدة كنت قد نسيتها.

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

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

كما تعلم ، لقد بدأت حقًا في التفكير في أنه يجب تشغيل Fix Toolbar to Top بشكل افتراضي.

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

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

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

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

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

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

هل يمكنك قص بعض لقطات الشاشة لهذه الواجهةSuperGeniusZeb؟

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

هل يمكنك قص بعض لقطات الشاشة لهذه الواجهةSuperGeniusZeb؟

chrisvanpatten لا ، لم أتمكن من الوصول إليه إلا مؤقتًا أثناء مساعدة شخص ما.

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

chrisvanpatten عثرت على مقال يتحدث فيه شخص ما عن منشئ البريد الإلكتروني في Infusionsoft ولديه مقطع فيديو له:

https://www.monkeypodmarketing.com/the-new-email-builder/

chrisvanpatten Argh ، لقد تحققت للتو ويبدو أن هذا الفيديو قديم ... يبدو أنه في ذلك الوقت كان شريط أدوات التنسيق مرتبطًا بالكتل ، مثل ما يفعله Gutenberg الآن. من المثير للاهتمام أنهم غيروها ، رغم ذلك.

بعض الأفكار:

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

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

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

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

لقد جربت للتو # 8836. أعتقد أنه إذا تم دمجها ، فقد يساعد ذلك في تقليل مشكلات واجهة المستخدم الثقيلة / الممتلئة التي يبدو أن الكثير من تصميمات واجهة المستخدم في هذه البطاقة بها.

في التذكرة رقم 9074 و 9075 ، أقترح خطوتين صغيرتين ، مستوحاة من هذه المناقشة ، لتخفيف الوضع وتحسينه. في الاقتراح الأول ، يتمثل الاقتراح في نقل زر Ellipsis / More إلى شريط الأدوات ، لذلك لدينا جزء واحد فقط من واجهة المستخدم الجانبية (المحركين) ، وفي الآخر هناك اقتراح للسماح لمجموعة أدوات الحظر بالانهيار لتلائم بشكل أفضل سياقات رقيقة.

فقط من أجل إبقائهم محدثين ، قمت بتحديث jasmussen وتغييرات واجهة المستخدم الأخيرة في 3.6:

في الواقع ، قد لا يكون تحريك محركات الأسهم أسفل الكتل ضروريًا بعد الآن إذا تم تنفيذ # 9074 و # 9075. قد يكون الأمر جيدًا إذا بقوا على جانب الكتلة ، نظرًا لأن علامات الحذف للكتل المجاورة لن تتداخل معهم في أشياء مثل الأعمدة. إذا حدثت حلول لـ # 8880 و # 8881 و # 8883 ، وإذا تم تنفيذ # 8836 و # 8920 ، فربما تكون واجهة المستخدم جيدة بالفعل للسياقات المتداخلة. لقد بدأت في الميل نحوها ، حيث إن الأسهم لأعلى / لأسفل للبقاء على الجانب الأيسر من الكتلة.

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

دعنا نركز على الحصول على التكرارات في jasmussen التي يعمل عليها في # 9074 و # 9075 ، ثم يمكننا التفكير في الخطوات التالية. أرغب تمامًا في تغيير الكثير من الأشياء ولكن دعونا نتوازن.

بفضل # 9074 و # 9075 المذكورين أعلاه ، بالإضافة إلى المشكلات الأخرى والعلاقات العامة مثل # 8920 و # 9197 ، قررت أن نقل محركات الأسهم أسفل الكتلة لم يعد له فوائد كثيرة.

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

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