Gutenberg: ब्लॉक-विशिष्ट उत्तरदायी नियंत्रण

मैं इस विषय पर कुछ प्रारंभिक अन्वेषणों को साझा करूँगा।

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

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

इस बात को ध्यान में रखते हुए, मैंने अपने अन्वेषण को कुछ मुख्य विचारों के साथ बनाया:

1. उत्तरदायी नियंत्रण "उन्नत" पैनल में रहना चाहिए। यह पैनल वर्तमान में बहुत कम उपयोग में है, लेकिन उत्तरदायी सेटिंग्स के लिए एक उचित घर जैसा लगता है। हमें अच्छी डिफ़ॉल्ट सेट करनी चाहिए, और ज्यादातर मामलों में उपयोगकर्ता कभी भी इस पैनल पर नहीं जाएगा।
2. 3 विभिन्न विकल्पों के लिए अनुमति दें :
   A. हमारा स्मार्ट डिफॉल्ट: मोबाइल पर स्टैक कॉलम।
   B. हर जगह समान कॉलम का उपयोग करें।
   C. मोबाइल, टैबलेट और डेस्कटॉप स्क्रीन साइज के लिए कॉलम काउंट निर्दिष्ट करें।

उन लोगों को ध्यान में रखते हुए, मैंने कुछ प्रोटोटाइप बनाए:

डेस्कटॉप प्रोटोटाइप (Figma)
मोबाइल प्रोटोटाइप (Figma)

संदर्भ के लिए _Sreenshots: _

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

मैं कुछ प्रतिक्रिया में दिलचस्पी रहा हूँ! मैं यह भी उत्सुक हूं कि इस प्रकार के नियंत्रण अन्य प्रकार की सेटिंग्स तक कैसे फैल सकते हैं: इस तरह के उत्तरदायी नियंत्रणों के लिए अन्य ब्लॉक क्या लाभकारी होंगे?

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

शीर्ष खंड (मार्जिन / पैडिंग) सभी ब्लॉकों पर भी उपलब्ध है। पूरी तरह से संपादक से कुछ सुंदर शानदार लेआउट बनाने की अनुमति।

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

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

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

शेयर करने के लिए धन्यवाद, @mattbolt यदि आपने इसे नहीं देखा है, तो हम यहीं पर इस तरह की सटीक चर्चा कर रहे हैं: # 13203

उत्तरदायी मार्जिन / पेडिंग नियमों के लिए: मैं मार्जिन + पैडिंग के लिए अधिक ठीक-ठीक नियंत्रण देखने के लिए _love_ करूंगा। लेकिन अधिकांश उपयोगकर्ताओं के लिए, मुझे लगता है कि वे वैश्विक स्तर पर अधिक फायदेमंद होंगे। इसलिए मैंने उन्हें अपने अन्वेषणों से ऊपर छोड़ दिया। मुझे लगता है कि हमें निश्चित रूप से मार्जिन / पेडिंग कंट्रोल _somewhere_ को शामिल करना चाहिए, लेकिन प्रति-ब्लॉक मुझे बहुत कम लगता है (कम से कम कोर के लिए)।

heya @mapk @kjellr - मैंने # 13203 पर एक टिप्पणी छोड़ी है, लेकिन मुझे लगता है कि इस मुद्दे में इसके एक हिस्से को भी उजागर करना लायक है।

यह नवीनतम प्रोटोटाइप है जिस पर हम काम कर रहे हैं - यह फीडबैक पर आधारित है जो हमें हमारे हालिया प्रयोज्य परीक्षण से मिला है जिसे मैंने # 13203 में नोट किया था।

Figma

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

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

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

हमें इस नवीनतम संस्करण का परीक्षण करने का मौका नहीं मिला है, लेकिन हमें जल्द ही उम्मीद है।

@kjellr

मैं कुछ प्रतिक्रिया में दिलचस्पी रहा हूँ! मैं यह भी उत्सुक हूं कि इस प्रकार के नियंत्रण अन्य प्रकार की सेटिंग्स तक कैसे फैल सकते हैं: इस तरह के उत्तरदायी नियंत्रणों के लिए अन्य ब्लॉक क्या लाभकारी होंगे?

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

@mattbolt

शीर्ष खंड (मार्जिन / पैडिंग) सभी ब्लॉकों पर भी उपलब्ध है।

धन्यवाद मैट! हाशिये और पैडिंग में आपकी खोज यहाँ साझा करने के लिए एक अच्छा है। # 11,824

@LevinMedia

हमारे कई प्रतिभागियों ने सवाल पूछा, "मैं मोबाइल उपकरणों के लिए इन लेआउट सेटिंग्स को कैसे बदलूं?"

बहुत दिलचस्प!

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

यह वू ब्लॉक के संदर्भ में समझ में आता है जो उत्पाद संख्या को भी समायोजित करने की अनुमति देता है। क्या आपको लगता है कि जब @kjellr के मॉकअप में केवल एक ही समायोजन (यानी कॉलम) है तो यह आवश्यक है।

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

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

हेया @ मम्पक

क्या आपको लगता है कि जब @kjellr के मॉकअप में केवल एक ही समायोजन (यानी कॉलम) है तो यह आवश्यक है।

मैं करता हूँ। खोजशीलता मेरे लिए उस कारण का एक बड़ा हिस्सा है। यह सेटिंग (s) के संदर्भ में उत्तरदायी सेटिंग्स को सीधे जोड़ देता है जिन्हें हेरफेर किया जा रहा है।

मुझे लगता है कि ऐसे कई मामले होने जा रहे हैं जहां एक ब्लॉक में कई प्रतिक्रियाशील सेटिंग्स हैं, और उनमें से सभी एक ही बाल्टी, जैसे कि लेआउट में बड़े करीने से फिट नहीं हो रहे हैं।

उदाहरण के लिए, ऊपर आपका दूसरा प्रश्न।

क्या डिवाइस की चौड़ाई के आधार पर ब्लॉक को छिपाना / दिखाना आवश्यक है?

पृष्ठ बिल्डरों के मेरे पिछले उपयोग में, उस प्रश्न का उत्तर हाँ है। इसके साथ "विज़िबिलिटी" सेटिंग्स जोड़ने के लिए यह उत्तरदायी नियंत्रण है जो इसके लिए अनुमति देगा।

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

[टॉगल करें] डेस्कटॉप पर दिखाएं
[टॉगल करें] टेबलेट पर दिखाएं
[टॉगल करें] मोबाइल पर दिखाएं

हमारे कई प्रतिभागियों ने सवाल पूछा, "मैं मोबाइल उपकरणों के लिए इन लेआउट सेटिंग्स को कैसे बदलूं?"

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

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

ब्लॉक के लिए डिफ़ॉल्ट सेटिंग कौन सी होनी चाहिए? डेस्कटॉप, मोबाइल, टैबलेट?

यह प्रश्न अभी मेरे लिए सबसे ऊपर है। मुझे @kkkrr की डिज़ाइन ऊपर बताए गए कारणों के कारण बहुत पसंद है, लेकिन मुझे यकीन नहीं है कि यह "मोबाइल पहले" अनुभव में कितना अच्छा होगा?

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

इस समय मेरा झुकाव @ लिविनमीडिया से सहमत लिए इन सेटिंग्स को समझना बहुत आसान होना चाहिए।

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

यह प्रश्न अभी मेरे लिए सबसे ऊपर है। मुझे @kkkrr की डिज़ाइन ऊपर बताए गए कारणों के कारण बहुत पसंद है, लेकिन मुझे यकीन नहीं है कि यह "मोबाइल पहले" अनुभव में कितना अच्छा होगा?

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

