@sapallie , क्या आप डिज़ाइन मॉकअप को सार्वजनिक रूप से सुलभ बना सकते हैं? जब तक कि उन्हें इस बिंदु पर साझा न किया जाए।

वर्तमान में एक्सएएमएल विकास कर रहा है, और मुझे ऐसा कुछ देखना अच्छा लगेगा। या, एक अच्छा स्क्रॉलिंग संदेश नियंत्रण जैसा कुछ।

Microsoft ब्रांडिंग के दृष्टिकोण से, एक मानकीकृत त्रुटि बैनर ऐसा लगता है जैसे यह बहुत गलत हो सकता है। मुझे डर है कि अंतिम उपयोगकर्ता हर एप्लिकेशन त्रुटि को Microsoft ब्रांड के साथ जोड़ दें। मैंने अभी प्रस्ताव पढ़ा, और पहली बात जो दिमाग में आई, वह थी मृत्यु के आकर्षक बैनर के बारे में ट्वीट करना।

@sapallie , क्या आप डिज़ाइन मॉकअप को सार्वजनिक रूप से सुलभ बना सकते हैं? जब तक कि उन्हें इस बिंदु पर साझा न किया जाए।

क्षमा करें @adrientetar , मैं उन्हें अभी साझा नहीं कर सकता। अभी के लिए डिज़ाइन केवल Microsoft हैं।

@sapallie , इस अभूतपूर्व फीचर आइडिया के लिए धन्यवाद! मैं विनयूआई के लिए एक प्रोग्राम मैनेजर हूं और टीम को इसे पेश करने के लिए उत्साहित हूं!

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

यहां कुछ चीजें हैं जो मुझे पहले से ही पता हैं मुझे इसके लिए थोड़ा और विचार प्राप्त करने की आवश्यकता है ...

• दृश्य व्यवहार

क्या आपका प्रस्ताव एक किनारे-से-बैनर के लिए है? या एक अधिसूचना टाइल जैसे कि विंडोज़ अधिसूचनाएं क्या करती हैं लेकिन ऐप विंडो में जैसे केंद्र में, निचले किनारे पर, या कोने में?

क्षमा करें @adrientetar , मैं उन्हें अभी साझा नहीं कर सकता। अभी के लिए डिज़ाइन केवल Microsoft हैं।

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

बैनर उपयोगकर्ताओं को उन त्रुटियों से अवगत कराएगा जो उन्हें किसी ऐप/सुविधा का उपयोग करने से रोकती हैं

गैर-महत्वपूर्ण त्रुटियों के लिए बैनर खारिज किया जा सकता है

क्या मैं इन बयानों को पढ़ने में सही हूं, इसका मतलब यह है कि आपके पास महत्वपूर्ण त्रुटियों के लिए एक गैर-खारिज करने योग्य बैनर का विकल्प भी होना चाहिए? यदि हां, तो क्या आप मुझे अपने विशिष्ट ऐप परिदृश्य के बारे में और बता सकते हैं कि एक गैर-खारिज करने योग्य बैनर होने के बिंदु से एक प्राप्त करने/आगे बढ़ने के लिए क्या है? क्या उपयोगकर्ताओं को समस्या का समाधान होने तक ऐप को बंद करने के लिए आरोपित किया जाता है? या यह वह जगह है जहां बटन आएंगे, कहें, उन्हें नेटवर्क और इंटरनेट सेटिंग पृष्ठ पर नेविगेट करें?

फिर से धन्यवाद और मैं इस विचार को परिष्कृत करने के लिए तत्पर हूं!

हर कोई, कृपया इस बातचीत में अपनी आवश्यकताओं, डिजाइनों और दृष्टिकोणों को योगदान देने के लिए प्रोत्साहित महसूस करें! :शरमाना:

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

@SavoySchuler - आपसे सुनकर अच्छा लगा। मैंने आपके सभी सवालों के जवाब देने की कोशिश की लेकिन अगर आपको और कुछ चाहिए तो कृपया मुझे बताएं।

दृश्य व्यवहार:
आदर्श रूप से बैनर विंडोज नोटिफिकेशन टाइल के समान होगा और इसे ऐप विंडो के ऊपर या नीचे पिन किया जाएगा। इसे कहां पिन किया गया है यह ऐप के अन्य विज़ुअल तत्वों पर निर्भर करता है और जहां फोकस निहित है। यह निर्णय एक डिजाइनर द्वारा किया जाना चाहिए।
मुझे लगता है कि जीआईएफ @mdtauk पोस्ट किया गया एक महान प्रारंभिक बिंदु होगा।

खारिज करना:
मुझे लगता है कि महत्वपूर्ण बनाम गैर-महत्वपूर्ण त्रुटियों के साथ मेरे मतलब को गहराई से खोदना समझ में आता है:

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

और मुझे लगता है कि इन सभी को खारिज किया जाना चाहिए (मैंने इसे प्रस्ताव विवरण में भी अपडेट किया है)

उदाहरण दृश्य
मैंने दृश्यों में कुछ बदलाव किए हैं और उन्हें इस तरह साझा करने में सक्षम हूं:

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

मुझे बैनर के लिए वे दृश्य बहुत पसंद हैं। मैं टेक्स्ट और आइकन को 4 px ऊपर ले जाऊंगा, ताकि वे सफेद और रंगीन पट्टी के बजाय सफेद क्षेत्र में केंद्रित हों।

माना। पोस्ट किए गए दृश्य काफी अच्छे लगते हैं।

मुझे बैनर के लिए वे दृश्य बहुत पसंद हैं। मैं टेक्स्ट और आइकन को 4 px ऊपर ले जाऊंगा, ताकि वे सफेद और रंगीन पट्टी के बजाय सफेद क्षेत्र में केंद्रित हों।

मैंने पिक्सल की गिनती नहीं की है, लेकिन ऐसा लगता है कि ये केंद्रित हैं यदि एक्स-ऊंचाई के ऊपर विशेषक चिह्नों के लिए स्थान का हिसाब है।

@sapallie क्या आपने इन नियंत्रणों को स्वचालित रूप से, या प्रोग्रामेटिक रूप से खारिज करने की अनुमति देने के बारे में कोई विचार किया है?

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

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

मैं समझता हूं कि इस तरह के नियंत्रण और इन व्यवहारों के आसपास संभावित अतिरिक्त पहुंच संबंधी विचार हैं लेकिन मेरा मानना ​​​​है कि नियंत्रण को खारिज करने के ये तरीके आवश्यक हैं।

मुझे लगता है कि यह कहना महत्वपूर्ण है कि इस तरह का नियंत्रण किसी ऐप के भीतर सामान्य संदेश भेजने के लिए नहीं है। जब तक कि वास्तव में वांछित उपयोग का मामला न हो।

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

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

मैं इसे StatusTip या StatusNotification जैसा कुछ भी कहूंगा, इसलिए यह न केवल नकारात्मक उपयोगों से जुड़ा होगा।

मुझे लगता है कि जब खिड़की के नीचे रखा जाता है तो ठोस रंग की पट्टी पर प्लेसमेंट को बदलकर डिजाइन अनुकूलित होगा?

इसमें संभवतः एक टाइमआउट संपत्ति होनी चाहिए, और त्रुटि संदेश की पुष्टि पर स्विच करने से पहले एक लंबित संदेश, जैसे प्रगति रिंग और "अभी लॉग इन करना" जैसे कुछ पाठ दिखाने की क्षमता भी हो सकती है।

मुझे बैनर के लिए वे दृश्य बहुत पसंद हैं। मैं टेक्स्ट और आइकन को 4 px ऊपर ले जाऊंगा, ताकि वे सफेद और रंगीन पट्टी के बजाय सफेद क्षेत्र में केंद्रित हों।

मैंने पिक्सल की गिनती नहीं की है, लेकिन ऐसा लगता है कि ये केंद्रित हैं यदि एक्स-ऊंचाई के ऊपर विशेषक चिह्नों के लिए स्थान का हिसाब है।

मुझे लगता है कि यह अधिक संभावना थी कि रंगीन बार को ध्यान में रखे बिना टेक्स्ट बॉक्स में लंबवत केंद्रित था

यहां बताया गया है कि कंट्रोल के प्लेसमेंट के साथ रंगीन बार प्लेसमेंट कैसे बदल सकता है

@mrlacey हाँ, जब बैनर प्रासंगिक नहीं है तो प्रोग्रामेटिक/स्वचालित बर्खास्तगी काफी महत्वपूर्ण है - मैंने इसे प्रस्ताव विवरण में जोड़ा।

स्थिति परिवर्तन और त्रुटियाँ: बैनरों का उपयोग इसी के लिए किया जाना चाहिए। सामान्य संदेश नहीं - मैं उस पर सहमत हूं।

और मुझे लगता है कि कई बैनर काम करने चाहिए। उन्हें बस ढेर किया जाना चाहिए।

@mdtauk मैंने इसका नाम बदलकर "स्टेटस बैनर" कर दिया - आपके सुझावों के लिए धन्यवाद।

लोडिंग स्थिति के लिए - मुझे नहीं लगता कि बैनर में ऐसा होना चाहिए। सामग्री को उस ऐप में प्रदर्शित किया जाना चाहिए जहां सामग्री वास्तव में दिखाई देगी।

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

मुद्दे #622 और #792 भी इस नियंत्रण द्वारा कवर किए जा सकते हैं, अगर इसे बनाया जाना था।

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

