sapallie ، هل يمكنك جعل نماذج التصميم متاحة للجمهور؟ ما لم يتم عدم مشاركتهم في هذه المرحلة.

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

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

sapallie ، هل يمكنك جعل نماذج التصميم متاحة للجمهور؟ ما لم يتم عدم مشاركتهم في هذه المرحلة.

آسف adrientetar ، لا يمكنني مشاركتها بعد. التصاميم هي Microsoft فقط في الوقت الحالي.

sapallie ، شكرًا لك على فكرة الميزة الهائلة هذه! أنا مدير برنامج في WinUI وأنا متحمس لعرض هذا على الفريق!

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

في ما يلي بعض الأشياء التي أعرفها بالفعل أنني بحاجة للحصول على فكرة أكثر قليلاً من أجل ...

• السلوك البصري

هل اقتراحك لشريط من الحافة إلى لافتة؟ أو مربع إعلام مثل ما تفعله إشعارات Windows ولكن في نافذة التطبيق مثل في المنتصف أو على طول الحافة السفلية أو في الزاوية؟

آسف adrientetar ، لا يمكنني مشاركتها بعد. التصاميم هي Microsoft فقط في الوقت الحالي.

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

سيجعل الشعار المستخدمين على دراية بالأخطاء التي تمنعهم من استخدام التطبيق / الميزة

سيكون الشعار قابلاً للرفض بسبب الأخطاء غير الفادحة

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

شكرا مرة أخرى وأنا أتطلع إلى تحسين هذه الفكرة!

الجميع ، من فضلكم نشجعهم على المساهمة باحتياجاتكم وتصميماتكم ووجهات نظركم في هذه المحادثة! :احمر خدود:

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

SavoySchuler - من الجيد أن نسمع منك. حاولت الإجابة على جميع أسئلتك ولكن يرجى إعلامي إذا كنت بحاجة إلى أي شيء آخر.

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

الرفض:
أعتقد أنه سيكون من المنطقي التعمق أكثر في ما أعنيه بالأخطاء الفادحة مقابل الأخطاء غير الفادحة:

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

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

مثال المرئيات
لقد أجريت بعض التغييرات على العناصر المرئية ويمكنني مشاركتها على النحو التالي:

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

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

متفق. تبدو الصور المنشورة جميلة جدًا.

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

لم أحسب وحدات البكسل ولكن يبدو كما لو كانت في المنتصف إذا تم حساب مساحة علامات التشكيل فوق X-height.

sapallie هل فكرت في السماح بعناصر التحكم هذه تلقائيًا ، أو رفضها برمجيًا؟

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

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

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

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

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

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

أود أيضًا أن أسميها شيئًا مثل StatusTip أو StatusNotification حتى لا ترتبط بالاستخدامات السلبية فقط.

أفترض أن التصميم سيتكيف عن طريق تغيير الموضع على الشريط الملون عندما يتم وضعه في أسفل النافذة؟

من المحتمل أن تحتوي على خاصية timeout ، ويمكن أن يكون لديها القدرة على إظهار رسالة معلقة ، مثل حلقة التقدم وبعض النصوص مثل "Logging in now" قبل التبديل إلى تأكيد رسالة الخطأ.

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

لم أحسب وحدات البكسل ولكن يبدو كما لو كانت في المنتصف إذا تم حساب مساحة علامات التشكيل فوق X-height.

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

إليك كيفية تغيير موضع الشريط الملون مع وضع عنصر التحكم

mrlacey نعم ، يعد الفصل الآلي / التلقائي في حالة عدم وجود صلة للشعار أمرًا مهمًا للغاية - لقد أضفته إلى وصف الاقتراح.

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

وأعتقد أن لافتات متعددة يجب أن تعمل. يجب أن تكون مكدسة فقط.

mdtauk أعدت تسميته "لافتة الحالة" - شكرًا على اقتراحاتكم.

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

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

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

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

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

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

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

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

كنت أتخيل النص الفرعي الذي يحتوي على ارتباط تشعبي إلى تطبيق داخل التطبيق أو تطبيق الإعدادات (راجع رمز معرض تعليمات Xaml Control الخاص بـ TeachingTip). هل كنت تفكر في شيء معياريmdtauk؟

SavoySchuler محتوى خاصية بدلاً من MessageText؟

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

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

mdtauk - نعم ، أعني بالتأكيد خاصية المحتوى!

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

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

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

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

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

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

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

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

نعم ، هذا يعمل أيضًا. 👍

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

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

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

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

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

أمثلة متحركة

أدخل ، حدّث ، اخرج - رابط YouTube

تحريك - رابط YouTube

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