लेकिन सामान्य तौर पर, मैं डिवाइस-जागरूक होने के सामान्य विचार को पसंद करता हूं। Mockups @LevinMedia में पोस्ट किया गया, जो मोबाइल डिवाइस पर जाने पर मोबाइल टैब को चुनने में चूक करने या टैबलेट से जाने पर टैबलेट के बराबर होने पर

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

यह अन्वेषण विकल्पों को थोड़ा सरल करता है और सब कुछ वापस मुख्य "कॉलम" क्षेत्र में ले जाता है:

🖥 डेस्कटॉप प्रोटोटाइप

📱 मोबाइल प्रोटोटाइप

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

कुछ विचार:

• आम तौर पर, इसके लिए बेहतर लेबलिंग + विवरण की आवश्यकता होती है।
• यह एक विकल्प के लिए ठीक काम करता है, लेकिन यह अच्छी तरह से पैमाने पर नहीं होगा अगर प्रति ब्रेकप्वाइंट प्रति कई सेटिंग्स थे।
• टॉगल स्विच के बंद होने के आधार पर हम आमतौर पर नियंत्रण नहीं दिखाते / छिपाते हैं। यकीन नहीं होता अगर वाकई यहां समझ में आता है।
• उपरोक्त से संबंधित: पदानुक्रम-वार, यह अजीब लगता है कि टॉगल स्विच इसके ऊपर के क्षेत्रों को प्रभावित करता है। इस मामले में स्विच के साथ नेतृत्व करना अधिक स्वाभाविक होगा। यह _also_ हालांकि सही नहीं लगेगा, क्योंकि प्राथमिक चीज़ जो लोग यहाँ करना चाहेंगे, वह है, जो कि उत्तरदायी गणनाओं को टॉगल नहीं करने के लिए कॉलम की संख्या को समायोजित करता है।

एक प्रश्न जो मैं यहाँ खोज रहा हूँ और यहाँ पढ़ रहा हूँ, उसके बारे में जानने के लिए वापस आता रहूँगा: यह कितना सरल या जटिल होना चाहिए _ _ डाक! _ कुछ कस्टम ब्लॉक में निश्चित रूप से प्रत्येक ब्रेकपॉइंट के लिए व्यक्तिगत सेटिंग्स का एक टन शामिल होगा: मार्जिन, पैडिंग, दिखाने + छुपाने वाले ब्लॉक, आदि हो सकता है कि उनके उपयोगकर्ता आधार के साथ सहज है। लेकिन हम जरूरी नहीं कि डिफ़ॉल्ट ब्लॉकों में नियंत्रण के स्तर को शामिल करना चाहते हैं क्योंकि यह नौसिखिए उपयोगकर्ता के लिए भारी हो सकता है। उस ने कहा ... यह हमारे लिए डिज़ाइन पैटर्न स्थापित करने के लिए फायदेमंद है जो उन सुपर-जटिल परिदृश्यों को माप सकता है, ताकि हम यह प्रदर्शित करने में मदद कर सकें कि इसे सभी मामलों में कैसे नियंत्रित किया जाना चाहिए। हम एक साधारण पैटर्न को कैसे परिभाषित कर सकते हैं जो _not_ करने वाले लोगों के बीच उत्तरदायी सेटिंग्स को प्रबंधित करना चाहते हैं और जो लोग इन चीजों के बारे में वास्तव में विशिष्ट होना चाहते हैं?

अच्छा मॉकअप, @kjellr!

आम तौर पर, इसके लिए बेहतर लेबलिंग + विवरण की आवश्यकता होती है।

बहुत कम से कम, डिवाइस आइकन को प्रत्येक स्लाइडर्स के लिए लेबल पर ले जाया जाना चाहिए, जैसे "the डेस्कटॉप"।

यह एक विकल्प के लिए ठीक काम करता है, लेकिन यह अच्छी तरह से पैमाने पर नहीं होगा अगर प्रति ब्रेकप्वाइंट प्रति कई सेटिंग्स थे।

मुझे लगता है कि इसका जवाब टॉगल में निहित है। क्या होगा यदि हर उत्तरदायी नियंत्रण में सेटिंग की जवाबदेही को अनुकूलित / सक्षम करने के लिए एक टॉगल था? Divi बिल्डर के पास इसके समान कुछ सुंदर है।

उपरोक्त से संबंधित: पदानुक्रम-वार, यह अजीब लगता है कि टॉगल स्विच इसके ऊपर के क्षेत्रों को प्रभावित करता है। इस मामले में स्विच के साथ नेतृत्व करना अधिक स्वाभाविक होगा। हालांकि यह भी सही नहीं लगेगा, क्योंकि लोग जिस चीज को यहां करना चाहते हैं, वह यह है कि स्तंभों को समायोजित किया जाए ताकि वे उत्तरदायी नियंत्रणों को न पकड़ सकें।

मुझे लगता है कि मैं स्लाइडर्स के ऊपर टॉगल करना पसंद करूंगा, क्योंकि टॉगल करने से यह स्लाइडर्स को प्रभावित करता है।

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

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

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

सभी प्रतिभागी WooCommerce Design Feedback Group से आए थे - जैसा कि उल्लेख किया गया था, हमारे प्रतिभागियों और विशेष रूप से अधिक अनुभव वाले बिल्डर / स्टोर असेंबलर प्रोफ़ाइल की ओर प्रतिभागियों के इस समूह ने एक DIY दुकान के मालिक की बजाए बहुत अधिक तिरछा किया।

कल पोस्ट किए गए मॉकअप का एक छोटा सा फॉलोअप:

🖥 डेस्कटॉप प्रोटोटाइप

📱 मोबाइल प्रोटोटाइप

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

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

इसके अलावा, यदि उपयोगकर्ता ने मैन्युअल रूप से स्विच किया, तो सेटिंग्स को तोड़ने के लिए समायोजन का एक गुच्छा बनाया, और चीजों को गड़बड़ कर दिया, "ऑटो" विकल्प उनके लिए एक त्वरित एस्केप हैच है।

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

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

बहुत अच्छा, @kjellr!

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

पहुँच के संदर्भ में भी, क्या हम सुनिश्चित हैं कि एक बटन समूह इस संदर्भ में टॉगल की तुलना में अधिक उपयुक्त है?

मुझे ये अवधारणाएं पसंद हैं और वे कॉलम के लिए अच्छी तरह से काम करते हैं लेकिन मैं दोनों के साथ कुछ छोटे मुद्दों को देखता हूं।

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

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

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

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

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

इसके अलावा, उस दिशा का क्रूस उपकरणों के लिए खंडित नियंत्रण है:

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

मुख्य बात जो मुझे उस दिशा से गायब दिखाई देती है वह है "आइए हम इसे संभाल लें" विकल्प की प्रस्तुति।

पकड़ लिया। तो चिंता यह है कि टैबलेट / मोबाइल टॉगल वैकल्पिक नहीं है? यह समझ आता है। लेकिन मुझे लगता है कि डिवाइस सेगमेंटेड नियंत्रण अलग-अलग सेटिंग प्रकारों में अधिक सुसंगत पैटर्न प्रदान करेगा और इसलिए बेहतर होगा। उपयोग में आसानी बनाम संगति और स्केलेबिलिटी एक कठिन है!

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

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

हाँ, मैंने इसे जल्दी से आज़माने के लिए कुछ इस तरह मज़ाक उड़ाया। यह तकनीकी रूप से काम करता है, हालांकि इसे थोड़ा दोहराव + लंबे समय तक प्राप्त होता है:

एक अन्य अवधारणा को लॉग इन करना जो @kjellr और मैंने अतिरिक्त विचारों के लिए यहां काम किया:

अंजीर का प्रोटोटाइप

चीज़ें जो मुझे पसंद है:

1. इसका मतलब है कि लेखक को केवल एक सेटिंग को समायोजित करना होगा, यह मानते हुए कि वे चीजों को स्वचालित रूप से संभालना चाहते हैं।
2. यहां तक ​​कि "स्वचालित मोड" में, वे अभी भी देख सकते हैं कि उन्हें मोबाइल पर कितने कॉलम मिलेंगे, कोई रहस्य नहीं है।
3. पूर्ण नियंत्रण के लिए सेटिंग्स को अनलिंक करना एक क्लिक दूर है।

जो चीजें मुझे इतनी पसंद नहीं हैं:

1. यह नेत्रहीन अंतरिक्ष का एक सा स्थान लेता है
2. मोबाइल पर कोई सरल "स्टैक कॉलम" विकल्प नहीं है। ईमानदारी से सुनिश्चित नहीं है कि यह एक बड़ी बात है या नहीं ...

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

मुझे लगता है कि UI इस तरह दिख सकता है:

कॉलम की गिनती
(ON () मोबाइल उपकरणों के लिए कॉलम को स्वचालित रूप से समायोजित करें।
――――― o [__4]

कॉलम की गिनती
(DevicesOFF) मोबाइल उपकरणों के लिए कॉलम को स्वचालित रूप से समायोजित करें।

🖥️Desktop
――――― o [__4]
⬛Tablet
――― ओ ――― [__3]
📱Phone
―O ――――― [__2]

दृश्यता
(ON () डेस्कटॉप पर onShow
(ON () onShow टेबलेट पर
(ON () मोबाइल पर 📱Show

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

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

तकनीकी रूप से "लिंक" अवधारणा एक ही बात है, टॉगल बस एक अलग स्थान पर नेत्रहीन है। यह अभी भी एक ही तरीके से स्क्रीन पाठकों के लिए प्रकट हो सकता है और एक टूलटिप को एक लेबल के रूप में जोड़ा जा सकता है (मुझे यकीन नहीं है कि हालांकि वे कितने सुलभ हैं)।

दर्शनीय लेबल हमेशा अधिक सुलभ होते हैं। यह भी ध्यान में रखा जाना चाहिए कि नियंत्रण के दृश्य क्रम को उनके टैब क्रम से मेल खाना चाहिए, और उनके टैब क्रम को सूचना वास्तुकला का पालन करना चाहिए ... मतलब नियंत्रण जो आप तार्किक रूप से पहले उपयोग करेंगे, जो आपके द्वारा बाद में उपयोग किए जाएंगे, और चीजें शीर्षकों की तरह वे पैराग्राफ से पहले आते हैं। @Afercia को पिंग

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

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

इस विचार और चर्चा से प्यार करें!

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

आप वास्तव में 3 डिवाइस प्रतिमान को हरा नहीं सकते हैं जब यह "उत्तरदायी डिजाइन" को समझने के लिए नियमित उपयोगकर्ताओं को प्राप्त करने की बात आती है। बात 3 उपकरणों के लिए 3 डिजाइन वास्तव में उत्तरदायी डिजाइन नहीं है। यह अनुकूली डिजाइन है। यह पिक्सेल का सही सपना है, जो आधुनिक वेब के साथ मौजूद नहीं है। यह कठोर, नाजुक है, भविष्य का सबूत नहीं है और हमेशा यह अपेक्षा नहीं करता है कि उपयोगकर्ता क्या उम्मीद करता है।

नई सीएसएस विशेषताएं हमें अनुकूली डिजाइन से दूर और उत्तरदायी की ओर ले जाने के लिए हर समय जारी की जा रही हैं। rem , vw , flex , grid ।

उत्तरदायी डिज़ाइन सामग्री को डिज़ाइन को निर्देशित करने और सामग्री से समझौता करने के बजाय डिज़ाइन को सूचित करने देता है।

यहां ट्वेंटीनीटीन का एक कॉलम दृश्य है

यदि मेरी साइट डिज़ाइन ने पाठ के 6 स्तंभों के लिए कॉल किया है, तो मैं पसंद करूंगा कि डिज़ाइन को चौड़ाई से थोड़ा सा समझौता करने से पहले 150px से कम हो।

फ्लेक्सबॉक्स इसे काफी स्वचालित बना सकता है। कोशिश करके देखो।

.wp-block-columns {
    display: flex;
    flex-wrap: wrap;
}

.wp-block-column {
    flex: auto;
    width: 100%;
    margin: 0 1rem 1rem;
}

.has-4-columns .wp-block-column {
    width: calc(100% / 4 - 2rem);
}

.has-6-columns .wp-block-column {
    width: calc(100% / 6 - 2rem);
}

.wp-block-column {
    min-width: 100px
}

हालांकि अब तक जो चर्चा हुई है वह UX के नजरिए से बहुत अच्छी है:

3 विभिन्न विकल्पों के लिए अनुमति दें:
A. हमारा स्मार्ट डिफॉल्ट: मोबाइल पर स्टैक कॉलम।
B. हर जगह समान कॉलम का उपयोग करें।
C. मोबाइल, टैबलेट और डेस्कटॉप स्क्रीन साइज के लिए कॉलम काउंट निर्दिष्ट करें।

मैं इसे पहली सामग्री के परिप्रेक्ष्य से बाहर फेंकना चाहता हूँ:

शायद ये 3 विकल्प?
A. स्मार्ट डिफ़ॉल्ट: न्यूनतम स्तंभ चौड़ाई 200px (ईश)।
B. कॉलम की संख्या निर्दिष्ट करें।
C. न्यूनतम स्तंभ की चौड़ाई जिस पर एक कॉलम अगली पंक्ति में धकेल दिया जाएगा।

इसे ऊपर लाने के लिए धन्यवाद, @meh। आप इसके बारे में बहुत सही हैं - यह निश्चित रूप से मेरे दिमाग में भी है।

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

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

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

यह सब पूरी तरह से बहस के लिए है, लेकिन इस विषय पर मेरी सोच कम से कम है। 🙂

हां, मैं समझता हूं और डिवाइस संचालित समाधान का पता लगाने के लिए कारणों से सहमत हूं। बस इस बग को कान में चिपकाना चाहते थे जबकि इसकी योजना बनाई जा रही थी।

मुझे लगता है कि कोई समझौता हो सकता है। अधिकतर यह है कि CSS किस तरह से चुने गए विकल्पों और मूल्यों को संभालता है।

बस पिछले सप्ताह से इस दिशा में कुछ मामूली अपडेट साझा कर रहे हैं।

सबसे पहले, मैंने टॉगल विकल्प के लिए कुछ वैकल्पिक लेबल के माध्यम से सोचा:

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

मुझे यह भी लगता है कि माध्यमिक पाठ की एक वैकल्पिक पंक्ति को शामिल करना उपयोगी होगा ताकि ब्लॉक डिफ़ॉल्ट व्यवहार के लिए थोड़ा जोड़ा संदर्भ प्रदान कर सकें। कॉलम ब्लॉक के मामले में, यह कुछ इस तरह हो सकता है:

मैंने अधिक जटिल सेटअपों के आसपास अन्वेषण का पुनर्मूल्यांकन

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

प्रक्रिया के बारे में ध्यान दें: नए UI नियंत्रणों की शुरूआत के बारे में चर्चा करने वाला एक मुद्दा "एक्सेसिबिलिटी" लेबल होना चाहिए यदि हम वास्तव में टीमों में सहयोग को बेहतर बनाने और एक बेहतर उत्पाद बनाने का लक्ष्य रखते हैं। उचित लेबलिंग और उत्साहजनक भागीदारी को बहुत सराहा जाएगा encour

पुन: "ऑटो" और "कस्टम" विकल्पों के साथ नवीनतम प्रोटोटाइप: अंतर्निहित मूल HTML तत्व क्या हैं जो इन नियंत्रणों पर आधारित होना चाहिए?

• बटन: सहायक तकनीकों के संदर्भ में पाठ "ऑटो" और "कस्टम" बहुत समझ में नहीं आता
• रेडियो बटन: ऊपर दिया गया "डिवाइस-विशिष्ट लेआउट" टेक्स्ट का उपयोग एक क्षेत्र कथा के लिए किया जा सकता है जो रेडियो बटन को संदर्भ देगा।

इस बिंदु पर: देशी रेडियो बटन का उपयोग न करने के लिए क्या तर्क है, जो एकल-विकल्प विकल्प के लिए उपयोग किए जाने वाले उचित तत्व हैं?

@kjellr @afercia
मुझे कोई कारण नहीं है कि "कस्टम डिवाइस-विशिष्ट लेआउट का उपयोग करें" या ऐसा कुछ टॉगल लेबल का उपयोग न करें जो डिफ़ॉल्ट रूप से अक्षम हो। वर्तमान स्थिति का वर्णन करने वाला अतिरिक्त पाठ टॉगल के नीचे दिखाया जा सकता है, गुटेनबर्ग में कुछ मौजूदा टॉगल नियंत्रणों के समान। लेकिन अगर रेडियो बटन का उपयोग किया जाता है, तो मैं मानता हूं कि "कस्टम" "मैनुअल" से बेहतर काम करता है।

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

मैं इसे +1 कर रहा हूं।

सेगमेंटेड कंट्रोल के साथ मेरा मुख्य आकर्षण यह है कि यह दो विकल्पों की तरह दिखता है, जिससे कथित जटिलता 100% बनाम एकल टॉगल बढ़ जाती है। लेखक को _one_ के बजाय _two_ सेटिंग्स को समझना होगा।

जैसा कि टॉगल में एक अधिक विस्तृत लेबल हो सकता है जो समझने में आसान बनाता है। यह एक बहुत स्पष्ट स्पष्टीकरण बनाम दो सेटिंग के साथ एक अधिक अस्पष्ट विवरण के साथ एक सेटिंग का मामला लगता है। वहाँ एक स्पष्ट विजेता वहाँ imo है।

हालाँकि, मैं विचार करूंगा कि टॉगल _on_ डिफ़ॉल्ट रूप से किया जाए और लेबल को "अन्य स्वचालित आकार के लिए स्वचालित रूप से लेआउट कॉन्फ़िगर करें" जैसी चीज़ पर सेट करें। मेरा कारण यह है कि यह एक ऐसी चीज़ है जिसे हम "स्मार्ट डिफ़ॉल्ट" के रूप में प्रस्तुत कर रहे हैं, जो कि डिफ़ॉल्ट रूप से _enabled_ है। मेरे लिए ऐसा लगता है कि आप कुछ चुन रहे हैं। जैसे प्रशिक्षण पहियों को हटाना या ABS को अक्षम करना।

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

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

मेरे पास व्यक्तिगत रूप से कोई प्राथमिकता नहीं है कि हम किस संस्करण के लिए संभवत: समीक्षात्मक समुद्र को निर्धारित कर सकते हैं, लेकिन टॉगल के हाल के उल्लेखों को देखते हुए, ऐसा लगता है कि यह एक विकल्प के रूप में भी दिखाने योग्य हो सकता है।

बटोंगग्रुप छवि आयामों के लिए विशेष रूप से काम करता है क्योंकि समूह में प्रत्येक आइटम विशिष्ट रूप से संबंधित हैं:

हमेशा की तरह प्रतिक्रिया के लिए धन्यवाद। 👏

@afercia

उचित रूप से लेबलिंग और उत्साहजनक भागीदारी की काफी सराहना की जाएगी

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

इस बिंदु पर: देशी रेडियो बटन का उपयोग न करने के लिए क्या तर्क है, जो एकल-विकल्प विकल्प के लिए उपयोग किए जाने वाले उचित तत्व हैं?

मैंने पहले कोशिश की, लेकिन अन्वेषण साझा नहीं किया:

यहाँ मैंने इसे व्यक्तिगत रूप से क्यों पारित किया:

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

@jasmussen

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

हां, मैंने डीएम से इस बारे में बात करते हुए आपसे साझा किया। यह रहा:

मैंने इस दृष्टिकोण के लिए एक डेस्कटॉप प्रोटोटाइप भी तैयार किया।

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

पूरी तरह से उन संक्षिप्त विवरणों के आधार पर, मैंने सोचा कि फॉर्मटॉगल ने अधिक समझ बनाई। लेकिन यह कमोबेश दोनों दृष्टिकोणों के बीच टॉस था।

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

ओह, यहाँ से खुद

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

मैंने एक त्वरित अन्वेषण किया कि यह कैसे दिख सकता है, एक मोडल के अंदर पूर्वावलोकन के बारे में सोच:

यह मज़ेदार लगता है, लेकिन इस मुद्दे के दायरे से बाहर भी हो सकता है।

मैं भी वास्तव में मेरे "केवल होवर पर" पूर्वावलोकन आइकन के उपचार में नहीं हूँ। जब मैंने मोबाइल पर इसे आज़माया तो मैंने इसे थोड़ा ट्विक किया:

वास्तव में उस संवेदनशील पूर्वावलोकन को खोदें। मैं खाली समय में उसी लाइनों के साथ काम कर रहा हूँ, बस उस के साथ पूर्वावलोकन बटन की जगह:

👆 लेकिन ओवन में अधिक समय की आवश्यकता होती है, कृपया इसे एक प्रस्ताव भी न मानें। मिश्रण में फेंकने के लिए बस एक विचार का एक बीज, कुछ में बढ़ने के लिए _actual_।

मैंने डिवाइस आइकन पर लेबल और स्लाइडर्स के समूह में "कॉलम की गिनती" लेबल जोड़कर अधिक एक्सेसिबिलिटी फ्रेंडली होने के लिए @kjellr के नीट मॉकअप में से एक को

एक बात मुझे यकीन नहीं है कि ब्रेकप्वाइंट की चौड़ाई कैसे परिभाषित की जाती है। क्या वे विषय या ब्लॉक द्वारा प्रदान किए गए हैं? क्या कोई ब्लॉक 3 के बजाय सिर्फ 2 ब्रेकप्वाइंट कर सकता है? 4 के बारे में क्या? कस्टम ब्रेकप्वाइंट की चौड़ाई के बारे में क्या? जो भी हो, मुझे नहीं लगता कि संपादक को उन्हें प्रदान करना चाहिए।

इस टिप्पणी में @meh किस तरह के संबंधों की बात कर रहा था। मैं उस टिप्पणी के अंत में जो कुछ सुझाता हूं, उसके समान झुकना शुरू कर रहा हूं। मैं कल्पना करता हूं कि स्तंभों के लिए उत्तरदायी नियंत्रण सिर्फ 2 स्लाइडर्स के साथ लागू किया जा सकता है:

न्यूनतम कॉलम चौड़ाई
――――― ओ ―――― [300] पीएक्स
प्रति पंक्ति अधिकतम कॉलम
――― o ―――――――― [__3]

औसत डिवाइस स्क्रीन चौड़ाई के आधार पर हार्ड ब्रेकप्वाइंट का सहारा लेने के बिना, यह मेरे लिए बहुत सरल और कहीं अधिक "उत्तरदायी" लगता है।

यहां एक लक्ष्य यह है कि यह सरल दिखाई दे

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

इसके बजाय, एक पौराणिक कथा के साथ एक क्षेत्र में वर्गीकृत रेडियो बटन संदर्भ देते हैं क्योंकि किंवदंती की घोषणा की जाती है।

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

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

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

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

कॉलम के अलावा, मैं छवि ब्लॉकों के लिए "स्टैक-ऑन-मोबाइल" विकल्प की आवश्यकता का सामना कर रहा हूं। मैं जिस विरासत की वेबसाइट पर वर्डप्रेस ट्वेंटी उन्नीस की ओर पलायन कर रहा हूं, उसमें बाईं और दाईं ओर बड़ी-बड़ी, टेक्स्ट-रैप्ड छवियां हैं, जो चौड़ाई में हैं (और रहने की जरूरत है) 300px या तो। एक पैराग्राफ ब्लॉक में गिरा, ये छवि ब्लॉक डेस्कटॉप पर ठीक काम करते हैं, लेकिन अधिकांश मोबाइल स्क्रीन पर वे बगल में पाठ को अवैधता में निचोड़ते हैं। प्रत्येक छवि के लिए, मैं CSS वर्ग जोड़ने के लिए छवि ब्लॉक पर उन्नत पैनल का उपयोग कर रहा हूँ .isom (टाइपिंग की तुलना में तेज "is-stacked-on-mobile"!) जो छवि को ब्रेकपॉइंट के लिए 100% चौड़ाई तक विस्तारित करता है। बीस उन्नीस उपयोग करता है। मुझे लगता है कि यह कई उपयोगकर्ताओं के लिए एक आम समस्या हो सकती है, और न केवल प्रवासी (यदि यह एक शब्द है)।

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

निरंतर प्रतिक्रिया के लिए धन्यवाद, हर कोई!

एक बात मुझे यकीन नहीं है कि ब्रेकप्वाइंट की चौड़ाई कैसे परिभाषित की जाती है। क्या वे विषय या ब्लॉक द्वारा प्रदान किए गए हैं? क्या कोई ब्लॉक 3 के बजाय सिर्फ 2 ब्रेकप्वाइंट कर सकता है? 4 के बारे में क्या? कस्टम ब्रेकप्वाइंट की चौड़ाई के बारे में क्या? जो भी हो, मुझे नहीं लगता कि संपादक को उन्हें प्रदान करना चाहिए।

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

ऐसा लगता है कि लोग इस मामले में एक मानक टॉगल नियंत्रण का उपयोग करने के लिए कम या ज्यादा इकट्ठा हो रहे हैं।

मैंने ऊपर @ZebulanStanphill के COMP के लिए हल्की सफाई की है, रिक्ति और प्रकार का समायोजन समायोजित किया है। चूंकि हम पहले से ही टेक्स्ट वेट को अलग-अलग फील्ड लेबल से पैनल टाइटल्स को अलग करने के लिए उपयोग कर रहे हैं, इसलिए मैं अलग-अलग डिवाइस लेबल के लिए एक रंग समायोजन के साथ गया हूं। उन लोगों के लिए ग्रे $dark-gray-300 , जो एए गुजरता है।

यहाँ एक अद्यतन मॉकअप और प्रोटोटाइप है:

🖥 डेस्कटॉप प्रोटोटाइप

📱 मोबाइल प्रोटोटाइप

मैंने भी आगे बढ़कर कुछ वैकल्पिक मामलों का मजाक उड़ाया है:

• एक गैलरी ब्लॉक
• एक और अधिक जटिल उदाहरण (मुझे लगता है कि यहाँ बॉटलॉस्ट सेक्शन में कुछ लेबलिंग को समेकित किया जा सकता है।)

चीजों को साथ ले जाने के हित में, यहां मैं सोच रहा हूं:

1. धागे में सभी से प्रतिक्रिया का एक और दौर प्राप्त करें । मैं a11y परिप्रेक्ष्य से विशेष रूप से सुनना पसंद करूंगा: यह एक ठोस समाधान की तरह लगता है या नहीं।
2. कुछ वैकल्पिक लेबल इकट्ठा करें । टॉगल फ़ील्ड के लिए लेबल अभी भी थोड़ा भ्रमित है। हमें कुछ और विकल्प तैयार करने चाहिए और फिर:
3. लेबलिंग के कुछ हल्के उपयोगकर्ता परीक्षण करें, यह देखने के लिए कि कौन इस कार्यक्षमता के लिए अपेक्षाओं को ठीक से निर्धारित करता है।

कृपया मुझे इस दिशा में और अगले चरणों पर कोई विचार बताएं!

@kjellr

चूंकि हम पहले से ही टेक्स्ट वेट को अलग-अलग फील्ड लेबल से पैनल टाइटल्स को अलग करने के लिए उपयोग कर रहे हैं, इसलिए मैं अलग-अलग डिवाइस लेबल के लिए एक रंग समायोजन के साथ गया हूं। उन लोगों के लिए ग्रे $dark-gray-300 , जो एए गुजरता है।

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

एक और अधिक जटिल उदाहरण (मुझे लगता है कि यहाँ बॉटलॉस्ट सेक्शन में कुछ लेबलिंग को समेकित किया जा सकता है।)

हाँ, प्रत्येक टॉगल के ऊपर के लेबल का कोई कारण नहीं है। टॉगल लेबल से पहले टॉगल के बगल में आइकन लगाए जा सकते हैं।

इसके अलावा, यह सिर्फ एक नाइटपिक है, लेकिन क्या उन स्लाइडर्स को ब्रेकपॉइंट लेबल से इंडेंट होने के बजाय बाईं ओर सभी तरह से नहीं बढ़ाया जाना चाहिए?

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

थोड़ा गहरा जाना ठीक है। मैं $dark-gray-500 से अधिक गहरा नहीं जाऊंगा (हालांकि नीचे चित्र), अन्यथा ग्रे बाकी के पाठ के समान दिखता है।

इसके अलावा, यह सिर्फ एक नाइटपिक है, लेकिन क्या उन स्लाइडर्स को ब्रेकपॉइंट लेबल से इंडेंट होने के बजाय बाईं ओर सभी तरह से नहीं बढ़ाया जाना चाहिए?

मैंने उन्हें खेतों में थोड़ा और पदानुक्रम जोड़ने के लिए प्रेरित किया। जब प्रत्येक क्षेत्र पूर्ण-चौड़ाई वाला होता है, तो यह कम स्पष्ट होता है कि ये "कॉलम की संख्या" लेबल के अधीन हैं।

@kjellr

मैंने उन्हें खेतों में थोड़ा और पदानुक्रम जोड़ने के लिए प्रेरित किया। जब प्रत्येक क्षेत्र पूर्ण-चौड़ाई वाला होता है, तो यह कम स्पष्ट होता है कि ये "कॉलम की संख्या" लेबल के अधीन हैं।

उस स्थिति में, क्या यह ब्रेकपॉइंट लेबल को भी इंडेंट करने के लिए समझ में नहीं आएगा?

उस स्थिति में, क्या यह ब्रेकपॉइंट लेबल को भी इंडेंट करने के लिए समझ में नहीं आएगा?

क्रमबद्ध करें, लेकिन हम आम तौर पर चीजों को इंडेंट नहीं करते हैं। यहाँ ऐसा करना मेरे लिए अनजाना / टूटा हुआ दिखता है:

यहां पूर्ण-चौड़ाई वाले फ़ील्ड का भी तुलना के साथ अनुपालन है:

जैसा कि मैंने ऊपर उल्लेख किया है, कि कुछ दृश्य पदानुक्रम को समाप्त करता है और मुझे एक नज़र में कम स्कैन करने योग्य लगता है। सिर्फ खेतों का संकेत एक अच्छा समझौता जैसा लग रहा था:

मैं वास्तव में सिर्फ खेतों को इंडेंट करने के साथ लेआउट को पसंद करता हूं। यह a11y मुद्दों को संबोधित करने के लिए प्रकट होता है, और वहां कुछ प्रतिक्रिया मिलने पर सहमत होता है।

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

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

मैं वहां पूरी तरह से सहमत हूं। पिछले एक्सपायरीज़ पर जिनमें लेबल नहीं थे, मुझे लगा कि ये अभी भी ज्यादातर सुपाच्य हैं:

... लेकिन नया संस्करण जटिल होने पर स्कैन करना बहुत कठिन है। इसे सुधारने का एक संभव तरीका निम्नलिखित विचारों को अपनाना होगा:

• एक ही डिवाइस सेक्शन के तहत कई नियंत्रणों को समेकित करने की सलाह देते हैं (जैसा कि नीचे लेआउट अनुभाग में दिखाया गया है)।
• डिवाइस के लेबल को हटा दें जब नियंत्रण का लेबल डिवाइस नाम को बता सकता है (जैसा कि नीचे दृश्यता अनुभाग में दिखाया गया है)।

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

मैं पहले शब्दार्थ के संदर्भ में सोचने की सलाह दूंगा, और फिर आवश्यक शब्दार्थ के आसपास डिजाइन करूंगा।

प्रत्येक इनपुट को सार्थक और _unique_ तरीके से लेबल करने की आवश्यकता है। उन पाठ लेबल <label> स्लाइडर्स और संख्या फ़ील्ड से जुड़े तत्व होंगे। सहायक तकनीकों के उपयोगकर्ता के रूप में, मुझे एक ही पाठ के साथ लेबल किए गए कई क्षेत्रों को कैसे अलग करना है?

उदाहरण के लिए:

• एक स्क्रीन रीडर उपयोगकर्ता के रूप में, विभिन्न संख्या फ़ील्ड्स पर टैब करता हूँ, जिन्हें "डेस्कटॉप (मोबाइल)?"
• वाक् इनपुट उपयोगकर्ता के रूप में, "कॉलम की संख्या पर क्लिक करें" कमांड को आवाज देने से मैं जिस ध्वनि पहचान सॉफ़्टवेयर का उपयोग कर रहा हूं, वह भ्रमित हो जाएगा, क्योंकि यह समान नाम वाले क्षेत्रों के बीच अंतर नहीं कर पाएगा

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

इन सभी लेबल को बेहतर संदर्भ देने की आवश्यकता है और प्रत्येक क्षेत्र के लिए अद्वितीय होने की आवश्यकता है।

यह इंटरफ़ेस जटिल है, मैं मौलिक रूप से इसे सरल बनाने का तरीका तलाशने की सलाह दूंगा। उदाहरण के लिए:

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

खुशी है कि "ऑटो" और "मैनुअल" बटन अंतिम प्रोटोटाइप में चले गए हैं और उन्हें टॉगल के साथ बदल दिया गया है (हालांकि टॉगल की अपनी समस्याएं हैं)। धन्यवाद।

तो दृश्यता सेटिंग्स कुछ उपकरणों के लिए पूरे ब्लॉक को छिपाने के लिए है? क्या इसे हर ब्लॉक के विकल्प के रूप में जोड़ा जाएगा? बटन, पैराग्राफ, विभाजक, आदि?

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

तो दृश्यता सेटिंग्स कुछ उपकरणों के लिए पूरे ब्लॉक को छिपाने के लिए है? क्या इसे हर ब्लॉक के विकल्प के रूप में जोड़ा जाएगा? बटन, पैराग्राफ, विभाजक, आदि?

ओह, वहाँ भ्रम की स्थिति के लिए खेद है: यह विभिन्न परिस्थितियों के लिए इस पैटर्न के तनाव-परीक्षण का एक उदाहरण है (यह ऊपर एक 3 पार्टी उत्पाद ब्लॉक के संदर्भ में उठाया गया था)। हम इसे किसी भी कोर ब्लॉक में नहीं जोड़ेंगे।

इनपुट के लिए धन्यवाद, @afercia! मैं यहां आपकी प्रतिक्रिया की सराहना करता हूं।

सहायक तकनीकों के उपयोगकर्ता के रूप में, मुझे एक ही पाठ के साथ लेबल किए गए कई क्षेत्रों को कैसे अलग करना है?

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

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

• मुझे यकीन नहीं है कि स्लाइडर्स द्वारा जोड़ा गया मूल्य क्या है, उनके "प्रीटीनेस" के अलावा: वे एक माउस के साथ भी उपयोग करना मुश्किल है, वे बहुत सारे स्थान लेते हैं, और पहले से ही इनपुट फ़ील्ड हैं

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

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

• यकीन नहीं है कि डिवाइस आइकन वास्तव में आवश्यक हैं: उन्हें हटाने से कुछ स्थान बचा सकता है

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

@afercia

मैं पहले शब्दार्थ के संदर्भ में सोचने की सलाह दूंगा, और फिर आवश्यक शब्दार्थ के आसपास डिजाइन करूंगा।

यदि HTML fieldset , legend और इसी तरह का उपयोग करते हुए लिखा गया था, तो क्या @kjell का लेआउट

ऐसा लगता है कि प्रत्येक लेबल के अलग और स्पष्ट होने से हमें सबसे अच्छी सेवा मिलेगी।

@kjellr हां :) मैं आपके उदाहरण के अनुसार संदर्भ देने वाले प्रत्येक लेबल पर विचार करूंगा। यह सरल और अधिक समझ में आता है। शायद थोड़ा कम शब्दांकन मदद कर सकता है। उदाहरण के लिए, क्या "संख्या" वास्तव में आवश्यक है? मैं कहता हूं कि नेत्रहीन भी बहुत कुछ करने की प्रक्रिया है और शायद चीजों को सरल बनाने में थोड़ी मदद मिल सकती है।

@मैप हां, मैंने उस पर विचार किया है। fieldset और legend एक साथ नियंत्रण का समूह बनाने और समूह को एक नाम देने का सही तरीका है। हालांकि यह वास्तविक समर्थन की बात है, और इसका परीक्षण करने की आवश्यकता होगी। यह रेडियो बटन या चेकबॉक्स के समूहों के साथ बहुत अच्छी तरह से काम करता है। मुझे नहीं पता कि यह range और number इनपुट के साथ अच्छा काम करता है या नहीं।

RangeControl घटक का एक और मुद्दा है: समान लेबल मान का उपयोग सीमा और संख्या इनपुट दोनों के लिए किया जाता है। इस प्रकार, सीमा और संख्या इनपुट का एक ही सुलभ नाम है। आदर्श नहीं। पहुँच टीम की बैठक के दौरान आज चर्चा करने का प्रस्ताव करेगा (हर किसी का स्वागत है)।

समान लेबल मान का उपयोग रेंज और संख्या इनपुट दोनों के लिए किया जाता है

मैं https://github.com/WordPress/gutenberg/pull/13863 @afercia के साथ इसे बदलने की उम्मीद कर रहा हूं

धन्यवाद @meh! मैंने जल्दी से वहाँ टिप्पणी की है।

@kjellr हां :) मैं आपके उदाहरण के अनुसार संदर्भ देने वाले प्रत्येक लेबल पर विचार करूंगा। यह सरल और अधिक समझ में आता है। शायद थोड़ा कम शब्दांकन मदद कर सकता है। उदाहरण के लिए, क्या "संख्या" वास्तव में आवश्यक है? मैं कहता हूं कि नेत्रहीन भी बहुत कुछ करने की प्रक्रिया है और शायद चीजों को सरल बनाने में थोड़ी मदद मिल सकती है।

धन्यवाद, @afercia। यहाँ एक मजाक है:

फील्ड लेबल के "कॉलम" पर "मुझे कॉलम की संख्या" के बाद थोड़ा दोहराव लगता है। लेकिन मुझे लगता है कि यह व्यावहारिक है।

हां, मैंने ऐसा माना है। fieldset और legend एक साथ नियंत्रण का समूह बनाने और समूह को एक नाम देने का सही तरीका है। हालांकि यह वास्तविक समर्थन की बात है, और इसका परीक्षण करने की आवश्यकता होगी। यह रेडियो बटन या चेकबॉक्स के समूहों के साथ बहुत अच्छी तरह से काम करता है। मुझे नहीं पता कि यह range और number इनपुट के साथ अच्छा काम करता है या नहीं।

हम यह कैसे सत्यापित कर सकते हैं कि यह range और number इनपुट के साथ काम करता है? यदि यह लेबलिंग समस्या पहले से ही इस तरह से कवर की गई है, तो मैं व्यक्तिगत फ़ील्ड लेबल को अधिक संक्षिप्त रखना पसंद करूंगा।

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

इसके अलावा, डिवाइस प्रकार के नाम सभी एकवचन या सभी बहुवचन होंगे। मुझे पता है कि वे मजाक कर रहे हैं। बस कहना: स्माइली:

इसके अलावा, डिवाइस प्रकार के नाम सभी एकवचन या सभी बहुवचन होंगे। मुझे पता है कि वे मजाक कर रहे हैं। बस साईं 😃

ऊपर अपडेट किया गया।

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

उस आखिरी मॉकअप, @kjellr के संबंध में, "कॉलम" का अकॉर्डियन शीर्षक "कॉलम की संख्या" और "डेस्कटॉप पर कॉलम" या टैबलेट पर "कॉलम" आदि शब्द "कॉलम" के निरंतर पढ़ने के साथ बेमानी लगता है। बहुत कुछ दिखाई देता है।

क्या a11y की जरूरत अभी भी पूरी होगी यदि शीर्षक "कॉलमों की संख्या" legend fieldset ? फिर यह इंगित करना चाहिए कि उस फ़ील्डसेट में समूहीकृत आइटम वापस "कॉलम की संख्या" से संबंधित हैं? तो इनपुट लेबल सिर्फ "डेस्कटॉप", "टैबलेट", और "मोबाइल" हो सकते हैं।

फ़ील्ड और किंवदंती: जैसा कि पहले टिप्पणी की गई है, जिसे जांचने की आवश्यकता होगी:

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

ऊपर मेरी टिप्पणी के आधार पर, शायद नीचे जैसा कुछ? मैंने मार्कअप भी शामिल किया है। @kjellr , आपको क्या लगता है?

@मैपक शायद स्लाइडर को हटा दिया जाना चाहिए क्योंकि वे स्तंभ गणना जैसे मोटे नियंत्रण के संदर्भ में बहुत उपयोगी नहीं हैं।

मैं @ZebulanStanphill जैसी ही बात सोच रहा

वॉल्यूम इनपुट या हमारी छवि ओवरले अपारदर्शिता जैसी चीजों के लिए रेंज इनपुट अच्छी तरह से काम करते हैं जहां आपको स्लाइडर को देखकर परिणाम का अंदाजा हो जाता है। _25%, 50%, 100% _

MDN डॉक्स से

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

मुझे लगता है कि टिकमार्क इसे और अधिक उपयोगी बना सकता है, लेकिन फिर भी, कॉलम समायोजित करने के लिए 2 तरीके क्यों प्रदान करते हैं?

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

[4] columns on desktops
[2] columns on tablets
[1] column on mobile devices

नमस्ते! उत्तरदायी दृश्यता के संबंध में, मेरे पास मेरे संपादकों प्लगइन (पहले ब्लॉक विकल्प) पर यह सुविधा है। यहां बताया गया है कि विशेषताएं कैसे काम करती हैं:

https://www.youtube.com/watch?v=1VuBXAUqTjA

आशा है आप इसे पसंद करेंगे! चीयर्स!

धन्यवाद @ एफबिट्स! मैं वहां आपके अन्वेषण की सराहना करता हूं, हालांकि मुझे लगता है कि "ऑन / ऑफ" राज्य इस मामले में विचार करना बहुत मुश्किल है। उस मामले में टॉगल नियंत्रण या चेकबॉक्स जैसा कुछ बेहतर काम कर सकता है?

कॉलम की गिनती जैसे मोटे नियंत्रण के संदर्भ में स्लाइडर्स को संभवतः हटा दिया जाना चाहिए क्योंकि वे बहुत उपयोगी नहीं हैं।

धन्यवाद @ZebulanStanphill @afercia ने भी ऊपर इसका उल्लेख किया है। मैं एक और डिज़ाइन पुनरावृत्ति के लिए खुला हूँ जो इसकी पड़ताल करता है। @kjellr कोई विचार?

इसके अलावा इस बात को पिछले डिजाइन से प्राप्त करें और इसके लिए एक पीआर पर शुरू करें। मुझे लगता है कि हम वास्तविक उपयोगकर्ताओं के साथ बेहतर तरीके से प्लगइन का परीक्षण कर सकते हैं।

धन्यवाद @ एफबिट्स! मैं वहां आपके अन्वेषण की सराहना करता हूं, हालांकि मुझे लगता है कि "ऑन / ऑफ" राज्य इस मामले में विचार करना बहुत मुश्किल है। उस मामले में टॉगल नियंत्रण या चेकबॉक्स जैसा कुछ बेहतर काम कर सकता है?

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

मुझे लगता है कि रेंज इनपुट अच्छे हैं क्योंकि वे मिन (अधिकतम) मानों का एक स्पष्ट (एर) दृश्य संकेत प्रदान करते हैं।

कॉलम की गिनती जैसे मोटे नियंत्रण के संदर्भ में स्लाइडर्स को संभवतः हटा दिया जाना चाहिए क्योंकि वे बहुत उपयोगी नहीं हैं।

धन्यवाद @ZebulanStanphill @afercia ने भी ऊपर इसका उल्लेख किया है। मैं एक और डिज़ाइन पुनरावृत्ति के लिए खुला हूँ जो इसकी पड़ताल करता है। @kjellr कोई विचार?

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

मैंने यहाँ लगभग सभी टिप्पणियाँ पढ़ीं, लेकिन किसी ने भी सामने-अंत में सामग्री को लोड नहीं करने के लिए फ़ंक्शन के रूप में डिवाइस दृश्यता का उपयोग करने के बारे में सोचा और न केवल display:none , क्योंकि मुझे हमेशा कुछ पागल डिजाइनर मिलता है जो चाहता है सामने मोबाइल पर कई छवियों को छुपाने के लिए लेकिन इससे कोई फर्क नहीं पड़ता कि क्या छवियाँ अभी भी भरी हुई हैं ... इसलिए मैं रोकने के लिए ACF सामान बनाता हूं ...

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

एक और लाभ यह है कि स्लाइडर्स के साथ, यदि अच्छी तरह से डिज़ाइन किया गया है (बड़े अंगूठे, टिक के निशान आदि), तो वे नेत्रहीन एक रिश्तेदार न्यूनतम / अधिकतम मूल्यों का संचार कर सकते हैं।

मैं समझता हूं कि मैं एक माउस उपयोगकर्ता हूं, और अन्य उपयोगकर्ताओं के लिए स्लाइडर्स आदर्श भी नहीं हो सकते हैं। मुझे उम्मीद है कि हम एक संतुलन पा सकते हैं जो अधिक से अधिक उपयोगकर्ताओं के लिए काम करता है।

मैंने अब विलय कर लिया है:

• ResponsiveBlockControl घटक
• DimensionControl घटक

ये किसी दिए गए ब्लॉक विशेषता जैसे padding लिए व्यूपोर्ट विशिष्ट नियंत्रण सक्षम करने के लिए नींव रखते हैं।

# 19909 में मैंने उत्तरदायी संपादन के लिए एक वैकल्पिक दृष्टिकोण को टिकट दिया, जो संभावित रूप से प्रत्येक मौजूदा ब्लॉक को अतिरिक्त कोड के बिना, उत्तरदायी परिवर्तन करने में सक्षम बनाता है।

मोबाइल पर कॉलम चौड़ाई समायोजन के साथ हाथ से दस्ताने मोबाइल पर स्तंभ क्रम होगा।

उदाहरण के लिए, एक पूर्ण स्क्रीन पर मैंने कॉलम 1-2-3-4-5 सेट किया। जब यह जिम्मेदारी से परिवर्तित होता है, तो मैं चाहता हूं कि वे 5, 4, 3, 2, 1 दिखाई दें।
या 5-3, 1 (* 2, 4 को प्रदर्शित न करें)।

व्यक्तिगत कॉलम नियंत्रित करता है _on Responsive_:

1. टॉगल शो / छुपाएँ
2. नियंत्रण चौड़ाई
3. पुन: व्यवस्थित करने के लिए ड्रॉप-डाउन बॉक्स

इसके लायक क्या है - यह कस्टम शैली नियंत्रण का हमारा नवीनतम पुनरावृत्ति है, पहले एक एकल ब्लॉक के लिए और फिर एक कस्टम कॉलम ब्लॉक के लिए

इसे प्यार करना!!!!!!!!!!!!!!

कब? कब?!

साझा करने के लिए धन्यवाद! मैं उत्तेजित हूँ!!!!!

यह वही है जो मैंने अपने स्वयं के कस्टम ब्लॉक उत्तरदायी नियंत्रणों के लिए विकसित किया है:

@mattbolt एक लेआउट पुनरावृत्ति है क्या यह वास्तव में इस समय विकसित किया जा रहा है? यदि यह बाद का है, तो मुझे यह जानकर अच्छा लगेगा कि आपने मीडिया के सवालों को कैसे सुलझाया।

यह इन उपकरणों का हमारा दूसरा दृश्य पुनरावृत्ति है। मूल रूप से हम Wordpress 5 के 2018 के अंत में रिलीज़ होने के बाद घर में विकसित हुए थे और कई साइटों पर जनवरी 2019 से उत्पादन उपयोग में थे, लेकिन मुख्य रूप से www.minderoo.org ।

मीडिया के प्रश्नों के लिए, हमारे सभी ब्लॉक एक सर्वर साइड रेंडर घटक द्वारा समर्थित हैं। इससे पहले कि हम $content = apply_filters('the_content', $post->post_content); कॉल करें हम किसी भी मौजूदा पंजीकृत शैलियों को फ्लश करते हैं। फिर रेंडर प्रक्रिया के दौरान, प्रत्येक ब्लॉक किसी भी विशिष्ट रूप से लागू शैलियों को पंजीकृत करता है और एक अद्वितीय आईडी प्राप्त करता है जिसमें यह ब्लॉक की सीएसएस कक्षाओं में शामिल है।

the_content कॉल करने के बाद, हम एक वेरिएबल को अनूठी शैली "रेंडर" करते हैं। यह एक फ़ंक्शन कॉल है जो 'मीडिया क्वेरिस्ड' सीएसएस उत्पन्न करता है और इसे फ़ंक्शन में सम्मिलित करता है

यह एक पूरी तरह से व्याख्या थी, @mattbolt मुझे यह समझाने के लिए समय निकालने के लिए धन्यवाद :) मेरी क्षमताओं से परे थोड़ा सा लगता है, लेकिन यह एक दिलचस्प नज़र रखना और हुड के नीचे क्या है देखना दिलचस्प होगा।

धन्यवाद फिर से, मैट :)