मैं समझता हूं कि इस तरह के नियंत्रण और इन व्यवहारों के आसपास संभावित अतिरिक्त पहुंच संबंधी विचार हैं लेकिन मेरा मानना ​​​​है कि नियंत्रण को खारिज करने के ये तरीके आवश्यक हैं।

@mrlacey , बढ़िया कॉलआउट! सौभाग्य से, मैंने टीचिंगटिप पर समयबद्ध ऑटो-बर्खास्तगी के विचार के दौरान इसके एक महत्वपूर्ण हिस्से के माध्यम से काम किया है, और कुछ टीमों के साथ साझेदारी करते हुए जिनके पास एक्सेसिबिलिटी सेटिंग्स की आवश्यकता होगी, मुझे विश्वास नहीं है कि यह सुविधा एक्सेसिबिलिटी चिंताओं के कारण अवरुद्ध हो जाएगी। आपके अन्य सभी बिंदुओं पर +1!

क्या हाइपरलिंकबटन को किसी समाधान से जोड़ने की क्षमता हो सकती है, या नेटवर्किंग जैसे सेटिंग शॉर्टकट से जोड़ने की क्षमता हो सकती है?

क्या हाइपरलिंकबटन को किसी समाधान से जोड़ने की क्षमता हो सकती है, या नेटवर्किंग जैसे सेटिंग शॉर्टकट से जोड़ने की क्षमता हो सकती है?

मैं इन-ऐप या सेटिंग ऐप के लिए हाइपरलिंक वाले सबटेक्स्ट की कल्पना कर रहा था (टीचिंगटिप का एक्सएएमएल कंट्रोल का गैलरी कोड देखें)। क्या आप कुछ और मानकीकृत @mdtauk के बारे में सोच रहे थे?

MessageText के बजाय @SavoySchuler सामग्री संपत्ति?

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

हाँ, शायद मुझे लगता है... निश्चित रूप से इसे जोड़ने में कोई हर्ज नहीं है। यह सब के बाद लचीलापन जोड़ता है और शायद कुछ उपयोग के मामलों के लिए काफी उपयोगी होगा।

@mdtauk - हाँ, मेरा मतलब निश्चित रूप से सामग्री संपत्ति है!

@sapallie

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

हाँ, शायद मुझे लगता है... निश्चित रूप से इसे जोड़ने में कोई हर्ज नहीं है। यह सब के बाद लचीलापन जोड़ता है और शायद कुछ उपयोग के मामलों के लिए काफी उपयोगी होगा।

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

शायद एक से अधिक UI + टिप-शैली पॉप-अप के बजाय, UI + एज-टू-एज बैनर (जिनकी पसंद का उपयोग ऑफिस सूट द्वारा अपडेट के बारे में सूचित करने के लिए किया जाता है - नीचे देखें) होने पर भी जरूरतों को पूरा करेगा आपके UI में निरंतर स्थान प्रदान करता है?

@SavoySchuler नियंत्रण पर एक व्यवहार हो सकता है, जहां यह शीर्षलेख और सामग्री को एक पंक्ति पर रखता है, यदि नियंत्रण चौड़ाई पर्याप्त विस्तृत है।

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

शायद एक से अधिक UI + टिप-शैली पॉप-अप के बजाय, UI + एज-टू-एज बैनर (जिनकी पसंद का उपयोग ऑफिस सूट द्वारा अपडेट के बारे में सूचित करने के लिए किया जाता है - नीचे देखें) होने पर भी जरूरतों को पूरा करेगा आपके UI में निरंतर स्थान प्रदान करता है?

हाँ, यह भी काम करता है। मैं

ऐसा लगता है कि इनलाइन और ओवरले दोनों विकल्पों के लिए आदर्श होगा क्योंकि पूर्व-निरीक्षण में ऑफिस सूट रिबन वाले अपने सभी ऐप्स पर भरोसा करने में सक्षम है। @mdtauk मुझे आपका सुझाव पसंद है जो संकेत देना शुरू कर रहा है कि हम उपस्थिति/गायब व्यवहार के बारे में कैसे सोचते हैं।

@all , क्या कोई मेरे साथ आपके वास्तविक ऐप्स में विशिष्ट परिदृश्य साझा कर सकता है जहां आप इस नियंत्रण का उपयोग करने की कल्पना करते हैं? विशेष रूप से, मुझे दृश्य प्रवेश और बर्खास्तगी का संकेत देने के लिए आवश्यक उपयोगकर्ता सहभागिता पर विचारों में दिलचस्पी है? क्या यहां की आवश्यकताएं इस नियंत्रण से आपके लिए आवश्यक मुख्य व्यवहारों को कवर करती हैं?

@SavoySchuler प्रवेश और निकास को ध्यान में रखते हुए, यह किनारे से स्लाइड कर सकता है, लेकिन यदि डेवलपर चुनता है तो फ़्लोटिंग ओवरले के रूप में भी एनिमेट कर सकता है। OS स्तर पर स्क्रीन के दाहिने किनारे से स्लाइड करना - ऐप विंडो के दाहिने किनारे से, या नियंत्रण या UI तत्व के किनारे से बाहर की ओर।

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

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

एनिमेटेड उदाहरण

दर्ज करें, अपडेट करें, बाहर निकलें - YouTube लिंक

एनिमेट इन - यूट्यूब लिंक

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

स्टेटस बैनर और टीचिंग टिप के बीच अंतर के बारे में मेरे व्यक्तिगत विचार नीचे दिए गए हैं

• वास्तविक कार्रवाई योग्य स्थितियों के लिए स्थिति बैनर _I विश्वास_ को प्रोत्साहित किया जाना चाहिए, और इसलिए टैप किए जाने पर एक ही कार्रवाई को लागू करना चाहिए।

  • टीचिंग टिप क्रियाओं को एक बटन या हाइपरलिंक के रूप में प्रस्तुत करेगी, जिसका उपयोग आमतौर पर ऐसी जानकारी के लिए किया जाता है जिसे आसानी से खारिज किया जा सकता है।

• जब कोई ऐप या ओएस की स्थिति बदलती है, जो ऐप के लिए जरूरी है, तो उसे दिखाने के लिए स्टेटस बैनर ट्रिगर करना चाहिए।

  • टीचिंग टिप महत्वपूर्ण जानकारी प्रदान नहीं करेगी, और एक बार खारिज कर दिए जाने के बाद फिर से नहीं दिखाया जाएगा जब तक कि कुछ नया नहीं जोड़ा जाता है।

• स्थिति बैनर या तो दिखाते समय बना रहना चाहिए, जब तक कि बंद करें बटन से खारिज न किया जाए, या शायद संपर्क में रहने पर स्वाइप किया जाए। एक चल रहे प्रगति परिदृश्य को पूरा करने के अपवाद के साथ, या ओएस स्थिति हल हो जाती है (नेटवर्क बहाल हो जाता है)।

  • टीचिंग टिप में संभवतः एक टाइमआउट फ़ंक्शन शामिल होगा, जो ऐप के चलने के दौरान बेतरतीब ढंग से प्रदर्शित नहीं होगा, ज्यादातर ऐप लॉन्च या पेज/स्क्रीन पर नेविगेशन पर प्रदर्शित होता है।

• स्थिति बैनर का उपयोग ओएस शेल में एक सुसंगत तरीके से किया जाना चाहिए - एक एनम के रूप में सामग्री, आइकन, रंगों के साथ मानक स्थानीयकृत बैनर का एक सेट हो सकता है।

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

  • टीचिंग टिप ऐप विशिष्ट होगी, और कोई परिभाषित मानक सामग्री नहीं होगी, और केवल देव को शामिल करने के लिए।

@mdtauk , वीडियो पर शानदार काम! वे इन विचारों को जीवंत करने में सहायक से परे हैं।

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

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

क्या ऐसे कोई हितधारक हैं जिनकी ज़रूरतें @mdtauk ने ऊपर साझा की गई किसी चीज़ से पूरी नहीं की होंगी?

ऐसा लगता है कि ओपी में नकली स्टेटस बैनर और ऑफिस में देखी गई पूर्ण-चौड़ाई अधिसूचना (पहले की टिप्पणियों में ऊपर की छवियां) या विजुअल स्टूडियो (नीचे के रूप में) के बीच मतभेद हैं।

दोनों के बीच मतभेदों का मतलब है कि मुझे आश्चर्य है कि क्या वे एक ही नियंत्रण या अलग होने चाहिए।

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

स्थिति बैनर

• _आइकन_
• संदेश पाठ
• अतिरिक्त पाठ (दूसरी पंक्ति)
• प्रकार (महत्वपूर्ण, चेतावनी, या सूचना)
• रंग
• स्थान
• एनिमेशन डायरेक्शन
• ईवेंट/कमांड टैप करें
• समय समाप्त

पूर्ण-चौड़ाई वाली सूचनाएं

• _आइकन (संभवतः)_
• संदेश पाठ
• लिंक शैली (बटन या हाइपरलिंक)
• लिंक्स (टेक्स्ट और टैप इवेंट/कमांड - मल्टीपल)
• समय समाप्त

दोनों में केवल बोल्ड गुण मौजूद हैं। _Icon_ संभावित रूप से भ्रमित करने वाला है क्योंकि प्रत्येक प्रकार के लिए विभिन्न प्रकार के आइकन (एक मंडली, या रूपरेखा में) की आवश्यकता होती है।
किस शैली का उपयोग करना है, यह इंगित करने के लिए एक संपत्ति भी होनी चाहिए।