فيما يلي أفكاري الشخصية حول التمييز بين لافتة الحالة ونصيحة التدريس

• يجب تشجيع شعار الحالة _ أعتقد_ على الحالات الفعلية القابلة للتنفيذ ، وبالتالي يجب استدعاء إجراء واحد عند النقر عليه.

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

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

  • لن تقدم إرشادات التدريس معلومات مهمة ، وبمجرد رفضها لن يتم عرضها مرة أخرى ما لم تتم إضافة شيء جديد ليتم استدعاؤه.

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

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

• يجب استخدام شعار الحالة في OS Shell بطريقة متسقة - يمكن أن تكون هناك مجموعة من اللافتات القياسية المترجمة مع المحتوى والأيقونات والألوان كتعداد.

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

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

mdtauk ، عمل رائع على مقاطع الفيديو! 🎉 إنها مفيدة للغاية في إعادة الحياة إلى هذه الأفكار.

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

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

هل هناك أي أصحاب مصلحة لن يلبوا احتياجاتهم بشيء مثل ما شاركهmdtauk أعلاه؟

يبدو أن هناك اختلافات بين لافتات الحالة التي تم عرضها في OP وإشعار العرض الكامل كما هو موضح في Office (الصور أعلاه في التعليقات السابقة) أو Visual Studio (على النحو التالي)

الاختلافات بين الاثنين تعني أنني أتساءل عما إذا كان ينبغي أن يكونا نفس السيطرة أم منفصلان.

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

لافتات الحالة

• _أيقونة_
• رسالة نصية
• نص إضافي (السطر الثاني)
• النوع (هام أو تحذير أو معلومات)
• اللون
• موقع
• اتجاه الرسوم المتحركة
• اضغط على حدث / أمر
• نفذ الوقت

إخطارات العرض الكامل

• _Icon (ربما) _
• رسالة نصية
• نمط الارتباط (زر أو ارتباط تشعبي)
• الروابط (نص وضغط حدث / أمر - متعدد)
• نفذ الوقت

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

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

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

سيوفر أكبر قدر من القيمة وأقل ارتباك كعناصر تحكم منفصلة.

كيف ستدعم لافتات الحالة المتحركة عرض إعلامات متعددة في وقت واحد؟
أم أن هذا الآن خارج النطاق؟

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

يُظهر هذا المستوى من تكامل نظام التشغيل طموحًا يتجاوز تحكمًا واحدًا ويتجاوز WinUI.

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

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

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

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

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

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

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

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

لذلك ، بالنسبة لأي شخص ( sapallie و adrientetar و EverydayApps @ Felix-Dev و mdtauk وmrlacey) ، هل يمكن أن تزودني بما يلي هنا أو dm @ [email protected] :

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

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

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

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

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

سأعيد صياغة طلبي أعلاه. sapallie و adrientetar و EverydayApps @ Felix-Dev و mdtauk و mrlacey ، لرسائل الحالة / الخطأ التي ترغب في عرضها في تطبيقاتك ، هل يمكنك تزويدنا بما يلي هنا أو على [email protected] :

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

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

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

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

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

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

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

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

يمتلك فريق Your Phone أحد هذه الأنواع من عناصر التحكم ، لذا ربما يمكنك أن تسألهم عن المشكلات التي واجهوها ، وتقنعهم بالانتقال إلى استخدام عنصر تحكم WinUI عند الانتهاء منه وإدراجه؟

يستخدم Dropbox أيضًا Snackbar في نظام التصميم الخاص بهم (قم بالتمرير لأسفل ، من الصف الثاني إلى الصف الأخير من الصور).

رصدت مؤخرًا بضعة أمثلة أخرى لرسائل الحالة طويلة الأمد على مستوى التطبيق:

(رسالة "بدأ التسجيل" في Teams)

("محاولة الاتصال بمنسق اللعبة" في Dota 2)

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

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

هل يجب تقريب هذه؟ أو لا؟

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

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

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

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

لقطة شاشة مثال على رمز VS:

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

رأيت للتو لقطة شاشة Cortana ...

يبدو شريط رسالة Office UI Fabric رائعًا ، IMO:

لقد لاحظت أن Samsung Notes لنظام التشغيل Windows 10 يستخدم نخب الإخطار لشرح أنه تم تجاهل ملاحظة لأنه لم يكن هناك شيء مزعج للغاية فيها

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

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

كملخص لنطاقنا الحالي في الجزء العلوي من الاقتراح:

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

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

