दिलचस्प विचार @melchoyce।

मेरी पहली प्रतिक्रिया थी कि कैसे उन्हें नीचे की ओर ले जाने से यह ब्लॉक को और अधिक 'ब्लॉकी' बना देता है - जो कहने के लिए एक अजीब बात है लेकिन यह कुछ मुझे महसूस कराता है। बॉर्डर क्लिक पर दिखा रहा है या होवर पर? मुझे लगता है कि मेरे पास इसके साथ एक मुद्दे पर कम क्लिक है अगर यह होवर पर है। एक और दिलचस्प दृश्य यह कम से कम आपके उदाहरणों को पोलेरॉइड छवि की तरह दिखता है, सुपर दिलचस्प है कि मेरा मस्तिष्क वहां कैसे गया।

हालांकि, यह मेरी पहली प्रतिक्रिया है, मुझे लगता है कि एक ब्लॉक पर इंटरेक्शन आइकन के लिए एक अलग स्थिति की खोज करने में योग्यता है। मुझे लगता है कि उसे जो हासिल हुआ है, वह बिल्कुल ऐसा तरीका है, जो सभी स्क्रीनों पर बेहतर काम करता है, कि हमें एक गाइड के रूप में आगे के अन्वेषणों को पकड़ना चाहिए।

मुझे लगता है कि हम बातचीत के कुछ संदर्भ खो देते हैं। उदाहरण के लिए, एक लंबे प्लेसहोल्डर वाले ब्लॉक में उन इंटरैक्शन होते हैं जो सीधे दिखाई नहीं देते हैं। मुझे लगता है कि यह एक अड़चन होने वाली है जो कम खोज-बीन में जुड़ सकती है।

इस सब ने कहा, मैं बिल्कुल नहीं कह रहा हूं कि हमारे पास अब आगे का रास्ता होना चाहिए। क्या आप पुनरावृत्ति के लिए तैयार हैं और शायद अधिक खोज कर रहे हैं? मैं वास्तव में आशा करता हूं कि आप हैं।

मुझे लगता है कि नेत्रहीन यह अच्छा है। यह अनिवार्य रूप से डेस्कटॉप ब्रेकपॉइंट पर मोबाइल यूआई है, और यह कुछ ऐसा है जिसे मैंने दोनों को प्लान बी के रूप में माना है यदि साइड यूआई बाहर काम नहीं करता है, या शायद नेस्टेड संदर्भों के लिए।

तब से हम दोनों साइड यूआई के साथ संघर्ष कर चुके हैं, हाल ही में https://github.com/WordPress/gutenberg/pull/6141 में , और हमने इसे अच्छी तरह से नेस्टेड संदर्भों में अच्छी तरह से काम करने के लिए प्राप्त किया है, हालांकि पहलू अभी भी कुछ प्यार की जरूरत है

Althougn के रूप में सुंदर नहीं है, इस तरफ यूआई होने के मुख्य लाभ हैं, हैं,

1. कि वे मंडराने पर दिखाई दे सकते हैं
2. वे ब्लॉक के पदचिह्न का विस्तार नहीं करते हैं

1 विशेष रूप से महत्वपूर्ण है, क्योंकि शुरू से ही यह सुनिश्चित करने के लिए एक स्पष्ट लक्ष्य है कि ड्रैग एंड ड्रॉप _additive_ है, न कि ब्लॉकिंग, रीऑर्डरिंग और सॉर्टिंग ब्लॉक के साथ बातचीत का प्राथमिक रूप। यदि हम उन्हें ब्लॉक के नीचे रखते हैं, तो संभवतः वे क्लिक पर दिखाई देंगे, जो इसे खींचने और छोड़ने के लिए माध्यमिक होगा जो हमेशा होवर पर काम करेगा।

2 इस बात पर निर्भर करता है कि हम नेस्टेड संदर्भों में साइड यूआई से कैसे निपटते हैं। अभी हम https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863 में कुछ चुनौतियों का सामना कर रहे हैं, और हालांकि मुझे यकीन है कि हम उन, इस तथ्य को हल करने में सक्षम होंगे कि पदचिह्न 't परिवर्तन मदद करता है।

यह सब "काम नहीं कर सकता" कहने के लिए नहीं है - यह बहुत अच्छी तरह से काम कर सकता है। एक पुराने पुराने मॉकअप में यह यूआई कोने में एक ओवरले के रूप में था:

तो सब में, अच्छे विचार, और अच्छे के लिए उन्हें नूडल में रखने के लिए रास्ते के रूप में खोज की जा सकती है जो फीडबैक के आधार पर हमें रिहाई के लिए मिलती है!

बॉर्डर क्लिक पर दिखा रहा है या होवर पर?

बस क्लिक पर। होवर इसी तरह का होगा कि यह अब कैसे काम करता है।

क्या आप पुनरावृत्ति के लिए तैयार हैं और शायद अधिक खोज कर रहे हैं? मैं वास्तव में आशा करता हूं कि आप हैं।

हमेशा 👍

वे ब्लॉक के पदचिह्न का विस्तार नहीं करते हैं

हाँ, निश्चित रूप से इस विचार के साथ एक मुद्दा है। यहां तक ​​कि इस प्रोटोटाइप में आप आकार बदलने के कारण कुछ कूदते हुए देख सकते हैं।

तो सब में, अच्छे विचार, और अच्छे के लिए उन्हें नूडल में रखने के लिए रास्ते के रूप में खोज की जा सकती है जो फीडबैक के आधार पर हमें रिहाई के लिए मिलती है!

👍 👍

मुझे लगता है कि हम बातचीत के कुछ संदर्भ खो देते हैं। उदाहरण के लिए, एक लंबे प्लेसहोल्डर वाले ब्लॉक में उन इंटरैक्शन होते हैं जो सीधे दिखाई नहीं देते हैं। मुझे लगता है कि यह एक अड़चन होने वाली है जो कम खोज-बीन में जुड़ सकती है।

Althougn के रूप में सुंदर नहीं है, इस तरफ यूआई होने के मुख्य लाभ हैं, हैं,

1. कि वे मंडराने पर दिखाई दे सकते हैं
2. वे ब्लॉक के पदचिह्न का विस्तार नहीं करते हैं

मुझे लगता है कि इन समस्याओं को हल करने का एक तरीका यह होगा कि ब्लॉक टूल टूलबार नीचे ब्लॉक के शीर्ष पर दिखाई दे और उस स्थान को न बढ़ाएं जो ब्लॉक वास्तव में संपादक को लेता है। लंबे ब्लॉकों के साथ खोज करने के लिए, टूलबार को चिपचिपा बनाया जा सकता है ताकि यदि आप स्क्रॉल करते हैं, तो टूलबार ऑफ-स्क्रीन पर न जाए। (यह अभी भी गायब हो जाता है जब ब्लॉक पर मंडराना नहीं होता है, निश्चित रूप से, और शायद यह केवल तब दिखाई दे सकता है जब ब्लॉक का निचला हिस्सा जो वर्तमान में दिखाई दे रहा है, वर्तमान में कैसे काम करता है के समान है।) सभी बटनों को दिखाने के लिए आवश्यक स्थान, और नियंत्रण के 2 सेटों के बीच खाली स्थान की एक पूरी पंक्ति को न लें, जैसे कि इस मुद्दे के मुख्य पोस्ट में मॉकअप में है।

+1 बस ध्यान दें कि यह ब्लॉकों के आसपास UI नियंत्रणों के टैब क्रम को बेहतर बनाने में भी मदद कर सकता है। जैसा कि https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531 में बताया गया है कि मोबाइल UI में "साइड कंट्रोल" को अधिक तार्किक तरीके से रखा गया है। टैब क्रम को दर्शाने वाली एनिमेटेड जीआईएफ देखें, आप पिछले जीआईएफ की तुलना डेस्कटॉप ऑर्डर में टैब दृश्य के साथ पिछली टिप्पणी में कर सकते हैं https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

यह भी ध्यान में रखना:

3976 ब्लॉक टूलबार (स्वरूपण टूलबार) को ब्लॉक के नीचे रखने के लिए एक तीसरा विकल्प प्रस्तावित करता है; यह दोनों ब्लॉक टूलबार के साथ एक डिजाइन पर विचार करने के लिए बहुत अच्छा होगा _and_ ब्लॉक के नीचे रखा गया नियंत्रण यह देखने के लिए कि क्या यह काम कर सकता है।

टैब क्रम की स्थिरता के बारे में एक सामान्य समस्या के रूप में 1934

इससे # 6272 में उठाए गए कुछ मुद्दों को सुलझाने पर भी असर पड़ सकता है।

लंबे ब्लॉकों के साथ खोज करने के लिए, टूलबार को चिपचिपा बनाया जा सकता है ताकि यदि आप स्क्रॉल करते हैं, तो टूलबार ऑफ-स्क्रीन पर न जाए।

हां, यह वही है जो शीर्ष स्वरूपण टूलबार के साथ भी होता है:

सभी भयानक प्रतिक्रिया के माध्यम से पढ़ना यहाँ लगता है कि यह आगे और आज पहुंच के साथ कई मुद्दों को हल करता है। यह ध्यान में रखते हुए, मुझे लगता है कि हमें यहां कुछ पुनरावृत्तियों पर काम करना चाहिए और फिर एक पीआर में प्रोटोटाइप के लिए जाना चाहिए। क्या आप उस @melchoyce को करने के लिए तैयार होंगे?

हाँ, मैं एक और रूप ले सकता हूं।

इसे आज़माने के लिए +10।

जब मैं अपने ब्राउज़र विंडो की चौड़ाई को कम करता हूं, तो यह ब्लॉक UI जैसा दिखता है। (यदि मैं इसे कुछ और सिकोड़ता हूं, तो ब्लॉक टूलबार ब्लॉक से नीचे चला जाता है, लेकिन जो मैं सुझाव दे रहा हूं वह प्रासंगिक नहीं है।)

मैंने देखा कि ब्लॉक इंसट्रक्टर अप / डाउन मूवमेंट कंट्रोल के बगल में दिखाई देता है। यदि इस तरह के UI का उपयोग सभी स्क्रीन आकारों के लिए किया जाता था जैसे कि यह मुद्दा प्रस्तावित है, तो शायद वर्तमान ब्लॉक परिशिष्ट को नेस्टेड ब्लॉक संदर्भों से हटाया जा सकता है, जिससे संपादक हमेशा सामने वाले अतिरिक्त स्थान को हटाकर फ्रंट-एंड जैसा दिखता है घोंसले के शिकार के प्रत्येक स्तर के लिए प्रत्येक ब्लॉक परिशिष्ट द्वारा। (मैंने # 6834 में एपेंडर-ईटिंग-अप-स्पेस मुद्दे का एक वैकल्पिक समाधान भी सुझाया।)

इसके अलावा, यह सिर्फ एक साइड नोट है, लेकिन क्या निकालें बटन को अधिक विकल्प बटन के दाईं ओर माना जाता है, या यह बाईं ओर होना चाहिए? अधिकांश UI डिज़ाइनों में, दीर्घवृत्त मेनू को दाईं ओर रखा जाता है।

एक अन्य विचार:

होवर पर नीचे की तरफ इन ब्लॉक कंट्रोल्स को दिखाएं, लेकिन इस अवस्था में, वे पेज पर कोई स्पेस नहीं लेते हैं, और इसके बजाय होवर ब्लॉक के नीचे जो भी ऊपर दिखाई देता है (ठीक उसी तरह जैसे ब्लॉक टूलबार वर्तमान से ऊपर के ब्लॉक के लिए करता है) एक) या शायद hovered ब्लॉक के शीर्ष पर। तल पर ब्लॉक नियंत्रण भी होवर पर एक निर्बाध सफेद पट्टी नहीं होना चाहिए, लेकिन नियंत्रण को कम जगह लेने और अधिक कवर नहीं करने के लिए, ब्लॉक टूलबार के समान प्रत्येक तरफ 2 छोटे बार।

जब आप एक ब्लॉक का चयन करेंगे, तो नीचे स्थित ब्लॉक नियंत्रण स्थान लेगा, ब्लॉक के दृश्य पदचिह्न को बढ़ाता है और ब्लॉक को नीचे से बाहर धकेलता है, जैसे जब आप एक छवि का चयन करते हैं तो कैप्शन प्लेसहोल्डर प्रकट होता है। इससे ब्लॉक का चयन करना आसान हो जाता है यदि यह एकल-पंक्ति पैरा ब्लॉक की तरह लंबवत छोटा ब्लॉक होता।

यह दृष्टिकोण आपको वर्तमान ऑन-होवर नियंत्रणों के लाभों को रखने की अनुमति देगा, जिससे आप उन्हें पहले चयन किए बिना आसानी से ब्लॉकों को स्थानांतरित करने / हटाने की अनुमति दे सकते हैं, जबकि यह भी सुनिश्चित कर सकते हैं कि जब ब्लॉक संपादित किया जा रहा हो, तो नियंत्रण कुछ भी कवर न करें, जिससे यह बना रहे फिर एक अलग ब्लॉक का चयन करना आसान है।

एक और विचार:

पूरे ब्लॉक बार (और ब्लॉक टूलबार) को ड्रैग हैंडल (बटनों सहित, जैसे जीटीके हेडर बार काम करते हैं) को दोगुना करने की अनुमति दें। मुझे लगता है कि यह विशेष रूप से चयनित ब्लॉकों के संदर्भ में ड्रैग-एंड-ड्रॉप खोजनीयता के मुद्दे को बहुत हल करेगा, जहां नीचे नियंत्रण बार ऐसा लगता है कि यह प्रारंभिक पोस्ट में मॉकअप में ब्लॉक का हिस्सा है, और इसलिए उपयोगकर्ता शायद इसे ड्रैग हैंडल के रूप में उपयोग करने के बारे में सोचने की अधिक संभावना है।

कंट्रास्ट करें कि वर्तमान स्थिति के साथ जहां ब्लॉक के किनारे नहीं दिखते हैं जैसे वे ब्लॉक का हिस्सा हैं, और इसलिए यह स्पष्ट नहीं है कि वे ड्रैग हैंडल के रूप में कार्य कर सकते हैं, और यह भी मुद्दा है कि सिंगल-लाइन पैरा ब्लॉक कहां हैं शायद ही किसी भी खाली जगह को अपनी तरफ से खींचने के लिए। (और चूंकि साइड कंट्रोल बटन का उपयोग वर्तमान में ड्रैग हैंडल के रूप में नहीं किया जा सकता है, जब तक कि वे अक्षम न हों, मुद्दा और भी खराब हो जाता है।)