मेरे लिए ऐसा लगता है कि एकल नियंत्रण के लिए बहुत अधिक अंतर है और इन सभी कार्यक्षमताओं को एक साथ रखना भ्रमित और जटिल होगा।
मुझे लगता है कि ये दो अवधारणाएं हैं:

• शून्य या अधिक कार्रवाई योग्य उप-तत्वों के साथ एक खारिज करने योग्य पूर्ण-चौड़ाई वाला बैनर
• एक बैनर जिसका उद्देश्य स्थिति परिवर्तन को इंगित करना है और जो एक बटन के रूप में कार्य करता है

अलग नियंत्रण के रूप में सबसे अधिक मूल्य और कम से कम भ्रम प्रदान करेगा।

एनिमेटेड स्थिति बैनर एक साथ कई सूचनाएं प्रदर्शित करने में कैसे सहायता करेंगे?
या यह अब दायरे से बाहर है?

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

OS एकीकरण का यह स्तर एकल नियंत्रण से परे और WinUI से परे महत्वाकांक्षा को दर्शाता है।

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

नेटवर्क कनेक्टिविटी के नुकसान जैसे सिस्टम वाइड परिदृश्यों के लिए खुले ऐप में ओएस शो बैनर मेरे लिए कई चिंताएं पैदा करता है।

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

• इस तरह के नियंत्रण का एक लक्ष्य जैसा कि यहां बताया गया है, डेवलपर्स के लिए इसे लागू करना आसान बनाना है। इसे नियंत्रित करने की उनकी क्षमता को हटाने से उन ऐप्स के लिए समस्याएँ पैदा होंगी जहाँ विशिष्ट परिदृश्यों को कस्टम तरीकों से नियंत्रित किया जाना चाहिए।

एनिमेटेड मॉक-अप के बारे में ट्विटर पोस्ट से बस यह मुद्दा मिला। ऐसा लगता है कि हमने टूलकिट में InAppNotification नियंत्रण के साथ किए गए बहुत सारे कामों को ओवरलैप कर दिया है। जिसमें कई संदेश कैसे प्रबंधित किए जाते हैं जैसी चीजें शामिल हैं।

हमने सीखा है कि हालांकि यह एक साधारण नियंत्रण की तरह प्रतीत होता है, यह काफी जटिल है। इन सभी मामलों को कवर करने के लिए एक समग्र समाधान होना अच्छा होगा जिसे WinUI में अंतर्निहित किया जा सकता है। तब हम टूलकिट नियंत्रण को हटा सकते हैं।

@ryandemopoulos के साथ चर्चा करते हुए, और मैं समाधान से पहले समस्या (त्रुटि UI की आवश्यकता) पर ध्यान केंद्रित करने के लिए इस प्रारंभिक वार्तालाप को थोड़ा सा पुन: सक्रिय करना चाहता हूं (त्रुटि UI का कोई विशिष्ट टुकड़ा/टुकड़ा)।

यह अंत करने के लिए, मेरा पहला लक्ष्य त्रुटि UI के लिए परिदृश्यों और आवश्यकताओं को बंद करना है ( @sapallie , आपका "क्रिटिकल: वाईफाई कनेक्टिविटी खो गया" परिदृश्य एक आदर्श शुरुआत है)। वहां से, हम यह तय करने के लिए एक साथ काम कर सकते हैं कि समाधान में त्रुटि सूचना UI का एक टुकड़ा या त्रुटि UI घटकों का सेट शामिल है या नहीं। जिससे, हम @mrlacey के एपीआई समानता के ब्रेक डाउन (इसे शुरू करने के लिए धन्यवाद) का विस्तार करेंगे ताकि यह तय किया जा सके कि इस बातचीत के कई आउटपुट होने पर व्युत्पत्ति दृष्टिकोण बनाम विशिष्ट नियंत्रण के लिए पर्याप्त समानता है या नहीं। मैं खुद से आगे नहीं बढ़ना चाहता लेकिन @mrlacey के अलग-अलग समाधानों के लिए तर्क _is_ पहले से ही कुरकुरा दिख रहा है और यह ठीक है। मेरा ध्यान यहां हर किसी के लिए समाधान के टुकड़ों का सही सेट बनाने पर है।

तो, किसी के लिए भी ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , और @mrlacey) जिसके लिए यह नियंत्रण विशेष रूप से प्रासंगिक है, क्या आप मुझे निम्नलिखित प्रदान कर सकते हैं या dm @ [email protected] :

• ऐप का शीर्षक
• परिदृश्य विवरण (त्रुटि, महत्वपूर्ण/गैर-महत्वपूर्ण, और आप इसे कैसे प्रस्तुत करना चाहते हैं इसका विवरण)
• ऐप स्क्रीन का स्क्रीन शॉट जहां त्रुटि मौजूद होगी (यदि उपलब्ध हो)

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

@sapallie मैंने आपके शुरुआती काम को संरक्षित करने में विनम्र होने की कोशिश की। संस्करण इतिहास अंक के शीर्ष पर "द्वारा संपादित..." ड्रॉप डाउन के अंतर्गत देखा जा सकता है। कृपया मुझे बताएं कि क्या मैंने कुछ भी सही ढंग से कैप्चर नहीं किया है।

मैंने इसे WinUI टीम के सामने रखा है और हम मानते हैं कि यहां परिभाषित कार्यक्षमता न केवल त्रुटि संदेशों बल्कि लंबे समय तक चलने वाले ऐप-व्यापी स्थिति संदेशों की सेवा करने में सक्षम होगी। इसमें त्रुटि-विशिष्ट परिदृश्यों के अलावा "अपडेट उपलब्ध" और "बैक-अप पूर्ण" प्रकार के स्थिति संदेश शामिल हैं।

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

मैं ऊपर अपने अनुरोध को फिर से लिखूंगा। @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , और @mrlacey , स्थिति/त्रुटि संदेशों के लिए जिन्हें आप अपने अनुप्रयोगों में प्रदर्शित करना चाहते हैं, क्या आप मुझे निम्नलिखित प्रदान कर सकते हैं या [email protected] पर:

• ऐप का शीर्षक
• परिदृश्य विवरण (स्थिति संदेश, महत्वपूर्ण/गैर-महत्वपूर्ण, और आप इसे कैसे प्रस्तुत करना चाहते हैं इसका विवरण)
• ऐप स्क्रीन का स्क्रीन शॉट जहां त्रुटि मौजूद होगी (यदि उपलब्ध हो)

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

@mdtauk पोस्ट किए गए दृश्यों के संबंध में, क्या हमें वास्तव में स्क्रीन/ऐप के चारों किनारों से प्रदर्शित होने वाले पॉपअप की आवश्यकता है? WinUI का उद्देश्य ऐसी वस्तुओं की स्थिति और स्वरूप को मानकीकृत करना होना चाहिए ताकि सभी ऐप्स समान उपयोग करें, और उस संबंध में, Android Snackbar एक स्पष्ट संदर्भ है। स्नैकबार के साथ ध्यान देने वाली एक और बात यह है कि चमकदार लाल रंग या किसी भी चीज़ के साथ त्रुटियों को प्रदर्शित नहीं करता है, इसकी एक शांत उपस्थिति है जो मुझे लगता है कि उपयोगकर्ता को वह जो कर रहा है उससे बहुत अधिक विचलित न करने में फिर से फायदेमंद है।

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

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

@adrientetar प्रत्येक ऐप समान नहीं है, इसलिए इस नियंत्रण के लिए एक डिफ़ॉल्ट होने पर, डेवलपर्स को इस स्थान को बदलने के लिए, फिर से टेम्पलेट या नियंत्रण को फिर से इंजीनियर किए बिना, इस स्थान को बदलने का एक तरीका होना चाहिए।

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

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

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

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

हाल ही में लंबे समय तक चलने वाले, ऐप-व्यापी स्थिति संदेशों के कुछ और उदाहरण देखे गए:

("रिकॉर्डिंग शुरू हुई" टीम में संदेश)

(Dota 2 में "गेम कोऑर्डिनेटर से जुड़ने की कोशिश कर रहा है")

क्षमा करें, ये छोटे हैं - पहली तस्वीर मेरे डेस्कटॉप से ​​एक अल्ट्रावाइड मॉनिटर के साथ ली गई थी। :)

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

क्या इन्हें गोल किया जाना चाहिए? याँ नहीं?

हाँ, मुझे लगता है कि टीचिंग टिप से यहाँ मुख्य अंतर यह है कि ऐप्स अपने मैसेजिंग स्पेस को समन्वित करना चाहते हैं और एक ही समय में (या उत्तराधिकार में) प्रदर्शित करने के लिए कई त्रुटि / स्थिति अपडेट हो सकते हैं।

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

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

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

वीएस कोड उदाहरण स्क्रीनशॉट:

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

अभी देखा Cortana का ये स्क्रीनशॉट...

ऑफिस यूआई फैब्रिक का मैसेजबार बहुत अच्छा लग रहा है, आईएमओ:

मैंने देखा है कि विंडोज 10 के लिए सैमसंग नोट्स अधिसूचना टोस्ट का उपयोग यह समझाने के लिए करता है कि एक नोट को छोड़ दिया गया था क्योंकि इसमें कुछ भी नहीं था जो इतना कष्टप्रद है