الآن بعد أن حددنا النطاق ، هناك عدد قليل من السيناريوهات المحددة وتجارب المستخدم التي لا تزال بحاجة إلى تحديد. آمل أن يساعد تحديد هذه التجارب في توجيه إمكانيات واجهة المستخدم للتحكم. ما هي أفكارك لسيناريوهاتك؟
CC: sapallie ، adrientetar ، EverydayApps @ Felix-Dev، mdtauk ،mrlacey

الخبرات هي:

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

شكرًا لك مرة أخرى على كل أفكارك وأتطلع إلى إلقاء الضوء على هذا الأمر!

سعيد برؤية هذا الاقتراح لم يُنسى gabbybilka وشكرا لك على قبوله!

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

قد تكون chigy شخصًا يمكن التحدث إليه حول مواصفات التصميم النهائية ، حيث تعمل مع فرق Fluent Design.

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

• كورتانا
• موسيقى Groove
• السينما والتلفزيون
• هاتفك

هذه هي التطبيقات التي تتبادر إلى الذهن.

gabbybilka لدينا أيضًا التحكم في مجموعة أدوات مجتمع Windows ، ويسعدنا التحدث عن ذلك معك في أي وقت. سيكون من الرائع حقًا أن يكون لديك مسار ترقية لمستخدمينا هنا وترحيله من Toolkit إلى WinUI.

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

المتابعة من مجموعة الأدوات مع بعض محفوظات عنصر التحكم من مجموعة الأدوات (كانت موجودة منذ فترة):

• البند الاصلي
• أول مراجعة للعلاقات العامة
• سجل GitHub - لست متأكدًا من كيفية الحصول على القائمة الكاملة في صفحة واحدة ، لذا قم بالتمرير لأسفل واستمر في النقر فوق "أقدم"

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

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

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

الفرق (قيد التسجيل الآن)

المكتب (وضع التوافق)

فرق (بدون إنترنت)

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

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

أعتقد أن هذين المفهومين:

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

سيوفر أكبر قدر من القيمة وأقل ارتباك كعناصر تحكم منفصلة.

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

شكرا مرة أخرى للجميع!

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

إلخ

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

شكرا مرة أخرى للجميع!

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

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

هل / يمكن أن يعمل هذا أيضًا بمثابة CommandBar قابل للرفض مثل تلك المستخدمة أثناء التقديم / مشاركة سطح المكتب؟ على سبيل المثال

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

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

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

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

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

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

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

هل / يمكن أن يعمل هذا أيضًا بمثابة CommandBar قابل للرفض مثل تلك المستخدمة أثناء التقديم / مشاركة سطح المكتب؟ على سبيل المثال

@ مايكل هوكر

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

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

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

كملخص لما تم تحديده حتى الآن ، نختار إنشاء عنصر تحكم واحد مع وضعين مرئيين ، "Bar" و "Toast" أو "Card". جهودنا الحالية في تحديد ووضع النماذج الأولية "شريط". مكونات هذين الوضعين هي نفسها ومن المخطط لها أن تختلف فقط في التخطيط المرئي. نظرًا لوجود العديد من الأوضاع المرئية ، فأنا أعتبر حاليًا عنصر التحكم StatusBanner هذا بدلاً من InformationBar لعدم التقييد بنمط "Bar" الفردي ، ومع ذلك ، لا تتردد في مشاركة أفكارك الخاصة بالتسمية 😊

المكونات الرئيسية لـ StatusBanner من اليسار إلى اليمين في التخطيط هي:

• لون الحالة
• أيقونة
• لقب
• رسالة
• زر التشغيل
• زر الاغلاق

هذه الخصائص اختيارية ولا يزال المحتوى المخصص عبر خاصية "المحتوى" خيارًا متاحًا.

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

النموذج الورقي لشريط الحالة في وضع "الشريط" بدون زر الإجراء أو زر الإغلاق المخصص.

التصميم الحالي لتخطيطات شريط StatusBanner مستوحى بشكل كبير من تصميماتmdtauk لبطاقة الحالة ، شكرًا لك!

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

yaichenbaum في هذه الأثناء ، هناك عنصر تحكم Toolkit InAppNotification .

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

yaichenbaum في هذه الأثناء ، هناك عنصر تحكم Toolkit InAppNotification .

hawkerm لم أنظر كثيرًا إلى InAppNotification لكنني أفضل انتظار إصدار WinUI بدلاً من التبديل إلى عنصر التحكم الجديد عندما يكون جاهزًا.

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

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

يرجى التحقق من المواصفات إذا كنت ترغب في رؤية بعض الأمثلة الأخرى:

شكراً لكم جميعاً وأتطلع إلى الاستماع منك!

هل هذا متوفر فقط في WinUI 3 ، أم أنه سينتقل إلى إصدار ما قبل WinUI 2؟