इस के आसपास बहुत बढ़िया चर्चा, चलो देखते हैं कि क्या मैं कुछ सारांश प्रतिक्रिया दे सकता हूं उम्मीद है कि आप @melchoyce के साथ चलना में कुछ दे सकते हैं।

कुल मिलाकर मुझे लगता है कि मुझे इसे एक प्रोटोटाइप में महसूस करने की जरूरत है और मुझे लगता है कि मेरे विचार से बहुत कुछ किया जा सकता है। हालांकि कुछ विचार हैं जो मैं एक नकली में काम करना चाहूंगा:

• लंबे ब्लॉकों के लिए एक समाधान।
• एक कम 'रुकावट' की भावना: यह सिर्फ स्थानधारक राज्यों को मजाक में दिखा सकता है, मैं इन परिवर्तनों के साथ इसे अधिक स्पष्ट रूप से पढ़ रहा हूं।
• यह दिखाते हुए कि यह नेस्टिंग के साथ कैसे काम करता है।

मैं यह देखना पसंद करूंगा कि यह अलग-अलग उपकरणों के लिए कैसे अनुकूल है, मेरी सोच में कम बदलाव है और यह बहुत अच्छी बात हो सकती है।

@SuperGeniusZeb आपके पास कुछ दिलचस्प विचार हैं। मैं यह देखना चाहूंगा कि मेल को उपरोक्त पुनरावृत्तियों के साथ कहाँ मिलता है। मुझे लगता है कि हैंडल को खींचने के लिए यूआई को दोगुना करना अब बचने के लिए कुछ है, ऐसे घोंसले के बदलाव हैं जिन पर मैं काम करना चाहता हूं। मैं यह नहीं कह रहा हूं कि हम इसे पुनरावृत्त नहीं करेंगे, लेकिन यह UI विशेष रूप से इसके लिए नहीं है। मुझे यह भी लगता है कि आप स्पष्ट रूप से स्पष्ट नहीं होने के बिना संबंधित हो सकते हैं और जहां यह बहुत स्पष्ट हो जाता है वह है जहां ब्लॉकों की नकारात्मक भावना आती है - यह करीब और बहुत सीमित लगता है।

मैं # 7211 के आसपास नूडलिंग कर रहा था और उस काम के संदर्भ में मैंने # 7646 की खोज की, और इसने मुझे इस विचार पर वापस लाया, जो वास्तव में समस्याओं के एक समूह के लिए सबसे अच्छा समाधान की तरह लगता है।

यह टिकट प्रत्यक्ष या परोक्ष रूप से, चीजों का एक पूरा गुच्छा तय करेगा:

• # 7646 → नियंत्रण ऊपर / नीचे तैनात होने के साथ, आपको यूआई को समायोजित करने के बारे में चिंता करने की आवश्यकता नहीं है
• # 7182 → इस टिकट पर मॉकअप में नियंत्रण सीधे ब्लॉक से जुड़ा हुआ है और इसमें निम्न स्तर की परवाह किए बिना लगातार यूआई होगा।
• # 6451 → अगर टॉप / बॉटम टूलबार की ठोस पृष्ठभूमि है, तो आपको यह पता लगाने की चिंता करने की ज़रूरत नहीं है कि किसी भी पृष्ठभूमि पर नियंत्रण कैसे बनाया जाए
• # 7114 / # 6265 → यदि आप ऊपर दिए गए कुछ मॉकअप की तरह पूरी चौड़ाई वाले टूलबार का उपयोग करते हैं, तो आप खाली क्षेत्र को खींचने / छोड़ने के लिए उपयोग कर सकते हैं

यह सब कहने के लिए, अगर वहाँ अभी भी एक मौका है तो यह परिवर्तन गुटेनबर्ग में उतर सकता है, मुझे लगता है कि यह बहुत सारी समस्याओं को हल कर सकता है और बहुत सारी चीजें आसान बना सकता है :) मैं इसमें शामिल होने जा रहा हूं और काम करना चाहता हूं इस सप्ताह के अंत में कुछ मॉकअप / अवधारणाएं उम्मीद करती हैं।

@chrisvanpatten परिप्रेक्ष्य को जोड़ने के लिए यह समस्या नियंत्रण के बारे में है कि टूलबार नीचे नहीं ले जाया जा रहा है। यह प्रयोज्य के कई और मुद्दों का कारण होगा। बस आपके द्वारा लिंक किए जाने वाले कुछ मुद्दों की जाँच करना टूलबार के आसपास लगता है।

मैं पूरी तरह से इसे आज़माने के पक्ष में हूँ, क्योंकि यह टैब ऑर्डर को बेहतर बनाता है। एक त्वरित अपडेट: निकालें "कचरा" बटन को इलिप्सिस मेनू के भीतर स्थानांतरित कर दिया गया है। मैं नियंत्रण सिद्धांत की

@ वेफर्सिया के रूप में वे अलग-अलग नियंत्रण हैं जो मुझे लगता है कि दाईं ओर दीर्घवृत्त होता है। आइए एक कदम के रूप में इसका पता लगाएं। हमें निम्नलिखित की खोज पर ध्यान देने की आवश्यकता है:

लंबे ब्लॉकों के लिए एक समाधान।
एक कम 'रुकावट' की भावना: यह सिर्फ स्थानधारक राज्यों को मजाक में दिखा सकता है, मैं इन परिवर्तनों के साथ इसे अधिक स्पष्ट रूप से पढ़ रहा हूं।
यह दिखाते हुए कि यह नेस्टिंग के साथ कैसे काम करता है।

इन बिंदुओं को इस आशाजनक बिंदु से मार्ग निर्धारित करने के लिए खोज की आवश्यकता है।

@karmatosed मैं भ्रामक लिंगो का उपयोग कर रहा था - मेरा मतलब था नियंत्रण, टूलबार नहीं। टूलबार पहले से ही शीर्ष पर हैं - वहाँ कुछ भी नहीं बदलने के लिए :)

मैं सिर्फ ब्लॉक के नीचे डाल अगर मैं देख सकता हूँ कि ब्लॉक उपकरण की कल्पना के कुछ नकली बना दिया। ध्यान दें कि इन मॉकअप में, ब्लॉक टूल कभी भी स्पेस नहीं लेते हैं, केवल डेस्कटॉप पर ब्लॉक टूलबार की तरह ओवरले के रूप में कार्य करते हैं। इन मॉकअप में ब्लॉक भी चुने गए हैं। यदि केवल एक ब्लॉक पर मंडराता है, तो शीर्ष पर ब्लॉक टूलबार नहीं दिखाया जाएगा। यह भी ध्यान रखें कि नीचे का नियंत्रण तब भी दिखाई दे सकता है जब वर्तमान साइड नियंत्रणों की तरह उनके निकट मंडराता हो।

सामान्य:

जब एक ब्लॉक का निचला भाग ऑफ-स्क्रीन होता है:

(साइड नोट: इमेज ब्लॉक टूलबार इन मॉकअप में किसी से मेल नहीं खाता है क्योंकि इसके ब्लॉक टूलबार में अलग-अलग विकल्प हैं।)

मुद्दों को देखते हुए ब्लॉक टूल पक्षों पर हैं और उन्हें तल पर होने के कई लाभों के साथ, मुझे अब यकीन है कि उन्हें तल पर होने का रास्ता है।

@SuperGeniusZeb मूल रूप से वही है जो मैं सोच रहा था सिवाय इसके कि मैं एक संयुक्त टूलबार के रूप में दाईं ओर के बजाय ऊपर / नीचे तीर के साथ अधिक विकल्प बटन को स्थिति में ले जा रहा था।

@chrisvanpatten हाँ, अगर नियंत्रण अलग किया गया था या नहीं तो मैं किसी भी तरह से बुरा नहीं

यहां कुछ और मॉकअप दिए गए हैं:

होवर:

फ़ुल विस्फ़ोटक बार के साथ चुना गया जो मोबाइल की तरह जगह लेता है (केवल एक ओवरले होने के बजाय) और एक ड्रैग हैंडल के रूप में दोगुना हो सकता है:

मुझे कहना है कि मुझे लगता है कि हम इस बारे में बहुत अधिक खतरे में हैं। यह वर्णन करने का एक अजीब तरीका है, लेकिन इसके साथ जा रहा है :) उदाहरण के लिए, पिछले मॉक में दिखाया गया हॉवर काफी तीव्र है। मुझे लगता है कि हमें यह देखने के लिए अधिक जाना होगा कि मेल ने पहली छवि में क्या दिखाया जो एक कम सीमा है और यह वास्तव में ऐसा करने में मदद नहीं करता है।

मैंने पहला मौक्स लिया और कचरा निकाला जो मुझे लगता है कि प्रगति के लिए सबसे अच्छा होगा:

हमें अतिरिक्त सीमाओं की आवश्यकता नहीं है और हमें अतिरिक्त वजन की आवश्यकता नहीं है। इस तरह से यह असामान्य होवरिंग रूपरेखा के बिना आसान खींचने की अनुमति देता है।

@karmatosed मैंने आपके मॉकअप को यह दिखाने के लिए संशोधित किया है कि जब आप किसी ब्लॉक पर

और यहाँ यह चयनित ब्लॉक के साथ है और ब्लॉक टूलबार दिखाया गया है:

(मैंने गुटेनबर्ग में वर्तमान एक से मिलान करने के लिए छवि ब्लॉक प्लेसहोल्डर को भी अपडेट किया है।)

कुछ ऐसा है जो नियंत्रण पर कोई ऊपरी सीमा नहीं होने के बारे में मुझे भ्रमित करता है: क्या नियंत्रण अभी भी एक सफेद पृष्ठभूमि पर हैं? क्या इसका मतलब है कि पूरे ब्लॉक के पीछे एक सफेद पृष्ठभूमि है? ऐसा लगता है कि यह नेस्टेड संदर्भों में मुद्दों का कारण होगा जहां एक ब्लॉक एक अंधेरे पृष्ठभूमि के साथ एक कंटेनर में नेस्टेड है, चयन के रूप में (और / या होवरिंग) ब्लॉक की पृष्ठभूमि को बदलने का कारण होगा, जो कि काफी परेशान लगेगा।

कुछ ऐसा है जो नियंत्रण पर कोई ऊपरी सीमा नहीं होने के बारे में मुझे भ्रमित करता है: क्या नियंत्रण अभी भी एक सफेद पृष्ठभूमि पर हैं? क्या इसका मतलब है कि पूरे ब्लॉक के पीछे एक सफेद पृष्ठभूमि है?

यह करता है, लेकिन नियंत्रण लक्ष्य है। मुझे लगता है कि यह दिखाने के लायक है और बिना ब्लॉक विजुअल मुद्दों से बचा जाता है। यह पूरी तरह से घोंसले के शिकार में की जरूरत है, हालांकि पृष्ठभूमि के बिना यह नेत्रहीन घोंसले के शिकार में भी बदतर हो जाएगा।

यह करता है, लेकिन नियंत्रण लक्ष्य है। मुझे लगता है कि यह दिखाने के लायक है और बिना ब्लॉक विजुअल मुद्दों से बचा जाता है। यह पूरी तरह से घोंसले के शिकार में की जरूरत है, हालांकि पृष्ठभूमि के बिना यह नेत्रहीन घोंसले के शिकार में भी बदतर हो जाएगा।

सहमत, और पृष्ठभूमि भी # 6451 हल करती है।

मुझे लगता है कि उन पिछले नकली में मँडरा पर दिखाया गया है कि खाली खाली बार पसंद नहीं है। आदर्श रूप से, आप होवर पर यथासंभव आसपास के ब्लॉक को कवर करना चाहेंगे, लेकिन यह नीचे के ब्लॉक का काफी हिस्सा कवर करता है। इस जैसे किसी और के बारे में क्या राय है?