हेलो सब लोग! मैं WinUI के लिए एक प्रोग्राम मैनेजर हूं और @SavoySchuler से इस प्रस्ताव को वापस ले रहा हूं। इस सूत्र में पहले से ही बहुत अच्छी चर्चा और विचार साझा किया जा चुका है, आपके सभी सुझावों के लिए धन्यवाद!

चूंकि यहां कुछ गतिविधि हुए कई महीने हो गए हैं, इसलिए मैं सभी के साथ वापस जांच करना चाहता था और वर्तमान में हम जहां हैं, फिर से पुनरावृति करना चाहता था।

प्रस्ताव के शीर्ष पर हमारे वर्तमान दायरे के सारांश के रूप में:

• अधिसूचना समग्र रूप से आवेदन से संबंधित आवश्यक जानकारी के उपयोगकर्ता को सचेत करने के लिए होगी
• कस्टम सामग्री और स्टाइल का समर्थन करेगा
• स्वचालित रूप से और प्रोग्रामेटिक रूप से खारिज किए जा सकेंगे
• अधिसूचना को उपयोगकर्ता द्वारा खारिज करने में सक्षम होना चाहिए
• कई सूचनाओं का समर्थन करना चाहिए जिन्हें ऐप द्वारा निर्दिष्ट तरीके के अनुसार स्टैक किया जा सकता है
• ऐप्लिकेशन के आकार बदलने और UI में बदलाव के लिए उत्तरदायी होना चाहिए
• अधिसूचना सिस्टम-व्यापी अधिसूचनाएं प्रदर्शित करने के लिए नहीं होगी

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

अब जब हमने कार्यक्षेत्र को परिभाषित कर लिया है, तो कुछ विशिष्ट परिदृश्य और उपयोगकर्ता अनुभव हैं जिन्हें अभी भी परिभाषित करने की आवश्यकता है। मेरी आशा है कि इन अनुभवों को परिभाषित करने से नियंत्रण के लिए UI खर्चे को निर्देशित करने में मदद मिलेगी। आपके परिदृश्यों के लिए आपके क्या विचार हैं?
सीसी: @sapallie , @adrientetar , @EverydayApps @ फ़ेलिक्स-देव, @mdtauk , @mrlacey

अनुभव हैं:

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

आपके सभी विचारों के लिए फिर से धन्यवाद और मैं इसे प्रकाश में लाने के लिए तत्पर हूं!

यह देखकर खुशी हुई कि @gabbybilka इस प्रस्ताव को नहीं भुलाया गया है और इसे स्वीकार करने के लिए धन्यवाद!

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

@chigy अंतिम डिज़ाइन स्पेक्स के बारे में बात करने वाला कोई होगा, क्योंकि वह फ़्लुएंट डिज़ाइन टीमों के साथ काम करती है।

यदि दूसरों को एक सुसंगत WinUI नियंत्रण का उपयोग करने के लिए प्रोत्साहित किया जाना है, तो Microsoft को इसके साथ उदाहरण पेश करना चाहिए।

• Cortana
• नाली संगीत
• फिल्म और टीवी
• अपने फोन को

वे ऐप्स हैं जो दिमाग में आते हैं।

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

मुझे लगता है कि आपके प्रारंभिक सारांश से अधिकांश चीजें शामिल हैं, लेकिन वैकल्पिक, कार्रवाई योग्य बटनों के बारे में कुछ भी कॉल करना अच्छा हो सकता है? या वह हमेशा सिर्फ कस्टम सामग्री होगी?

टूलकिट से नियंत्रण के कुछ इतिहास के साथ टूलकिट से अनुवर्ती (यह कुछ समय के आसपास रहा है):

• वास्तविक मुद्दा
• पहली पीआर समीक्षा
• गिटहब इतिहास - सुनिश्चित नहीं है कि एक पृष्ठ पर पूरी सूची कैसे प्राप्त करें, इसलिए नीचे स्क्रॉल करें और 'पुराना' पर क्लिक करते रहें

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

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

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

टीमें (अब रिकॉर्डिंग)

कार्यालय (संगतता मोड)

टीमें (कोई इंटरनेट नहीं)

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

इससे पहले चर्चा में @mrlacey और अन्य ने दो अलग-अलग नियंत्रण रखने की क्षमता को सामने लाया जो उल्लिखित परिदृश्यों को कवर कर सकते थे।

मुझे लगता है कि ये दो अवधारणाएं हैं:

• शून्य या अधिक कार्रवाई योग्य उप-तत्वों के साथ एक खारिज करने योग्य पूर्ण-चौड़ाई वाला बैनर
• एक बैनर जिसका उद्देश्य स्थिति परिवर्तन को इंगित करना है और जो एक बटन के रूप में कार्य करता है

अलग नियंत्रण के रूप में सबसे अधिक मूल्य और कम से कम भ्रम प्रदान करेगा।

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

सभी को फिर से धन्यवाद!

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

आदि

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

सभी को फिर से धन्यवाद!

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

डिज़ाइन जो @mdtauk ने पोस्ट किया है या ऊपर Cortana स्क्रीनशॉट अधिक बेहतर होंगे। ऐप्स के डिज़ाइन को आगे बढ़ने की ज़रूरत है न कि कार्यक्रमों से पीछे हटना।

क्या यह एक खारिज करने योग्य कमांडबार के रूप में भी कार्य कर सकता है जैसे कि प्रस्तुत/डेस्कटॉप साझा करते समय उपयोग किया जाता है? उदाहरण के लिए

मुझे पता है कि यह सब कुछ पर ओवरले का समर्थन नहीं करेगा, लेकिन इसकी चौड़ाई को ठीक करने और इसे ऐप की ओवरले परत में डालने के मामले में, मैं इस दिशा में डिज़ाइन/कार्यक्षमता में समान ओवरलैप देख सकता था।

@mdtauk

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

@शहीदमालिक

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

डिज़ाइन जो @mdtauk ने पोस्ट किया है या ऊपर Cortana स्क्रीनशॉट अधिक बेहतर होंगे। ऐप्स के डिज़ाइन को आगे बढ़ने की ज़रूरत है न कि कार्यक्रमों से पीछे हटना।

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

क्या यह एक खारिज करने योग्य कमांडबार के रूप में भी कार्य कर सकता है जैसे कि प्रस्तुत/डेस्कटॉप साझा करते समय उपयोग किया जाता है? उदाहरण के लिए

@ माइकल हॉकर

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

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

हाय @yaichenbaum , चेक इन करने के लिए धन्यवाद! इस प्रस्ताव पर एक अद्यतन के रूप में मुझे उस विशिष्ट दस्तावेज़ को साझा करने में प्रसन्नता हो रही है जिसे हम प्रारूपित करना शुरू कर रहे हैं।

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

लेआउट में बाएँ से दाएँ StatusBanner के मुख्य घटक हैं:

• स्थिति रंग
• आइकन
• शीर्षक
• संदेश
• एक्शन बटन
• बंद करें बटन

ये गुण वैकल्पिक हैं और "सामग्री" संपत्ति के माध्यम से कस्टम सामग्री अभी भी एक विकल्प है।

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

बिना एक्शन बटन या कस्टम क्लोज बटन के "बार" मोड में StatusBanner का पेपर प्रोटोटाइप।

StatusBanner बार लेआउट का वर्तमान डिज़ाइन @mdtauk के स्टेटस कार्ड के डिज़ाइन से बहुत अधिक प्रेरित था, धन्यवाद!

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

@yaichenbaum इस बीच टूलकिट का InAppNotification नियंत्रण है।

@gabbybilka अद्यतन के लिए धन्यवाद, एक महत्वपूर्ण विशेषता जिसकी मुझे अपने उपयोग के मामले में आवश्यकता होगी, वह है एक समय में कई स्थिति संदेश दिखाने की क्षमता, जैसे @hawker ने पहले इस धागे में साझा किया था। कंट्रोल हैंडल होने से कई स्टेटस संदेशों का प्लेसमेंट एक प्लस होगा।

@yaichenbaum इस बीच टूलकिट का InAppNotification नियंत्रण है।

@hawkerm मैंने InAppNotification पर ज्यादा ध्यान नहीं दिया है, लेकिन मैं इसके तैयार होने पर नए नियंत्रण पर स्विच करने के बजाय WinUI संस्करण की प्रतीक्षा करूंगा।

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

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

यदि आप कुछ और उदाहरण देखना चाहते हैं तो कृपया विशिष्टता देखें:

आप सभी को धन्यवाद और मैं आपसे सुनने के लिए उत्सुक हूं!

क्या यह सिर्फ WinUI 3 में उपलब्ध है, या यह WinUI 2 प्री-रिलीज़ में जा रहा है?

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

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

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

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

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

अभी के लिए मैं उस चीज़ की प्रतीक्षा करूँगा जो इसे पूर्वावलोकन में बनाती है।

फिर से हैलो! कुछ अपडेट:

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

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

• @teaP ने इस नियंत्रण के मूल संस्करण को लागू करना शुरू कर दिया है क्योंकि यह WinUI 2.5 प्रीरिलीज़ की ओर बढ़ता है। शुक्रिया!

पहले की तरह, यदि आप स्वयं को इस नियंत्रण के संभावित उपयोगकर्ता के रूप में देखते हैं, तो अपने द्वारा विकसित किए जा रहे एप्लिकेशन और उन परिदृश्यों के बारे में बेझिझक टिप्पणी करें जिनमें आप InfoBar का उपयोग करेंगे। आप सभी को धन्यवाद!