kmgallahan WinUI 2 ، ما قبل الإصدار ، لست متأكدًا تمامًا من إصدار الشحن الدقيق حتى الآن لأننا نريد تلقي المزيد من التعليقات من المجتمع والعملاء حول النموذج الأولي وإصدارات المعاينة.

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

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

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

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

في الوقت الحالي ، سأنتظر ما يصل إلى معاينة.

مرحبا مجددا! بعض التحديثات:

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

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

• اختار teaP تنفيذ الإصدار الأصلي لعنصر التحكم هذا أثناء تحركه نحو الإصدار التجريبي لـ WinUI 2.5 . شكرا لك!

كما في السابق ، إذا كنت ترى نفسك كمستخدم محتمل لعنصر التحكم هذا ، فلا تتردد في التعليق على التطبيق الذي تقوم بتطويره والسيناريوهات التي ستستخدم فيها شريط المعلومات. شكرا لكل شخص!

مرحبا مجددا! فقط للتوضيح ، فتحت teaP مؤخرًا طلب سحب # 3325 لشريط المعلومات إذا كنت ترغب في التحقق من ذلك 😊

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

سيكون NotificationView أو MessageView ، وما إلى ذلك أسماء أفضل في رأيي.

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

سيكون NotificationView أو MessageView ، وما إلى ذلك أسماء أفضل في رأيي.

تم اقتراحه في الأصل باعتباره StatusBanner
ثم تم تغييره إلى InformationBar / InfoBar

يسمى إصدار FluentUI لعنصر التحكم هذا MessageBar

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

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

2. تلميح تدريسي: قائمة منبثقة / منبثقة تستضيف برنامج MessageView .

   • نصيحة مستضافة

3. NotificationBar أو StatusTip : إشعار على مستوى التطبيق بتنسيق "شريط" أعلى التطبيق أو العرض.

   • نصيحة مستضافة

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

   • نصيحة مستضافة

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

فكر في اسم مثالي لعنصر تحكم "MessageView": أطلق عليه اسم "نصيحة". يمكن أن يستضيف ToolTip ذلك أيضًا. تم التحديث وفقًا لذلك.

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

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

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

• تلميح أداة لعنصر واحد حيث يرغب المستخدم بنشاط في التعرف عليه ؛
• تلميح تدريس لعنصر واحد يريد المطور من المستخدم أن يلاحظه (يمكن أيضًا أن يكون غير مرتبط بعنصر) ؛
• شريط المعلومات لمنطقة التطبيق / المحتوى بالكامل حيث يريد المطور تقديم بعض المعلومات ؛
• Flyout / Dialog عندما يريد المطور من المستخدم تأكيد قراءته لشيء ما قبل رفضه ؛
• حوار المحتوى عندما يطلب المطور من المستخدم أن يختار أو يتخذ إجراءً قبل كل شيء ؛

أود أيضًا تجنب استخدام كلمة Notification نظرًا لوجود إشعار مستوى نظام التشغيل ومركز الإعلام لهؤلاء

أود أيضًا تجنب استخدام كلمة Notification نظرًا لوجود إشعار مستوى نظام التشغيل ومركز الإعلام لهؤلاء

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

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

تعد مربعات حوار Flyout / المحتوى مفاهيم منفصلة لأنها عناصر تحكم عامة في المحتوى في الغالب.

فكرت في اسم مثالي لعنصر تحكم نوع "عرض الرسالة" المعمم لاستضافته في سيناريوهات مختلفة: أطلق عليه اسم "نصيحة". لقد قمت بتحديث تعليقي أعلاه وفقًا لذلك: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

فكرت في اسم مثالي لعنصر تحكم نوع "عرض الرسالة" المعمم لاستضافته في سيناريوهات مختلفة: أطلق عليه اسم "نصيحة". لقد قمت بتحديث تعليقي أعلاه وفقًا لذلك: # 913 (تعليق)

لن أشعر بالراحة عند وضع تحذير مهم أو رسالة خطأ في نصيحة ...

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

تعد مربعات حوار Flyout / المحتوى مفاهيم منفصلة لأنها عناصر تحكم عامة في المحتوى في الغالب.

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

فكرت في اسم مثالي لعنصر تحكم نوع "عرض الرسالة" المعمم لاستضافته في سيناريوهات مختلفة: أطلق عليه اسم "نصيحة". لقد قمت بتحديث تعليقي أعلاه وفقًا لذلك: # 913 (تعليق)

لن أشعر بالراحة عند وضع تحذير مهم أو رسالة خطأ في نصيحة ...

كما أنني أتفق مع هذا ... المزيد من الاستكشاف الذي يتعين القيام به.

