@sapallie , pourriez-vous rendre les maquettes de conception accessibles au public ? À moins qu'ils ne soient pas partagés à ce stade.

Je fais actuellement du développement XAML, et j'aimerais voir quelque chose comme ça. Ou, quelque chose comme un joli contrôle de message défilant.

Du point de vue de la marque Microsoft, une bannière d'erreur standardisée semble pouvoir mal tourner. Je craindrais que les utilisateurs finaux associent chaque erreur d'application à la marque Microsoft. Je viens de lire la proposition, et la première chose qui m'est venue à l'esprit était les memelords qui tweetaient à propos de la bannière flashy de la mort.

@sapallie , pourriez-vous rendre les maquettes de conception accessibles au public ? À moins qu'ils ne soient pas partagés à ce stade.

Désolé @adrientetar , je ne peux pas encore les partager. Les conceptions sont uniquement Microsoft pour le moment.

@sapallie , merci pour cette idée de fonctionnalité phénoménale ! Je suis responsable de programme pour WinUI et je suis ravi de le présenter à l'équipe !

Je voulais écrire un peu sur notre processus afin que vous puissiez être au courant de la façon dont nous allons procéder à partir d'ici. À partir de maintenant, je vais travailler pour affiner la portée/les exigences de haut niveau de cette proposition et la justification du développement. Ensuite, je le présenterai au reste de l'équipe WinUI et nous délibérerons pour savoir s'il s'aligne sur notre feuille de route (#717) et si nous pensons pouvoir agir relativement rapidement. Si c'est le cas, je serai approuvé pour comprendre les détails et commencer à rédiger les spécifications afin que la fonctionnalité soit prête pour un développeur.

Voici quelques choses que je sais déjà pour lesquelles j'ai besoin d'avoir un peu plus d'idée...

• Comportement visuel

Votre proposition concerne-t-elle une bannière bord à bord ? Ou une vignette de notification comme ce que font les notifications Windows mais dans la fenêtre de l'application, comme au centre, le long du bord inférieur ou dans un coin ?

Désolé @adrientetar , je ne peux pas encore les partager. Les conceptions sont uniquement Microsoft pour le moment.

Je ne pense pas que je serais en mesure de faire approuver cette proposition sans pouvoir inclure un visuel public de la demande, car le dépôt _est_ open source et la proximité du côté visuel de la conversation emmêlerait le processus et l'expérience pour notre communauté . Sur la base des réponses à ce qui précède, je suis heureux de tenter de rédiger une maquette pour la proposition. Préférez-vous ceci ou avez-vous un délai prévu pour accorder votre permission de rendre votre conception publique ? J'adore votre maquette et je serais impatient de les inclure dans notre brainstorming ici, de peur que nous ne prenions inutilement la discussion dans une direction divergente de votre intention. S'il vous plaît, faites-moi savoir! :rougir:

La bannière informera les utilisateurs des erreurs qui les empêchent d'utiliser une application/une fonctionnalité

La bannière pourra être ignorée pour les erreurs non critiques

Ai-je raison de lire ces déclarations comme signifiant que vous devez également avoir l'option d'une bannière non révocable pour les erreurs critiques ? Si oui, pourriez-vous m'en dire plus sur votre scénario d'application spécifique pour en recevoir une/procéder à partir du point d'avoir une bannière non révocable ? Les utilisateurs sont-ils relégués à fermer l'application tant que le problème n'est pas résolu ? Ou est-ce là que les boutons viendraient, par exemple, les diriger vers la page des paramètres Réseau et Internet ?

Merci encore et j'ai hâte de peaufiner cette idée!

Tout le monde, n'hésitez pas à partager vos besoins, vos conceptions et vos points de vue dans cette conversation ! :rougir:

Je voudrais dire qu'il y a quelques propositions qui demandent toutes la même chose. Plutôt que d'en faire spécifiquement une bannière d'erreur - pourquoi ne pas simplement apporter la notification dans l'application de la boîte à outils communautaire. Il pourrait y avoir une propriété d'icône ajoutée, ce qui lui ferait afficher une icône d'erreur, ou une icône de confirmation, etc.

@SavoySchuler - ravi de vous entendre. J'ai essayé de répondre à toutes vos questions, mais n'hésitez pas à me faire savoir si vous avez besoin d'autre chose.

Comportement visuel :
Idéalement, la bannière serait similaire à une vignette de notification Windows et serait épinglée en haut ou en bas de la fenêtre de l'application. L'endroit où il est épinglé dépend des autres éléments visuels de l'application et de l'endroit où se trouve le focus. Cette décision doit être prise par un concepteur.
Je pense que le GIF posté par @mdtauk serait un excellent point de départ.

Rejet :
Je pense qu'il serait logique d'approfondir ce que je veux dire avec les erreurs critiques et non critiques :

• Erreurs critiques = la fonctionnalité de l'application est altérée en raison d'un problème à l'échelle du système (par exemple, la connexion Internet est perdue) - celles-ci doivent être liées aux paramètres du système où l'utilisateur peut éventuellement résoudre le problème
• Erreurs non critiques = certaines fonctionnalités sont altérées ou une seule fonctionnalité ne fonctionne pas, mais les utilisateurs peuvent toujours faire d'autres choses dans l'application
• Ce serait également cool d'introduire une itération purement informative de la bannière qui peut être utilisée pour informer les utilisateurs que des mises à jour d'applications ou de nouvelles fonctionnalités sont disponibles.

Et je pense que tout cela devrait être rejeté (j'ai également mis à jour cela dans la description de la proposition)

Exemples de visuels
J'ai apporté quelques modifications aux visuels et je peux les partager comme ceci :

Ces exemples sont une itération où la bannière entière est essentiellement un gros bouton. Les utilisateurs peuvent l'ignorer ou cliquer dessus pour accéder aux paramètres système (erreur critique), ouvrir une page Web contenant des détails sur les correctifs de fonctionnalités (avertissement 1), recharger la page de l'application (avertissement 2) ou accéder au magasin Microsoft pour mettre à jour le application (informative).
Il serait possible d'étendre ce concept pour ajouter plusieurs boutons dans la bannière.

J'aime beaucoup ces visuels pour la bannière. Je déplacerais le texte et l'icône vers le haut de 4 px, afin qu'ils soient centrés dans la zone blanche, plutôt que dans la barre blanche et colorée.

D'accord. Les visuels affichés sont plutôt sympas.

J'aime beaucoup ces visuels pour la bannière. Je déplacerais le texte et l'icône vers le haut de 4 px, afin qu'ils soient centrés dans la zone blanche, plutôt que dans la barre blanche et colorée.

Je n'ai pas compté les pixels, mais il semble qu'ils soient centrés si l'espace pour les signes diacritiques au-dessus de la hauteur X est pris en compte.

@sapallie Avez-vous pensé à autoriser le rejet automatique ou programmé de ces contrôles ?

Si vous êtes invité à vous déconnecter, il serait logique de supprimer par programme une telle invite lorsque vous serez à nouveau en ligne. (J'ai vu des applications ne pas le faire et cela peut conduire à une expérience déroutante.)

De même, le fait d'avoir des messages non essentiels non affichés indéfiniment peut éviter un encombrement inutile de l'interface utilisateur et peut empêcher les utilisateurs expérimentés d'avoir à sortir du flux une fois qu'ils ont lu un message en ne les forçant pas à ignorer manuellement la notification.

Je comprends qu'il existe des considérations d'accessibilité supplémentaires potentielles autour d'un tel contrôle et de ces comportements, mais je pense que ces moyens de rejeter le contrôle sont essentiels.

Je pense qu'il est important de rappeler qu'un tel contrôle n'est pas destiné à la messagerie générale au sein d'une application. Sauf si c'est vraiment un cas d'utilisation souhaité.

Une application doit-elle être autorisée à afficher plusieurs bannières à la fois ?
Si oui, comment seront-ils organisés ? Et est-ce quelque chose que l'application peut contrôler ?

Cela satisferait ceux qui ont demandé un style Android Toast dans le contrôle des notifications d'application, cela pourrait également être utile pour les scénarios de validation, pour afficher le texte d'erreur là où l'espace dans le formulaire est limité.

Je l'appellerais aussi quelque chose comme un StatusTip ou StatusNotification afin qu'il ne soit pas uniquement associé à des utilisations négatives.

Je suppose que la conception s'adapterait en changeant le placement sur la barre de couleur unie lorsqu'elle est placée au bas de la fenêtre ?

Il devrait probablement avoir une propriété de délai d'attente et pourrait même avoir la possibilité d'afficher un message en attente, comme un anneau de progression et du texte comme "Se connecter maintenant" avant de passer à une confirmation du message d'erreur.

J'aime beaucoup ces visuels pour la bannière. Je déplacerais le texte et l'icône vers le haut de 4 px, afin qu'ils soient centrés dans la zone blanche, plutôt que dans la barre blanche et colorée.

Je n'ai pas compté les pixels, mais il semble qu'ils soient centrés si l'espace pour les signes diacritiques au-dessus de la hauteur X est pris en compte.

Je pense qu'il était plus probable que le texte soit centré verticalement dans la case sans tenir compte de la barre de couleur

Voici comment le placement de la barre colorée pourrait changer avec le placement du contrôle

@mrlacey oui, le rejet programmatique/automatique lorsque la bannière n'est plus pertinente est assez important - je l'ai ajouté à la description de la proposition.

Changements de statut et erreurs : c'est à cela que doivent servir les bannières. Pas de messagerie générale - je suis d'accord là-dessus.

Et je pense que plusieurs bannières devraient fonctionner. Ils doivent simplement être empilés.

@mdtauk Je l'ai renommé "Bannière de statut" - merci pour vos suggestions.

Pour l'état de chargement - je ne pense pas que cela devrait se produire dans la bannière. Le chargement du contenu doit être affiché dans l'application où le contenu apparaîtrait réellement.

Et lorsqu'il s'agit de changer l'emplacement de la barre colorée, ce serait bien d'avoir la flexibilité là-bas en fonction de l'endroit où la bannière d'erreur est placée dans la fenêtre de l'application. 👍

Les numéros #622 et #792 pourraient également être couverts par ce contrôle, s'il devait être construit.

@sapallie Votre note sur les circonstances d'erreur critique est intéressante en ce qui concerne les conseils suggérés selon lesquels les bannières d'état orientent l'utilisateur vers une solution. Mon intuition me dit que vous pourriez aussi avoir besoin d'une API pour désactiver, ou au moins temporairement la révocation ?

Je comprends qu'il existe des considérations d'accessibilité supplémentaires potentielles autour d'un tel contrôle et de ces comportements, mais je pense que ces moyens de rejeter le contrôle sont essentiels.

@mrlacey , super légende ! Heureusement, j'ai travaillé sur une partie importante de cela lors de l'examen du rejet automatique chronométré sur TeachingTip, et bien que certains partenariats avec des équipes qui possèdent des paramètres d'accessibilité seraient nécessaires, je ne pense pas que cette fonctionnalité serait bloquée en raison de problèmes d'accessibilité. +1 sur tous vos autres points !

Pourrait-il y avoir la possibilité d'ajouter un lien hypertexte vers une solution ou vers un raccourci de paramètres, comme la mise en réseau ?

Pourrait-il y avoir la possibilité d'ajouter un lien hypertexte vers une solution ou vers un raccourci de paramètres, comme la mise en réseau ?

J'envisageais le sous-texte contenant un lien hypertexte vers une application intégrée ou une application de paramètres (voir le code de la galerie Xaml Control de TeachingTip). Pensiez-vous à quelque chose de plus standardisé @mdtauk ?

Propriété @SavoySchuler Content au lieu de MessageText ?

Votre note sur les circonstances d'erreur critique est intéressante en ce qui concerne les conseils suggérés selon lesquels les bannières d'état orientent l'utilisateur vers une solution. Mon intuition me dit que vous pourriez aussi avoir besoin d'une API pour désactiver, ou au moins temporairement la révocation ?

Ouais, peut-être que je suppose… Cela ne fait certainement pas de mal de l'ajouter. Cela ajoute de la flexibilité après tout et sera probablement très utile pour certains cas d'utilisation.

@mdtauk - Oui, je veux certainement dire la propriété du contenu !

@sapallie

Votre note sur les circonstances d'erreur critique est intéressante en ce qui concerne les conseils suggérés selon lesquels les bannières d'état orientent l'utilisateur vers une solution. Mon intuition me dit que vous pourriez aussi avoir besoin d'une API pour désactiver, ou au moins temporairement la révocation ?

Ouais, peut-être que je suppose… Cela ne fait certainement pas de mal de l'ajouter. Cela ajoute de la flexibilité après tout et sera probablement très utile pour certains cas d'utilisation.

D'une part, vous avez une fenêtre contextuelle non révocable couvrant l'interface utilisateur (et provoquant éventuellement sa propre erreur basée sur un scénario) et d'autre part, vous avez un avertissement/erreur critique de l'application qui n'est pas persistant, ce qui rend également mes sens d'araignée picotent.

Peut-être plutôt qu'une fenêtre contextuelle de style over UI + tip, une bannière in UI + bord à bord (comme celle qui est utilisée par la suite Office pour notifier les mises à jour - voir ci-dessous) répondrait aux besoins tout en étant accordé un espace persistant dans votre interface utilisateur ?

@SavoySchuler Il peut y avoir un comportement sur le contrôle, où il place l'en-tête et le contenu sur une seule ligne, si la largeur du contrôle est suffisamment large.

Ma suggestion précédente avec les différentes dispositions de positionnement fonctionnerait également si le contrôle sortait du bord d'un autre contrôle - pas seulement dans la fenêtre ou le panneau.

Peut-être plutôt qu'une fenêtre contextuelle de style over UI + tip, une bannière in UI + bord à bord (comme celle qui est utilisée par la suite Office pour notifier les mises à jour - voir ci-dessous) répondrait aux besoins tout en étant accordé un espace persistant dans votre interface utilisateur ?

Ouais, ça marche aussi. 👍

Il semble qu'il serait idéal d'avoir à la fois des options en ligne et de superposition, car rétrospectivement, la suite Office peut compter sur toutes ses applications ayant un ruban. @mdtauk J'aime votre suggestion qui commence à faire allusion à la façon dont nous pensons au comportement d'apparition/disparition.

@all , quelqu'un peut-il partager avec moi des scénarios spécifiques dans vos applications réelles où vous envisagez d'utiliser ce contrôle ? Plus précisément, je m'intéresse aux réflexions sur l'entrée visuelle et l'interaction de l'utilisateur requise pour provoquer le licenciement ? Les exigences ici couvrent-elles les comportements de base dont vous avez besoin pour ce contrôle ?

@SavoySchuler Compte tenu de l'entrée et de la sortie, il peut glisser depuis un bord, mais également s'animer en tant que superposition flottante si le développeur le souhaite. Glisser depuis le bord droit de l'écran au niveau du système d'exploitation - depuis le bord droit d'une fenêtre d'application, ou vers l'extérieur depuis le bord d'un élément de contrôle ou d'interface utilisateur.

Il y a un bouton de fermeture pour le rejet, mais pour les écrans tactiles, la possibilité de le faire glisser dans le sens inverse d'où il est sorti pourrait également fonctionner. Pour assurer la cohérence, cela doit être intégré dans le contrôle.

Appuyer sur la commande devrait probablement déclencher une action que le texte du message spécifierait.
L'exception serait d'afficher la progression d'une action qui ne pourrait pas être rejetée jusqu'à ce qu'elle expire avec une erreur ou se termine avec succès.

Exemples animés

Entrer, mettre à jour, quitter - Lien YouTube

Animer dans - Lien YouTube

TeachingTip existe et est un bon moyen de cibler un élément de contrôle ou d'interface utilisateur spécifique, et bon pour mettre en évidence une nouvelle fonctionnalité dans une application. Il pourrait techniquement être utilisé aux mêmes fins que ce StatusBanner, il faut donc réfléchir à l'utilisation sémantique de chacun d'entre eux et identifier ce qui rend chacun unique.

Vous trouverez ci-dessous mes réflexions personnelles sur la différenciation entre la bannière d'état et le conseil d'enseignement

• La bannière de statut _je crois_ devrait être encouragée pour les statuts actionnables réels, et devrait donc invoquer une seule action lorsqu'elle est tapée.

  • Le conseil d'enseignement présenterait les actions sous forme de bouton ou de lien hypertexte, généralement utilisé pour des informations pouvant être facilement ignorées.

• Lorsqu'une condition d'application ou de système d'exploitation change, cela est nécessaire pour l'application, cela devrait déclencher l'affichage d'une bannière d'état.

  • Conseil d'enseignement ne fournirait pas d'informations critiques et, une fois rejeté, ne serait plus affiché à moins que quelque chose de nouveau ne soit ajouté pour être appelé.

• La bannière d'état doit soit persister lors de l'affichage, à moins qu'elle ne soit rejetée avec le bouton Fermer, ou peut-être un balayage lorsqu'il est en contact. À l'exception d'un scénario de progression en cours qui se termine ou de l'état du système d'exploitation résolu (le réseau est restauré).

  • L'astuce d'enseignement inclurait éventuellement une fonction de temporisation, ne s'afficherait pas de manière aléatoire pendant l'exécution de l'application, principalement affichée lors du lancement de l'application ou de la navigation vers une page/un écran.

• La bannière d'état doit être utilisée dans le shell du système d'exploitation de manière cohérente - il peut y avoir un ensemble de bannières localisées standard avec du contenu, des icônes, des couleurs, sous forme d'énumération.

• Il pourrait y avoir une certaine logique du système d'exploitation pour ajouter des bannières d'état aux fenêtres d'application.
  Par exemple, lorsqu'une application tente d'accéder au réseau et qu'elle n'est pas disponible, le système d'exploitation peut afficher une bannière d'état standard dans la fenêtre de l'application, plutôt que dans l'espace de l'écran, ou laisser les développeurs la mettre en œuvre.

  • Le conseil d'enseignement serait spécifique à l'application, et aucun contenu standard défini, et pour le développeur seul à inclure.

@mdtauk , travail fantastique sur les vidéos ! 🎉 Ils sont plus qu'utiles pour donner vie à ces idées.

Le besoin de persistance est un excellent point et je pense que la fonction de rejet pourrait également être atténuée par des directives qui suggèrent de rendre les notifications d'état disponibles de manière persistante dans un volet de notification si elles sont critiques ou, éventuellement, de les refaire surface à des intervalles non invasifs si les problèmes persistent. Ce ne sont pas des affirmations définitives, juste des points de considération à prendre en compte pour s'assurer que cette solution est suffisamment complète dans sa solution de scénario.

La nécessité de distinguer TeachingTip de cette fonctionnalité est parfaite et je suis d'accord avec vos points. Ce contrôle répondrait à un besoin distinct que TeachingTip n'a pas été conçu pour résoudre, bien qu'il puisse y avoir une opportunité pour certaines fonctionnalités ou certains codes partagés.

Y a-t-il des parties prenantes dont les besoins ne seraient pas satisfaits par quelque chose comme ce que @mdtauk a partagé ci-dessus ?

Il semble y avoir des différences entre les bannières d'état simulées dans l'OP et la notification pleine largeur comme on le voit dans Office (images ci-dessus dans les commentaires précédents) ou Visual Studio (comme ci-dessous)

Les différences entre les deux signifient que je me demande s'ils devraient être le même contrôle ou des contrôles séparés.

Voici une liste rapide des propriétés dont chacun aurait besoin. (noms par exemple, non figés mais destinés à inférer un sens)

Bannières de statut

• _Icône_
• Texte du message
• Texte supplémentaire (deuxième ligne)
• Type (Critique, Avertissement ou Information)
• Couleur
• Lieu
• Direction des animations
• Appuyez sur Événement/Commande
• Temps libre

Notifications pleine largeur

• _Icône (éventuellement)_
• Texte du message
• Style de lien (bouton ou lien hypertexte)
• Liens (Texte et Tap Event/Command - multiple)
• Temps libre

Seules les propriétés en gras existent dans les deux. _Icon_ est potentiellement déroutant car différents types d'icônes (dans un cercle ou un contour) sont nécessaires pour chaque type.
Il devrait également y avoir une propriété pour indiquer le style à utiliser.

Pour moi, cela donne l'impression qu'il y a trop de différence pour un seul contrôle et que mettre toutes ces fonctionnalités ensemble serait déroutant et compliqué.
Je pense que ces deux concepts:

• une bannière pleine largeur escamotable avec zéro ou plusieurs sous-éléments actionnables
• une bannière destinée à indiquer les changements d'état et qui fonctionne comme un bouton unique

fournira le plus de valeur et le moins de confusion en tant que contrôles séparés.

Comment les bannières d'état animées prendraient-elles en charge l'affichage de plusieurs notifications à la fois ?
Ou est-ce maintenant hors de portée ?

• La bannière d'état doit être utilisée dans le shell du système d'exploitation de manière cohérente - il peut y avoir un ensemble de bannières localisées standard avec du contenu, des icônes, des couleurs, sous forme d'énumération.
• Il pourrait y avoir une certaine logique du système d'exploitation pour ajouter des bannières d'état aux fenêtres d'application.
  Par exemple, lorsqu'une application tente d'accéder au réseau et qu'elle n'est pas disponible, le système d'exploitation peut afficher une bannière d'état standard dans la fenêtre de l'application, plutôt que dans l'espace de l'écran, ou laisser les développeurs la mettre en œuvre.

Ce niveau d'intégration du système d'exploitation montre une ambition au-delà d'un seul contrôle et au-delà de WinUI.

Est-ce que les "bannières standard localisées" seraient tout ce qui est disponible ou seraient-elles en plus de pouvoir avoir quelque chose d'entièrement personnalisable ?
Si vous en fournissez par défaut, quels seront-ils ?
Je craindrais que le fait de ne fournir qu'un ensemble limité d'options limite inutilement le potentiel d'un tel contrôle.

Le fait que le système d'exploitation affiche des bannières dans l'application ouverte pour des scénarios à l'échelle du système, tels que la perte de connectivité réseau, me pose un certain nombre de problèmes.

• Le centre d'action fournit déjà un moyen de fournir des notifications à l'échelle du système.
• Avec plusieurs fenêtres ouvertes, voir des bannières affichées dans chacune semble inutilement intrusif.
• Avoir les notifications d'affichage du système (bannières) dans une application est quelque chose que je m'attendrais à ce que les développeurs veuillent contrôler ou désactiver.
• Si une application n'a besoin d'une connexion réseau qu'occasionnellement, voir une invite concernant une perte de connexion peut être déconcertant ou distrayant pour l'utilisateur s'il n'est pas pertinent par rapport à ce qu'il est en train de faire.
• Cela lierait les applications à des versions spécifiques du système d'exploitation pour obtenir des mises à jour ou le comportement souhaité. Une future modification de la fonction du système d'exploitation pourrait casser ou modifier une application de manière indésirable.
• Les mises à jour et les corrections de bogues ne seraient disponibles qu'aux calendriers de publication au niveau du système d'exploitation. Une partie de la raison de l'existence de WinUI est de rompre ce couplage avec les fonctionnalités du système d'exploitation et de l'application.

• L'un des objectifs d'un tel contrôle tel que décrit ici est de le rendre facile à mettre en œuvre pour les développeurs. La suppression de leur capacité à le contrôler entraînerait des problèmes pour les applications où des scénarios spécifiques doivent être gérés de manière personnalisée.

Je viens de trouver ce problème dans le message Twitter sur les maquettes animées. Cela semble chevaucher une grande partie du travail que nous avons effectué avec le contrôle InAppNotification dans la boîte à outils. Y compris des choses comme la façon dont plusieurs messages sont traités.

Nous avons appris que même si cela apparaît comme un simple contrôle, c'est assez complexe. Ce serait bien d'avoir une solution holistique qui peut être intégrée à WinUI pour couvrir tous ces cas. Ensuite, nous pouvons déprécier le contrôle de la boîte à outils.

Conversation avec @ryandemopoulos , et je veux refactoriser un peu cette conversation initiale pour me concentrer sur le problème (besoin d'interface utilisateur d'erreur) avant la solution (tout élément spécifique / éléments d'interface utilisateur d'erreur).

À cette fin, mon premier objectif est de verrouiller les scénarios et les exigences d'erreur d'interface utilisateur ( @sapallie , votre scénario "Critique : connectivité wifi perdue" est un début parfait). À partir de là, nous pouvons travailler ensemble pour décider si la solution inclut une partie de l'interface utilisateur de notification d'erreur ou un ensemble de composants d'interface utilisateur d'erreur. À partir de là, nous développerons la décomposition de la similarité de l'API de @mrlacey (merci d'avoir commencé) pour décider s'il y a suffisamment de points communs pour une approche de dérivation par rapport à des contrôles distincts s'il y a plusieurs sorties de cette conversation. Je ne veux pas prendre d'avance sur moi-même, mais l'argument de @mrlacey pour des solutions distinctes a déjà l'air clair et c'est OK. Mon objectif est de créer le bon ensemble de solutions pour tout le monde ici.

Donc, pour toute personne ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk et @mrlacey) pour qui ce contrôle est particulièrement pertinent, pourriez-vous me fournir ce qui suit ici ou dm @ [email protected] :

• Titre de l'application
• Description du scénario (erreur, critique/non critique et description de la manière dont vous souhaitez le présenter)
• Capture d'écran de l'écran de l'application où l'erreur se présenterait (si disponible)

J'ai mis à jour le problème pour refléter cette approche axée sur les problèmes et j'ai répertorié les exigences, les scénarios et les possibilités de solutions décrites jusqu'à présent.

@sapallie J'ai essayé d'être aussi courtois que possible en préservant votre travail initial. L'historique des versions est visible sous le menu déroulant "édité par..." en haut du numéro. S'il vous plaît laissez-moi savoir si je n'ai pas saisi quelque chose correctement.

J'ai proposé cela à l'équipe WinUI et nous pensons que la fonctionnalité définie ici serait capable de servir non seulement des messages d'erreur, mais aussi des messages d'état de longue durée à l'échelle de l'application dans son ensemble. Cela inclut les types de messages d'état "mise à jour disponible" et "sauvegarde terminée" en plus des scénarios spécifiques aux erreurs.

J'ai mis à jour le numéro pour refléter cette approche plus holistique. J'espère finaliser les exigences et les scénarios dans les semaines à venir afin que nous puissions examiner les éléments de sortie d'interface utilisateur nécessaires pour afficher ces messages.

Je vais reformuler ma demande ci-dessus. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk et @mrlacey , pour les messages d'état/d'erreur que vous souhaitez afficher dans vos applications, pourriez-vous me fournir les éléments suivants ici ou à [email protected] :

• Titre de l'application
• Description du scénario (message d'état, critique/non critique et description de la manière dont vous souhaitez le présenter)
• Capture d'écran de l'écran de l'application où l'erreur se présenterait (si disponible)

Il convient de noter que, imo, les boîtes de dialogue contextuelles doivent être évitées si possible. Le Web regorge d'invites contextuelles partout et elles interrompent le flux en essayant d'attirer votre attention. Par exemple, je pense que le statut vide ( exemple ) devrait être préféré, par exemple si quelque chose ne pouvait pas être chargé dans un contrôle.

En ce qui concerne les visuels publiés par @mdtauk , avons-nous vraiment besoin de fenêtres contextuelles affichées sur les quatre bords de l'écran/de l'application ? Le but de WinUI devrait être de normaliser la position et l'apparence de ces éléments afin que toutes les applications utilisent la même chose, et à cet égard, Android Snackbar est une référence évidente. Une autre chose à noter avec Snackbar est qu'il n'affiche pas d'erreurs avec une couleur rouge vif ou quoi que ce soit, il a une apparence sobre qui, je pense, est à nouveau bénéfique pour ne pas trop distraire l'utilisateur de ce qu'il fait.

Nous aurons également besoin de conseils pour savoir quand utiliser cette fenêtre contextuelle au lieu d'une boîte de dialogue par exemple, sinon cela créera simplement une fragmentation (différentes applications utilisant les commandes de messagerie de différentes manières).

Les Flyouts ont un concept de placement, ce contrôle pourrait faire la même chose. Apparaît depuis le bord intérieur d'un contrôle conteneur, qu'il s'agisse d'un contenu de page ou d'onglet, etc.

@adrientetar Toutes les applications ne sont pas identiques, donc bien qu'il y ait une valeur par défaut pour ce contrôle, il doit y avoir un moyen pour les développeurs de changer cet emplacement, sans avoir à re-modèler ou à repenser le contrôle.

Office utilise l'espace sous le ruban. Edge utilise le bas de l'écran. Seul Windows lui-même serait en mesure de l'attacher aux bords du Shell ou de l'écran, et il y a probablement une bonne raison d'empêcher les applications d'imiter les alertes au niveau du système.

De plus, tout développeur a la possibilité de redéfinir ses propres contrôles d'alerte, donc à ce stade, il doit être aussi flexible que possible, puis l'équipe Shell aura son mot à dire sur les restrictions liées à l'utilisation des contrôles.

L'équipe Your Phone dispose de l'un de ces types de contrôles, alors peut-être pourriez-vous leur demander quels problèmes ils ont rencontrés et les persuader de passer à l'utilisation du contrôle WinUI une fois terminé et inclus ?

Dropbox utilise également Snackbar dans son système de conception (faites défiler vers le bas, avant-dernière rangée d'images).

Récemment repéré quelques autres exemples de messages d'état de longue durée à l'échelle de l'application :

(message "l'enregistrement a commencé" dans Teams)

("essayer de se connecter au coordinateur du jeu" dans Dota 2)

Désolé, ils sont petits - la première photo a été prise depuis mon bureau avec un moniteur ultra-large. :)

Certaines barres d'en-cas de dropbox contiennent une barre de progression en bas. Cela devrait-il être inclus ici? Cela peut avoir du sens, par exemple pour des choses comme le téléchargement, le téléchargement, la mise à jour, la progression de la synchronisation. Ce n'est pas un imo indispensable, mais peut-être pourrait-il ou devrait-il ?

Faut-il les arrondir ? Ou pas?

Oui, je pense que la principale différence ici par rapport à Teaching Tip est que les applications veulent coordonner leur espace de messagerie et peuvent avoir plusieurs mises à jour d'erreur/de statut à afficher en même temps (ou successivement).

Je pense qu'idéalement, il s'agit d'un contrôle que le développeur configure et place dans son application, puis transmet également les messages (qui, j'imagine, ont une sorte de type pour indiquer s'il s'agit d'une erreur, d'un statut, d'un avertissement ou d'un autre message général).

Dans le cas de la bannière et du pop-up, j'ai vu des applications qui peuvent avoir plusieurs messages. Parfois, ils empilent les bannières qui dominent alors l'immobilier de l'interface utilisateur, donc ce serait bien si cette solution évitait cela (bien que rien n'empêcherait un développeur d'utiliser plusieurs instances du contrôle pour recréer ce comportement encore).

Je suis surpris que nous n'ayons pas non plus appelé VS Code, car ils ont leurs panneaux de notification contextuels empilables en bas à droite qui ont également des boutons d'action supplémentaires (pour passer aux paramètres par exemple).

Capture d'écran de l'exemple de code VS :

Ils ont différents types d'icônes qui apparaissent en haut à gauche, des actions de bouton personnalisables et la possibilité d'avoir l'icône « engrenage » pour configurer les paramètres concernant les notifications par extension, dans leur cas.

Je viens de voir cette capture d'écran de Cortana...

MessageBar d'Office UI Fabric a fière allure, IMO :

J'ai remarqué que Samsung Notes pour Windows 10 utilise des toasts de notification pour expliquer qu'une note a été supprimée car elle ne contient rien de si ennuyeux

Salut à tous! Je suis responsable de programme pour WinUI et je reprends cette proposition de @SavoySchuler. Il y a déjà eu beaucoup de discussions et de partages d'idées dans ce fil, merci pour toutes vos suggestions !

Comme cela fait plusieurs mois qu'il n'y a pas eu d'activité ici, je voulais vérifier avec tout le monde et réitérer où nous en sommes actuellement.

En guise de résumé de notre portée actuelle en haut de la proposition :

• La notification servira à alerter l'utilisateur des informations essentielles liées à l'application dans son ensemble
• Prend en charge le contenu et le style personnalisés
• Pourra être automatiquement et programmatiquement rejeté
• La notification doit pouvoir être rejetée par l'utilisateur
• Devrait prendre en charge plusieurs notifications qui peuvent être empilées en fonction de la façon dont l'application a spécifié
• Doit être réactif au redimensionnement de l'application et aux modifications de l'interface utilisateur
• La notification ne sera pas destinée à afficher des notifications à l'échelle du système

N'hésitez pas à commenter et à me faire savoir si j'ai oublié quelque chose dans mon résumé de portée ou si vous n'êtes pas d'accord. Je veux être sûr que nous sommes tous sur la même longueur d'onde avant d'avancer 😊

Maintenant que nous avons défini la portée, il reste quelques scénarios et expériences utilisateur spécifiques qui doivent encore être définis. J'espère que la définition de ces expériences aidera à guider les affordances de l'interface utilisateur pour le contrôle. Que pensez-vous de vos scénarios ?
CC : @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

Les expériences sont :

• Comment la notification quitte la vue
  
  
  
  • L'utilisateur rejette manuellement la notification
  
  
  • La notification expire automatiquement et se ferme d'elle-même
  
  
  • La notification ne disparaît qu'après que l'utilisateur a effectué une action liée à la raison pour laquelle la notification est apparue en premier lieu
    
    
    
    
    
    • c'est-à-dire qu'après avoir reçu une notification indiquant qu'Internet s'est déconnecté, la notification ne disparaît que lorsque l'Internet est déconnecté
    
    
    
  
  
  • Autre?
  
  
• Comment l'utilisateur réagira à la notification
  
  
  
  • Prendre immédiatement des mesures liées à la notification
  
  
  • Reporter leur action liée à la notification à une date ultérieure
  
  
  • Ignorer et/ou rejeter complètement la notification
  
  
  • Autre?
  
  
• Quand la notification apparaîtra
  
  
  
  • Au lancement de l'application
  
  
  • Par programmation à partir de l'état de l'application
  
  
  • Après qu'un utilisateur a effectué une action (c'est-à-dire qu'il a choisi de sauvegarder ses documents)
  
  
  • Autre?
  
  
• S'il est possible d'afficher plusieurs notifications à la fois et pourquoi

Merci encore pour toutes vos pensées et j'ai hâte de mettre cela en lumière!

Content de voir que cette proposition n'a pas été oubliée @gabbybilka et merci de l'avoir acceptée !

Si cela est possible, vous pouvez contacter ceux qui travaillent sur des applications propriétaires qui incluent ces types d'interfaces utilisateur de notification pour établir une liste d'exigences, pour qu'ils passent de leur solution personnalisée à un contrôle natif WinUI. Leurs besoins, combinés aux désirs et aux besoins de la communauté, devraient couvrir suffisamment pour un V1 de ce contrôle.

@chigy serait quelqu'un à qui parler des spécifications de conception finales, car elle travaille avec les équipes de Fluent Design.

Microsoft devrait donner l'exemple avec cela, si d'autres doivent être encouragés à utiliser un contrôle WinUI cohérent.

• Cortana
• Groove Musique
• Cinéma et télévision
• Ton téléphone

Ce sont les applications qui me viennent à l'esprit.

@gabbybilka, nous avons également le contrôle dans la boîte à outils de la communauté Windows , nous sommes ravis d'en parler avec vous à tout moment. Ce serait vraiment génial d'avoir un chemin de mise à niveau pour nos utilisateurs ici et de le migrer de la boîte à outils vers WinUI.

Je pense que d'après votre résumé initial, la plupart des choses sont couvertes, mais pourrait-il être bon d'appeler quelque chose autour d'avoir des boutons optionnels et actionnables également ? Ou serait-ce toujours juste un contenu personnalisé ?

Suivi de la boîte à outils avec un historique du contrôle de la boîte à outils (ça fait un moment):

• Édition originale
• Premier examen des relations publiques
• Historique GitHub - vous ne savez pas comment saisir la liste complète sur une page, alors faites défiler vers le bas et continuez à cliquer sur "Plus ancien"

Les styles de la boîte à outils sont calqués sur les styles de notification Microsoft Edge et VS Code d'origine (qui ont tous deux été mis à jour depuis lors). Mais comme indiqué, il est flexible et peut être modifié et fonctionnerait à la fois pour un avertissement de style Office de barre d'état de niveau supérieur OU pour une notification générale de style pop-up.

Rebonjour! En tant que mise à jour à ce sujet, j'ai récemment présenté à nouveau cette proposition à l'équipe et j'ai reçu le feu vert pour définir davantage cette fonctionnalité.

Pour les scénarios décrits précédemment, nous cherchons à aller de l'avant avec la création d'un contrôle actuellement intitulé InformationBar (InfoBar en abrégé) pour représenter les messages d'état essentiels à long terme à l'échelle de l'application. La conception visuelle initiale s'inspire de la barre de messages de FluentUI et de la façon dont Teams affiche ses messages "Enregistrement en cours" et "Internet déconnecté".
Plus précisément, inclure une icône, un titre, une zone de message flexible et un bouton de rejet en tant que composants visuels principaux et minimum dans un conteneur qui s'adapte par défaut à la largeur de la zone de contenu dans laquelle il réside. l'utilisateur ou par programme lorsque la fonctionnalité de l'application affectant le statut est résolue, c'est-à-dire que la connectivité Internet est restaurée, sans animations d'introduction/de sortie.

Équipes (enregistrement en cours)

Office (mode de compatibilité)

Équipes (pas d'internet)

Au fur et à mesure que l'API commence à se cristalliser, je commencerai à guider la discussion vers la spécification. En attendant , n'hésitez pas à continuer à partager vos scénarios dans lesquels vous utiliseriez une InfoBar et les fonctionnalités dont vous avez besoin 😊

Plus tôt dans la discussion, @mrlacey et d'autres ont évoqué la possibilité d'avoir deux contrôles distincts qui pourraient couvrir les scénarios mentionnés.

Je pense que ces deux concepts:

• une bannière pleine largeur escamotable avec zéro ou plusieurs sous-éléments actionnables
• une bannière destinée à indiquer les changements d'état et qui fonctionne comme un bouton unique

fournira le plus de valeur et le moins de confusion en tant que contrôles séparés.

Je reconnais que le style visuel et les composants d'InfoBar peuvent ne pas convenir à certains des cas d'utilisation précédemment partagés. Si vos scénarios et fonctionnalités d'application spécifiques nécessitent un style visuel différent, n'hésitez pas à continuer à partager ces situations dans ce fil.

Merci encore à tous !

Le contrôle doit être conçu pour bien fonctionner avec les modèles et le style - afin qu'il puisse être adapté aux besoins tandis que tous les comportements sont des propriétés du contrôle.
Animer ou ne pas animer.
Afficher le bouton de fermeture ou le masquer.
Position.
Afficher l'icône ou non.

etc

Je reconnais que le style visuel et les composants d'InfoBar peuvent ne pas convenir à certains des cas d'utilisation précédemment partagés. Si vos scénarios et fonctionnalités d'application spécifiques nécessitent un style visuel différent, n'hésitez pas à continuer à partager ces situations dans ce fil.

Merci encore à tous !

C'est super que ça avance. Ces styles visuels, comme indiqué, laissent beaucoup à désirer au point que je ne voudrais pas utiliser l'application.

Les conceptions publiées par @mdtauk ou les captures d'écran de Cortana ci-dessus seraient bien plus préférables. Les conceptions d'applications doivent aller de l'avant et ne pas être freinées par des programmes.

Cela pourrait-il/pouvait-il également agir comme une barre de commande éliminable comme celles utilisées lors de la présentation/du partage de bureau ? Par exemple

Je sais que cela ne prendrait pas en charge la superposition sur tout, mais en termes de fixation de sa largeur et de mise en place dans une couche de superposition d'une application, je pouvais voir que le chevauchement de la conception/fonctionnalité était similaire dans cette direction.

@mdtauk

Le contrôle doit être conçu pour bien fonctionner avec les modèles et le style - afin qu'il puisse être adapté aux besoins tandis que tous les comportements sont des propriétés du contrôle.
Animer ou ne pas animer.
Afficher le bouton de fermeture ou le masquer.
Position.
Afficher l'icône ou non.

@shaheedmalik

C'est super que ça avance. Ces styles visuels, comme indiqué, laissent beaucoup à désirer au point que je ne voudrais pas utiliser l'application.

Les conceptions publiées par @mdtauk ou les captures d'écran de Cortana ci-dessus seraient bien plus préférables. Les conceptions d'applications doivent aller de l'avant et ne pas être freinées par des programmes.

Merci pour vos commentaires là-bas ! Je conviens que le contrôle doit être suffisamment flexible pour ce comportement de base et cette personnalisation dans le système Fluent Design. Les visuels que j'ai partagés étaient principalement des références d'exemples précédemment implémentés.
Nous continuerons d'essayer de trouver l'équilibre entre la surcharge d'un seul contrôle avec trop de fonctionnalités tout en veillant à ce qu'il soit suffisamment personnalisable et utile pour les différents scénarios de messages d'état à l'échelle de l'application.

Cela pourrait-il/pouvait-il également agir comme une barre de commande éliminable comme celles utilisées lors de la présentation/du partage de bureau ? Par exemple

@michael-hawker

Je pense que c'est un scénario intéressant qui n'a pas encore été évoqué dans le fil et qui pourrait potentiellement être pris en charge par ce contrôle. Merci de l'avoir porté à notre attention ! En ce qui concerne la portée, cela semble être un scénario de moindre priorité, mais je conviens que la conception/fonctionnalité est similaire en dehors de la hiérarchisation de la superposition.

Existe-t-il une mise à jour sur ce problème ? Nous prévoyons actuellement une interface utilisateur pour afficher l'état des opérations sur les fichiers dans Files UWP, la conception vers laquelle nous penchons peut bénéficier d'une telle fonctionnalité proposée ici.

Salut @yaichenbaum , merci pour l'enregistrement ! En tant que mise à jour sur cette proposition, je suis heureux de partager le document de spécification que nous commençons à rédiger.

En résumé de ce qui a été défini jusqu'à présent, nous choisissons de créer un seul contrôle avec deux modes visuels, "Bar" et "Toast" ou "Carte". Nos efforts actuels portent sur la définition et le prototypage du mode "Bar". Les composants de ces deux modes sont les mêmes et ne devraient différer que par la disposition visuelle. Comme il y aura plusieurs modes visuels, je considère actuellement que ce contrôle StatusBanner au lieu d'InformationBar ne se limite pas au seul style "Bar", cependant, n'hésitez pas à partager vos idées pour nommer 😊

Les principaux composants du StatusBanner de gauche à droite dans la mise en page sont :

• Couleur d'état
• Icône
• Titre
• Un message
• Bouton Action
• Bouton Fermer

Ces propriétés sont facultatives et le contenu personnalisé via la propriété "Contenu" est toujours une option.

De plus, nous prévoyons de définir divers types de bannières qu'un développeur peut définir et qui ont des combinaisons d'icônes et de couleurs prédéfinies en fonction du statut. Cela peut simplifier le choix de la bonne icône ou de la bonne couleur de bannière en fonction de la criticité de la notification et fournir une certaine cohérence entre les applications. La personnalisation de l'icône ou de la couleur de la bannière est également prise en charge.

Prototype papier de la StatusBanner en mode "Barre" sans bouton d'action ni bouton de fermeture personnalisé.

La conception actuelle des dispositions de la barre StatusBanner a été fortement inspirée par les conceptions de @mdtauk pour la carte de statut, merci !

Si vous souhaitez partager des commentaires concernant l'état actuel de la spécification, n'hésitez pas à commenter dans ce numéro. Nos prochaines étapes consistent à solidifier les conceptions et les extraits de code (et à les développer pour couvrir davantage de cas d'utilisation) et à définir des fonctionnalités telles que l'empilement et l'emballage des messages. Merci tout le monde!

@yaichenbaum en attendant, il y a le contrôle InAppNotification du Toolkit.

@gabbybilka Merci pour la mise à jour, une fonctionnalité importante dont j'aurai besoin pour mon cas d'utilisation est la possibilité d'afficher plusieurs messages d'état à la fois, tout comme @hawkerm partagé plus tôt dans ce fil. Avoir le contrôle pour gérer le placement de plusieurs messages d'état sera un plus.

@yaichenbaum en attendant, il y a le contrôle InAppNotification du Toolkit.

@hawkerm Je n'ai pas beaucoup regardé le InAppNotification mais je préfère attendre la version WinUI au lieu de passer au nouveau contrôle lorsqu'il est prêt.

Bonjour à tous!
Toutes mes excuses pour le manque de temps entre la dernière mise à jour et maintenant, nous avons travaillé dur pour définir ce contrôle 😊
Vous avez peut-être vu le prototype de @chenss3 fusionner dans le référentiel il y a quelques semaines, nous sommes vraiment ravis de voir cela prendre vie ! À ce stade, nous sommes intéressés à entrer en contact avec tous les consommateurs de ce contrôle qui seraient intéressés par le prototypage et l'utilisation dans leurs applications. Veuillez contacter et partager l'application que vous développez, les scénarios d'utilisation de ce contrôle, si vous avez besoin d'aide pour démarrer et vos commentaires sur l'utilisation du prototype.

Comme nous avons commencé à comprendre les détails de mise en œuvre d'une version contextuelle de ce contrôle avec prise en charge du positionnement et de l'empilement de plusieurs notifications, nous avons décidé de continuer à travailler sur une version en ligne dans un avenir proche . Nous entendons vos commentaires sur l'exigence d'une fonctionnalité contextuelle pour certains de vos scénarios et nous continuerons d'avancer dans cette direction ! En attendant, nous développons notre prochaine version du prototype qui ressemble plus aux maquettes ci-dessous.

Veuillez consulter les spécifications si vous souhaitez voir quelques exemples supplémentaires :

Merci à tous et j'ai hâte d'avoir de vos nouvelles!

Est-ce uniquement disponible dans WinUI 3, ou va-t-il faire partie d'une pré-version de WinUI 2 ?

@kmgallahan WinUI 2 pré-version, pas encore tout à fait sûr de la version exacte du navire, car nous souhaitons recevoir un peu plus de commentaires de la communauté et des clients sur les versions prototype et aperçu.

Pour maximiser les premiers retours, je vous recommande de rendre aussi simple que possible l'essai de prototypes comme celui-ci. Peut-être les pousser dans des versions préliminaires avec des clauses de non-responsabilité, ou fournir des versions de développement/bêta.

Être obligé de créer une branche de développement de WinUI pour essayer des prototypes fournit un bon peu de friction, surtout si vous êtes principalement un consommateur WinUI plutôt qu'un contributeur (à la base de code de toute façon).

D'accord, une fois que le prototype est à l'état solide (ressemblant aux maquettes présentées et avec la prise en charge de différentes options d'entrée), nous aimerions le mettre en aperçu 2.5. Seriez-vous capable/intéressé de l'essayer à ce moment-là ?

Je suis intéressé à l'essayer maintenant, je préfère simplement consommer à partir de NuGet plutôt que d'ajouter un projet massif comme WinUI à ma construction.

Pour l'instant, j'attendrai ce qui en fera un aperçu.

Rebonjour! Quelques mises à jour :

• La spécification a continué d'être revue et itérée. N'hésitez pas à le vérifier sur ce PR et à laisser des commentaires. Un changement notable est l'ajout d'une propriété ActionButton générique qui prendra en charge votre propre contenu qui hérite de ButtonBase.

  • Une incohérence dans les maquettes actuelles que je voudrais souligner est l'emplacement de cet ActionButton. Dans la spécification, le bouton d'action est actuellement affiché comme étant aligné à droite directement à gauche du bouton de fermeture, mais l'emplacement réel sera directement à droite du message. L'image montrée dans mon commentaire précédent et ci-dessous est l'emplacement correct. Les maquettes améliorées continueront d'être mises à jour et ajoutées à la spécification au fur et à mesure du développement 😊

• @teaP a repris la mise en œuvre de la version native de ce contrôle alors qu'il évolue vers une version préliminaire de WinUI 2.5 . Merci!

Comme précédemment, si vous vous considérez comme un utilisateur potentiel de ce contrôle, n'hésitez pas à commenter l'application que vous développez et les scénarios dans lesquels vous utiliseriez la barre d'informations. Merci tout le monde!

Rebonjour! Juste pour souligner, @teaP a récemment ouvert la pull request #3325 pour InfoBar si vous souhaitez le vérifier 😊

Pourquoi s'appelle-t-elle InfoBar ? Les informations ne sont qu'une petite classe d'informations qu'elles peuvent contenir. Il prend également en charge les erreurs et les avertissements ainsi que les actions basées sur ceux-ci. La barre contraint également artificiellement la "forme" du contrôle. Il existe plusieurs autres cas d'utilisation en plus d'un bar.

NotificationView ou MessageView, etc. seraient de meilleurs noms à mon avis.

Pourquoi s'appelle-t-elle InfoBar ? Les informations ne sont qu'une petite classe d'informations qu'elles peuvent contenir. Il prend également en charge les erreurs et les avertissements ainsi que les actions basées sur ceux-ci. La barre contraint également artificiellement la "forme" du contrôle. Il existe plusieurs autres cas d'utilisation en plus d'un bar.

NotificationView ou MessageView, etc. seraient de meilleurs noms à mon avis.

Il a été proposé à l'origine en tant que StatusBanner
Ensuite, il a été changé en InformationBar / InfoBar

La version FluentUI de ce contrôle s'appelle MessageBar

Merci pour le résumé. Le nom n'a toujours pas beaucoup de sens pour moi. La façon dont le contrôle actuel est conçu est comme une notification. Plus généralisé, il devrait s'agir d'un "message" afin qu'il puisse également prendre en charge les scénarios d'aide/d'enseignement. En généralisant les différents concepts, voici une meilleure conception des contrôles :

1. ~ MessageView ~ ou Astuce : Un contrôle pour afficher l'état, un indice ou des informations d'enseignement à l'utilisateur avec une action facultative, un titre, un glyphe, une image et des boutons. Cela peut être placé n'importe où et n'est pas un popup. Il prendrait également en charge différentes mises en page.

2. Conseil d' enseignement : un menu volant/popup hébergeant un MessageView.

   • Conseil hébergé

3. NotificationBar ou StatusTip : notification à l'échelle de l'application au format « barre » en haut de l'application ou de la vue.

   • Conseil hébergé

4. ToolTip : Sera désormais en mesure d'héberger également l'info-bulle qui prendra en charge les actions et les images, etc.

   • Conseil hébergé

Nous devons vraiment penser en termes généraux et combiner des concepts de haut niveau dans les mêmes contrôles. Sinon, nous allons créer de nombreux contrôles très spécialisés avec des propriétés similaires mais différentes.

Idée d'un nom parfait pour un contrôle général 'MessageView' : Appelez-le un 'Tip'. ToolTip pourrait également l'héberger. Mis à jour en conséquence.

Voici un autre exemple "réel" d'une barre de notification en haut de certains champs de saisie. Le contrôle actuel serait utile pour ce scénario :

Voici un autre exemple "réel" d'une barre de notification en haut de certains champs de saisie. Le contrôle actuel serait utile pour ce scénario :

Les zones de texte recevront des états de validation qui pourraient couvrir une partie de cela, mais voici comment je vois les différents contrôles...

• Info -bulle pour un élément unique où l'utilisateur souhaite activement s'identifier ;
• Conseil d' enseignement pour un seul élément que le développeur souhaite que l'utilisateur remarque (peut également être détaché d'un élément) ;
• InfoBar pour l'ensemble de l'application/de la zone de contenu où le développeur souhaite fournir des informations ;
• Flyout/Dialog lorsque le développeur souhaite que l'utilisateur confirme qu'il a lu quelque chose avant de le rejeter ;
• Boîte de dialogue de contenu lorsque le développeur demande à l'utilisateur de faire un choix ou d'entreprendre une action avant tout ;

J'éviterais également d'utiliser le mot Notification car il existe la notification au niveau du système d'exploitation et le centre de notification pour ces

J'éviterais également d'utiliser le mot Notification car il existe la notification au niveau du système d'exploitation et le centre de notification pour ces

Eh bien, je pense que les développeurs connaîtraient la différence, mais c'est certainement un point juste.

Il est également vrai que nous pouvons faire beaucoup de contrôles séparés. Mais il existe certainement des concepts de haut niveau autour de la notification/de l'état/des messages/des conseils/de l'enseignement qui pourraient être combinés. Il faudrait au moins en faire une interface.

Les boîtes de dialogue Flyout/Content sont des concepts distincts car ce sont pour la plupart des contrôles de contenu génériques.

J'ai pensé à un nom parfait pour un contrôle de type "affichage de message" généralisé à héberger dans divers scénarios : appelez-le un "Astuce". J'ai mis à jour mon commentaire ci-dessus en conséquence : https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

J'ai pensé à un nom parfait pour un contrôle de type "affichage de message" généralisé à héberger dans divers scénarios : appelez-le un "Astuce". J'ai mis à jour mon commentaire ci-dessus en conséquence : #913 (commentaire)

Je ne me sentirais pas à l'aise de mettre un message d'avertissement ou d'erreur important dans un conseil ...

Il est également vrai que nous pouvons faire beaucoup de contrôles séparés. Mais il existe certainement des concepts de haut niveau autour de la notification/de l'état/des messages/des conseils/de l'enseignement qui pourraient être combinés. Il faudrait au moins en faire une interface.

Les boîtes de dialogue Flyout/Content sont des concepts distincts car ce sont pour la plupart des contrôles de contenu génériques.

J'aime vraiment cette idée. Je pense qu'il existe des points communs dans les API d'icône, de titre, de message et de bouton d'action qui peuvent être cohérents entre ces contrôles d'informations. Avec InfoBar, je ne sais pas si c'est quelque chose que nous pouvons implémenter dans cette version actuelle mais potentiellement pour notre prochain contrôle de cette nature.

J'ai pensé à un nom parfait pour un contrôle de type "affichage de message" généralisé à héberger dans divers scénarios : appelez-le un "Astuce". J'ai mis à jour mon commentaire ci-dessus en conséquence : #913 (commentaire)

Je ne me sentirais pas à l'aise de mettre un message d'avertissement ou d'erreur important dans un conseil ...

Je suis également d'accord avec cela... plus d'exploration à faire.

J'ai pensé à un nom parfait pour un contrôle de type "affichage de message" généralisé à héberger dans divers scénarios : appelez-le un "Astuce". J'ai mis à jour mon commentaire ci-dessus en conséquence : #913 (commentaire)

Je ne me sentirais pas à l'aise de mettre un message d'avertissement ou d'erreur important dans un conseil...

Je suis également d'accord avec cela... plus d'exploration à faire.

Pensez à la façon dont il s'intègre à tous les contrôles et idées existants - c'est parfait à cet égard. Mais oui, cela ne semble pas à sa place dans le contexte des erreurs/avertissements. Je pense que les gens le comprendraient rapidement, mais je ne peux pas contester cette logique.

Pourquoi s'appelle-t-elle InfoBar ? Les informations ne sont qu'une petite classe d'informations qu'elles peuvent contenir. Il prend également en charge les erreurs et les avertissements ainsi que les actions basées sur ceux-ci. La barre contraint également artificiellement la "forme" du contrôle. Il existe plusieurs autres cas d'utilisation en plus d'un bar.

NotificationView ou MessageView, etc. seraient de meilleurs noms à mon avis.

Je suis d'accord avec votre point de vue selon lequel l'InfoBar n'est peut-être pas toujours une barre, mais je pense que l'inclusion de "bar" dans le nom implique qu'elle est destinée à des scénarios à l'échelle de l'application, à la fois visuellement et conceptuellement. En recherchant des images de "barre d'informations", vous trouvez des images d'expériences similaires d'IE (pas que nous essayons nécessairement de faire correspondre IE) et je pense que cela évoque la disposition visuelle et fonctionnelle attendue. Je ne vois pas cela comme une "vue", mais j'aime l'accent mis sur le message ou la notification.

@gabbybilka Oui, c'est assez similaire à l'ancienne StatusBar ou à la nouvelle AppBar... CommandBar... etc. "View" ne correspond pas non plus à 100 %, mais il est plus proche d'un nom général. Vraiment, mon souci est d'unifier les concepts sous-jacents afin que nous ne nous retrouvions pas avec plusieurs contrôles faisant des variations de la même chose.

Modifié pour m'être embrouillé avec plusieurs commentaires à deux endroits.

Faisant écho aux pensées que j'ai postées dans l'un des autres numéros...

_Réponse au fait qu'un mode flottant pour la commande n'est plus envisagé pour V2_
Je peux comprendre que le changement de comportement et de forme vous inciterait à vous tourner vers l'astuce pédagogique comme alternative, mais je suggérerais que le manque de sévérité, la couleur du statut et la conception de l'astuce pédagogique elle-même - ne seraient pas compatibles avec le même type de messages auxquels le contrôle InformationBar répond.

La largeur de l'écran et les différences dans les dispositions de l'interface utilisateur entre une application WinUI plein écran, une fenêtre à largeur étroite et des choses comme Hololens et Xbox - ne se prêteraient pas à un facteur de forme de barre ancrée.

Donc, dans cet esprit, peut-être que la barre d'informations devrait être enveloppée, avec un contrôle InformationCard dans une API AppMessage - afin que les mêmes propriétés de gravité, couleur, titre, message, boutons d'action, etc. puissent être placées dans le XAML, ou dans le le code de l'application - et la façon dont ils sont présentés à l'écran changent pour s'adapter au facteur de forme/à la famille d'appareils.

Un conseil d'enseignement non attaché pourrait intervenir, mais il ne prendrait pas en charge les personnalisations adaptées aux messages d'état de l'application - ce qui est l'intention initiale derrière ce contrôle.

Et si nous avions un « conseil » qui n'est en fait qu'un message. Il a un glyphe, des images, un texte de message, un titre.

Ensuite, en dérivant de Tip, nous avons AppMessage qui ajoute de la gravité, des actions et des choses. Tip serait alors toujours utilisable dans TeachingTip et ToolTip tels qu'ils existent aujourd'hui. ce serait également utile dans mon scénario pour les conseils contextuels en ligne.

Et si nous avions un « conseil » qui n'est en fait qu'un message. Il a un glyphe, des images, un texte de message, un titre.

Ensuite, en dérivant de Tip, nous avons AppMessage qui ajoute de la gravité, des actions et des choses. Tip serait alors toujours utilisable dans TeachingTip et ToolTip tels qu'ils existent aujourd'hui. ce serait également utile dans mon scénario pour les conseils contextuels en ligne.

TeachingTip without a Tail semble parfait pour votre situation...

TeachingTip without a Tail semble parfait pour votre situation...

Je ne savais pas que vous pouviez faire cela avec TeachingTip. De plus, mon contrôle existe depuis bien plus longtemps que TeachingTip, donc je n'ai jamais vraiment cherché à le mettre à niveau jusqu'à présent. Quoi qu'il en soit, si vous pouvez le faire, c'est un oubli de ma part.

Edit: Peu importe, même sans queue, c'est toujours une superposition qui est rejetée d'une manière ou d'une autre. L'indice que je décris est entièrement en ligne et persiste jusqu'à ce que l'utilisateur crée essentiellement le premier élément. Il s'agit simplement d'un contrôle qui présente des informations - pas dans une fenêtre contextuelle, un menu volant ou une autre vue non persistante.

Je suis toujours convaincu qu'il y a beaucoup de points communs à décomposer en interfaces/contrôles utilisés à plusieurs endroits. Tous ces contrôles dont nous discutons ont beaucoup plus de similitudes que de différences. C'est seulement où/comment l'information sous-jacente est présentée qui change. Tout cela est mûr pour la simplification.

TeachingTip without a Tail semble parfait pour votre situation...

Je ne savais pas que vous pouviez faire cela avec TeachingTip. De plus, mon contrôle existe depuis bien plus longtemps que TeachingTip, donc je n'ai jamais vraiment cherché à le mettre à niveau jusqu'à présent. Quoi qu'il en soit, si vous pouvez le faire, c'est un oubli de ma part.

Je suis toujours convaincu qu'il y a beaucoup de points communs à décomposer en interfaces/contrôles utilisés à plusieurs endroits. Tous ces contrôles dont nous discutons ont beaucoup plus de similitudes que de différences. C'est seulement où/comment l'information sous-jacente est présentée qui change. Tout cela est mûr pour la simplification.

Lorsque vous le décomposez, il ne s'agit que d'une icône et d'un texte, et aucun "contexte" n'y est associé. Mais ma suggestion de l'envelopper dans un AppMessage pourrait inclure des Conseils d'enseignement non attachés comme une autre forme d'interface utilisateur, je suppose.

Lorsque vous le décomposez, il ne s'agit que d'une icône et d'un texte, et aucun "contexte" n'y est associé. Mais ma suggestion de l'envelopper dans un AppMessage pourrait inclure des Conseils d'enseignement non attachés comme une autre forme d'interface utilisateur, je suppose.

Désolé, voir ma modification ci-dessus. La pointe d'enseignement n'est toujours pas en ligne et flotte juste en bas jusqu'à ce qu'elle soit rejetée. Il y a aussi une image et un titre à considérer.

Lorsque vous le décomposez, il ne s'agit que d'une icône et d'un texte, et aucun "contexte" n'y est associé. Mais ma suggestion de l'envelopper dans un AppMessage pourrait inclure des Conseils d'enseignement non attachés comme une autre forme d'interface utilisateur, je suppose.

Désolé, voir ma modification ci-dessus. La pointe d'enseignement n'est toujours pas en ligne et flotte juste en bas jusqu'à ce qu'elle soit rejetée.

Il n'est pas nécessaire d'être en bas.

Inline est peut-être un cas d'utilisation inhabituel pour un indice, car il déplacerait d'autres contenus autour de lui.

Vous pouvez suggérer qu'une V2 ajoute la prise en charge d'un mode d'affichage en ligne/non flottant

Pour donner un peu plus de contexte au commentaire de @mdtauk , voici ma réponse initiale à sa question concernant la suppression du mode flottant de la section "Fonctionnalités prévues pour InfoBar V2" dans la spécification.
De moi:

Sauter ici pour la discussion sur la conception. Bon œil sur le fait que les fonctionnalités prévues pour la V2 changent 😉 Pour le moment, nous ne nous engageons pas sur le mode flottant pour InfoBar dans une version V2 pour plusieurs raisons. J'aimerais explorer plus avant si le mode flottant _devrait_ être dans une barre d'informations ou si les notifications de type toast devraient être un contrôle complètement différent. En enquêtant, nous avons réalisé qu'une implémentation de base du mode flottant serait incroyablement similaire à Teaching Tip et que pour explorer pleinement les fonctionnalités de scénarios de notification de type toast comme l'empilement, le positionnement et les choix de superposition (voir WCT InAppNotification's StackMode ) sont probablement nécessaires. Cela élargirait la portée et l'intention de l'InfoBar pour qu'elle soit beaucoup plus large que son objectif initial. À noter, nous n'avons pas complètement fermé la porte à l'ajout de fonctionnalités flottantes à InfoBar, mais nous penchons vers non.

Pour la proposition InformationBar et InformationCard basée sur une classe AppMessage de base, j'aime cette idée. Vous avez mentionné que "la façon dont ils sont présentés à l'écran changerait pour s'adapter au facteur de forme/famille d'appareils" que je voudrais explorer plus en profondeur. Je pense qu'il existe des scénarios mieux adaptés à la carte UX (en particulier les messages transitoires, les messages d'erreur spécifiques à la page et les applications sans surfaces ancrables) que la barre UX et vice versa.

Pour moi, il existe à la fois des différences dans le « quand » utiliser une InfoBar/InfoCard/Conseil pédagogique (lié aux besoins visuels et fonctionnels) ainsi que le « pourquoi » à utiliser (basé sur la perception de l'utilisateur final et la cohérence de l'expérience). Les messages transitoires sont un point fort pour moi en tant que quelque chose qui devrait être pris en charge par une InfoCard et non pris en charge par une InfoBar. Les messages pouvant être ignorés par les non-utilisateurs sont un exemple du contraire, car le contenu superposé persistant est difficile à prendre en charge du point de vue de l'accessibilité.

Ne vous laissez pas distraire cependant :) Tous ces différents contrôles présentent, pour la plupart, le même type d'informations - juste dans des domaines/styles différents. Cela doit être généralisé et unifié. Je pense que nous pouvons unifier autour d'un contrôle commun 'AppMessage' si vous voulez l'appeler ainsi. Ensuite, ayez simplement différents conteneurs pour présenter cet 'AppMessage' de différentes manières. Il peut être présenté dans un TeachingTIp, un ToolTip, un NotificationBar, comme une carte quelque part, etc. Chaque conteneur peut modifier le style pour s'adapter à son cas d'utilisation. Les propriétés et les types sous-jacents seraient cependant unifiés.

Je n'essayais pas de mal interpréter le contexte avec la réponse de @gabbybilka 😄

Pour la proposition InformationBar et InformationCard basée sur une classe AppMessage de base, j'aime cette idée.

C'est là que la dénomination entre en jeu. J'aime bien "AppMessage" ("Astuce" serait génial, car il semblerait que ce soit le plan depuis le début), mais si nous y allons, ce devrait être "MessageBar" et "MessageCard" hébergement ce.

Pour moi, il existe à la fois des différences dans le « quand » utiliser une InfoBar/InfoCard/Conseil pédagogique (lié aux besoins visuels et fonctionnels) ainsi que le « pourquoi » à utiliser (basé sur la perception de l'utilisateur final et la cohérence de l'expérience).

Je suis définitivement d'accord avec ces différents cas d'utilisation et présentations. Cependant, ils présentent toujours un message qui peut être généralisé et standardisé. Je pense que nous sommes tous d'accord sur ce concept maintenant :)

Exemple de message de carte/pourboire

Je pense que l'un des objectifs devrait être d'encourager les applications de boîte de réception et de première partie/Windows Shell à s'éloigner de leurs solutions personnalisées pour utiliser un contrôle/API de boîte de réception cohérent

Je devrais probablement ajouter que dans une application UWP, je travaille sur certains de ces concepts qui étaient déjà unifiés. La version simplifiée pertinente pour cette discussion est :

Il existe une classe 'Message' (ce n'est pas un contrôle, seulement une structure de données) avec les propriétés suivantes :

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

La priorité est fondamentalement la même que ce que vous avez déjà décidé (c'est assez standardisé de nos jours). DisplayMode prend en charge Notification, None et Popup. Lorsqu'un message est généré par le code back-end, il est transmis au front-end qui l'affichera en conséquence soit sous forme de notification rapide dans une "barre" en haut de l'application à rejeter. Ou comme popup de blocage pour les messages plus sévères.

De plus, il existe un contrôle 'MessageView' qui prend un message par lui-même mais ajoute un glyphe et un titre et le présente comme le 'Hint' contextuel en ligne dont nous avons déjà parlé.

C'est exactement ce que je proposerais : Faites l'abstraction sur la couche App. Ayez une classe ViewModel simple que vous pouvez attacher à l'une ou l'autre vue. C'est simple à faire et plus flexible. Peut-être souhaitez-vous également effectuer la journalisation avec votre infrastructure de journalisation préférée, vous souhaitez avoir des priorités personnalisées, vous souhaitez ajouter vos propres données. Tout est facile à faire dans votre ViewModel.

L'intention des contrôles que vous avez mentionnés est de fournir une manière unifiée de réaliser certains scénarios, dans de nombreuses applications et cas d'utilisation du système d'exploitation, au lieu que chaque application soit livrée avec une interface utilisateur et un comportement légèrement différents. Les info-bulles et la barre d'informations/barre de messages sont des concepts bien connus, tant pour les développeurs que pour l'utilisateur final. Bien que les deux présentent des informations, ils sont utilisés pour des choses très différentes. Je ne vois pas beaucoup d'avantages à avoir une classe de base commune ou un concept commun pour ceux-ci. Pourquoi voudriez-vous mettre un message dans une info-bulle, qui est déjà affichée dans la barre d'informations globale de l'application (et où joignez-vous cette info-bulle) ? Ce n'est pas comme si cela conduirait à beaucoup de réutilisation.

Il existe d'autres domaines où des concepts communs seraient beaucoup plus utiles à l'OMI. Pensez à Button, AppBarButton, MenuItem. Tous ces éléments affichent du texte et une icône, tous sont utilisés pour déclencher une action. Souvent, vous fournissez les mêmes commandes à la fois dans un MenuItem (ContextMenu) et dans une AppBar/CommandBar. Ici, un concept commun serait très utile, où vous pourriez mettre votre commande, texte, icône, peut-être aussi un long message (info-bulle). Mais avoir un concept commun pour ToolTip et MessageBar ? Je ne vois vraiment pas la nécessité de cela. Bien sûr, si nous avions réécrit UWP à partir de zéro, nous aurions peut-être trouvé une classe de base commune. Mais je ne pense pas que ce soit nécessaire ou trop utile.

@lukasf Vos points ont du sens ; cela peut être fait dans l'application elle-même. Cependant, il existe de nombreux concepts très similaires et tout le monde peut bénéficier d'une unification ici.

ToolTip a été lancé dans la discussion car il pourrait être avantageux d'avoir un glyphe et un titre avec un message. Conceptuellement, tous ces contrôles sont également des messages d'une certaine forme - seuls l'endroit et la manière dont ils sont affichés sont différents. Même si nous ne procédons pas à une grande standardisation, une MessageBar et une MessageCard nécessiteraient toujours de nombreuses propriétés/types partagés. Nous ne voulons pas avoir MessageBarPriority avec les enems MessageCardPriority. Il faut encore réfléchir pour s'assurer que même les types de base sont à l'épreuve du temps.

Combiner tout cela avec des idées existantes dans l'Astuce Pédagogique me semble tout à fait logique. Je suis sûr que la direction à suivre aurait du sens avec une comparaison côte à côte de tous les contrôles mentionnés et de leurs propriétés. Si j'ai le temps, je ferai la comparaison moi-même.

Vos commentaires sur Button/AppBarButton/etc. sont un exemple parfait de la pensée que nous ne voulons pas faire proliférer. Microsoft prend l'habitude de créer plusieurs contrôles similaires mais différents sans perdre de temps/d'efforts pour les rendre cohérents. Ce long terme n'est pas bon pour un cadre de quelque sorte que ce soit pour un certain nombre de raisons.

J'ai mis en place une comparaison des commandes de messagerie. Je vais le donner en consultation gratuite car c'est tellement difficile qu'il est :)

C'est le genre de documentation de comparaison et de stratégie de haut niveau que je m'attendrais à voir créée en interne chez Microsoft. Si c'était moi-même qui dirigeait les revues de spécifications/conception, j'exigerais ces types d'analyses ou personne ne peut s'attendre à partir avec l'approbation. Il est absolument important de :

1. Combler les écarts de compréhension entre les membres de l'équipe
2. Surmonter les « silos » qui se produisent dans les grandes équipes et organisations
3. assurer une direction future cohérente du cadre afin que les fonctionnalités futures puissent être ajoutées sur une bonne base (le plus important)

Microsoft a en quelque sorte perdu ces principes d'ensemble après WPF et il semble qu'il n'y ait plus de vision "de plus haut niveau" de la part des dirigeants dans cet espace. Quoi qu'il en soit, je ne suis pas au courant des discussions internes, j'espère donc qu'il y a beaucoup plus de planification en interne avec des personnes qui ont beaucoup d'expérience et une longue histoire des principes avec XAML.

Cela dit, n'hésitez pas à déchirer le document ci-dessous. C'est la discussion elle-même qui est la plus importante.

MessageControlComparison 20200929.xlsx

Merci pour le document de comparaison, très cool de voir vos réflexions sur les contrôles d'informations de manière globale ! Deux sujets principaux sur lesquels je souhaite poursuivre la discussion sont les suivants : 1. Pourquoi _ne devrait-il pas_ y avoir des API/propriétés/fonctionnalités différentes entre l'Astuce pédagogique et la barre d'informations ? et 2. Quelle serait la différence entre une InfoBar et une InfoCard si l'InfoCard n'était pas une Popup comme indiqué dans le document de comparaison ?

Pour la première question, je peux mettre en évidence les décisions de conception prises sur les éléments en texte rouge et fournir un peu plus de clarté :

• TeachingTip Subtitle vs InfoBar Message : Fonctionnellement, oui, ils sont identiques ! Il s'agit du message secondaire avec du texte non gras dans ces contrôles. Dans un conseil d'enseignement, ce message s'affichera toujours sous le titre et sera logiquement nommé en tant que sous-titre. Pour InfoBar, ce message sera le plus souvent en ligne et directement à droite du titre, ce qui, conceptuellement, n'a pas autant de sens qu'un sous-titre.
• TeachingTip HeroContent vs InfoBar Content : Teaching Tip a à la fois HeroContent et Content tandis que InfoBar n'a que Content. La propriété HeroContent est unique à Teaching Tip en raison de sa prise en charge de ces images plus grandes pour faciliter l'enseignement. InfoBar ne prend pas explicitement en charge les images car il se concentre sur une disposition horizontale. La propriété Content des deux contrôles concerne le contenu personnalisé supplémentaire et se trouve en dessous du reste des éléments de l'interface utilisateur dans les deux.
• Astuce d'enseignement stratégie de bouton vs stratégie de bouton InfoBar : les principales différences ici sont que InfoBar prend en charge plus de types de boutons en dehors du "bouton" classique et qu'il n'encourage pas la personnalisation du bouton de fermeture pour inclure du texte.
  
  
  
  • Un scénario courant pour les InfoBars consiste à inclure un bouton de lien hypertexte. En raison du contraste des couleurs avec la couleur de premier plan du bouton d'hyperlien par défaut et nos couleurs d'arrière-plan de différentes couleurs, nous voulions nous assurer que nous pouvions appliquer notre propre style personnalisé à tous les boutons d'hyperlien inclus dans la barre d'informations afin qu'ils restent accessibles.
  
  
  • Nous avons décidé de ne pas inclure la personnalisation du bouton de fermeture (au texte, il existe toujours une propriété CloseButtonStyle pour faire un style léger si vous le souhaitez) à l'InfoBar après nos révisions de conception pour garantir que l'accent reste sur le texte inclus et l'action unique. Dans le même ordre d'idées, comme mentionné dans la spécification, nous pensons à une ActionContentArea dans la V2 pour prendre en charge plus d'un bouton d'action ici et pourrions étudier la possibilité d'activer à nouveau la personnalisation du bouton de fermeture.
  
  
• InfoBar IsClosable & IsIconVisible : l'astuce d'enseignement n'a pas IsClosable car une astuce d'enseignement doit toujours pouvoir être fermée car il s'agit d'une fenêtre contextuelle et affiche des informations non bloquantes/urgentes. Il n'a pas non plus IsIconVisible car une icône n'apparaît pas avec son style par défaut, ce qu'InfoBar fait via les différents niveaux de gravité. Nous voulions fournir un moyen pour un développeur de supprimer l'icône fournie s'il le souhaitait. Nous avons essayé de définir IconSource sur null, ce qui a provoqué de nombreux bogues géniaux et simplifié via la propriété IsIconVisible.

Est-ce que cela a du sens ? Je pense que les deux contrôles ont des objectifs différents et que les différences de fonctionnalité reflètent cela. J'espère que ces explications et ces justifications de conception ont été utiles !

Modifier pour les problèmes de formatage et de faute de frappe😊 x2

Je ne préconiserais pas l'harmonisation entre ces contrôles directement, car il est justifié que ces contrôles fassent leur propre chose dans leurs propres contextes.

Cependant, la création d'une API In App Messaging, qui agit comme une structure unificatrice, mais peut s'adapter au facteur de forme, ne nécessite pas de modifications des contrôles.

Il y a des questions à discuter et des réponses pour ce type d'API :

• Devriez-vous/comment, en tant que développeur, pouvez-vous spécifier le type de contrôle qu'un appel de message affiche à l'écran ?
• Si vous ne spécifiez pas de type de contrôle, l'API prend-elle les propriétés données et "choisit-elle" la plus appropriée ?
• Comment feriez-vous passer les choix comportementaux aux contrôles sous-jacents ?
• Quels facteurs de forme seraient prioritaires en fonction de l'adéquation de la plate-forme ?

Et surement bien d'autres auxquelles je n'ai pas pensé lol

Prendre Xbox comme plate-forme
Les méthodes de saisie sont très différentes, tout comme la taille/la mise à l'échelle de l'écran.

Les barres d'informations pleine largeur devraient prendre en compte le surbalayage sur les bords de l'écran, et donc pour ces applications, une carte d'informations peut être plus appropriée.

Mais comment géreriez-vous le licenciement ?

Pas de curseur à déplacer sur un bouton de fermeture, mais voulez-vous que la carte prenne en charge les entrées du contrôleur ? Cela le rend modal. Mais alors, s'il est superposé au contenu, comment le sélectionner et lui donner le focus ?

Alors, apparaît-il en ligne et pousse-t-il le contenu vers le bas, mais n'est-il pas en pleine largeur ?

De plus, la Xbox a son propre système de notification de type toast, alors cette API devrait-elle / devrait-elle fonctionner avec cela ? Peut-il fonctionner avec ou est-ce uniquement le système ?

1. Pourquoi l'astuce pédagogique et la barre d'informations ne devraient-elles pas avoir des API/propriétés/fonctionnalités différentes ?

L'objectif doit toujours être de fournir des API communes pour les mêmes choses. Toute cette discussion porte sur les messages destinés aux utilisateurs en général et plusieurs similitudes sont apparues une fois que cela a été compris. Il est incontestable que les cas d'utilisation de TeachingTip et d'un contrôle de type MessageBar sont différents. Fondamentalement, l'un présente un message et l'autre un conseil également. Je ne remets pas en question les choix de conception globaux ici. Cependant, il y a BEAUCOUP plus de similitudes que de différences avec ces contrôles. Regardez simplement le design : ils ont tous une icône, un titre, un sous-titre, un contenu, un bouton d'action et un bouton de fermeture (pourtant vous les avez nommés différemment et il y a une surface d'API différente). Si vous ne voyez pas pourquoi c'est une bonne idée de normaliser au moins la dénomination et les énumérations ici, je ne peux rien dire de plus. C'est juste quelque chose de fondamental pour une bonne architecture.

Pour les boutons, les deux contrôles prennent en charge un bouton d'action et un bouton de fermeture. Mais vous l'avez fait de manière complètement différente. Vous avez expliqué certaines raisons ci-dessus, mais nous avons maintenant une API "laide" pour utiliser des boutons dans des situations comme celle-ci. Pourquoi ne pas généraliser cela maintenant afin d'avoir quelque chose de bon pour l'avenir ? Des boutons comme celui-ci s'appliquent à plusieurs contrôles : ContentDialog, TeachingTip, InfoBar et qui sait quoi ensuite. Nous continuons à concevoir en pensant uniquement au contrôle actuel - mauvaise architecture !

Pour le texte du message ou du conseil, l'un s'appelle Subtitle et l'autre Message fondamentalement, ils peuvent être les mêmes, pourquoi différents termes sont-ils utilisés si ce n'est que différents chefs de projet travaillent sur ces contrôles ?

Dans l'ensemble, ne serait-il pas utile pour les développeurs que les commandes fonctionnent de la même manière ? Oui bien sûr! Cela signifie-t-il qu'il y aura le même contrôle sous tout cela ? Pas nécessairement, mais nous devrions utiliser les mêmes noms de propriétés, les mêmes concepts de boutons d'action et les mêmes types. J'espère toujours que nous pourrions avoir une structure de message ou une interface utilisée pour tout relier. Ne serait-il pas formidable de simplement définir un message dans la MessageBar et de l'afficher au lieu d'avoir à définir manuellement toutes ces propriétés ?

Quelle serait la différence entre une InfoBar et une InfoCard si l'InfoCard n'était pas une Popup comme indiqué dans le document de comparaison ?

Ma conclusion finale de la comparaison est que MessageBar/MessageCard devrait être le même contrôle et également prendre en charge le cas d'utilisation de mon exemple d'astuce ou d'astuce en ligne grâce à la personnalisation du style.

• Il est possible d'unifier MessageBar/MessageCard et Tip en un seul contrôle. La seule préoccupation est la différence conceptuelle entre « message » et « astuce ».
• Devrait être le même contrôle sous-jacent, le style doit cependant être hautement personnalisable pour prendre en charge les deux cas. La seule préoccupation est la différence conceptuelle entre « message » et « astuce ». Le design est extrêmement similaire.

Edit : Dans l'ensemble, je pense que ma préoccupation fondamentale est que nous avons en quelque sorte reculé dans la pensée architecturale. La conception des contrôles est désormais effectuée comme si c'était l'époque des Windows Forms. Les nouveaux contrôles UWP doivent être basés sur les concepts WPF. Les contrôles deviennent hautement spécialisés et je ne vois pas les fils unificateurs couvrant le cadre qui ont vraiment "épaté" les développeurs qui ont touché WPF pour la première fois. Nous devons revenir à la mentalité "grande image" à mon avis.

Je suis d'accord à 100% avec @robloo que les noms de propriété et les noms d'énumération pour des choses similaires doivent être alignés (dans la mesure du possible) avec les contrôles existants. Des contrôles similaires doivent avoir une surface d'API similaire. Si une classe MessageCard devait être ajoutée ultérieurement (au lieu d'étendre MessageBar, ce que je préférerais personnellement), elle devrait au moins avoir une API très similaire à MessageBar.

Il existe d'autres domaines où des concepts communs seraient beaucoup plus utiles à l'OMI. Pensez à Button, AppBarButton, MenuItem. Tous ces éléments affichent du texte et une icône, tous sont utilisés pour déclencher une action. Souvent, vous fournissez les mêmes commandes à la fois dans un MenuItem (ContextMenu) et dans une AppBar/CommandBar. Ici, un concept commun serait très utile, où vous pourriez mettre votre commande, texte, icône, peut-être aussi un long message (info-bulle).

@lukasf Connaissez -vous la classe XamlUICommand ? Cela vous permet de regrouper ces propriétés en un seul endroit, puis de les affecter à votre Button/MenuItem/.... en passant simplement votre XamlUICommand défini à l'API Command de ces contrôles.

@Felix-Dev Oui, vous avez raison. J'ai failli oublier ça. Je ne l'utilise pas car il n'était pas disponible dans WinUI lorsque je l'ai essayé la dernière fois, mais aussi parce que ce n'est pas une solution complète. AppBar et ContextMenu ont plus que de simples liens de commande. Pour une solution complète, nous aurions besoin de :

• XamlUICommandXamlUICommand
• XamlToggleUICommandXamlToggleUICommand
• XamlUICommandSubItem (sous-menu / flyout)
• XamlUICommandSeparatorXamlUICommandSeparator

Il manque également une propriété "Visible" et/ou une propriété "HideIfDisabled".

Ensuite, nous aurions besoin d'un ItemsSource sur MenuFlyout et AppBar/CommandBar et des contrôles similaires. Le contrôle de niveau supérieur créerait alors les sous-contrôles correspondants pour chaque élément de commande.

Ce n'est que lorsque tout cela était en place que nous pouvions avoir une collection de commandes dans notre application et les lier à MenuBar, ContextMenu, AppBar, NavigationView. Mais dans l'état actuel des choses, je dois conserver une liste de classes définies personnalisées, implémenter et utiliser manuellement des éléments tels que DataTemplateSelectors et d'autres solutions de contournement ennuyeuses, juste pour que la même définition de commande fonctionne à différents endroits.

XamlUICommand était un bon début, mais ce n'est pas une histoire complète.

Toutes mes excuses pour mon retard de réponse ici, @robloo merci d'avoir partagé votre point de vue et le tableau de comparaison d'il y a quelques semaines. J'apprécie vraiment toutes les réflexions et considérations visant à améliorer WinUI ! 😊

Dans InfoBar et sur toute la plate-forme, je pense que lors de la conception, nous nous efforçons de trouver le bon équilibre pour que les contrôles soient spécialement conçus pour des scénarios spécifiques en tant que modèle d'interface utilisateur défini - tout en étant suffisamment génériques et personnalisables pour s'étendre aux scénarios que nous n'avons pas encore identifié. En tant que nouveau membre de l'équipe, j'aimerais savoir pourquoi les contrôles WinUI devraient revenir aux concepts WPF. À quels problèmes quotidiens vous et les autres développeurs UWP êtes-vous confrontés lorsque des contrôles conceptuels similaires n'ont pas la même structure sous-jacente ? Quels sont les avantages pour vous afin que nous puissions mieux comprendre pourquoi nous devrions consacrer des ressources à la création de cette structure ? Y a-t-il d'autres contrôles dans WinUI qui gagneraient à être unifiés (je vois la conversation sur les boutons ci-dessus de @lukasf) Je pense que nous pouvons également poursuivre cette conversation dans un nouveau problème général s'il existe un domaine dans lequel nous pouvons modifier les contrôles existants / les approches de remue-méninges pour futurs contrôles. @SavoySchuler pour toute entrée ici.

Pour InfoBar, je ne prévois toujours aucun changement car il passe en aperçu à partir de cette conversation. Pour les API Action Button et Close Button en particulier, si des besoins spécifiques ne sont pas satisfaits, veuillez nous en informer afin que nous puissions évaluer tout changement potentiel. Je pouvais anticiper une classe ou une interface de base AppMessage commune à implémenter avec une v2 en association avec un contrôle InfoCard ou en tant que DisplayMode séparé pour activer la fonctionnalité de mise en page variable 'Auto' @mdtauk évoquée plus tôt. De plus, l'équipe WinUI ne voit pas encore l'intérêt d'aligner davantage les conseils d'enseignement et la barre d'informations pour le moment, mais nous pouvons poursuivre la conversation ici pour résoudre ce problème si certains besoins d'utilisation ne sont pas satisfaits. Une fois qu'InfoBar passe en préversion et peut être implémenté dans des applications, tout scénario spécifique ou retour d'utilisation serait formidable à entendre avant la sortie officielle.

En règle générale, si vous avez des scénarios qui correspondent à l'intention d'une InfoBar et que certains aspects de sa fonctionnalité ou de sa conception visuelle ne répondent pas à vos besoins, veuillez nous en informer lors de la prévisualisation. Merci encore pour tous vos commentaires et échanges !

Dans InfoBar et sur toute la plate-forme, je pense que lors de la conception, nous nous efforçons de trouver le bon équilibre pour que les contrôles soient spécialement conçus pour des scénarios spécifiques en tant que modèle d'interface utilisateur défini - tout en étant suffisamment génériques et personnalisables pour s'étendre aux scénarios que nous n'avons pas encore identifié. En tant que nouveau membre de l'équipe, j'aimerais savoir pourquoi les contrôles WinUI devraient revenir aux concepts WPF. À quels problèmes quotidiens vous et les autres développeurs UWP êtes-vous confrontés lorsque des contrôles conceptuels similaires n'ont pas la même structure sous-jacente ? Quels sont les avantages pour vous afin que nous puissions mieux comprendre pourquoi nous devrions consacrer des ressources à la création de cette structure ? Y a-t-il d'autres contrôles dans WinUI qui gagneraient à être unifiés (je vois la conversation sur les boutons ci-dessus de @lukasf) Je pense que nous pouvons également poursuivre cette conversation dans un nouveau problème général s'il existe un domaine dans lequel nous pouvons modifier les contrôles existants / les approches de remue-méninges pour futurs contrôles. @SavoySchuler pour toute entrée ici.

L'intérêt d'avoir une structure est que les programmeurs puissent coder plus rapidement avec moins d'erreurs afin d'avoir un code de haute qualité.

Parce qu'une grande partie de Microsoft sont des équipes cloisonnées, dans de nombreux cas, il existe plusieurs façons de faire quelque chose, mais aucune unification desdites procédures, ce qui entraîne une redondance et tente de réparer quelque chose qui est déjà corrigé.

Après la création de WPF, Microsoft est entré dans un état d'esprit "c'est assez bon", cela s'exprime directement dans la qualité des applications, même des propres équipes de Microsoft. Si les propres applications de boîte de réception de Microsoft ne peuvent pas accéder à la même page avec une cohérence uniforme de haute qualité dans le code et l'uniformité des applications, comment pouvons-nous nous attendre à ce que les partenaires tiers fournissent cela ?

Fournir des résultats de code génériques mais personnalisables dans des applications de base génériques. La plupart des développeurs ne feront pas d'efforts supplémentaires pour rendre leur application fonctionnelle et raffinée, ils en feront juste assez pour rendre leur application fonctionnelle. Ce niveau de "faire assez pour le rendre fonctionnel" est perçu par l'utilisateur final comme "à moitié le faire".

À mon avis, le but des contrôles est d'avoir un code de haute qualité que vous pouvez simplement utiliser, et vous pouvez le personnaliser si vous le souhaitez.

Donner aux développeurs des options sur la façon dont ils utilisent les contrôles a également ses avantages, au lieu de les verrouiller dans une seule façon de gérer la messagerie et les notifications.

Mais s'assurer que quelle que soit l'option qu'ils choisissent, ressemble et se comporte de manière familière, et "appartient" à Fluent Design - a l'avantage de la cohérence.

Donc, si les contrôles eux-mêmes dans WinUI ne fournissent pas une approche unifiée, peut-être que Windows Toolkit pourrait créer une API d'assistance qui le gère.

Je vous suggère de le proposer dans ce référentiel, et il peut utiliser les contrôles WinUI pour le présenter dans l'application

Bonjour à tous, en tant que mise à jour, le contrôle InfoBar est maintenant en avant-première 🎉 Si vous avez une application qui bénéficierait de ce contrôle, veuillez l'essayer et partager vos commentaires avec nous.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
Merci pour tout votre engagement jusqu'à présent pour ce contrôle !

Voici un autre exemple de barre d'information/boîte/carte

Edit : Je viens de réaliser que le problème ci-dessous est déjà résolu par https://github.com/microsoft/microsoft-ui-xaml/issues/3581. Veuillez ignorer le problème ci-dessous. Merci d'avoir fait le contrôle ! Il a fière allure dans Nightingale :)

@gabbybilka Je vais utiliser la barre d'informations dans mon application client Nightingale REST. C'est parfait pour un de mes scénarios. Lors de mes tests rapides, il semble que l'icône dans la barre d'informations ne supporte pas le thème clair ? Ou peut-être que je fais quelque chose de mal dans mon utilisation XAML du contrôle. Voici quelques captures d'écran

Envisageriez-vous d'ajouter un événement "Ouvert" au contrôle ? Dans certains cas, il convient de fermer automatiquement la barre d'informations après quelques secondes. Un gestionnaire d'événements "Opened" serait le bon endroit pour démarrer la minuterie.

Je pense que la couleur Success , dans le thème sombre, devrait être modifiée. @YuliKl @anawishnoff @chigy @teaP
La couleur de thème sombre actuelle est # 393D1B - qui semble être une couleur vert jaunâtre, presque de couleur olive. Alors que le thème de la lumière utilise un vert plus clair, presque menthe comme le vert.

_En haut des couleurs actuelles, en dessous d'un changement proposé_

#1d3d1b

Ce n'est pas seulement pour la valeur esthétique, mais aussi parce que la barre plus olive ne se distingue pas aussi bien de la couleur d'avertissement

Voici à quoi cela ressemblerait