यह एक बटन ब्लॉक है। इसके चारों ओर सभी व्हाट्सएप को देखें - विशेष रूप से ऊपर और नीचे।

ब्लॉक तत्वों के लिए auto / 0 मार्जिन संरेखण में बदल जाएगा।
उदाहरण Egmargin-left: ऑटो; मार्जिन-राइट: 0; `दाईं ओर एक ब्लॉक एलिमेंट को पुश करेगा।
मार्जिन-विशिष्ट संरेखण के साथ ब्लॉक संरेखण विकल्प (बाएं / दाएं) को कैसे समेटा जा सकता है?

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

क्यों नहीं स्मार्टवॉच, स्मार्ट-टीवी, चश्मा या जो भी अन्य डिवाइस वेब तक पहुंच है? डेस्कटॉप क्या बनता है? 13 इंच के टैबलेट से 12 इंच के लैपटॉप को क्या अलग करता है? क्योंकि अगर हम स्क्रीन-रिज़ॉल्यूशन के बारे में बात कर रहे हैं, तो एक 7-इंच फोन में 50-इंच टीवी से बड़ा रिज़ॉल्यूशन हो सकता है।
और 2 ब्रेकप्वाइंट (मोबाइल / टैबलेट, टैबलेट / डेस्कटॉप) और सिर्फ 1 (छोटा / बड़ा) क्यों नहीं?

पिक्सेल-पूर्ण होने का प्रयास करने वाली किसी चीज़ के निर्माण के बजाय, क्या हमें शायद दृष्टिकोण को थोड़ा बदल देना चाहिए और कुछ ऐसा बनाने की कोशिश करनी चाहिए जो पिक्सेल-अज्ञेयवादी हो?

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

जबकि # 19909 में दिखाए गए मॉकअप बहुत पुराने हैं, उस टिकट का प्राथमिक लक्ष्य उत्तरदायी ब्रेकप्वाइंट संपादन के लिए एक _global और extensible_ इंटरफ़ेस का पता लगाना है। जो, अगर सही किया जाता है, तो हम उस स्थिति से बचते हैं जहां आप एक संपादक में एक स्तंभ ब्लॉक के मोबाइल गुणों को संपादित करते हैं जो डेस्कटॉप ब्रेकपॉइंट की तरह दिखता है। इसके विपरीत, संपादक दृश्य मोड और उत्तरदायी गुणों के बीच संबंध बनाकर, हम उलटा कर सकते हैं, डेस्कटॉप ब्रेकप्वाइंट के संपादन की अनुमति तब भी दे सकते हैं, जब मोबाइल डिवाइस पर सभी, प्रत्येक उत्तरदायी ब्रेकप्वाइंट का बेहतर दृश्य प्रतिनिधित्व दिखाते हुए।