فكرت في اسم مثالي لعنصر تحكم نوع "عرض الرسالة" المعمم لاستضافته في سيناريوهات مختلفة: أطلق عليه اسم "نصيحة". لقد قمت بتحديث تعليقي أعلاه وفقًا لذلك: # 913 (تعليق)

لن أشعر بالراحة عند وضع تحذير مهم أو رسالة خطأ في نصيحة ...

كما أنني أتفق مع هذا ... المزيد من الاستكشاف الذي يتعين القيام به.

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

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

سيكون NotificationView أو MessageView ، وما إلى ذلك أسماء أفضل في رأيي.

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

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

تم تعديله لإرباك نفسي بتعليقات متعددة في موقعين.

صدى الأفكار التي نشرتها في أحد الأعداد الأخرى ...

_ الاستجابة للحقيقة أنه لم يعد يتم النظر في وضع عائم لعنصر التحكم لـ V2_
أستطيع أن أفهم أن التغيير في السلوك والشكل سيجعلك تتجه نحو إرشادات التدريس كبديل ، لكنني أقترح أن الافتقار إلى الشدة ، ولون الحالة ، وتصميم نصيحة التدريس نفسها - لن تكون متوافقة مع نفس النوع من الرسائل التي يلبيها عنصر التحكم InformationBar.

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

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

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

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

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

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

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

يبدو التدريس بدون ذيل مثاليًا لموقفك ...

يبدو التدريس بدون ذيل مثاليًا لموقفك ...

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

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

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

يبدو التدريس بدون ذيل مثاليًا لموقفك ...

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

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

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

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

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

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

آسف ، انظر تعديلي أعلاه. النصيحة التعليمية لا تزال غير مضمنة وتطفو في الأسفل حتى يتم رفضها.

لا يجب أن يكون في الأسفل.

ربما تكون الحالة المضمنة حالة استخدام غير معتادة للتلميح ، حيث إنها ستؤدي إلى إزاحة المحتوى الآخر من حولها.

يمكنك اقتراح أن V2 يضيف دعمًا لوضع العرض المضمن / غير العائم

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

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

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

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

لا تنحرف عن مسارك على الرغم من :) كل هذه الضوابط المتنوعة تقدم ، في الغالب ، نفس النوع من المعلومات - فقط في مناطق / أنماط مختلفة. هذا يحتاج إلى التعميم والموحد. أعتقد أنه يمكننا التوحيد حول عنصر تحكم "AppMessage" واحد مشترك إذا كنت تريد تسميته كذلك. ثم فقط لديك حاويات مختلفة لتقديم "AppMessage" بطرق مختلفة. يمكن تقديمها في TeachingTIp ، ToolTip a NotificationBar ، كبطاقة في مكان ما ، إلخ. يمكن لكل حاوية تعديل النمط ليناسب حالة الاستخدام الخاصة بها. الخصائص والأنواع الأساسية ستكون موحدة بالرغم من ذلك.

لم أكن أحاول إساءة فهم أي سياق برد gabbybilka 😄

بالنسبة لمقترح InformationBar و InformationCard المستند إلى فئة AppMessage الأساسية ، أحب هذه الفكرة.

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

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

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

مثال على رسالة / نصيحة بطاقة

أعتقد أن أحد الأهداف يجب أن يكون تشجيع تطبيقات البريد الوارد والطرف الأول / Windows Shell على الابتعاد عن حلولهم المخصصة لاستخدام عنصر تحكم / واجهة برمجة تطبيقات (API) متسقة في علبة الوارد

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

هناك فئة "رسالة" (ليست عنصر تحكم ، فقط بنية بيانات) بالخصائص التالية:

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

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

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

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

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

هناك مجالات أخرى قد تكون فيها المفاهيم المشتركة مفيدة بدرجة أكبر في المنظمة البحرية الدولية. فكر في زر ، AppBarButton ، MenuItem. تعرض كل هذه النصوص والرمز ، وكلها تستخدم لتشغيل إجراء. غالبًا ما تقدم نفس الأوامر في كل من MenuItem (ContextMenu) و AppBar / CommandBar. هنا ، سيكون المفهوم الشائع مفيدًا جدًا ، حيث يمكنك وضع الأمر ، والنص ، والرمز ، وربما أيضًا رسالة طويلة (تلميح أداة). ولكن هل لديك مفهوم مشترك لـ ToolTip و MessageBar؟ أنا حقًا لا أرى ضرورة لذلك. بالتأكيد ، إذا أعدنا كتابة UWP من البداية ، فربما توصلنا إلى فئة أساسية مشتركة. لكنني لا أعتقد أنه ضروري أو مفيد للغاية.

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

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

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

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