फिर से हैलो! बस हाइलाइट करने के लिए, @teaP ने हाल ही में InfoBar के लिए पुल अनुरोध #3325 खोला है यदि आप इसे देखना चाहते हैं

इसे इन्फोबार क्यों कहा जाता है? जानकारी जानकारी का केवल एक छोटा वर्ग है जिसमें यह हो सकता है। यह त्रुटियों और चेतावनियों के साथ-साथ उन पर आधारित कार्रवाइयों का भी समर्थन करता है। बार भी कृत्रिम रूप से नियंत्रण के 'आकार' को बाधित कर रहा है। इसके लिए एक बार के अलावा कई अन्य उपयोग के मामले हैं।

अधिसूचना दृश्य या संदेश दृश्य, आदि मेरी राय में बेहतर नाम होंगे।

इसे इन्फोबार क्यों कहा जाता है? जानकारी जानकारी का केवल एक छोटा वर्ग है जिसमें यह हो सकता है। यह त्रुटियों और चेतावनियों के साथ-साथ उन पर आधारित कार्रवाइयों का भी समर्थन करता है। बार भी कृत्रिम रूप से नियंत्रण के 'आकार' को बाधित कर रहा है। इसके लिए एक बार के अलावा कई अन्य उपयोग के मामले हैं।

अधिसूचना दृश्य या संदेश दृश्य, आदि मेरी राय में बेहतर नाम होंगे।

इसे मूल रूप से StatusBanner . के रूप में प्रस्तावित किया गया था
फिर इसे बदल कर InformationBar / InfoBar . कर दिया गया

इस नियंत्रण के FluentUI संस्करण को MessageBar . कहा जाता है

सारांश के लिए धन्यवाद। नाम अभी भी मेरे लिए बहुत मायने नहीं रखता है। वर्तमान नियंत्रण को जिस तरह से डिज़ाइन किया गया है वह एक अधिसूचना के रूप में है। अधिक सामान्यीकृत यह एक 'संदेश' होना चाहिए ताकि यह सहायता/शिक्षण परिदृश्यों का भी समर्थन कर सके। विभिन्न अवधारणाओं को सामान्य करते हुए, यहाँ नियंत्रणों के लिए एक बेहतर डिज़ाइन दिया गया है:

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

2. टीचिंग टिप : MessageView को होस्ट करने वाला फ़्लायआउट/पॉपअप।

   • होस्टेड टिप

3. नोटिफिकेशनबार या स्टेटसटिप : एप्लिकेशन या व्यू के शीर्ष पर 'बार' फॉर्मेट में ऐप-वाइड नोटिफिकेशन।

   • होस्टेड टिप

4. टूलटिप : अब टिप को भी होस्ट करने में सक्षम होगा जो क्रियाओं और छवियों आदि के लिए समर्थन देगा।

   • होस्टेड टिप

हमें वास्तव में सामान्य शब्दों में सोचने और उच्च-स्तरीय अवधारणाओं को समान नियंत्रणों में संयोजित करने की आवश्यकता है। अन्यथा हम समान लेकिन भिन्न गुणों के साथ बहुत अधिक विशिष्ट नियंत्रण बनाने जा रहे हैं।

सामान्य 'MessageView' नियंत्रण के लिए एक आदर्श नाम के बारे में सोचा: इसे 'टिप' कहें। टूलटिप इसे भी होस्ट कर सकता है। तदनुसार अद्यतन किया गया।

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

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

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

• एकल तत्व के लिए टूलटिप जहां उपयोगकर्ता सक्रिय रूप से पहचानना चाहता है;
• एक तत्व के लिए टीचिंगटिप डेवलपर चाहता है कि उपयोगकर्ता नोटिस करे (किसी तत्व से भी जुड़ा हो सकता है);
• संपूर्ण ऐप/सामग्री क्षेत्र के लिए इन्फोबार जहां डेवलपर कुछ जानकारी देना चाहता है;
• फ़्लायआउट/डायलॉग जब डेवलपर चाहता है कि उपयोगकर्ता पुष्टि करे कि उन्होंने इसे खारिज करने से पहले कुछ पढ़ा है;
• सामग्री संवाद उस समय के लिए जब डेवलपर को उपयोगकर्ता को एक विकल्प बनाने या सबसे ऊपर कोई कार्रवाई करने की आवश्यकता होती है;

मैं अधिसूचना शब्द का उपयोग करने से भी बचूंगा क्योंकि इनके लिए ओएस स्तर की अधिसूचना और अधिसूचना केंद्र है

मैं अधिसूचना शब्द का उपयोग करने से भी बचूंगा क्योंकि इनके लिए ओएस स्तर की अधिसूचना और अधिसूचना केंद्र है

खैर, मुझे लगता है कि डेवलपर्स को अंतर पता होगा लेकिन यह निश्चित रूप से एक उचित बिंदु है।

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

फ्लाईआउट/सामग्री संवाद अलग अवधारणाएं हैं क्योंकि वे अधिकांश भाग के लिए सामान्य सामग्री नियंत्रण हैं।

मैंने विभिन्न परिदृश्यों में होस्ट करने के लिए सामान्यीकृत 'संदेश दृश्य' प्रकार नियंत्रण के लिए एक आदर्श नाम के बारे में सोचा: इसे 'टिप' कहें। मैंने ऊपर अपनी टिप्पणी तदनुसार अपडेट की है: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

मैंने विभिन्न परिदृश्यों में होस्ट करने के लिए सामान्यीकृत 'संदेश दृश्य' प्रकार नियंत्रण के लिए एक आदर्श नाम के बारे में सोचा: इसे 'टिप' कहें। मैंने ऊपर अपनी टिप्पणी को तदनुसार अपडेट किया है: #913 (टिप्पणी)

मैं एक महत्वपूर्ण चेतावनी या त्रुटि संदेश को टिप में डालने में सहज महसूस नहीं करूंगा ...

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

फ्लाईआउट/सामग्री संवाद अलग अवधारणाएं हैं क्योंकि वे अधिकांश भाग के लिए सामान्य सामग्री नियंत्रण हैं।

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

मैंने विभिन्न परिदृश्यों में होस्ट करने के लिए सामान्यीकृत 'संदेश दृश्य' प्रकार नियंत्रण के लिए एक आदर्श नाम के बारे में सोचा: इसे 'टिप' कहें। मैंने ऊपर अपनी टिप्पणी को तदनुसार अपडेट किया है: #913 (टिप्पणी)

मैं एक महत्वपूर्ण चेतावनी या त्रुटि संदेश को टिप में डालने में सहज महसूस नहीं करूंगा ...

मैं भी इससे सहमत हूं...और अधिक अन्वेषण किए जाने हैं।

मैंने विभिन्न परिदृश्यों में होस्ट करने के लिए सामान्यीकृत 'संदेश दृश्य' प्रकार नियंत्रण के लिए एक आदर्श नाम के बारे में सोचा: इसे 'टिप' कहें। मैंने ऊपर अपनी टिप्पणी को तदनुसार अपडेट किया है: #913 (टिप्पणी)

टिप में महत्वपूर्ण चेतावनी या त्रुटि संदेश डालने में मुझे सहज महसूस नहीं होगा...

मैं भी इससे सहमत हूं...और अधिक अन्वेषण किए जाने हैं।

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

इसे इन्फोबार क्यों कहा जाता है? जानकारी जानकारी का केवल एक छोटा वर्ग है जिसमें यह हो सकता है। यह त्रुटियों और चेतावनियों के साथ-साथ उन पर आधारित कार्रवाइयों का भी समर्थन करता है। बार भी कृत्रिम रूप से नियंत्रण के 'आकार' को बाधित कर रहा है। इसके लिए एक बार के अलावा कई अन्य उपयोग के मामले हैं।

अधिसूचना दृश्य या संदेश दृश्य, आदि मेरी राय में बेहतर नाम होंगे।

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

@gabbybilka हां, यह पुराने StatusBar या नए AppBar... CommandBar... आदि से काफी मिलता-जुलता है। मुद्दा यह है कि नियंत्रण के उपयोग को कुछ हद तक सामान्यीकृत किया जाना चाहिए ताकि मनमाने स्थानों में संकेत और संदेश भी दिखाए जा सकें। 'व्यू' भी 100% फिट नहीं बैठता है लेकिन यह एक सामान्य नाम के करीब है। वास्तव में मेरी चिंता अंतर्निहित अवधारणाओं को एकीकृत करने में है, इसलिए हम एक ही चीज़ के रूपांतर करने वाले कई नियंत्रणों के साथ समाप्त नहीं होते हैं।

दो स्थानों पर कई टिप्पणियों के साथ खुद को भ्रमित करने के लिए संपादित किया गया।

अन्य मुद्दों में से एक में पोस्ट किए गए विचारों की गूंज ...

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

एक पूर्ण स्क्रीन WinUI ऐप, एक संकीर्ण चौड़ाई वाली विंडो, और Hololens और Xbox जैसी चीज़ों के बीच स्क्रीन की चौड़ाई और UI लेआउट में अंतर - खुद को डॉक किए गए बार फॉर्म फैक्टर के लिए उधार नहीं देगा।

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