जैसा कि पहले सुझाव दिया गया है, तीर मूवर्स और एलिप्सिस ड्रैग हैंडल के रूप में दोगुना हो सकता है, और / या होवर शीर्षक एक ड्रैग हैंडल हो सकता है। (# 7114 देखें)

@SuperGeniusZeb whilst मैं इस मामले में आपके बिंदुओं को समझता हूं कि वास्तव में ब्लॉकों को रेखांकित नहीं किया गया है और यह बहुत अच्छा नहीं है। मेल के जबर्दस्त काम के आधार पर इसे मॉक के साथ चिपका दिया जाए ताकि इसे प्रोटोटाइप में देखा जा सके।

मेरे द्वारा चुने गए ब्लॉकों के पीछे एक सफेद पृष्ठभूमि होने के बारे में कुछ महसूस किया गया: एक सफेद (या अन्यथा हल्के रंग) वाले ब्लॉक के बारे में क्या होता है पाठ का रंग गहरे रंग के क्षेत्र में देखा जाना चाहिए (कंटेनर ब्लॉक जैसी चीज द्वारा प्रदान किया गया)? पूरे ब्लॉक के लिए एक सफेद पृष्ठभूमि होने से इस उदाहरण में काम नहीं होगा।

बैकग्राउंड टूलबार के आसपास होता है जो हमेशा उन नियंत्रणों को करने वाला होता है।

@SuperGeniusZeb हाँ, मैं ब्लॉक को प्रभावित करने वाली सफेद पृष्ठभूमि को नहीं देखता, केवल नियंत्रण करता हूँ। व्यावहारिक रूप से यह कुछ इस तरह हो सकता है:

या गद्दी को संभवतः हटाया जा सकता है (मैं वास्तव में इस दृष्टिकोण को पसंद करता हूं लेकिन यह स्पष्ट रूप से एक बड़ा सवाल है जिसका निहितार्थ w / खींचें और ड्रॉप है। फिर भी लगता है कि यह विचार करने लायक है):

@chrisvanpatten मुझे वह आखिरी मॉकअप पसंद है। मुझे नहीं लगता कि ड्रैग-एंड-ड्रॉप एक मुद्दा होगा क्योंकि नीचे की तरफ एक ड्रैग हैंडल के रूप में हो सकता है (और संभवतः बार के बटन एक के रूप में भी काम करेंगे)। आप यहां तक ​​कि होवर पर निचले बार में ड्रैग हैंडल आइकन जोड़ सकते हैं या हमेशा यह बताने के लिए कि आप ब्लॉक का उपयोग करके इसे खींच सकते हैं।

इस दृष्टिकोण से मुझे ब्लॉक की सीमाओं के पास ड्रैगेबल क्षेत्र को रखने का कोई कारण नहीं दिखता है। उस पैडिंग को हटाने से ब्लॉक होवर / चयनित रूपरेखाओं को ब्लॉक की वास्तविक सीमाओं के करीब लाने में मदद मिल सकती है, क्योंकि उन्हें अब उस ड्रैग स्पेस के लिए ध्यान नहीं देना होगा और केवल वास्तविक ब्लॉक से बड़ा होने के लिए समायोजित करना होगा माता-पिता ब्लॉक का चयन करना आसान बनाने के लिए घोंसले के शिकार के मामले। (यदि # 6459 में इस टिप्पणी में मॉकअप की तरह सामान लागू किया गया था, तो मूल ब्लॉक का चयन करना एक समस्या से कम नहीं होगा।)

@SuperGeniusZeb

आप यहां तक ​​कि होवर पर निचले बार में ड्रैग हैंडल आइकन जोड़ सकते हैं या हमेशा यह बताने के लिए कि आप ब्लॉक का उपयोग करके इसे खींच सकते हैं।

महान विचार 💡

मुझे लगता है कि चलो ड्रैग करने योग्य क्षेत्र को एक तरफ छोड़ दें और इसे लागू करें। यह उस चीज़ पर ध्यान केंद्रित करना महत्वपूर्ण है जो पहले हल हो रही है। मुझे कहना है कि मुझे यकीन नहीं है कि एक आइकन सही दृष्टिकोण है, हमने कहा कि एक बार हम इसे लागू किए बिना फिर से चलें।

@karmatosed

मुझे लगता है कि चलो ड्रैग करने योग्य क्षेत्र को एक तरफ छोड़ दें और इसे लागू करें।

मुझे पूरा यकीन नहीं है कि इसका क्या मतलब है? किस तरफ?

खुशी है कि यह होने जा रहा है। बस एक त्वरित अनुस्मारक कि यह केवल दृश्य प्लेसमेंट के बारे में नहीं है। A11y के लिए, विज़ुअल ऑर्डर और टैब ऑर्डर (DOM ऑर्डर) का मिलान होना चाहिए, इसलिए इन "ब्लॉक टूल्स" को वास्तव में मार्कअप में ब्लॉक एडिटेबल एरिया के बाद स्थानांतरित किया जाना चाहिए।

ब्लॉक के नीचे के नियंत्रणों पर स्विच करने का एक अच्छा लाभ यह है कि यह साइड स्पेस को खोलता है ताकि स्क्वीरेस्पेस में लोगों की तरह कुछ को फिर से डिज़ाइन किया जा सके यदि वर्तमान डिज़ाइन मुद्दों में चलता है। वर्तमान साइड नियंत्रणों ने इस तरह के आवेषण को ओवरलैप किया होगा और अव्यवस्थित दिखेंगे, लेकिन नियंत्रण नीचे की ओर चले गए, यह अब कोई मुद्दा नहीं है।

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

# 7500 पर बस इस बारे में टिप्पणी की। मैं सोच रहा था कि इस डिजाइन के साथ लगातार पैराग्राफ कैसे दिखेंगे? मुझे लगता है कि नीचे की तरफ बार होने से पैराग्राफ के बीच काफी अंतर होगा।

# दलदल ने # 7500 से खुद को उद्धृत किया:

ब्लॉक नियंत्रण हॉवर पर जगह नहीं लेगा (जैसे वे और ब्लॉक टूलबार अब जगह नहीं लेते हैं), और जहां तक ​​मैं बता सकता हूं यह अभी भी तय नहीं हुआ है कि क्या वे एक चयनित ब्लॉक पर जगह लेंगे। और निश्चित रूप से, नियंत्रण केवल उन ब्लॉकों के लिए दिखाया जाएगा जो या तो चयनित हैं या ओवर होवर हैं। ब्लॉक के बीच की मानक दूरी परिवर्तन से अप्रभावित होनी चाहिए; केवल चयनित ब्लॉक ही प्रभावित हो सकता है।

यह वास्तव में अच्छा लग रहा है, मैं इसके लिए सबकुछ हूं।

इस पर विचार करने के लिए एक बात जो हमने पहले नहीं की थी। लंबे ब्लॉक के बारे में क्या? क्या होता है उन और ब्लॉक के साथ संपादक स्क्रीन के नीचे?

आपका मतलब है कि जब ब्लॉक इतना लंबा होता है तो यह दृश्य से बाहर स्क्रॉल करता है? मैं कहूंगा कि ऐसा होने से पहले लोगों ने देखा होगा कि यह कैसे काम करता है और इसे कहां खोजना है। हमें बस यह परखना होगा कि यदि आप छोटे पर्दे पर बहुत सारे लंबे पैराग्राफ लिखते हैं तो यह कितना कष्टप्रद होता है। लेकिन मुझे यह पसंद है कि यह मोबाइल के अनुभव को बेहतर तरीके से प्रदर्शित करता है। आपको किसी पोस्ट में आखिरी ब्लॉक के लिए कौन सी चिंताएं हैं?

अगर उनका पहला ब्लॉक वास्तव में लंबा ब्लॉक होता तो वे कैसे देखते?

हमें कम से कम इसके बारे में एक NUX टिप जोड़ना चाहिए;) लेकिन आप जिस चीज के बारे में चिंतित हैं वह यह है कि कोई मौजूदा पोस्ट खोलता है कि शायद एक लंबा पैराग्राफ है या सही तरीके से ब्लॉक में परिवर्तित नहीं हुआ है? यह संभव है ... यदि वे एक नया पोस्ट शुरू करते हैं तो वे निश्चित रूप से इसे पहले प्लेसहोल्डर ब्लॉक पर देखेंगे, है ना?

इस बारे में सोचकर, मुझे ब्लॉक के शीर्ष पर नियंत्रण लगाने के लिए एक अन्वेषण नहीं दिखता है, जो एक विकल्प हो सकता है। उसके लिए जल्दी मॉकअप किया। ( सलाखों का संयोजन भी यहाँ उल्लेख किया गया है )

यदि कोई खंड बहुत लंबा है, तो नीचे का नियंत्रण स्क्रीन के नीचे तक नहीं जाएगा, जैसे शीर्ष नियंत्रण शीर्ष पर कैसे अटक जाता है या यह मोबाइल में कैसे काम करता है?

@hedgefield मुझे बहुत पसंद है लेकिन यह संकीर्ण संदर्भों में (कॉलम ब्लॉक की तरह) या लंबे टूलबार के साथ अच्छी तरह से काम नहीं करता है।

@hedgefield @chrisvanpatten शायद तीर / दीर्घवृत्त नियंत्रण पतले चौड़ाई के मामलों में नीचे (या ऊपर) स्वरूपण नियंत्रण को स्थानांतरित कर सकता है?

@karmatosed मैं कहूंगा कि नियंत्रण चिपचिपा हो सकता है और स्क्रीन के नीचे दिखाई दे सकता है। हालाँकि, यह नियंत्रण रेखा के इस मुद्दे का कारण बनता है जिस पंक्ति को आप हर बार लिखना शुरू करने के लिए एक अनुच्छेद में लिखने की कोशिश कर रहे हैं (संभवतः वे टाइपिंग के दौरान छिपे होंगे जैसे कि यह अब कैसे काम करता है)। लेकिन वैसे भी वह समाधान संदिग्ध लगता है।

हालांकि, @hedgefield द्वारा मॉकअप पर वापस जाना, जो नियंत्रणों को फॉर्मेटिंग टूल की तरह चिपचिपा होने की अनुमति दे सकता है। बेशक, टूलबार को उत्तरदायी होना होगा और तीर मूवर्स और इलिप्सिस को आदर्श रूप से पतले ब्लॉकों के लिए नीचे / ऊपर / कहीं चलना चाहिए।

पहुँच की चिंता भी है। @Khgefield के मॉकअप में ब्लॉक से पहले आने वाले सभी नियंत्रण हैं। आदर्श रूप से उन्हें मार्कअप में ब्लॉक के बाद आना चाहिए। सैद्धांतिक रूप से आप मार्कअप में ब्लॉक के बाद आने वाले नियंत्रणों को अनुमति देने के लिए CSS का उपयोग कर सकते हैं, लेकिन इसके ऊपर नेत्रहीन रूप से दिखाई दे सकते हैं। हालांकि, मुझे यकीन नहीं है कि व्यवहार में इसे लागू करना कितना मुश्किल है, और मुझे नहीं पता कि दृश्य उपस्थिति और स्रोत के आदेश के बीच असंगतता होनी चाहिए या नहीं। मुझे व्यक्तिगत रूप से कोई आपत्ति नहीं है, क्योंकि मार्कअप में ब्लॉक के बाद सभी ब्लॉक नियंत्रण दिखाई देते हैं, कीबोर्ड के माध्यम से नियंत्रण को अधिक सहज बनाते हैं क्योंकि आप पीछे की ओर जाने के बजाय उनमें आगे की तरफ टैब कर सकते हैं।

और मुझे नहीं पता कि दृश्य उपस्थिति और स्रोत क्रम के बीच एक असंगतता वांछनीय है या नहीं

यह इस बिंदु पर वांछनीय नहीं है कि इसके लिए एक विशिष्ट WCAG सफलता मानदंड है:
https://www.w3.org/TR/WCAG21/#focus -order

मैं कहूंगा कि नियंत्रण चिपचिपा हो सकता है और स्क्रीन के नीचे दिखाई दे सकता है। हालाँकि, यह नियंत्रण रेखा के इस मुद्दे का कारण बनता है जिस पंक्ति को आप हर बार लिखना शुरू करने के लिए एक अनुच्छेद में लिखने की कोशिश कर रहे हैं (संभवतः वे टाइपिंग के दौरान छिपे होंगे जैसे कि यह अब कैसे काम करता है)। लेकिन वैसे भी वह समाधान संदिग्ध लगता है।

वास्तव में, इसके बारे में कुछ और सोचने पर, नियंत्रण वास्तव में एक अनुच्छेद में अंतिम पंक्ति को कवर नहीं करेगा, जब तक कि पैरा स्क्रीन के निचले हिस्से के ठीक बगल में न हो, इसलिए # 353 इसे गैर-मुद्दा बना सकता है। और # 353 के बिना भी, आप अभी भी नीचे स्क्रॉल कर सकते हैं (जो कि ज्यादातर लोग वैसे भी करते हैं), और जैसा कि पहले उल्लेख किया गया है, नियंत्रण केवल तब दिखाएगा जब आपने अपना माउस स्थानांतरित किया था। मैंने अपना मन बदल दिया है। यह काम कर सकता है!

यह व्यापक ब्लॉकों के लिए कैसा दिखेगा:

यह पतले ब्लॉक के लिए कैसा दिखेगा:

यहां तक ​​कि पतले ब्लॉकों (लगता है कि 8 कॉलम या कुछ और):

मुझे लगता है कि मैं वास्तव में इस डिजाइन को पसंद करने लगा हूं। व्यापक ब्लॉक्स के लिए, मुझे यकीन नहीं है कि तीर मॉवर नियंत्रण स्वरूपण नियंत्रण के बाईं ओर या दाईं ओर जाना चाहिए, हालांकि।

अन्वेषणों के लिए धन्यवाद, हालांकि हर चीज को एक पंक्ति में मिलाना विभिन्न क्रियाओं को एक स्थान पर विलय करना है। मैं अनिश्चित हूं जो समझ में आता है। हम इस बात पर भी विचार करते हैं कि जब कोई व्यक्ति टूलबार को शीर्ष पर रखता है तो क्या होता है - वे 'जगह' में कुछ नहीं करने के लिए चुन रहे हैं और अब नियंत्रण हैं। यह अनुभव से कम की तरह लगता है क्योंकि हमारे पास टूलबार में ब्लॉक नियंत्रण नहीं हो सकता है - यह अनुभव करने के लिए बहुत अजीब होगा।

हालाँकि हर चीज को एक पंक्ति में मिलाने से विभिन्न क्रियाओं का एक ही स्थान पर विलय हो रहा है।

शैतान के वकील की भूमिका निभाने के लिए, क्या ऐसा नहीं है, परिभाषा के अनुसार, टूलबार का उद्देश्य?

आगे जोड़ने के लिए, जबकि मैं कुछ नियंत्रणों को अलग करने के पीछे के विचार को समझ सकता हूं, मुझे यकीन नहीं है कि इस मामले में इसके लिए पर्याप्त तर्क है। एक टूलबार एक टूलबार है; किसी दिए गए ब्लॉक के लिए सभी नियंत्रणों को एक ही स्थान पर रखने से फ़िज़ूल समझ में आता है, न कि फ़र्ज़ी कारणों से आने के बजाय कि कुछ उपकरण कुछ स्थानों पर हैं, जबकि अन्य उपकरण अन्य स्थानों पर हैं, जो प्लगइन्स अनिवार्य रूप से वैसे भी अनदेखा करेंगे।

@karmatosed रंग के माध्यम से नियंत्रणों को अलग करने के बारे में कैसे?

@SuperGeniusZeb दुर्भाग्य से जो मेरे अन्य बिंदुओं को हल नहीं करता है और मुझे यकीन नहीं है कि यह काम करता है।

मैं वास्तव में इस मामले में सोचता हूं कि यह एक डिजाइन को फिट करने की कोशिश करने का मामला है जो कि काम करने वाले पर काम करने के लिए सोचा जाता है। कैसे पीछे हटने और मेरे द्वारा उठाए गए अन्य बिंदुओं पर विचार करने के बारे में?

@chrisvanpatten एक टूलबार सब कुछ डालने के लिए एक जगह नहीं है, उपयोगी होने के लिए एक टूलबार के पास संदर्भ और व्यवस्था है। आपको एक उपयोगकर्ता के रूप में यह उम्मीद करनी होगी कि सही विकल्प होने के लिए क्या है। जब भी हम बहस कर सकते हैं कि एक विलक्षण शब्द का अर्थ थोड़ी देर के लिए है - यह करने के लिए मज़ेदार है - हम इस तथ्य पर ध्यान नहीं दे सकते हैं कि यह एक ही बार में बहुत सारी चीजों को जोड़ती है और अधिक लोगों के लिए एक समस्या होगी।

@karmatosed ठीक है तो। शीर्ष पर संपादन टूलबार होने पर वापस जाएं:

(निश्चित नहीं कि बार के ऊपर नीली रेखा होनी चाहिए या नहीं।)

क्या इस डिज़ाइन में कुछ गड़बड़ है? संपादन टूलबार को एक्सेसिबिलिटी के लिए सोर्स ऑर्डर में ब्लॉक के बाद दिखाई दे सकता है; यह आदर्श नहीं है, लेकिन चूंकि संपादन टूलबार को ब्लॉक के नीचे रखने से यह एक व्यवहार्य विकल्प नहीं लगता है, ऐसा लगता है कि केवल एक चीज है जो हम कर सकते हैं।

इसके अलावा, मुझे सिर्फ एक अंदाजा था: क्या होगा अगर नीचे की तरफ का हिस्सा आंशिक रूप से पारदर्शी होवर पर हो? क्या यह हल्का महसूस करेगा?

@SuperGeniusZeb विचार प्राप्त करने के लिए क्या मैं सुझाव दे सकता हूं कि हमारे पास कम रंगीन मॉक हैं? मैं समझता हूं कि जो सुझाव दिया जा रहा है, लेकिन इंटरफ़ेस को अपने दम पर खड़ा होने देना विजुअल जटिलता के बिना आसान होगा।

बस एक अगला कदम नकली पाने के लिए। @SuperGeniusZeb एक स्क्रीन (सामान्य डेस्कटॉप आकार) और एक बहुत लंबे ब्लॉक के संदर्भ में ऊपर जैसा दिखता है? यह नीचे के ब्लॉक के साथ कैसा दिखता है? आदर्श रूप से चलो थोड़ी पारदर्शिता के लिए पार्क करें और इस बार UI पर ध्यान न देने के बारे में मेरी टिप्पणी पर विचार करें, यह हमें सभी गेज में मदद करनी चाहिए।

कुछ मॉकअप:

नियंत्रण पट्टी के शीर्ष पर सीमा के साथ

नियंत्रण पट्टी के शीर्ष पर सीमा के बिना

ध्यान दें कि टूलबार हॉवर पर कोई स्थान नहीं लेता है, लेकिन यह तब होता है जब ब्लॉक का चयन किया जाता है।

इन मॉकअप को बनाते समय, मैंने कुछ देखा: इस तरह की स्थितियों में क्या किया जाना चाहिए?

चयनित ब्लॉक के प्रारूपण टूलबार और होवरेड ब्लॉक के निचले नियंत्रण दोनों को दिखाने के बीच यहां एक संघर्ष है। यदि स्वरूपण टूलबार नीचे था (या यदि ब्लॉक नियंत्रण सभी शीर्ष पर थे), तो यह एक समस्या नहीं होगी, लेकिन यहां नीचे दिखाए गए नियंत्रणों और ब्लॉकों के ऊपर दिखाए गए नियंत्रण का संयोजन एक मुद्दा बनाता है।

सबसे अच्छा समाधान मैं यह सोच सकता हूं कि होवरेड ब्लॉक बनाने के लिए होगा और इसके टूलबार में एक उच्च जेड-इंडेक्स है और नीचे ब्लॉक के शीर्ष पर और इसके स्वरूपण टूलबार पर दिखाई देगा। मुझे यकीन नहीं है कि यह सही दृष्टिकोण है, हालांकि। यहाँ एक मज़ाक है कि यह कैसा दिखेगा:

और फिर, नीचे पट्टी और ब्लॉक सामग्री के बीच की सीमा के बिना:

मैं वास्तव में चयनित ब्लॉक को ओवरलैप करने वाले होवरेड ब्लॉक के विचार को पसंद नहीं करता, लेकिन अन्यथा मुझे चयनित लोगों के ऊपर सीधे hovered ब्लॉकों के नीचे की सलाखों का उपयोग करने का कोई तरीका नहीं दिखता है। क्या आप सुनिश्चित हैं कि केवल एक बार में ऊपर या नीचे, कम से कम डेस्कटॉप पर सभी नियंत्रण रखना बेहतर नहीं होगा? यह निश्चित रूप से इस तरह के मुद्दों को रोक देगा।

@SuperGeniusZeb मैं किसी तरह उन

यह एक बहुत अच्छा बिंदु है जिसके बारे में मैंने नहीं सोचा था (चयनित ब्लॉक के ऊपर ब्लॉक को मँडरा)। यह निश्चित रूप से एक समस्या है। निवासी पेज बिल्डर विशेषज्ञ के रूप में, इस तरह के स्तरित टूलबार के साथ अन्य पेज बिल्डरों में कोई अन्य समान पैटर्न हैं?

इसके अलावा, इसके लायक क्या है, मुझे लगता है कि टूलबार को हमेशा मँडरा, चयनित या नहीं होना चाहिए। यह _sometimes_ स्थान लेने के बाद उछल-कूद करने वाली सामग्री को जन्म देगा जो समग्र रूप से अधिक अजीब अनुभव है।

@chrisvanpatten सभी पृष्ठ बिल्डरों जो मैंने देखे हैं उनमें केवल एक मॉड्यूल / विजेट के शीर्ष पर दिखाए गए नियंत्रण (शायद एक सहोदर

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

वीडियो में नहीं दिखाया गया है, Divi में स्वरूपण टूलबार तब दिखाई देता है जब आप किसी मॉड्यूल में पाठ पर क्लिक करते हैं, और आपके द्वारा लिखी गई पंक्ति के ऊपर थोड़ा पॉप-अप दिखाई देता है।

तत्वकार लगभग एक ही कार्य करता है।

बीवर बिल्डर में, टेक्स्ट को एक विजेट में क्लिक करने से ब्लॉक कंट्रोल टूलबार को फॉर्मेटिंग टूलबार द्वारा बदल दिया जाएगा, जब तक कि आपका माउस विजेट की सीमाओं के बाहर नहीं चला जाता है, जिसके कारण मानक ब्लॉक नियंत्रण तब दिखाई देगा जब आप अगली बार होवर करेंगे। , हालांकि आप अभी भी विजेट में टाइप कर सकते हैं। पाठ को फिर से क्लिक करने से स्वरूपण टूलबार मानक टूलबार को फिर से बदल देगा।

इसके अलावा, इसके लायक क्या है, मुझे लगता है कि टूलबार को हमेशा मँडरा, चयनित या नहीं होना चाहिए। इसे कभी-कभी जगह लेने से उछल-कूद करने वाली सामग्री हो जाएगी जो कि समग्र रूप से अधिक अजीब अनुभव है।

सच है, लेकिन मुझे इस बात की चिंता है कि यह एक स्वच्छ यूआई होने के लिए है। यदि आपके पास उपरोक्त सामग्री में से कुछ को ओवरलैप करने वाला टूलबार है, तो यह ठीक है। लेकिन तब यदि आप ब्लॉक के नीचे एक पूर्ण-चौड़ाई बार जोड़ते हैं, तो अब आप बहुत अधिक अन्य सामग्री को ओवरलैप कर रहे हैं।

आदर्श रूप से, आप चाहते हैं कि सभी नियंत्रण ब्लॉक के ऊपर या नीचे हों। यह ज्यादातर मामलों में टूलबार को एक-दूसरे को ओवरलैप करने से रोकेगा। अभिगम्यता के लिए, नियंत्रणों को नीचे रखना आदर्श होगा। हालाँकि, आप उन मुद्दों पर चल सकते हैं जहाँ टूलबार उस सामग्री को ओवरलैप कर रहे हैं जो आप किसी पैरा ब्लॉक की तरह लिख रहे हैं। हालांकि, यह ध्यान दिया जाना चाहिए कि केवल स्वरूपण टूलबार को वास्तव में हर समय दिखाई देने की आवश्यकता होती है, क्योंकि तीर मूवर्स और एलिप्सिस कुछ ऐसी चीजें नहीं हैं जो लगभग अक्सर उपयोग की जाती हैं। इसके अलावा, यदि किसी ब्लॉक की सामग्री का वर्तमान में संपादित किया जा रहा हिस्सा स्क्रीन के नीचे से काफी दूर रखा जाता है, तो फॉर्मेटिंग टूलबार को इसे ओवरलैप नहीं करना पड़ेगा।

यदि तल पर नियंत्रण रखना बहुत अजीब लगता है, तो ऐसा लगता है कि अगले सबसे अच्छा विकल्प उन सभी को शीर्ष पर रखना है। बेशक, पतले ब्लॉकों के लिए अजीब लगने वाले नियंत्रण का संभावित मुद्दा है।

डेस्कटॉप बनाम मोबाइल के मामलों में, आप आमतौर पर टूलबार की स्थिति को बदलने के साथ दूर हो सकते हैं। अभी स्वरूपण टूलबार और अन्य नियंत्रण वर्तमान में चयनित ब्लॉक के नीचे दिखाए जाते हैं और मोबाइल पर जगह लेते हैं।

व्यापक ब्लॉकों बनाम पतले ब्लॉकों के मामलों में, हालांकि, पतले ब्लॉकों के लिए चारों ओर बढ़ते नियंत्रण अजीब लग सकते हैं। सबसे सुसंगत रूप से शीर्ष पर स्वरूपण टूलबार और तल पर अन्य नियंत्रण हो सकते हैं। लेकिन यह हमें अतिव्यापी टूलबार और सामग्री ओवरलैप की बढ़ी हुई राशि के मुद्दे पर वापस लाता है।

गुटेनबर्ग को इस विचार के चारों ओर डिज़ाइन किया गया है कि चयनित ब्लॉक की उपस्थिति संपादन के लिए अनुकूलित है, इसलिए मुझे लगता है कि टूलबार लेने से भौतिक स्थान इतना खराब नहीं होता है, जब तक आप ब्लॉक का चयन करते हैं केवल ब्लॉक के चारों ओर सामान ले जाते हैं, और स्थानांतरित नहीं होते हैं चयनित ब्लॉक ही।

अंत में, मुझे लगता है कि ये मॉकअप अभी भी एक बहुत अच्छा विकल्प है। यह सही नहीं है, लेकिन यह एक पहुंच के दृष्टिकोण से समझ में आता है, यह बहुत अजीब नहीं लगता है, यह मोबाइल के अनुरूप है, और इसे शायद ही कभी अतिव्यापी टूलबार में परिणाम होना चाहिए।

यह कैसे काम करेगा इसके बारे में कुछ नोट्स:

नियंत्रण हॉवर पर कोई जगह नहीं लेता है, लेकिन ब्लॉक चुने जाने पर जगह नहीं लेता है। ब्लॉक को मँडराते समय, केवल तीर मूवर्स और इलिप्सिस को दिखाया जाता है, लेकिन ब्लॉक का चयन करने से स्वरूपण टूलबार प्रकट होता है, जो अन्य नियंत्रणों को नीचे की ओर धकेलता है। यह संभवतः इस डिजाइन के साथ सबसे बड़ा मुद्दा है। मुझे लगता है कि इस काम को सबसे अच्छा बनाने के लिए, आप चाहते हैं कि मूवर्स / एलिप्सिस टूलबार पर क्लिक करके ब्लॉक का चयन करते समय ब्लॉक की सामग्री को ऊपर की ओर धकेल दिया जाए, लेकिन आप टूलबार को स्थानांतरित करना चाहेंगे यदि आपने सामग्री क्षेत्र पर क्लिक करके ब्लॉक का चयन किया है।

जब कोई ब्लॉक सामग्री क्षेत्र के नीचे फैला होता है, तो तीर मूवर्स और इलिप्सिस ऑफ-स्क्रीन हो जाएगा, लेकिन प्रारूपण टूलबार दृश्यमान रहेगा, स्क्रीन के नीचे (या सामग्री संपादक क्षेत्र) से चिपचिपा हो जाएगा।

यदि यह सबसे अच्छा समाधान नहीं है, तो मैं मूल रूप से एक ही चीज के लिए जाऊंगा, लेकिन सभी शीर्ष पर नियंत्रण के साथ, मूवर्स / इलिप्सिस पतले ब्लॉकों के लिए स्वरूपण उपकरण पट्टी के ऊपर दिखाई दे रहा है, और शायद स्वरूपण नियंत्रण के बाईं ओर। विस्तृत ब्लॉक। मोबाइल अब भी वैसा ही दिख सकता है जैसा अभी है।

एक और विचार: आप दोनों स्थानांतरण नियंत्रण मुद्दे से छुटकारा पा सकते हैं और टूलबार एक दूसरे के मुद्दे को ओवरलैप कर रहे हैं यदि आपने बस होवर पर कोई नियंत्रण नहीं दिखाया है। इससे ब्लॉक के ऊपर और नीचे दोनों तरफ टूलबार दिखाना एक समस्या से बहुत कम होगा। लेकिन निश्चित रूप से, आप होवर पर दिखाए गए नियंत्रण होने के लाभों को खो देते हैं। मुझे वास्तव में यकीन नहीं है कि क्या वह दिशा है जो कोई भी जाना चाहता है, लेकिन मुझे आश्चर्य हो रहा है कि क्या यह आवश्यक है।

मेरा कहना है कि मंडराने वाले ब्लॉक ओवरलैपिंग का विचार मुझे पसंद नहीं है। मुझे कुछ और सोचने की जरूरत है। होवर पर संभावित रूप से अलग-अलग स्थान लेने वाले नियंत्रण का विचार थोड़ा अजीब लगता है।

नियंत्रण हॉवर पर कोई जगह नहीं लेता है, लेकिन ब्लॉक चुने जाने पर जगह नहीं लेता है। ब्लॉक को मँडराते समय, केवल तीर मूवर्स और इलिप्सिस को दिखाया जाता है, लेकिन ब्लॉक का चयन करने से स्वरूपण टूलबार प्रकट होता है, जो अन्य नियंत्रणों को नीचे की ओर धकेलता है। यह संभवतः इस डिजाइन के साथ सबसे बड़ा मुद्दा है।

मुझे लगता है कि यह मोक्स के साथ एक बड़ा मुद्दा है। और क्या हो सकता है?

जब भी पृष्ठ बिल्डरों को देखना एक पहलू है, तो अन्य ऐप्स और उत्पादों के बारे में क्या है? क्या यह कहीं और हल है?

@karmatosed

जब भी पृष्ठ बिल्डरों को देखना एक पहलू है, तो अन्य ऐप्स और उत्पादों के बारे में क्या है? क्या यह कहीं और हल है?

यूटी के एनालॉग उदाहरणों को खोजने की कोशिश करना, जो गुटेनबर्ग का उपयोग कर सकते हैं, मुश्किल है, क्योंकि गुटेनबर्ग के पास सभी चीजों के लिए लगभग कुछ भी नहीं है।

बहुत सारे सरल / पुराने पेज बिल्डर प्लगइन्स को अपने ब्लॉक के समकक्ष सामग्री को कवर करने के बारे में चिंता करने की ज़रूरत नहीं है, क्योंकि सभी सामग्री संपादन एक मोडल या साइडबार में किया जाता है। यह उनके मॉड्यूल नियंत्रण को सामग्री को ओवरलैप करने की अनुमति देने के लिए मुक्त करता है।

यहां तक ​​कि दिवी या बीवर बिल्डर जैसे मामलों में, जहां आप मोडल / साइडबार को खोले बिना पाठ को संपादित कर सकते हैं, मोडल / साइडबार अभी भी संपादन का प्राथमिक तरीका है। डिवाई और बीवर बिल्डर दोनों दिखाते हैं कि अनिवार्य रूप से फ्रंट-एंड की एक परिपूर्ण प्रतिकृति है, बिना किसी चीज़ के अनुकूलन के लिए उन्हें एक टेक्स्ट एडिटर के रूप में उपयोग करने की चिंता करने या यह सुनिश्चित करने के बिना कि प्रमुख ब्लॉक सामग्री के बहुमत को इनलाइन पर संपादित किया जा सकता है खंड।

इसके अतिरिक्त, दोनों पृष्ठ बिल्डरों और अन्य बिल्डर- ish UIs में, घोंसले के शिकार होने पर प्रतिबंध के कारण समस्या कम हो जाती है। Divi का एक सख्त खंड है → रो (निर्मित स्तंभों के साथ) → मॉड्यूल सेटअप (कुछ सामान्य नेस्टेड कॉलम संतृप्ति के लिए तैयार कुछ विशेष खंडों के साथ)। बीवर बिल्डर केवल स्तंभों में स्तंभित होने की अनुमति देता है, जैसा कि एलिमेंट करता है। वे एकमात्र प्रकार की वस्तु को नियंत्रित करते हैं जिसमें घोंसले के शिकार की कई परतें हो सकती हैं। सब कुछ डिफ़ॉल्ट रूप से एक पंक्ति के साथ एक अनुभाग में है। कस्टम ब्लॉक के किसी भी संयोजन के लिए संभावित रूप से नेस्टेड ब्लॉक की कोई असीमित परत नहीं है जो कि विभिन्न उद्देश्यों और विभिन्न शैलियों के लिए नेस्टिंग का उपयोग करता है जैसे कि गेनबर्ग अनुमति देता है।

Divi वर्गों, पंक्तियों और मॉड्यूल के लिए अपने नियंत्रणों को रंगीन कर सकता है क्योंकि इसकी एक सख्त संरचना है और कोई भी कस्टम मॉड्यूल नहीं हो सकता है जो अनुभाग या पंक्ति का कार्य करता है। (यह एक ही लाइन पर कई आवेषण बटन दिखाने की भी अनुमति देता है, लेकिन अलग-अलग रंगों के साथ यह भेद करने के लिए कि प्रत्येक क्या करेगा।) अधिकांश बिल्डरों में, मॉड्यूल लेआउट तत्वों से अलग होते हैं। बीवर बिल्डर मॉड्यूल और लेआउट तत्वों के अलगाव के कारण इसी तरह की चीजें कर सकता है।

यदि आप उन चीजों को देखते हैं जो पृष्ठ निर्माता नहीं हैं, तो पाठ संपादकों की तरह, आप देख सकते हैं कि उन सभी चीजों के बारे में चिंता करने की ज़रूरत नहीं है जो पृष्ठ बिल्डरों से निपटना है। यदि आप अधिकांश पृष्ठ बिल्डरों को देखते हैं, तो वे सीधे इनलाइन WYSIWYG नियंत्रणों के माध्यम से पाठ संपादक सामग्री को संभालते नहीं हैं।

गुटेनबर्ग जो करने की कोशिश कर रहा है वह अद्वितीय है। यह एक WYSIWYG- अपवाद-के लिए-चयनित-ब्लॉक-कौन-से-अनुकूलित-फॉर-एडिटिंग पेज बिल्डर है जो एक पूर्ण पाठ्य संपादक भी है, और वर्गों से लेकर कॉलम तक सब कुछ एक ही तरह का है। ऑब्जेक्ट का: ब्लॉक।

मूल रूप से, यह एक जटिल मुद्दा है क्योंकि गुटेनबर्ग एक ही समय में कई अलग-अलग चीजें करने की कोशिश कर रहे हैं जो प्रतीत होता है कि कुछ और करने की कोशिश नहीं करता है। : Stuck_out_tongue:

वैसे भी, यहां उन चीजों की एक सूची है जो देखने के लिए देखी जा सकती हैं कि वे ब्लॉक / मॉड्यूल / विजेट यूआई को कैसे संभालते हैं:

वर्डप्रेस प्लगइन्स / थीम

• अवदा (फ्यूजन बिल्डर)
• BeTheme (मफिन बिल्डर)
• बीवर बिल्डर
• दिवि (दिवि बिल्डर)
• Elementor
• ऑक्सीजन
• SiteOrigin पेज बिल्डर
• आर्किटेक्ट का काम
• दृश्य संगीतकार
• Themeco द्वारा X & Pro

वर्डप्रेस के बाहर वेबसाइट बनाने वाले

• Drupal
• Squarespace
• Weebly
• Wix

ऐसी चीजें जो पृष्ठ निर्माता नहीं हैं, लेकिन एक के समान हैं

• MailChimp
• धारणा

वो सब मैं अभी जानता हूँ।

सिबलिंग इंसुलेटर के साथ एक समस्या है: यह हमेशा चयनित ब्लॉक की सामग्री को ओवरलैप करता है। यह समस्या तब और भी बदतर हो जाती है जब आप गुटेनबर्ग को अधिक WYSIWING बनाने के लिए प्रत्येक ब्लॉक पर स्वचालित मार्जिन जैसी चीजों से छुटकारा पाने की कोशिश करते हैं।

समाधान? ठीक है, अगर हम ब्लॉक के निचले हिस्से में एक बार जोड़ने जा रहे हैं, तो सिबलिंग इंसुलेटर को उस बार में भी क्यों नहीं फेंकना चाहिए?

इसके अलावा, मैं बस होवरेड वैरिएंट पर बॉर्डर बनाने का एक तरीका लेकर आया हूं, थोड़ा कम झुंझलाता हुआ। बस सीमा के रंग को बदलें जो नीचे की पट्टी से ब्लॉक सामग्री को विभाजित करता है!

लाभ में शामिल हैं:

• सिबलिंग इंसुलेटर कभी भी चयनित ब्लॉक की सामग्री को ओवरलैप नहीं करता है। इसका मतलब यह है कि अब कोई यूआई नहीं होना चाहिए जो कभी भी चिपचिपा स्वरूपण टूलबार को छोड़कर चयनित ब्लॉक की सामग्री को ओवरलैप करता है, जो सामग्री को कवर नहीं करता है यदि आप बस ऊपर की ओर स्क्रॉल करते हैं या केवल टाइप कर रहे हैं और माउस को स्थानांतरित नहीं कर रहे हैं।
• सिबलिंग इंसुलेटर अब उसी क्रम में दिखाई देता है जो HTML टैब क्रम में होता है, जो एक्सेसिबिलिटी के लिए अच्छा है।
• सिबलिंग इंसुलेटर अब ऊपर के बजाय नीचे के ब्लॉक में दिखाई देता है। यह अधिक समझ में आता है, मेरी राय में।
• सिबलिंग इंसुलेटर हमेशा चयनित ब्लॉक के लिए दिखाई देता है (शायद तब जब टाइपिंग को नियंत्रित किया जाता है, जैसे कि अभी भी अदृश्य हैं जैसे वे अभी हैं)
• मोबाइल यूआई के साथ संगति।
• ब्लॉक के सभी मार्जिन और इनर पैडिंग को हटाया जा सकता है, और ब्लॉक बॉर्डर को ब्लॉक के वास्तविक आकार में बदल दिया जा सकता है, सभी बिना ब्लॉक यूआई के ब्लॉक की सामग्री के रास्ते में हो सकता है।

बोनस पॉइंट्स अगर सिबलिंग इंसुलेटर को एक खाली पैराग्राफ ब्लॉक डालने के बजाय सीधे इन्सर्ट मेनू को खोलने के लिए बदला जाता है (जैसा कि # 7271 में चर्चा की गई है)।

बेशक, जब आप ब्लॉक को चयनित के ऊपर लहराते हैं तो क्या होता है, यह सवाल अभी भी एक मुद्दा है। हालाँकि, मुझे नहीं लगता कि यह वास्तव में मुझे परेशान करता है। आपको बस इसे चुनने के लिए ब्लॉक पर क्लिक करना है और नियंत्रण देखना है, और यदि होवर नियंत्रण वर्तमान में चयनित ब्लॉक के नीचे दिखाया गया है, तो यह ठीक है क्योंकि चयनित ब्लॉक को फोकस माना जाता है।

मुझे लगता है कि यह आगे बढ़ने के लिए एक अच्छा डिज़ाइन है। मुझे लगता है कि सभी सकारात्मक नकारात्मक को पछाड़ते हैं, और मुझे लगता है कि यह निश्चित रूप से बेहतर है जो अभी मौजूद है। आप लोगों का क्या विचार है?

मैंने मज़ाक उड़ाया कि यह कैसे दिखता है यदि शीर्ष और नीचे दोनों टूलबार ओवरलैप करते हैं, और यह कैसे दिखेगा यदि हॉवर किए गए ब्लॉक हमेशा चयनित ब्लॉक पर उच्चतम जेड-इंडेक्स लेते हैं।

मुझे यह बहुत पसंद है, लेकिन इसकी एक छोटी सी समस्या है ... सिंगल लाइन ब्लॉक भाग्य से बाहर हैं, क्योंकि वे नीचे नियंत्रण पट्टी के नीचे लगभग पूरी तरह से छिपे होंगे।

@chrisvanpatten मैं सोच रहा था कि ब्लॉक चुने जाने पर नीचे की पट्टी वास्तव में जगह ले लेगी। मुझे लगता है कि सिंगल-लाइन ब्लॉक समस्या को ठीक कर देगा। क्या आप यह दिखाने के लिए मॉकअप बना सकते हैं कि यह कैसा दिखता है? इसके अलावा, यह क्या है अगर मंडराया हुआ ब्लॉक चयनित ब्लॉक को ओवरलैप नहीं करता है?

इसके अलावा, शायद नीचे पट्टी के नीचे एक छाया होना चाहिए जब यह कुछ ओवरलैप करता है।

@SuperGeniusZeb मैं वास्तव में दृढ़ता से विरोध करता हूं कि नीचे की पट्टी जगह लेती है - जिससे यूआई कूदता है। पुन: प्रयोज्य ब्लॉक करते हैं कि अब जब आप उन्हें चुनते हैं और यह मुझे पागल कर देता है।

(संपादित करें: विस्तृत करने के लिए, यह माउस उपयोगकर्ताओं के लिए चीजों को वास्तव में कठिन बना देता है क्योंकि आप वास्तव में एक ही क्षण से दूसरे स्थान पर एक ही स्थान पर होने वाली चीजों पर भरोसा नहीं कर सकते। यह बहुत अजीबता का कारण बनता है।)

@chrisvanpatten

मैं मुख्य रूप से सोच रहा हूं कि पोस्ट लिखने के संदर्भ में, आप शायद जिस टाइप में टाइप कर रहे हैं उसके नीचे के पैराग्राफ को कवर नहीं करना चाहेंगे। अभी यह ऐसा दिखता है कि चयनित पैरा के नीचे पैरा ब्लॉक अपनी पहली पंक्ति को याद कर रहा है। मुझे लगता है कि जब आप वर्तमान में संपादन कर रहे हैं तो मैं ब्लॉक के शीर्ष को तब पसंद करूंगा जब आप किसी एक को चुनते हुए ब्लॉक के शीर्ष को नहीं देख पाएंगे। व्यक्तिगत रूप से, आसपास कूदना मुझे ज्यादा परेशान नहीं करता है।

जब आप इसे चुनते हैं तो आकार बदलने के लिए गुटेनबर्ग में यह काफी सामान्य है: छवि कैप्शन प्लेसहोल्डर, उद्धरण उद्धरण प्लेसहोल्डर्स, गैलरी में प्लेसहोल्डर / सम्मिलन, और पुन: प्रयोज्य ब्लॉक, जैसा कि आपने उल्लेख किया है। गुटेनबर्ग को आमतौर पर इस विचार के इर्द-गिर्द बनाया गया है कि जब इसे चुना जाता है तो ब्लॉक की उपस्थिति को संपादन के लिए अनुकूलित किया जाना चाहिए। मैं कहूंगा कि नीचे की जगह को ऊपर ले जाने के कारण ब्लॉक की ऊंचाई को लंबा करना ठीक है।

वैकल्पिक रूप से, शायद नीचे पट्टी को अर्ध-पारदर्शी बनाया जा सकता है ताकि यह थोड़ा और स्पष्ट हो सके कि इसके नीचे एक ब्लॉक है? वह कैसा लगता है? मुझे लगता है कि मैं इसके साथ ठीक हो सकता हूं।

एकमात्र समस्या यह है कि गुटेनबर्ग यूआई में कहीं और पारदर्शिता का उपयोग नहीं किया जाता है। यह कहने के लिए नहीं है कि इसका उपयोग नहीं किया जाना चाहिए ... बस यह कि इसका कोई मौजूदा उदाहरण नहीं है, इसलिए हम एक यूआई डिजाइन असंगति पेश कर सकते हैं।

बाएं और दाएं पर नियंत्रणों के बीच खाली जगह से छुटकारा पाने का विचार भी है, लेकिन इससे पहले यूआई लुक को भी "रुकावट" बनाने के कारण टिकट में नीचे गोली मार दी गई थी।

@chrisvanpatten सभी ने कहा, मुझे लगता है कि मैं अभी भी आपके मॉकअप को पसंद करूंगा जो अभी मौजूद है । पहली पंक्ति का निम्नलिखित-ब्लॉक-प्रकट-से-लुप्त समस्या उन सभी चीज़ों की तुलना में मामूली है, जो या तो हमारे मॉकअप को ठीक कर देगी।

@SuperGeniusZeb मुझे लगता है कि यह इस मामले में विशेष रूप से अजीब बनाता है कि जब आप मंडराते हैं तो नियंत्रण वहां होता है। जंपिंग नियंत्रण के अन्य सभी उदाहरणों के साथ, कम से कम वे वहां नहीं हैं जब आप मँडराते हैं, तो वे केवल चयन पर होते हैं।

मुझे नहीं लगता कि यह हॉवर / सिलेक्ट / जंप / सिंगल-लाइन पैराग्राफ मुद्दों के कारण छोड़ने लायक है, लेकिन निश्चित रूप से थोड़ी और सोच की जरूरत है।

मुझे अभी भी विश्वास है कि यहाँ कहीं न कहीं एक समाधान है ... बस इसे जारी रखना है!

@chrisvanpatten

मुझे लगता है कि इस मामले में यह विशेष रूप से अजीब है कि जब आप मँडराते हैं तो नियंत्रण वहाँ होता है। जंपिंग नियंत्रण के अन्य सभी उदाहरणों के साथ, कम से कम वे वहां नहीं हैं जब आप मँडराते हैं, तो वे केवल चयन पर होते हैं।

ठीक है ... आप _could_ के पास होवर पर कोई नियंत्रण नहीं है, लेकिन मुझे लगता है कि यह मान लेना सुरक्षित है कि वास्तव में कोई भी ऐसा नहीं चाहता है। मुझे पता है कि मैं निश्चित रूप से उन नियंत्रणों को पसंद करता हूं जो हॉवर पर उपलब्ध हैं।

वैसे भी, पारदर्शिता के बारे में कैसे?

और अगर आप थोड़ा सपना देखना चाहते हैं और चाहते हैं कि सभी प्रमुख ब्राउज़रों में backdrop-filter लागू हो, तो आप कुछ धुंधला जोड़ सकते हैं:

यह 60% अस्पष्टता है, वैसे।

अस्पष्टता निश्चित रूप से मदद करती है, लेकिन मैं अस्पष्टता को समीकरण में पेश करने के बारे में अनिश्चित हूं। यह ठगा सा महसूस होता है।

@chrisvanpatten वास्तव में, यह धोखा देने जैसा महसूस होता है ... लेकिन हमारे पास और क्या विकल्प हैं?

हम नियंत्रणों को पक्ष में नहीं रख सकते, इसलिए यह समस्या पहले स्थान पर है।

हम ब्लॉक के भीतर नियंत्रण नहीं रख सकते, क्योंकि यह सामग्री को कवर करेगा।

हम पहले से ही फॉर्मेटिंग बार होने और उन मुद्दों के कारण शीर्ष पर नियंत्रण नहीं रख सकते हैं जो पतले ब्लॉकों के कारण होंगे।

नियंत्रण को नीचे रखना सबसे अधिक समझ में आता है क्योंकि यह एक्सेसिबिलिटी के लिए बेहतर काम करता है, सिबलिंग इंसुलेटर और ड्रैग हैंडल दोनों में फेंकने के लिए एक सुविधाजनक स्थान प्रदान करता है और उन से संबंधित मुद्दों को हल करता है, जो मोबाइल के साथ अधिक सुसंगत है, और पतले के लिए सबसे अच्छा काम करता है ब्लॉक।

नीचे पट्टी द्वारा उठाए गए स्थान को कम करने के लिए, वास्तव में केवल कुछ चीजें हैं जो हम कर सकते हैं:

• बार की ऊंचाई घटाएं।
• आवेषण / मूवर्स / ड्रैग हैंडल और दीर्घवृत्त के बीच की खाली जगह को हटा दें।
• एलिप्सिस को बाईं ओर पुश करें और दाईं ओर के अतिरिक्त स्थान को हटा दें।
• इसे चुने जाने पर जगह लें। (लेकिन आप यह नहीं चाहते हैं।)

इसके अलावा, जो कुछ भी किया जा सकता है वह इसे नेत्रहीन हल्का महसूस करने के लिए अर्ध-पारदर्शी बना रहा है और यह देखना आसान बनाता है कि इसके नीचे क्या है।

एक और विचार: हो सकता है कि पारदर्शिता की बात धोखा देने की तरह महसूस नहीं होगी अगर _both_ टूलबार केवल नीचे के बजाय पारदर्शी थे।

ऊपर बताई गई कुछ चीजों को आजमाने के लिए कुछ और मॉकअप बनाए।

पारदर्शी टूलबार:

कोई पारदर्शिता नहीं:

मुझे लगता है कि मैं वास्तव में पारदर्शिता के बिना इसे पसंद करता हूं। तुम क्या सोचते हो? मुझे लगता है कि नीचे की पट्टी की चौड़ाई को कम करने से ओवरलैपिंग-स्टार्ट-ऑफ-नेक्स्ट-ब्लॉक समस्या हल हो गई है। बेशक, यह अभी भी छोटी चौड़ाई में होगा ... लेकिन यह पहले से ही वैसे भी स्वरूपण टूलबार के साथ होता है, इसलिए मुझे नहीं लगता कि यह वास्तव में यहां एक समस्या है।

यह भी ध्यान दें कि मैंने ड्रैग हैंडल के लिए थोड़ी जगह छोड़ दी है। यह ड्रैग हैंडल्स को दर्शाने के लिए अक्सर ऐप में उपयोग किए जाने वाले डॉट्स को थोड़ा खींचा जा सकता था, या होवर या हर समय दिखाए गए ड्रैग आइकन हो सकते थे। या यह सिर्फ खाली रह सकता है। यह तकनीकी रूप से थोड़ा पतला भी हो सकता है, लेकिन मैंने इसे आराम के लिए एक बटन की चौड़ाई पर छोड़ दिया।

यह हो सकता है? क्या वर्तमान में इसे बदलने के लिए पुनरावृति काफी अच्छी हो सकती है? _ (कृपया "हां" कहें।: अटक_आउट_टॉन्ग:) _

यहां किए गए सभी अन्वेषणों के लिए सभी को धन्यवाद। केवल एक और कारण को जोड़ने के लिए कूदना अर्ध-पारदर्शिता आदर्श नहीं है: पृष्ठभूमि के साथ चिह्न विपरीत अनुपात 4.5: 1 होना चाहिए। अर्ध-पारदर्शिता का उपयोग करना असंभव बना देगा, बस प्रचलित गहरे रंगों के साथ एक छवि के बारे में सोचें, या एक अंधेरे पृष्ठभूमि के साथ एक पैराग्राफ, या एक अंधेरे पृष्ठभूमि के साथ एक विषय:

यहाँ उत्कृष्ट चर्चा के लिए धन्यवाद। यह उस जुनून को देखने के लिए दिल से प्रसन्न और आनंदमय है जिसके साथ यह चुनौती है।

मैं दूर से थोड़ा देख रहा हूं, ब्लॉक के प्रारंभिक कॉन्फ़िगरेशन को डिज़ाइन किया है - एक डॉक किए गए टूलबार के साथ, ऊपर / नीचे तीर, और अंत में दाईं ओर दीर्घवृत्त। मैंने अवयवों को इसलिए जोड़ा क्योंकि मुझे लगा कि मूवर्स प्राइम रियल एस्टेट को ड्रैग एंड ड्रॉप के विकल्प के रूप में देना बहुत ही उपयोगी है, जो अक्सर फिजूल होता है और त्रुटि की संभावना होती है, जबकि मूवर्स हमेशा अपने व्यवहार में पूर्वानुमानित होते हैं।

मैं नेस्टेड ब्लॉक्स के लिए इस तरह की चुनौतियों को पूरी तरह से पहचानता हूं, और मैंने लंबे समय से सोचा है कि सबसे अच्छा समाधान क्या था। मास्टर में क्या है - अगर नेस्टेड काम करता है, तो भी बाएं और दाएं ओवरलेइंग करें, लेकिन यह या तो महान नहीं है, मैं यह स्वीकार करता हूं। एक अन्य विकल्प मोबाइल यूआई का उपयोग करना है - चयनित होने पर ब्लॉक के नीचे यूआई दिखाएं, जो कि यहां विभिन्न वेरिएंट में नकली है, विशेष रूप से मोबाइल के लिए। लेकिन डेस्कटॉप पर यह बहुत ही विघटनकारी और उछल बन सकता है जब आप बस एक छोटे से संपादन करने के लिए एक पैराग्राफ का चयन करना चाहते हैं और सब कुछ कूद जाता है। इसी तरह अगर टूलबार नवीनतम संस्करण की तरह ओवरलैड हो जाता है, तो ऐसा लगता है कि यह लेखन अनुभव से बहुत दूर झुक रहा है, लेआउट अनुभव में। यह निरंतर संतुलन है जिसे हमने हासिल करने की कोशिश की है।

एक दूसरा विकल्प यह है कि वायाए ओल्ड मॉकअप के लिए वापस जाना है, यह एक:

शायद कुछ मोड़ के साथ, यह हो सकता है:

लेकिन मुझे वह पसंद नहीं है। और _either_ यह मूवर्स को केवल तभी दिखाई देगा जब ब्लॉक मँडरा जाएगा, या हम उपचार को थोड़ा मोड़ना चाहते हैं। यह बटन हिट क्षेत्रों को कई पिक्सेल छोटे बनाता है, जो प्रयोज्य के लिए महान नहीं है।

जैसे, अब तक उन वेरिएंट पर विचार नहीं किया गया है क्योंकि वे हमारे पास जो कुछ भी था उससे बेहतर महसूस नहीं करते थे। हालाँकि यहाँ पोस्टिंग की परवाह किए बिना वे इसे काम करने के लिए उपचार के लिए प्रेरित कर सकते हैं।

होवर लेबल के साथ ब्लॉक टूल के संयोजन के साथ मुझे जो सबसे बड़ा मुद्दा दिखाई दे रहा है, वह यह है कि यह चयनित और होवर ब्लॉक के बीच असंगतता पैदा करता है, जब तक कि आप चयनित ब्लॉक के लिए लेबल दिखाना शुरू नहीं करना चाहते। और यदि आप ऐसा करते हैं, तो लेबल ब्लॉक सीमाओं के भीतर नहीं होना चाहिए, बल्कि इसके बाहर होना चाहिए।

लेकिन अगर आप ऐसा करते हैं, तो आप ब्लॉक के शीर्ष पर बहुत अधिक नियंत्रण रखने और यह पता लगाने के लिए दौड़ते हैं कि कैसे विस्तृत और पतले दोनों ब्लॉक के अनुरूप हो।

मुझे दृढ़ता से लगता है कि, चिपचिपा टूलबार के अपवाद के साथ, जो स्क्रीन पर रहते हैं, मानक चयनित ब्लॉक UI में से कोई भी उस ब्लॉक के किसी भी हिस्से को कवर नहीं करना चाहिए।

तल पर ब्लॉक टूल होने से सिबलिंग इंसुलेटर लगाने के लिए एक अच्छा स्थान प्रदान करता है, जो दोनों को उपरोक्त नो-ओवरलैप लक्ष्य प्राप्त करने में मदद करता है, जबकि सिबलिंग इंसुलेटर को अधिक दृश्यमान बनाता है और अपने स्वयं के अतिव्यापी मुद्दों को हल करता है। (मुझे लगता है कि उद्धरण ब्लॉक के लिए नेस्टेड ब्लॉक अपडेट अभी तक सिबलिंग इंसर्टर्स को ओवरलैप करने के कारण नहीं हुआ है।)

सिबलिंग इंसुलेटर और एक्सेसिबिलिटी बेनिफिट्स के कारण, मुझे लगता है कि ब्लॉक के नीचे होना ब्लॉक टूल्स लगाने के लिए सबसे अच्छा संभव स्थान है।

अब, मैंने यह नहीं सोचा था कि नियंत्रण को बहुत छोटा करना टेबल पर था, क्योंकि उन्हें छोटा करने से उन्हें उपयोग करने में मुश्किल हो सकती है, ज़ाहिर है। हालाँकि, जब से आप इसके खिलाफ प्रतीत नहीं होते हैं, तब इसे आज़माएं क्यों नहीं?

यह कैसा है?

नीचे पट्टी में बटन (लेकिन आइकन नहीं) 38px से 32px के आकार में कम हो गए हैं, और मैंने पिछले मॉकअप से मावर कंट्रोल के बीच रिक्ति में एक असंगतता तय की है। ध्यान दें कि यदि आप दीर्घवृत्त बटन दूसरों की तुलना में पतला था (जैसे संपादक के शीर्ष पट्टी में एक) तो आप इसे थोड़ा छोटा कर सकते हैं।

आप बार को कम जगह लेने के लिए खाली ड्रैग हैंडल क्षेत्र के आकार को भी कम कर सकते हैं। यह और भी व्यवहार्य होगा यदि बार में सभी नियंत्रण ड्रैग हैंडल के रूप में दोगुने हो जाते हैं, जैसे कि GNOME कार्य में विंडोज़ के शीर्ष बार कैसे होते हैं।

ध्यान दें कि मोबाइल पर, नियंत्रण संभवतः लगभग वैसा ही दिखेगा जैसा वे master , जहां बार स्पेस लेते हैं और इसलिए उन्हें बड़ा करना कोई समस्या नहीं है। इस आकार में कमी केवल डेस्कटॉप उपयोगकर्ताओं को प्रभावित करती है, और इस आकार पर नियंत्रण अभी भी प्रयोग करने योग्य है।

मैंने एक शीर्ष टूलबार में नियंत्रणों को स्थानांतरित करने के साथ एक छोटा अन्वेषण भी किया, जो समस्याओं के एक सेट को हल करता है ... लेकिन जब आप ब्लॉक का चयन करते हैं, तो आप वापस एक सब कुछ टूलबार के पास होते हैं जो संकीर्ण संदर्भों में काम नहीं करता है, जो एक था पहले स्थान पर इस अन्वेषण का महत्वपूर्ण कारण।

मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि मैं उन आखिरी मॉकअप के बारे में कैसा महसूस करता हूं। नीचे से लटकते हुए नियंत्रण मुझे अजीब लगता है। मुझे यकीन नहीं है कि मेरे पास एक बेहतर विचार है, यह सिर्फ इतना है कि यह हमें उस तरह के अवरोधक / खंडित महसूस करता है जो @karmatosed से बचना चाहते थे।

यहां सभी कार्यों के लिए सभी को धन्यवाद। मैं कुछ प्रतिक्रिया देने की कोशिश करने जा रहा हूं, लेकिन मुझे अभी कहना है कि मुझे नहीं लगता कि यह प्रोटोटाइप में जाने के लिए तैयार है। मुझे अभी भी लगता है कि घोंसले के शिकार होने की समस्याएँ हैं और हल करने के लिए अलग-अलग डिवाइस भी हैं लेकिन जैसा कि मैंने पिछली टिप्पणियों में बताया था कि मुझे नहीं लगता कि वर्तमान ट्रैक सही है। मुझे लगता है कि हम भी उस क्षेत्र में वापस आ रहे हैं जिसका मैंने पहले ही सुझाव दिया था कि हम इससे बचते हैं।

मैं खोज को हतोत्साहित नहीं करना चाहता, लेकिन अभी मैं वैकल्पिक सुझावों पर विचार करने का सुझाव दूंगा। बड़ी समस्या यह है कि नीचे की ओर आधा टैब जोड़ने से लाभ के बिना दृश्य घनत्व बढ़ रहा है। आइए इस बारे में सोचें कि हम यहां क्या हल करने की कोशिश कर रहे हैं:

• विभिन्न उपकरणों पर क्या होता है।
• सहोदर डालने (हालांकि यह अन्य मुद्दों में तय किया जा सकता है) या कम से कम यह कैसे बातचीत करता है।
• घोंसले के शिकार दृश्यता और सहजता।

इस सब में प्राथमिक ड्राइव यह था कि यह कैसे प्रतिक्रिया देता है और घोंसला बनाता है।

आइए इस बात पर विचार करें कि यदि हम प्रयोज्यता बढ़ा रहे हैं या घटा रहे हैं तो हम क्या बनाते हैं। उदाहरण के लिए, पारदर्शिता और परतों जैसी चीजों का उपयोग करना सामान्य दृष्टि वाले किसी व्यक्ति के लिए ठीक है, वे बहुत सारे अन्य लोगों के लिए इसे बेहतर नहीं बनाते हैं। जटिल लेआउट के बारे में सोचें, जिनमें वीडियो और बहुत सारी छवियां हैं। इस घनी सूचना संरचना में जो सुझाव दिया जा रहा है वह पकड़ में नहीं आता है।

जटिल लेआउट के बारे में सोचें, जिनमें वीडियो और बहुत सारी छवियां हैं। इस घनी सूचना संरचना में जो सुझाव दिया जा रहा है वह पकड़ में नहीं आता है।

हाँ, मुझे लगता है कि यह सबसे बड़ा बिंदु है, और मैं उस घनत्व को वास्तव में _compounds_ को छोटे स्थानों में जोड़ दूंगा जो चुनौती का एक और हिस्सा है। नेस्टेड ब्लॉक को आम तौर पर सभी समान नियंत्रणों की आवश्यकता होती है जो गैर-नेस्टेड ब्लॉक की आवश्यकता होती है, लेकिन उन्हें इसे अंतरिक्ष के एक अंश के साथ करने की आवश्यकता होती है, और आदर्श रूप से गैर-अनूठे तरीके से (जैसे नेस्टेड ब्लॉक आमतौर पर गैर-नेस्टेड ब्लॉक से मिलते जुलते होने चाहिए; प्रयोज्य)।

ड्राइंग बोर्ड पर वापस……

मुझे लगता है कि मेरा मॉकअप मौजूदा यूआई से बेहतर है

मैं एक ब्लॉकी लुक से बचने की इच्छा को समझता हूं, लेकिन मुझे अभी तक कुछ भी ऐसा नहीं मिला है, जो ब्लॉकी-लुकिंग न हो, फिर भी सिर्फ कार्यात्मक हो। समस्या यह है कि आपको उस ब्लॉक के किनारों को जानना होगा, जिसमें आप काम कर रहे हैं, और आप चाहते हैं कि दोनों ब्लॉक में सामग्री को कवर न करें, साथ ही ब्लॉक के बाहर भी कवर करें। यह बहुत ज्यादा कुछ हद तक एक दिखावटी गारंटी देता है।

बस इस मुद्दे के शीर्ष पर स्क्रीनशॉट को देखते हुए, आप देख सकते हैं कि कैसे एक बिंदु पर गुटेनबर्ग एक बहुत संयुक्त राष्ट्र के ब्लॉक-यूआई था। लेकिन उस UI के साथ समस्या यह थी कि यह बताना मुश्किल था कि एक ब्लॉक के किनारे कहां थे। इसलिए हमारे पास अब हमारे पास UI है।

और जब आप सिबलिंग इंसुलेटर के साथ मुद्दों में फेंकते हैं, तो आपको पता चलता है कि सिबलिंग इंसुलेटर बटन को ब्लॉक के कंटेंट बॉर्डर के बाहर होना चाहिए। उस बिंदु के साथ मिलाएं जिसे आप आमतौर पर वर्तमान एक के बाद (पहले के बजाय) ब्लॉक करना चाहते हैं और साथ ही बढ़ती पहुंच की इच्छा भी रखते हैं, और आप मेरे नवीनतम मॉकअप की तरह कुछ होने के लिए हवा देते हैं।

व्यक्तिगत रूप से, मैं इस ब्लॉक यूआई को पहले मॉकअप की तरह दिखने वाली चीज़ पर पसंद करूंगा। वे पहले मॉकअप सामग्री और नियंत्रण के बीच सीमा की कमी के कारण भ्रमित दिखते हैं, और बार बहुत सारे अनावश्यक स्थान खाते हैं। चूंकि हम UI को कूदना नहीं चाहते हैं, इसलिए नीचे की पट्टी को चयनित ब्लॉक के बाहर की सामग्री पर एक ओवरले होना चाहिए, और इसलिए यह जितना संभव हो उतना छोटा होना चाहिए।

इसके अतिरिक्त, मुझे लगता है कि मेरा मॉकअप निश्चित रूप से वर्तमान के मुकाबले नेस्टेड संदर्भों में बेहतर है। जैसा कि मैं नीचे बताऊंगा, ओवरलैपिंग टूलबार / सामग्री की स्थिति पिछले एक की तुलना में इस यूआई के साथ बेहतर है। और नेस्टेड संदर्भों में, आपको एक ब्लॉक की सीमाओं को और भी अधिक जानने की जरूरत है, इसलिए कुछ हद तक अवरुद्ध रूप वास्तव में इस स्थिति में मदद करता है।

ओवरलैपिंग टूलबार कम भ्रमित और कम होने की संभावना है, क्योंकि ब्लॉक छोटे स्क्रीन पर क्षैतिज रूप से छोटे होने की तुलना में

नेस्टेड संदर्भों में, वर्तमान के ऊपर ब्लॉक पर मँडराते हुए नीचे ब्लॉक की सभी सामग्री को लगभग कभी भी कवर नहीं किया जा सकता है, क्योंकि या तो ब्लॉक सभी को कवर नहीं करने के लिए नीचे बार के लिए पर्याप्त चौड़ा होगा, या अन्यथा ब्लॉक निष्पक्ष रूप से होगा लंबा और इसलिए इसे चुनने के लिए अभी भी कमरा होगा।

इसके अतिरिक्त, ब्लॉक का निचला बार केवल तब दिखाई देना चाहिए जब आप ब्लॉक को हॉवर करते हैं, और न केवल तब जब आपका माउस इसके पास हो। ब्लॉकों के किनारों पर अजीब, अदृश्य ड्रैग हैंडल के कारण, यह वर्तमान यूआई के साथ ऐसा नहीं है।

ऊपर के बिंदु पर जोड़ने के लिए, यह केवल वर्तमान के ऊपर का ब्लॉक है जो चयनित ब्लॉक में कुछ भी कवर कर सकता है। अन्य 3 पक्ष पूरी तरह से ठीक हैं, क्योंकि एक क्षैतिज रूप से समीपवर्ती ब्लॉक को मँडराने से वर्तमान ब्लॉक में कुछ भी नहीं होगा, और होवर किए गए ब्लॉक में ऊपर यूआई नहीं है, इसलिए चयनित एक के नीचे के ब्लॉक को मँडराते हुए ठीक है।

इसके अतिरिक्त, आप बस होवर किए गए ब्लॉक नहीं बनाने का विकल्प चुन सकते हैं जो वर्तमान में चयनित एक को कवर नहीं करते हैं, और इसके परिणामस्वरूप शून्य संदर्भों में चयनित ब्लॉक के साथ वस्तुतः शून्य ओवरलैपिंग मुद्दे होंगे। चूंकि होवर किए गए ब्लॉक केवल तल पर एक बार होते हैं, इसलिए वर्तमान में नीचे वाला कभी चयनित नहीं होगा। केवल एक चीज जो आप इस स्थिति में छोड़ते हैं, वह ब्लॉक टूल के लिए वर्तमान के ऊपर ब्लॉक टूल तक पहुंचने की क्षमता है जब तक कि आप इसका चयन नहीं करते हैं।

फिर भी एक और विचार: जब आप कर्सर को दूसरे ब्लॉक से हटाते हैं तो नीचे की पट्टी अपने आप छिप सकती है। यह तब तक वापस नहीं आएगा जब तक आप कर्सर फिर से ब्लॉक की सीमा में नहीं चले जाते। यह नेस्टेड संदर्भों में और भी अधिक मदद कर सकता है।

इन सबसे ऊपर, यदि आप अभी भी नेस्टेड संदर्भों में कम ओवरलैप मुद्दों को चाहते हैं, तो आप संपादक के शीर्ष पट्टी पर स्वरूपण टूलबार को डॉक कर सकते हैं। (इससे मोबाइल पर कोई प्रभाव नहीं पड़ता है, लेकिन मोबाइल पर बार स्पेस लेते हैं और कुछ भी ओवरलैप नहीं करते हैं, इसलिए पहली बार में ओवरलैप मुद्दे नहीं हैं।)

कुल मिलाकर, मुझे लगता है कि मेरे नवीनतम मॉकअप से स्थितियों में सुधार हुआ है, जो कि बदतर हुई हैं।

जैसा कि यह है, मुझे लगता है कि मेरे मॉकअप (या इसके करीब) की तरह कुछ और समस्याएँ पैदा करता है। उपरोक्त के अलावा, लाभों में शामिल हैं:

• सभी ब्लॉक चौड़ाई के लिए काम करता है।
• सिबलिंग इंसुलेटर, मूवमेंट कंट्रोल और इलिप्सिस के लिए बेहतर पहुंच।
• बेहतर दृश्यता और खोजकर्ता डालने वाले और खींचने के हैंडल के लिए खोज क्षमता।
• ब्लॉक की तरफ के ड्रैग एरिया को हटाया जा सकता है और होवर लेबल को ड्रैग हैंडल नहीं बनना है (यह वैसे भी छोटा है)।
• सिबलिंग इंसुलेटर ब्लॉक से नीचे है, जो कि आप आमतौर पर इसका उपयोग करना चाहते हैं (जैसा कि ऊपर विरोध किया गया है)।
• जटिलता को कम करने के लिए अलग सिबलिंग यूआई यूआई की आवश्यकता नहीं है।
• सिबलिंग इंसुलेटर में अब नेस्टेड संदर्भों में ओवरलैप मुद्दे नहीं हैं। (मुझे लगता है कि यही कारण है कि # 6520 अभी तक नहीं हुआ है।)
• ब्लॉक के आसपास का ब्लॉक UI कभी भी उस ब्लॉक की सामग्री को ओवरलैप नहीं करता है।
• ब्लॉक के स्वचालित मार्जिन को हटाया जा सकता है, और एक ब्लॉक में कोई आंतरिक पैडिंग नहीं हो सकती है, और ब्लॉक यूआई बॉर्डर को वास्तविक सामग्री सीमाओं में वापस बदला जा सकता है, और फिर भी ब्लॉक की सामग्री में कुछ भी किसी भी नियंत्रण द्वारा ओवरलैप नहीं किया जाएगा। इस तरह के किनारे के मामले कस्टम ब्लॉक के साथ होंगे, इसलिए उनके लिए खाता अच्छा है।
• ब्लॉक के विपरीत किनारों पर होने वाले इलिप्सिस और तीर मूवर्स की पिछली स्थिति की तुलना में सभी ब्लॉक टूल एक साथ काफी करीब हैं, जिससे उन सभी तक पहुंचना और उन सभी की खोज करना आसान हो जाता है।
• यह बहुत स्पष्ट है कि नियंत्रणों को किस ब्लॉक से जोड़ा गया है, भ्रम की तुलना में आप अक्सर नेस्टेड संदर्भों में वर्तमान नियंत्रणों के साथ मिलते हैं।
• नियंत्रण मोबाइल के साथ अधिक सुसंगत हैं।

तो हाँ, मुझे लगता है कि मेरा मॉकअप वास्तव में नेस्टेड संदर्भों में बेहतर काम करता है, और मुझे लगता है कि ब्लॉक यूआई आपके द्वारा प्राप्त किए जाने की तुलना में शायद ही महत्वपूर्ण है। तुम क्या सोचते हो? यदि आप असहमत हैं, तो क्या आप उन स्थितियों को इंगित कर सकते हैं, जहां मॉकअप मौजूदा यूआई से काफी खराब होगा और पहले से बताए गए सुझावों में से कोई भी इसे हल नहीं करेगा?

वहाँ है ... एक और ... ~ स्काईवॉकर ~ विचार

यदि अन्य सभी विफल होते हैं, तो मेरे पास एक विचार है जो तकनीकी रूप से सभी प्रमुख मुद्दों को ठीक करेगा। क्या होगा यदि स्वरूपण टूलबार हमेशा शीर्ष पर डॉक किया गया था जैसे कि गुटेनबर्ग 1.6 में वापस था, लेकिन इस बार आंदोलन नियंत्रण और दीर्घवृत्त पक्षों के बजाय ब्लॉकों के ऊपर दिखाया जाएगा? (आप वैकल्पिक रूप से अभी भी मेरे मॉकअप की तरह तल पर हो सकते हैं।)

इस अवधारणा में, सिबलिंग इंसुलेटर मौजूद नहीं होगा, क्योंकि एडिटर के टॉप बार में इन्सर्टर एक ही फंक्शन पर काम करेगा, और इस संदर्भ में यह पहुंच के करीब होगा क्योंकि फॉर्मेटिंग टूलबार उसी क्षेत्र में होगा।

मोबाइल यूआई बिल्कुल वैसा ही होगा जैसा अभी है। यह परिवर्तन केवल डेस्कटॉप (और शायद टैबलेट) उपयोगकर्ताओं को प्रभावित करेगा।

लेकिन रुकिए, और भी है!

वास्तव में, यदि आप इसके बारे में सोचते हैं, तो इस विचार में क्या अंतर है और सिर्फ मेरा मॉकअप होना और फिक्स टूलबार को टॉप पर सक्षम फिक्स टूलबार टू टॉप विकल्प का हिस्सा हो सकता है।

वर्तमान UI की तुलना करें जहां फिक्स टूलबार टू टॉप सभी ओवरलैपिंग नियंत्रण मुद्दों से छुटकारा नहीं देता है क्योंकि साइड यूआई अभी भी दो पक्षों के बीच विभाजित है और भ्रामक अदृश्य ड्रैग हैंडल अभी भी वहां हैं, और सिबलिंग इंसर्टर्स अभी भी शून्य संदर्भों में ओवरलैप करते हैं, और आदि।

क्या यह निश्चित रूप से भविष्य के लिए पत्थर में सेट है कि पाठ का प्रत्येक पैराग्राफ एक अलग ब्लॉक है? यदि ऐसा है, तो ब्लॉक टूल के प्रदर्शन को कई टेक्स्ट-ब्लॉक चयन (जो मुझे विश्वास है कि कुछ स्तर पर आ रहा है) को ध्यान में रखना होगा।

@padraigobeirn यह एक अच्छा बिंदु है जिसके बारे में मैं भूल गया था।

विशेष रूप से, वर्तमान UI में नियंत्रण लंबे चयन के लिए जिम्मेदार नहीं हैं। आंदोलन नियंत्रण और दीर्घवृत्त चयन में पहले ब्लॉक के ऊपर बाईं और दाईं ओर रहता है। यहां तक ​​कि प्रारूपण टूलबार चयन में पहले ब्लॉक के लिए केवल चिपचिपा है। # 7962 देखें।

मेरे मॉकअप में नीचे की पट्टी के लिए, जब आप स्क्रॉल करते हैं तो आप सैद्धांतिक रूप से इसे कई चयनों के साथ काम कर सकते हैं। यह चिपचिपा व्यवहार केवल चयनित ब्लॉक के लिए वांछनीय हो सकता है, हालांकि।

तुम्हें पता है, मैं वास्तव में सोचना शुरू कर रहा हूं कि फिक्स टूलबार टू टॉप डिफ़ॉल्ट रूप से होना चाहिए।

जैसा कि यह है, वास्तव में केवल इतना है कि आप एक ब्लॉक के चारों ओर इतने सारे नियंत्रण फिट कर सकते हैं, और यहां तक ​​कि मेरे नवीनतम मॉकअप के साथ, अभी भी ऐसे मामले हैं जहां यूआई भीड़ महसूस कर सकता था। यूआई महसूस करने के बारे में भी चिंता है जो बहुत अवरुद्ध है।

इन मुद्दों को हल करने के लिए, मुझे लगता है कि स्वरूपण टूलबार को शीर्ष पर डॉकिंग डिफ़ॉल्ट होना चाहिए। यह बहुत सारे ब्लॉक के आसपास जगह बचाता है, और ओवरलैप के संभावित नियंत्रणों की मात्रा को काफी कम कर देता है।

मुझे लगता है कि मैं अभी भी आंदोलन नियंत्रण और दीर्घवृत्त को नीचे रहना पसंद करता हूं, लेकिन प्रारूपण टूलबार डॉक होने पर उन्हें भी शीर्ष पर ले जाया जा सकता है। ब्लॉक से जुड़े फ़ॉर्मेटिंग टूलबार के न होने से, ब्लॉक टूल बार को नीचे या ऊपर के दाईं ओर या तो ऊपर की ओर देखा जा सकता है, बिना अजीब दिखे या बहुत अधिक जगह खाए बिना।

मुझे लगता है कि मैं या तो नीचे बाएं या नीचे दाएं पसंद करूंगा। इस तरह, नियंत्रण नेत्रहीन और टैब क्रम में ब्लॉक के बाद आते हैं, जो मुझे सबसे अधिक समझ में आता है। ब्लॉक के बाद सिबलिंग इंसुलेटर को वहां फेंकने से अधिक समझ में आता है क्योंकि यह ब्लॉक से पहले दिखाई देता है।

साइड नोट: मैंने हाल ही में देखा कि Infusionsoft में ईमेल बिल्डर की वास्तव में अपनी "ब्लॉक" अवधारणा है, और इसमें ब्लॉक टूल (डुप्लिकेट और डिलीट) हैं जो शीर्ष दाईं ओर ब्लॉक से ऊपर दिखाए गए हैं। जब आपका कर्सर किसी पाठ क्षेत्र में प्रवेश करता है, तो संपादक के शीर्ष पर एक बार में स्वरूपण नियंत्रण दिखाई देता है।

मैंने हाल ही में देखा कि Infusionsoft में ईमेल बिल्डर की वास्तव में अपनी "ब्लॉक" अवधारणा है, और इसमें ब्लॉक टूल (डुप्लिकेट और डिलीट) हैं जो शीर्ष दाईं ओर ब्लॉक से ऊपर दिखाए गए हैं। जब आपका कर्सर किसी पाठ क्षेत्र में प्रवेश करता है, तो संपादक के शीर्ष पर एक बार में स्वरूपण नियंत्रण दिखाई देता है।

क्या आप उस इंटरफ़ेस @SuperGeniusZeb के कुछ स्क्रीनशॉट क्लिप कर सकते हैं?

जब मैंने पहली बार गुटेनबर्ग का उपयोग करना शुरू किया तो मैं निश्चित रूप से एक "फिक्स टूलबार टू टॉप" व्यक्ति था, लेकिन कुछ समय के लिए इसका उपयोग करने के बाद मुझे यकीन नहीं है कि मैं वापस जाना चाहता हूं। मैं पूरी तरह से पहचानता हूं कि कई मायनों में टूलबार इन सभी समस्याओं का कारण है - यह बहुत अधिक सामान होने की संभावना है जो नेस्टेड संदर्भों में कट जाता है, और अंतरिक्ष को आप नियंत्रण के लिए उपयोग कर सकते हैं - लेकिन यह होने ब्लॉक के साथ रखा सिर्फ इतना अच्छा है। यह आपकी जरूरत की हर चीज को एक जगह पर रखता है, बहुत सारे आई-मोशन और माउस मूवमेंट आदि से बचता है, मैं अब यह कहने के लिए हैरान हूं लेकिन मुझे लगता है कि मैं कुछ ऐसा नहीं कर पाऊंगा जिसके बिना मैं रह पाऊंगा

क्या आप उस इंटरफ़ेस @SuperGeniusZeb के कुछ स्क्रीनशॉट क्लिप कर सकते हैं?

@chrisvanpatten नहीं, किसी की मदद करने के दौरान मेरे पास केवल अस्थायी पहुंच थी।

मैं निश्चित रूप से फिक्स्ड / नॉट-फिक्स्ड फॉर्मेटिंग टूलबार पर जोरदार तरीके से महसूस नहीं करता हूं, लेकिन मैं फिक्स्ड की ओर झुकूंगा क्योंकि यह ब्लॉक के आसपास दृश्य अव्यवस्था को कम करने में मदद करेगा। उपयोगकर्ता की प्रतिक्रिया के आधार पर, अन्य लोग क्या पसंद करते हैं और क्यों?

@chrisvanpatten को एक लेख मिला जहां कोई व्यक्ति Infusionsoft में ईमेल बिल्डर के बारे में बात करता है और उसका एक वीडियो है:

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

@chrisvanpatten Argh , मैंने अभी-अभी जाँच की है और ऐसा लग रहा है कि यह वीडियो पुराना है ... यह पीछे की तरह दिखता है, तो स्वरूपण टूलबार ब्लॉकों से जुड़ा हुआ था, जैसे कि गुटेनबर्ग अभी करता है। दिलचस्प है कि उन्होंने इसे बदल दिया, हालांकि।

कुछ विचार:

यदि आप किसी पोस्ट के बीच में एक ब्लॉक डालने जा रहे हैं, तो आप आमतौर पर इसे _after_ करना चाहते हैं जिसे आपने चुना है, है ना? आप आमतौर पर _before_ चयनित ब्लॉक को सम्मिलित नहीं करना चाहते हैं। एक ब्लॉक के बाद सम्मिलित करना भी एक पहुंच के दृष्टिकोण से समझ में आता है। क्या कोई इससे सहमत नहीं है? मेरे लिए, ऐसा लगता है कि सहोदर आवेषण के पक्ष में एक मजबूत तर्क एक ब्लॉक के नीचे कहीं दिखाई देता है।

सिबलिंग इंसर्टर्स को चयनित ब्लॉक की सामग्री को ओवरलैप नहीं करना चाहिए। कुछ भी चयनित ब्लॉक की सामग्री को स्थायी रूप से ओवरलैप नहीं करना चाहिए। क्या कोई इससे सहमत नहीं है? यह मुझे विश्वास दिलाता है कि सिबलिंग इंसर्टर्स को चयनित ब्लॉक की सामग्री के बाहर तैनात किया जाना चाहिए।

मैं इसे इंगित करता हूं क्योंकि मुझे लगता है कि चाहे जहां पर नियंत्रण और इलिप्सिस जाना चाहिए, सिबलिंग इंसर्टर्स को चयनित ब्लॉक के नीचे एक प्रकार के टूलबार में दिखाई देता है, भले ही यह सब स्वयं और / या टूलबार से हो। कोई सीमा / पृष्ठभूमि नहीं। मुझे लगता है कि यह लगभग वैसा ही दिख सकता है जैसा कि यह अब है, लेकिन नीचे की ओर शिफ्ट हो गया और ब्लॉकों के नीचे दिखाई देने लगा, बजाय उनके ऊपर के।

एक और विचार: क्या यह आंदोलन के तीर या इसके विपरीत के रूप में एक ही तरफ दीर्घवृत्त डालने के लिए master का सुधार होगा? नेस्टेड संदर्भों में अतिव्यापी नियंत्रण के साथ बहुत सारे मुद्दों को हल कर सकता है, एक ब्लॉक के बाईं ओर (या दाएं) ब्लॉक यूआई की अधिक मात्रा में होने की कीमत पर।

मैंने # 8836 की कोशिश की। मुझे लगता है कि यदि इसे विलय कर दिया गया था, तो यह भारी / अवरुद्ध यूआई मुद्दों को कम करने में मदद कर सकता है जो इस टिकट में बहुत सारे यूआई डिजाइन लगते हैं।

टिकट # 9074 और # 9075 में, मैं इस चर्चा से प्रेरित, स्थिति को कम करने और बेहतर बनाने के लिए, दो बेबी-स्टेप्स का सुझाव दे रहा हूं। पहले एक सुझाव में हम टूलबार में एलिप्सिस / अधिक बटन को स्थानांतरित करते हैं, इसलिए हमारे पास केवल साइड-यूआई (मूवर्स) का एक टुकड़ा है, और दूसरे में ब्लॉक टूलबार को सेट करने के लिए बेहतर फिट करने का प्रस्ताव है। पतले संदर्भ।

बस उन्हें अप-टू-डेट रखने के लिए, मैंने @ masmups को जिम्मेदार ठहराया :

दरअसल, # 9074 और # 9075 लागू होने पर ब्लॉक के नीचे तीर मूवर्स को स्थानांतरित करना भी आवश्यक नहीं हो सकता है। यह ठीक हो सकता है यदि वे ब्लॉक के किनारे पर रहते हैं, क्योंकि आसन्न ब्लॉकों के दीर्घवृत्त अब उन्हें कॉलम जैसी चीजों में ओवरलैप नहीं करेंगे। यदि # 8880, # 8881, और # 8883 के लिए समाधान हुआ, और यदि # 8836 और # 8920 को लागू किया गया, तो शायद यूआई पहले से ही नेस्टेड संदर्भों के लिए ठीक होगा। मैं ऊपर / नीचे तीरों को ब्लॉक के बाईं ओर रहने के लिए ठीक होने की दिशा में झुकना शुरू कर रहा हूं।

उस ने कहा, मुझे अभी भी लगता है कि सिबलिंग इंसुलेटर निश्चित रूप से ब्लॉक्स से नीचे है , हालांकि आप निश्चित रूप से सिबलिंग इंसुलेटर को ब्लॉक से नीचे देख सकते हैं। शायद यह वर्तमान सिबलिंग इंसुलेटर की तरह केंद्रित हो सकता है, लेकिन जब आप किसी ब्लॉक के निचले हिस्से के अंदर मँडरा रहे हों तो ब्लॉक के नीचे एक फ्लोटिंग बटन के रूप में दिखाई देने वाला अप / डाउन मूवमेंट कंट्रोल की तरह काम करें और देखें।

आइए, @jasmussen में पुनरावृत्तियों पर ध्यान केंद्रित करने पर # 9074 और # 9075 पर काम कर रहे हैं, तो हम अगले चरणों पर विचार कर सकते हैं। मैं पूरी तरह से बहुत सी चीजों को बदलना चाहता हूं, लेकिन चलो संतुलन।

उपरोक्त # 9074 और # 9075, साथ ही अन्य मुद्दों और # 8920 और # 9197 जैसे पीआर के लिए धन्यवाद, मैंने तय किया है कि ब्लॉक के नीचे तीर मूवर्स को स्थानांतरित करने से अब कई फायदे नहीं हैं।

इसके बजाय, मैं अब प्रस्ताव कर रहा हूं कि सिबलिंग इंसुलेटर को ब्लॉक के नीचे ले जाया जाए, अभिनय किया जाए और अप / डाउन मूवर्स के समान फ्लोटिंग कंट्रोल के रूप में प्रदर्शित किया जाए। # 9202 देखें।

आइए इसे अभी के लिए बंद कर दें क्योंकि इस और अन्य चर्चाओं से कई सुधार सामने आए हैं। बनाने के लिए अंतिम कुछ शोधन अनुगामी आवेषण के आसपास हैं।