لقد جمعت مقارنة بين عناصر التحكم في المراسلة. سأعطيها كاستشارة مجانية لأنها قاسية كما هي :)

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

1. سد الفجوات في التفاهم بين أعضاء الفريق
2. تغلب على "الصوامع" التي تحدث في الفرق والمؤسسات الكبيرة
3. ضمان اتجاه مستقبلي متماسك للإطار بحيث يمكن إضافة وظائف مستقبلية فوق أساس جيد (الأهم)

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

مع ذلك ، لا تتردد في تمزيق المستند أدناه. المناقشة نفسها هي الأهم.

MessageControlComparison 20200929.xlsx

شكرًا لوثيقة المقارنة ، من الرائع جدًا رؤية أفكارك حول عناصر التحكم في المعلومات بشكل كلي! هناك موضوعان أساسيان أرغب في مواصلة المناقشة بشأنهما هما 1. لماذا _لا يجب أن يكون لكل من تلميح التدريس وشريط المعلومات واجهات برمجة تطبيقات / خصائص / وظائف مختلفة؟ و 2. ما هو الفرق بين InfoBar و InfoCard إذا لم تكن بطاقة InfoCard نافذة منبثقة كما هو موضح في مستند المقارنة؟

بالنسبة للسؤال الأول ، يمكنني تسليط الضوء على قرارات التصميم التي تم اتخاذها على العناصر ذات النص الأحمر وتقديم المزيد من الوضوح:

• TeachingTip Subtitle مقابل رسالة InfoBar: وظيفيًا ، نعم ، هما نفس الشيء! إنها رسالة ثانوية مع نص غير غامق في عناصر التحكم هذه. في إرشادات التدريس ، ستظهر هذه الرسالة دائمًا أسفل العنوان ويكون من المنطقي تسميتها كعنوان فرعي. بالنسبة لشريط المعلومات ، ستكون هذه الرسالة في أغلب الأحيان مضمنة ومباشرة على يمين العنوان ، وهو أمر لا معنى له من الناحية المفاهيمية باسم العنوان الفرعي.
• TeachingTip HeroContent vs InfoBar Content: يحتوي تلميح التدريس على محتوى HeroContent ومحتوى بينما يحتوي InfoBar على محتوى فقط. خاصية HeroContent هي خاصية فريدة لـ Teaching Tip بسبب دعمها لهذه الصور الكبيرة للمساعدة في التدريس. لا يدعم شريط المعلومات الصور بشكل صريح لأنه يركز على التخطيط الأفقي. خاصية المحتوى لكلا عناصر التحكم مخصصة للمحتوى الإضافي المخصص وهي أسفل باقي عناصر واجهة المستخدم في كليهما.
• إستراتيجية زر إرشادات التدريس مقابل إستراتيجية زر شريط المعلومات: تتمثل الاختلافات الرئيسية هنا في أن شريط المعلومات يدعم أنواعًا أكثر من الأزرار خارج "الزر" الكلاسيكي ولا يشجع على تخصيص زر الإغلاق لتضمين نص.
  
  
  
  • السيناريو الشائع لأشرطة المعلومات هو تضمين زر ارتباط تشعبي. نظرًا لتباين الألوان مع اللون الأمامي لزر الارتباط التشعبي الافتراضي وألوان الخلفية ذات الألوان المختلفة ، أردنا التأكد من أنه يمكننا تطبيق تصميمنا المخصص على أي أزرار ارتباط تشعبي مدرجة في شريط المعلومات بحيث تظل قابلة للوصول.
  
  
  • قررنا عدم تضمين تخصيص زر الإغلاق (للنص ، لا تزال هناك خاصية CloseButtonStyle للقيام ببعض التصميم الخفيف إذا رغبت في ذلك) إلى شريط المعلومات بعد مراجعات التصميم لدينا لضمان استمرار التركيز على النص المضمّن والإجراء الفردي. فيما يتعلق بذلك ، كما هو مذكور في المواصفات ، نحن نفكر في ActionContentArea في V2 لدعم أكثر من زر إجراء هنا ويمكننا التحقيق في تمكين تخصيص زر الإغلاق مرة أخرى هناك.
  
  
• InfoBar IsClosable & IsIconVisible: لا تحتوي إرشادات التدريس على IsClosable حيث يجب أن تكون إرشادات التدريس قابلة للإغلاق دائمًا لأنها نافذة منبثقة وتعرض معلومات غير قابلة للحظر / عاجلة. كما أنه لا يحتوي على IsIconVisible حيث لا يظهر رمز بتصميمه الافتراضي الذي يفعله InfoBar عبر مستويات الخطورة المختلفة. أردنا توفير وسيلة للمطور لإزالة الرمز المقدم إذا رغب في ذلك. لقد حاولنا تعيين IconSource إلى null مما تسبب في الكثير من الأخطاء غير التقليدية وتم تبسيطه عبر خاصية IsIconVisible.