एक असंबद्ध शिक्षण युक्ति सामने आ सकती है, लेकिन यह उन अनुकूलन का समर्थन नहीं करेगी जो ऐप स्थिति संदेशों के लिए उपयुक्त हैं - जो इस नियंत्रण के पीछे मूल उद्देश्य है।

तो क्या हुआ अगर हमारे पास एक 'टिप' है जो वास्तव में सिर्फ एक संदेश है। इसमें एक ग्लिफ़, चित्र, संदेश पाठ, शीर्षक है।

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

तो क्या हुआ अगर हमारे पास एक 'टिप' है जो वास्तव में सिर्फ एक संदेश है। इसमें एक ग्लिफ़, चित्र, संदेश पाठ, शीर्षक है।

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

टीचिंगटिप बिना पूंछ के आपकी स्थिति के लिए एकदम सही लगता है ...

टीचिंगटिप बिना पूंछ के आपकी स्थिति के लिए एकदम सही लगता है ...

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

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

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

टीचिंगटिप बिना पूंछ के आपकी स्थिति के लिए एकदम सही लगता है ...

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

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

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

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

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

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

क्षमा करें, ऊपर मेरा संपादन देखें। शिक्षण युक्ति अभी भी इनलाइन नहीं है और खारिज होने तक बस नीचे तैरती है।

सबसे नीचे होना जरूरी नहीं है।

इनलाइन शायद एक संकेत के लिए एक असामान्य उपयोग मामला है, क्योंकि यह इसके आसपास की अन्य सामग्री को विस्थापित कर देगा।

आप सुझाव दे सकते हैं कि V2 इनलाइन/गैर फ्लोटिंग डिस्प्ले मोड के लिए समर्थन जोड़ता है

@mdtauk की टिप्पणी को थोड़ा और संदर्भ देने के लिए, यहाँ कल्पना में "InfoBar V2 के लिए इच्छित सुविधाएँ" खंड से फ़्लोटिंग मोड को हटाने के बारे में उनके प्रश्न का मेरा प्रारंभिक उत्तर था।
मुझ से:

डिजाइन चर्चा के लिए यहां रुकना। यह ध्यान में रखते हुए कि V2 की इच्छित विशेषताएं बदल जाती हैं 😉 अभी हम कुछ कारणों से V2 संस्करण में InfoBar के लिए फ़्लोटिंग मोड के लिए प्रतिबद्ध नहीं हैं। मैं आगे यह पता लगाना चाहता हूं कि क्या फ्लोटिंग मोड _ should_ एक InfoBar में है या क्या टोस्ट जैसी सूचनाएं पूरी तरह से एक अलग नियंत्रण होनी चाहिए। जांच करते समय हमने महसूस किया कि फ्लोटिंग मोड का एक बुनियादी कार्यान्वयन अविश्वसनीय रूप से टीचिंग टिप के समान होगा और टोस्ट जैसी अधिसूचना परिदृश्य कार्यक्षमता जैसे स्टैकिंग, पोजिशनिंग और ओवरले विकल्पों का पूरी तरह से पता लगाने के लिए (WCT InAppNotification का StackMode देखें) की आवश्यकता है। यह InfoBar के दायरे और इरादे को इसके प्रारंभिक फोकस की तुलना में अधिक व्यापक बनाने के लिए विस्तारित करेगा। ध्यान दें, हमने InfoBar में फ्लोटिंग क्षमताओं को जोड़ने पर पूरी तरह से दरवाजा बंद नहीं किया है, लेकिन नहीं की ओर झुकाव है।

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

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

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

मैं @gabbybilka के जवाब के साथ किसी भी संदर्भ को गलत तरीके से समझने की कोशिश नहीं कर रहा था

एक आधार AppMessage वर्ग के आधार पर InformationBar और InformationCard प्रस्ताव के लिए मुझे यह विचार पसंद है।

यह वह जगह है जहां नामकरण आता है। मुझे "AppMessage" ("टिप" बहुत अच्छा होगा, हालांकि ऐसा लगता है कि यह पूरी तरह से योजना थी) लेकिन अगर हम इसके साथ जाते हैं तो यह "MessageBar" और "MessageCard" होस्टिंग होना चाहिए। यह।

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

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

कार्ड संदेश/टिप का उदाहरण

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

मुझे शायद यह जोड़ना चाहिए कि एक यूडब्ल्यूपी ऐप में मैं इनमें से कुछ अवधारणाओं पर काम करता हूं जो पहले से ही एकीकृत थे। इस चर्चा के लिए प्रासंगिक सरलीकृत संस्करण है:

निम्नलिखित गुणों के साथ एक 'संदेश' वर्ग है (यह एक नियंत्रण नहीं है, केवल एक डेटा संरचना है):

        protected MessageDisplayMode _DisplayMode;
        protected List<Message>      _InnerMessages;
        protected MessagePriority    _Priority;
        protected string             _Text;
        protected DateTimeOffset?    _Timestamp;

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

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

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

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

ऐसे अन्य क्षेत्र हैं जहां सामान्य अवधारणाएं आईएमओ अधिक उपयोगी होंगी। बटन, ऐपबारबटन, मेनूइटम के बारे में सोचें। ये सभी टेक्स्ट और एक आइकन दिखाते हैं, सभी का उपयोग किसी क्रिया को ट्रिगर करने के लिए किया जाता है। अक्सर आप MenuItem (ContextMenu) और AppBar/CommandBar दोनों में समान कमांड प्रदान करते हैं। यहां, एक सामान्य अवधारणा बहुत उपयोगी होगी, जहां आप अपना आदेश, टेक्स्ट, आइकन, शायद एक लंबा संदेश (टूलटिप) भी डाल सकते हैं। लेकिन टूलटिप और मैसेजबार के लिए एक सामान्य अवधारणा है? मैं वास्तव में इसकी आवश्यकता नहीं देखता। निश्चित रूप से, अगर हम यूडब्ल्यूपी को खरोंच से फिर से लिखेंगे, तो हम एक सामान्य आधार वर्ग के साथ आ सकते हैं। लेकिन मुझे नहीं लगता कि यह जरूरी है या अत्यधिक मददगार है।

@lukasf आपकी बातें समझ में आती हैं; यह ऐप में ही किया जा सकता है। हालाँकि, बहुत सारी समान अवधारणाएँ हैं और हर कोई यहाँ एकीकरण से लाभ उठा सकता है।

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

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

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

मैंने संदेश सेवा नियंत्रणों की तुलना एक साथ की है। मैं इसे मुफ्त परामर्श के रूप में दूंगा क्योंकि यह इतना मोटा है :)

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

1. टीम के सदस्यों के बीच समझ की खाई को पाटना
2. बड़ी टीमों और संगठनों में होने वाले 'सिलो' पर काबू पाएं
3. ढांचे की एक सुसंगत भविष्य की दिशा सुनिश्चित करें ताकि भविष्य की कार्यक्षमता को एक अच्छी नींव (सबसे महत्वपूर्ण) के शीर्ष पर जोड़ा जा सके।

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

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

MessageControlतुलना 20200929.xlsx

तुलना दस्तावेज़ के लिए धन्यवाद, समग्र रूप से जानकारी नियंत्रण पर आपके विचारों को देखकर बहुत अच्छा लगा! जिन दो मुख्य विषयों पर मैं चर्चा जारी रखना चाहता हूं, वे हैं 1. टीचिंग टिप और इन्फोबार में अलग-अलग एपीआई/गुण/कार्यक्षमता क्यों _नहीं होनी चाहिए? और 2. यदि InfoCard एक पॉपअप नहीं होता, जैसा कि तुलना दस्तावेज़ में बताया गया है, तो InfoBar और InfoCard में क्या अंतर होगा?

पहले प्रश्न के लिए मैं लाल-पाठ वाली वस्तुओं पर किए गए डिज़ाइन निर्णयों को हाइलाइट कर सकता हूं और थोड़ा और स्पष्टता प्रदान कर सकता हूं:

• टीचिंगटिप उपशीर्षक बनाम इन्फोबार संदेश: कार्यात्मक रूप से, हाँ, वे समान हैं! वे इन नियंत्रणों में गैर-बोल्ड टेक्स्ट वाले द्वितीयक संदेश हैं। एक शिक्षण युक्ति में, यह संदेश हमेशा शीर्षक के नीचे प्रदर्शित होगा और उपशीर्षक के रूप में नामित समझ में आता है। InfoBar के लिए, यह संदेश अक्सर इनलाइन होगा और सीधे शीर्षक के दाईं ओर होगा जो अवधारणात्मक रूप से उपशीर्षक के रूप में नामित अर्थ नहीं रखता है।
• टीचिंगटिप हीरोकंटेंट बनाम इन्फोबार कंटेंट: टीचिंग टिप में हीरोकंटेंट और कंटेंट दोनों होते हैं जबकि इन्फोबार में केवल कंटेंट होता है। पढ़ाने में मदद करने के लिए इन बड़ी छवियों के समर्थन के कारण HeroContent संपत्ति टीचिंग टिप के लिए अद्वितीय है। InfoBar स्पष्ट रूप से छवियों का समर्थन नहीं करता है क्योंकि यह एक क्षैतिज लेआउट पर केंद्रित है। दोनों नियंत्रणों के लिए सामग्री गुण अतिरिक्त कस्टम सामग्री के लिए है और दोनों में बाकी UI तत्वों से नीचे है।
• टीचिंग टिप बटन रणनीति बनाम इन्फोबार बटन रणनीति: यहां मुख्य अंतर यह है कि इन्फोबार क्लासिक "बटन" के बाहर अधिक प्रकार के बटनों का समर्थन करता है और यह टेक्स्ट को शामिल करने के लिए क्लोज बटन के अनुकूलन को प्रोत्साहित नहीं करता है।
  
  
  
  • InfoBars के लिए एक सामान्य परिदृश्य हाइपरलिंक बटन शामिल करना है। डिफ़ॉल्ट हाइपरलिंक बटन अग्रभूमि रंग के साथ रंग विपरीत होने और हमारे विभिन्न रंगीन पृष्ठभूमि रंगों के कारण हम यह सुनिश्चित करना चाहते थे कि हम InfoBar में शामिल किसी भी हाइपरलिंक बटन पर अपनी स्वयं की कस्टम स्टाइल लागू कर सकें ताकि वे सुलभ रहें।
  
  
  • हमने अपनी डिज़ाइन समीक्षाओं के बाद यह सुनिश्चित करने के लिए कि शामिल टेक्स्ट और एकल क्रिया पर ध्यान केंद्रित रहता है, हमने InfoBar में क्लोज़ बटन कस्टमाइज़ेशन (पाठ के लिए, अभी भी एक CloseButtonStyle संपत्ति है जो कुछ हल्के-फुल्के स्टाइल करने के लिए है) को शामिल नहीं करने का निर्णय लिया। संबंधित रूप से, जैसा कि विनिर्देश में उल्लेख किया गया है, हम यहां एक से अधिक क्रिया बटन का समर्थन करने के लिए V2 में एक ActionContentArea के बारे में सोच रहे हैं और वहां फिर से बंद बटन अनुकूलन को सक्षम करने की जांच कर सकते हैं।
  
  
• InfoBar IsClosable और IsIconVisible: टीचिंग टिप में IsClosable नहीं है क्योंकि टीचिंग टिप हमेशा बंद होनी चाहिए क्योंकि यह एक पॉपअप है और गैर-अवरुद्ध/तत्काल जानकारी प्रदर्शित करता है। इसमें IsIconVisible भी नहीं है क्योंकि एक आइकन अपनी डिफ़ॉल्ट स्टाइल के साथ प्रकट नहीं होता है जो InfoBar विभिन्न गंभीरता स्तरों के माध्यम से करता है। हम एक डेवलपर के लिए प्रदान किए गए आइकन को हटाने का एक तरीका प्रदान करना चाहते थे यदि वे चाहते थे। हमने IconSource को शून्य पर सेट करने का प्रयास किया जिसके कारण बहुत सारे फंकी बग्स और IsIconVisible प्रॉपर्टी के माध्यम से सरल हो गए।

क्या ये समझ में आते हैं? मेरा मानना ​​​​है कि दोनों नियंत्रणों के लिए अलग-अलग उद्देश्य हैं और कार्यक्षमता में अंतर यह दर्शाता है। मुझे आशा है कि ये स्पष्टीकरण और डिजाइन तर्क उपयोगी थे!

स्वरूपण समस्याओं और टाइपो के लिए संपादित करें😊 x2

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

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

इस प्रकार के एपीआई पर चर्चा करने और उत्तर देने के लिए प्रश्न हैं:

• क्या/कैसे आप एक डेवलपर के रूप में निर्दिष्ट कर सकते हैं कि संदेश कॉल स्क्रीन पर किस प्रकार का नियंत्रण प्रदर्शित करता है?
• यदि नियंत्रण प्रकार निर्दिष्ट नहीं है, तो क्या एपीआई दिए गए गुणों को लेता है और सबसे उपयुक्त "चुनें"?
• आप व्यवहार संबंधी विकल्पों को अंतर्निहित नियंत्रणों तक कैसे पहुंचाएंगे?
• प्लेटफ़ॉर्म की उपयुक्तता के आधार पर कौन से रूप कारक ओवरराइड होंगे?

और शायद कई और मैंने लोल के बारे में नहीं सोचा है

Xbox को एक मंच के रूप में लेना
स्क्रीन आकार/स्केलिंग के रूप में इनपुट विधियां बहुत अलग हैं।

पूर्ण-चौड़ाई वाली सूचना बार को स्क्रीन किनारों पर ओवरस्कैन को ध्यान में रखना होगा, और इसलिए इन ऐप्स के लिए, एक सूचना कार्ड अधिक उपयुक्त हो सकता है।

लेकिन आप बर्खास्तगी को कैसे संभालेंगे?

क्लोज बटन पर जाने के लिए कोई कर्सर नहीं है, लेकिन क्या आप चाहते हैं कि कार्ड कंट्रोलर इनपुट को अपने हाथ में ले ले? यह इसे मोडल बनाता है। लेकिन फिर अगर यह सामग्री के शीर्ष पर मढ़ा जाता है, तो आप इसे कैसे चुनते हैं और इसे फोकस कैसे करते हैं?

तो क्या यह इनलाइन दिखाई देता है और सामग्री को नीचे धकेलता है, लेकिन पूरी चौड़ाई का नहीं होता है?

प्लस एक्सबॉक्स के पास अधिसूचना प्रणाली की तरह अपना टोस्ट है, तो क्या यह एपीआई उसके साथ काम करेगा? क्या यह इसके साथ काम कर सकता है, या यह केवल सिस्टम है?

1. टीचिंग टिप और इन्फोबार में अलग-अलग एपीआई/गुण/कार्यक्षमता क्यों नहीं होनी चाहिए?

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

बटनों के लिए, दोनों नियंत्रण एक क्रिया बटन और एक बंद बटन का समर्थन करते हैं। लेकिन आपने इसे पूरी तरह से अलग तरीके से किया। आपने ऊपर कुछ कारण बताए हैं लेकिन अब हमारे पास इस तरह की स्थितियों में बटन का उपयोग करने के लिए एक 'बदसूरत' एपीआई है। हम इसे अभी सामान्यीकृत क्यों नहीं करते ताकि हमारे पास भविष्य के लिए कुछ अच्छा हो? इस तरह के बटन कई नियंत्रणों पर लागू होते हैं: ContentDialog, TeachingTip, InfoBar और कौन जानता है कि आगे क्या है। हम केवल वर्तमान नियंत्रण के बारे में सोचकर ही डिजाइनिंग करते रहते हैं - खराब वास्तुकला!

संदेश या टिप के पाठ के लिए एक को Subtitle कहा जाता है और दूसरे को Message मूल रूप से ये समान हो सकते हैं, इन नियंत्रणों पर विभिन्न परियोजना प्रबंधकों के अलावा अन्य अलग-अलग शब्दों का उपयोग क्यों किया जाता है?

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

यदि InfoCard तुलना दस्तावेज़ में उल्लिखित पॉपअप नहीं था, तो InfoBar और InfoCard के बीच क्या अंतर होगा?

तुलना का मेरा अंतिम निष्कर्ष यह है कि MessageBar/MessageCard समान नियंत्रण होना चाहिए और स्टाइल अनुकूलन के माध्यम से मेरे इनलाइन संकेत या टिप उदाहरण के उपयोग के मामले का भी समर्थन करना चाहिए।

• MessageBar/MessageCard और युक्ति को एक ही नियंत्रण में एकीकृत करना संभव है। एकमात्र चिंता 'संदेश' और 'टिप' के बीच वैचारिक अंतर है।
• एक ही अंतर्निहित नियंत्रण होना चाहिए, हालांकि दोनों मामलों का समर्थन करने के लिए स्टाइल को अत्यधिक अनुकूलन योग्य होना चाहिए। एकमात्र चिंता 'संदेश' और 'टिप' के बीच वैचारिक अंतर है। डिजाइन बेहद समान है।

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

मैं @robloo के साथ 100% सहमत हूं कि समान चीजों के लिए संपत्ति के नाम और एनम नामों को मौजूदा नियंत्रणों के साथ (जहाँ तक संभव हो) संरेखित किया जाना चाहिए। समान नियंत्रणों में समान API सतह होनी चाहिए। यदि एक संदेश कार्ड वर्ग को बाद के बिंदु पर जोड़ा जाना था (मैसेजबार को विस्तारित करने के बजाय, जिसे मैं व्यक्तिगत रूप से पसंद कर सकता हूं), तो कम से कम मैसेजबार के समान एक समान एपीआई होना चाहिए।

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

@lukasf क्या आप XamlUICommand वर्ग से अवगत हैं? इससे आप इन गुणों को एक ही स्थान पर बंडल कर सकते हैं और फिर इन नियंत्रणों के Command API में अपने परिभाषित XamlUICommand को पास करके उन्हें अपने बटन/मेनूइटम/... पर असाइन कर सकते हैं।

@ फ़ेलिक्स-देव हाँ, तुम सही हो। मैं इसके बारे में लगभग भूल गया था। मैं इसका उपयोग नहीं कर रहा हूं क्योंकि यह पिछली बार कोशिश करने पर WinUI में उपलब्ध नहीं था, बल्कि इसलिए भी कि यह पूर्ण समाधान नहीं है। AppBar और ContextMenu में केवल कमांड लिंक नहीं हैं। एक पूर्ण समाधान के लिए, हमें चाहिए:

• XamlUIकमांड
• XamlToggleUICommand
• XamlUICommandSubItem (उप मेनू / फ्लाईआउट)
• XamlUICommandSeparator