هل هذه منطقية؟ أعتقد أن هناك أغراض مختلفة لكل من الضوابط والاختلافات في الوظائف تعكس ذلك. آمل أن تكون هذه التفسيرات وأسباب التصميم مفيدة!

تحرير لمشكلات التنسيق والخطأ المطبعي x2

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

ومع ذلك ، فإن إنشاء In App Messaging API ، والذي يعمل كهيكل موحد ، ولكن يمكن أن يتكيف مع عامل الشكل لا يحتاج إلى تغييرات في عناصر التحكم.

هناك أسئلة يجب مناقشتها والإجابة عليها بخصوص هذا النوع من واجهة برمجة التطبيقات:

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

وربما أكثر من ذلك بكثير لم أفكر في لول

أخذ Xbox كمنصة
تختلف طرق الإدخال اختلافًا كبيرًا ، وكذلك حجم الشاشة / التحجيم.

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

لكن كيف ستتعامل مع الطرد؟

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

إذن ، هل يظهر مضمّنًا ويدفع المحتوى لأسفل ، لكن ليس بالعرض الكامل؟

Plus Xbox لديه نخب خاص به مثل نظام الإخطار ، فهل / هل يجب أن تعمل واجهة برمجة التطبيقات هذه مع ذلك؟ هل يمكن أن تعمل معها أم أنها نظام فقط؟

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

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

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

بالنسبة إلى نص الرسالة أو الإكرامية ، يُطلق على أحدهما اسم Subtitle والآخر Message يمكن أن يكونا متطابقين بشكل أساسي ، فلماذا يتم استخدام مصطلحات مختلفة بخلاف مديري المشروع المختلفين الذين يعملون على عناصر التحكم هذه؟

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

ما الفرق بين InfoBar و InfoCard إذا لم تكن بطاقة InfoCard نافذة منبثقة كما هو موضح في مستند المقارنة؟

استنتاجي النهائي للمقارنة هو أن MessageBar / MessageCard يجب أن تكون نفس عنصر التحكم وأن تدعم أيضًا حالة استخدام التلميح أو مثال التلميح الخاص بي من خلال تخصيص النمط.

• من الممكن توحيد MessageBar / MessageCard و Tip في عنصر تحكم واحد. الشاغل الوحيد هو الاختلاف المفاهيمي بين "الرسالة" و "الإكرامية".
• يجب أن يكون نفس عنصر التحكم الأساسي ، يجب أن يكون التصميم قابلاً للتخصيص بدرجة كبيرة لدعم كلتا الحالتين. الشاغل الوحيد هو الاختلاف المفاهيمي بين "الرسالة" و "الإكرامية". التصميم مشابه للغاية.

تحرير: بشكل عام ، أعتقد أن شاغلي الأساسي هو أننا تراجعت بطريقة ما في التفكير المعماري. يتم الآن تصميم عنصر التحكم كما لو كان أيام Windows Forms. يجب أن تستند ضوابط UWP الجديدة على مفاهيم WPF. أصبحت عناصر التحكم شديدة التخصص ولا أرى الخيوط الموحدة التي تغطي إطار العمل والتي `` أذهلت '' المطورين الذين لمسوا WPF لأول مرة. يجب أن نعود إلى عقلية "الصورة الكبيرة" في رأيي.

أوافق بنسبة 100٪ مع robloo على أنه يجب محاذاة أسماء الخصائص وأسماء التعداد لأشياء مماثلة (بقدر الإمكان) مع عناصر التحكم الحالية. يجب أن يكون لعناصر التحكم المماثلة سطح API مشابه. إذا تمت إضافة فئة MessageCard في وقت لاحق (بدلاً من توسيع MessageBar ، وهو ما قد أفضّله شخصيًا) ، فيجب على الأقل أن تحتوي على واجهة برمجة تطبيقات مشابهة جدًا مثل MessageBar.

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

lukasf هل أنت على علم بفئة XamlUICommand ؟ يتيح لك ذلك تجميع هذه الخصائص في مكان واحد ثم تعيينها إلى Button / MenuItem / .... بمجرد تمرير XamlUICommand المحدد إلى واجهة برمجة تطبيقات Command لعناصر التحكم هذه.

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

• XamlUIC أمر
• XamlToggleUIC أمر
• XamlUICommandSubItem (قائمة فرعية / قائمة منبثقة)
• XamlUICommandSeparator