इसमें "दृश्यमान" संपत्ति और/या एक संपत्ति "HideIfDisabled" भी गुम है।

फिर हमें MenuFlyout और AppBar/CommandBar और इसी तरह के नियंत्रणों पर एक ItemsSource की आवश्यकता होगी। शीर्ष स्तर का नियंत्रण तब प्रत्येक कमांड आइटम के लिए संबंधित उप नियंत्रण बनाएगा।

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

XamlUICommand एक अच्छी शुरुआत थी, लेकिन यह पूरी कहानी नहीं है।

यहाँ प्रतिक्रिया में मेरी देरी के लिए क्षमा करें, @robloo कुछ हफ़्ते पहले अपना दृष्टिकोण और तुलना तालिका साझा करने के लिए धन्यवाद। मैं वास्तव में WinUI को बेहतर बनाने के लिए सभी विचारों और विचारों की सराहना करता हूँ! मैं

InfoBar और पूरे प्लेटफ़ॉर्म में, मेरा विचार यह है कि डिज़ाइन करते समय हम एक परिभाषित UI पैटर्न के रूप में विशिष्ट परिदृश्यों के लिए विशेष रूप से डिज़ाइन किए जाने वाले नियंत्रणों के लिए सही संतुलन खोजने का प्रयास कर रहे हैं - जबकि सामान्य और अनुकूलन योग्य उन परिदृश्यों तक विस्तार करने के लिए जो हमारे पास नहीं हैं अभी तक पहचाना गया। टीम के लिए नए के रूप में मुझे यह सुनना अच्छा लगेगा कि क्यों WinUI नियंत्रण wpf अवधारणाओं पर वापस जाना चाहिए। जब समान वैचारिक नियंत्रणों में समान अंतर्निहित संरचना नहीं होती है, तो आप और अन्य UWP देवों को किस दिन-प्रतिदिन की समस्याओं का सामना करना पड़ रहा है? आपके लिए क्या लाभ हैं ताकि हम बेहतर ढंग से समझ सकें कि हमें इस संरचना को बनाने के लिए संसाधनों को क्यों समर्पित करना चाहिए? क्या विनयूआई में अन्य नियंत्रण हैं जो एकीकृत होने से लाभान्वित होंगे (मुझे @lukasf से ऊपर बटन वार्तालाप दिखाई देता है) मुझे लगता है कि हम इस बातचीत को एक नए सामान्य मुद्दे में भी जारी रख सकते हैं यदि कोई ऐसा क्षेत्र है जहां हम मौजूदा नियंत्रण/विचार-मंथन दृष्टिकोण को संशोधित कर सकते हैं भविष्य के नियंत्रण। @SavoySchuler यहां किसी भी इनपुट के लिए।

InfoBar के लिए, मुझे अभी भी कोई बदलाव नहीं दिख रहा है क्योंकि यह इस वार्तालाप से पूर्वावलोकन में जाता है। एक्शन बटन और क्लोज बटन एपीआई के लिए विशेष रूप से यदि विशिष्ट आवश्यकताएं पूरी नहीं होती हैं तो कृपया हमें बताएं ताकि हम किसी भी संभावित परिवर्तन का मूल्यांकन कर सकें। मैं एक सामान्य AppMessage बेस क्लास या इंटरफ़ेस को एक InfoCard नियंत्रण के साथ या एक अलग डिस्प्लेमोड के रूप में एक v2 के साथ कार्यान्वित करने की उम्मीद कर सकता था ताकि वेरिएबल लेआउट 'ऑटो' कार्यक्षमता @mdtauk को पहले लाया जा सके। इसके अतिरिक्त, WinUI टीम को इस समय टीचिंग टिप और InfoBar को और संरेखित करने में कोई महत्व नहीं दिखाई देता है, हालाँकि यदि उपयोग की ज़रूरतें पूरी नहीं हो रही हैं, तो हम इसे संबोधित करने के लिए यहाँ बातचीत जारी रख सकते हैं। एक बार InfoBar पूर्वावलोकन में चला जाता है और अनुप्रयोगों में लागू किया जा सकता है किसी भी विशिष्ट परिदृश्य या उपयोग की प्रतिक्रिया आधिकारिक रिलीज से पहले सुनने के लिए बहुत अच्छी होगी।

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

InfoBar और पूरे प्लेटफ़ॉर्म में, मेरा विचार यह है कि डिज़ाइन करते समय हम एक परिभाषित UI पैटर्न के रूप में विशिष्ट परिदृश्यों के लिए विशेष रूप से डिज़ाइन किए जाने वाले नियंत्रणों के लिए सही संतुलन खोजने का प्रयास कर रहे हैं - जबकि सामान्य और अनुकूलन योग्य उन परिदृश्यों तक विस्तार करने के लिए जो हमारे पास नहीं हैं अभी तक पहचाना गया। टीम के लिए नए के रूप में मुझे यह सुनना अच्छा लगेगा कि क्यों WinUI नियंत्रण wpf अवधारणाओं पर वापस जाना चाहिए। जब समान वैचारिक नियंत्रणों में समान अंतर्निहित संरचना नहीं होती है, तो आप और अन्य UWP देवों को किस दिन-प्रतिदिन की समस्याओं का सामना करना पड़ रहा है? आपके लिए क्या लाभ हैं ताकि हम बेहतर ढंग से समझ सकें कि हमें इस संरचना को बनाने के लिए संसाधनों को क्यों समर्पित करना चाहिए? क्या विनयूआई में अन्य नियंत्रण हैं जो एकीकृत होने से लाभान्वित होंगे (मुझे @lukasf से ऊपर बटन वार्तालाप दिखाई देता है) मुझे लगता है कि हम इस बातचीत को एक नए सामान्य मुद्दे में भी जारी रख सकते हैं यदि कोई ऐसा क्षेत्र है जहां हम मौजूदा नियंत्रण/विचार-मंथन दृष्टिकोण को संशोधित कर सकते हैं भविष्य के नियंत्रण। @SavoySchuler यहां किसी भी इनपुट के लिए।

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

क्योंकि अधिकांश Microsoft टीम खामोश हैं, कई मामलों में कुछ करने के कई तरीके हैं लेकिन उक्त प्रक्रियाओं का कोई एकीकरण नहीं है जिसके परिणामस्वरूप अतिरेक होता है और कुछ को ठीक करने का प्रयास किया जाता है जो पहले से तय है।

डब्ल्यूपीएफ के निर्माण के बाद, माइक्रोसॉफ्ट "यह काफी अच्छा दिमाग सेट है" में चला गया, यह सीधे माइक्रोसॉफ्ट की अपनी टीमों से भी ऐप्स की गुणवत्ता में व्यक्त किया गया है। यदि Microsoft के स्वयं के इनबॉक्स ऐप्स कोड और ऐप्स की एकरूपता में उच्च गुणवत्ता वाली एकसमान संगति के साथ एक ही पृष्ठ पर नहीं मिल सकते हैं, तो हम तृतीय पक्ष भागीदारों से इस तरह की डिलीवरी की अपेक्षा कैसे कर सकते हैं?

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

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

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

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

इसलिए यदि WinUI में नियंत्रण स्वयं एक एकीकृत दृष्टिकोण प्रदान नहीं करते हैं, तो शायद Windows टूलकिट एक सहायक API बना सकता है जो इसे प्रबंधित करता है।

मेरा सुझाव है कि आप इसे उस रेपो में प्रस्तावित करें, और यह ऐप में इसे प्रस्तुत करने के लिए WinUI नियंत्रणों का उपयोग कर सकता है

हाय सब, एक अद्यतन के रूप में InfoBar नियंत्रण अब पूर्वावलोकन में है यदि आपके पास कोई ऐसा एप्लिकेशन है जो इस नियंत्रण से लाभान्वित होगा तो कृपया इसे आज़माएं और अपनी प्रतिक्रिया हमारे साथ साझा करें।
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
इस नियंत्रण के लिए अब तक आपके सभी जुड़ावों के लिए धन्यवाद!

सूचना बार/बॉक्स/कार्ड का एक और उदाहरण यहां दिया गया है

संपादित करें: मुझे अभी एहसास हुआ कि नीचे दी गई समस्या पहले से ही https://github.com/microsoft/microsoft-ui-xaml/issues/3581 द्वारा तय की गई है। कृपया नीचे दी गई समस्या पर ध्यान न दें. नियंत्रण करने के लिए धन्यवाद! यह कोकिला में बहुत अच्छा लग रहा है :)

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

क्या आप नियंत्रण में "खोला गया" ईवेंट जोड़ने पर विचार करेंगे? कुछ मामलों में कुछ सेकंड के बाद InfoBar को स्वतः बंद करना उचित होता है। टाइमर शुरू करने के लिए एक "खोला गया" ईवेंट हैंडलर सही जगह होगा।

मुझे लगता है कि डार्क थीम में सक्सेस कलर को बदलना चाहिए। @YuliKl @anawishnoff @chigy @teaP
वर्तमान डार्क थीम का रंग #393D1B है - जो पीले-हरे रंग का प्रतीत होता है, लगभग जैतून का रंग। जबकि प्रकाश विषय हरे रंग की तरह एक स्पष्ट हरे, लगभग पुदीना का उपयोग करता है।

_वर्तमान रंगों के ऊपर, प्रस्तावित परिवर्तन के नीचे_

#1d3d1b

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

यहां बताया गया है कि यह कैसा दिखेगा