ما يفتقده أيضًا خاصية "مرئي" و / أو خاصية "HideIfDisabled".

ثم سنحتاج إلى ItemsSource في MenuFlyout و AppBar / CommandBar وعناصر تحكم مماثلة. عندئذٍ ينشئ عنصر التحكم في المستوى الأعلى عناصر التحكم الفرعية المقابلة لكل عنصر أمر.

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

كانت XamlUICommand بداية جيدة ، لكنها ليست قصة كاملة.

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

في InfoBar وعبر النظام الأساسي ، أرى أنه أثناء التصميم نسعى جاهدين لإيجاد التوازن الصحيح لعناصر التحكم التي يتم تصميمها خصيصًا لسيناريوهات محددة كنمط واجهة مستخدم محدد - بينما تكون عامة وقابلة للتخصيص بما يكفي لتمتد إلى السيناريوهات التي لم نقم بها بعد تحديدها. بصفتي شخصًا أحدث في الفريق ، أود أن أعرف لماذا يجب أن تعود عناصر تحكم WinUI إلى مفاهيم WPF. ما هي المشكلات اليومية التي تواجهها أنت ومطوروا UWP الآخرين عندما لا تحتوي عناصر التحكم المفاهيمية المماثلة على نفس البنية الأساسية؟ ما هي الفوائد المتوفرة لك حتى نتمكن من فهم أفضل لماذا يجب علينا تخصيص الموارد لإنشاء هذا الهيكل؟ هل توجد عناصر تحكم أخرى في WinUI يمكن أن تستفيد من الوحدة (أرى محادثة الزر أعلاه منlukasf) أعتقد أنه يمكننا أيضًا متابعة هذه المحادثة في مشكلة عامة جديدة إذا كانت هناك منطقة يمكننا فيها تعديل أساليب التحكم / تبادل الأفكار من أجل ضوابط المستقبل. SavoySchuler لأي إدخال هنا.

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

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

في InfoBar وعبر النظام الأساسي ، أرى أنه أثناء التصميم نسعى جاهدين لإيجاد التوازن الصحيح لعناصر التحكم التي يتم تصميمها خصيصًا لسيناريوهات محددة كنمط واجهة مستخدم محدد - بينما تكون عامة وقابلة للتخصيص بما يكفي لتمتد إلى السيناريوهات التي لم نقم بها بعد تحديدها. بصفتي شخصًا أحدث في الفريق ، أود أن أعرف لماذا يجب أن تعود عناصر تحكم WinUI إلى مفاهيم WPF. ما هي المشكلات اليومية التي تواجهها أنت ومطوروا UWP الآخرين عندما لا تحتوي عناصر التحكم المفاهيمية المماثلة على نفس البنية الأساسية؟ ما هي الفوائد المتوفرة لك حتى نتمكن من فهم أفضل لماذا يجب علينا تخصيص الموارد لإنشاء هذا الهيكل؟ هل توجد عناصر تحكم أخرى في WinUI يمكن أن تستفيد من الوحدة (أرى محادثة الزر أعلاه منlukasf) أعتقد أنه يمكننا أيضًا متابعة هذه المحادثة في مشكلة عامة جديدة إذا كانت هناك منطقة يمكننا فيها تعديل أساليب التحكم / تبادل الأفكار من أجل ضوابط المستقبل. SavoySchuler لأي إدخال هنا.

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

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

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

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

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

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

لكن ضمان أن أي خيار يختارونه ، وأن ينظر ويتصرف بطريقة مألوفة ، و "ينتمي" إلى Fluent Design - له ميزة الاتساق.

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

أود أن أقترحه في هذا الريبو ، ويمكنه استخدام عناصر تحكم 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 في تطبيق عميل Nightingale REST الخاص بي. إنه مثالي لواحد من السيناريوهات الخاصة بي. في الاختبار السريع الذي أجريته ، يبدو أن الرمز الموجود في شريط المعلومات لا يدعم المظهر الفاتح؟ أو ربما أفعل شيئًا خاطئًا في استخدام XAML لعنصر التحكم. وهنا بعض لقطات الشاشة

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

أعتقد أنه يجب تغيير لون النجاح في "المظهر الداكن". تضمين التغريدة _
لون المظهر الداكن الحالي هو # 393D1B - والذي يبدو أنه لون أخضر مصفر ، ولون زيتوني تقريبًا. حيث يستخدم المظهر الفاتح اللون الأخضر الأكثر وضوحًا ، والنعناع تقريبًا مثل الأخضر.

_أعلى الألوان الحالية ، أسفل التغيير المقترح_

# 1d3d1b

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

هنا كيف سيبدو