Cela devrait être un projet plus large que les coins arrondis des boutons, etc. utilisés par Fabric.

• Boutons
• Spinners/ProgressRing
• Barre de progression indéterminée
• Cases à cocher et boutons radio
• ComboBox et TextFields
  Etc.

Xbox continuera d'avoir des exigences différentes, mais avec un nouvel ensemble de consoles Xbox en route, les équipes de conception de Microsoft peuvent peut-être travailler ensemble pour tout aligner à temps pour WinUI 3.0 et Xbox Next.

Fabric semble faire l'objet de beaucoup d'attention en ce moment, avec ses cas d'utilisation multiplateformes et PWA. Alors peut-être que Fabric devient le modèle - au moins pour la densité compacte, et passe de 2px à 4px comme mesure minimale - puis vous extrapolez les capacités tactiles et remplissez les états de contrôle manquants.

Le ThemeShadows devra tenir compte des coins arrondis. Et les surfaces acryliques devraient probablement inclure des bordures intérieures et extérieures pour s'assurer qu'elles apparaissent surélevées par rapport aux arrière-plans.

@mdtauk Comme l'indique l'exigence numéro 4, il existe un plan pour rationaliser ce changement avec Xbox. Cela dit, cette caractéristique spécifique est limitée aux coins arrondis uniquement pour que le travail soit clairement défini. N'hésitez pas à ouvrir des demandes séparées pour d'autres suggestions de conception que vous avez.

BTW, je ne comprends pas très bien vos commentaires sur les bordures intérieures et extérieures des surfaces acryliques ? Est-ce la conception Xbox que vous mentionnez puisque nous n'utilisons actuellement pas deux bordures comme vous le spécifiez.

@chigy Bien sûr avec la Xbox, c'est son propre truc. Mais le fait est que les coins arrondis doivent fonctionner sur tous les contrôles pertinents.

Je ne suis pas au courant des spécifications de conception internes de la figma sur lesquelles l'équipe Fluent s'est peut-être mise d'accord - mais cela doit être plus que des boutons.

Fluent Web utilise un rayon de coin de 2px pour ses coins arrondis, mais Fluent XAML a eu tendance à utiliser 4px comme mesure de base. Ensuite, il y a les modèles CompactDensity qui utiliseraient probablement les mêmes métriques que FluentWeb ?

J'ai fait une image comparative des contrôles partagés Xbox Fluent et Fabric, et à quel point ils sont différents. Il y a donc plus que les coins arrondis qui doivent être faits pendant que ces modèles de contrôle sont examinés.

Ignorer les trucs Xbox

@mdtauk , Pour que vous ayez une impression, il ne s'agit que du bouton, je n'ai pas dû le spécifier clairement... Rassurez-vous, ce n'est pas le cas. Voir les exigences numéro 1 et leurs sous-éléments. Il s'agit de tous les contrôles.

Je n'ai pas eu l'occasion de publier le fichier de conception mais le rayon d'angle que nous prévoyons est en effet de 2px (4px pour l'interface utilisateur de superposition). En fait, je travaille en étroite collaboration avec l'équipe Fabric (c'est-à-dire Fluent Web) et nous évaluons ces changements ensemble. Cela dit, les faire correspondre exactement de la même manière n'est pas notre objectif, mais nous devons être cohérents et nous sentir comme faisant partie de la famille lorsque les utilisateurs les voient côte à côte. Voir l'exigence numéro 4.

Il y a donc plus que les coins arrondis qui doivent être faits pendant que ces modèles de contrôle sont examinés.

C'est en cours, mais nous le faisons un par un/au cas par cas. Nous faisons attention à apporter des changements qui ont du sens pour ne pas changer les choses pour le plaisir du changement.

@chigy Merci, merci, merci !

J'adorerais si vous pouviez partager ces conceptions avec la communauté, non seulement parce que nous voulons tous voir où vont les commandes et l'interface utilisateur, mais aussi lorsque les changements sont mis en œuvre, nous pouvons signaler les incohérences et assurer l'avenir les propositions de contrôle se sentiront chez elles !

Fabric Web ainsi que Fluent Web semblent être en tête du peloton, et XAML ainsi que WPF et WinForms/Visual Styles devraient suivre !

@chigy @mdtauk Voir ma réponse ici . À mon avis, il ne suffit pas de voir les concepts de l'interface utilisateur "pour savoir où va Fluent Design" ou de signaler les incohérences. Je développe ce point plus en détail dans le problème lié ci-dessus, mais pour faire court, je veux qu'il y ait un va-et-vient actif entre les utilisateurs et l'équipe Fluent Design (FD) même lorsqu'il s'agit de propositions de conception.

@mdtauk Je ne LE définitif Plateforme de présentation Windows.
Alors, @YuliKl @chigy @pag3 : Pouvez-vous commenter cela ? Les contrôles WinForms/WPF par défaut seront-ils mis à jour pour avoir un nouveau look FD ou les contrôles WinUI seront-ils la voie à suivre pour les fonctionnalités de conception les plus récentes et les plus performantes telles que je les comprends ?

J'ai posté cette image dans la proposition Numberbox, mais elle peut avoir une certaine pertinence pour les contrôles TextBox en cours de mise à jour.

The BorderThickness , FocusReveal sur l'état focalisé, Border on Disabled State.

Le style "Spin button" pourrait s'appliquer au bouton de recherche, au bouton de révélation du mot de passe, au bouton de texte clair.

L'ombre autour des éléments de bordure/contrôle dans l'état focalisé me semble beaucoup trop forte. Pourquoi ont-ils même besoin d'ombres ? La version actuelle (juste le changement de couleur des bordures) est tout à fait correcte. Les ombres peuvent suggérer que le contrôle (élément) est élevé au premier plan, ce qui peut avoir du sens dans les environnements 3D mais n'est certainement pas nécessaire pour les environnements de bureau classiques et, pourrait-on dire, ajoute une certaine distraction.

L'ombre autour des éléments de bordure/contrôle dans l'état focalisé me semble beaucoup trop forte. Pourquoi ont-ils même besoin d'ombres ? La version actuelle (juste le changement de couleur des bordures) est tout à fait correcte. Les ombres peuvent suggérer que le contrôle (élément) est élevé au premier plan, ce qui peut avoir du sens dans les environnements 3D mais n'est certainement pas nécessaire pour les environnements de bureau classiques et, pourrait-on dire, ajoute une certaine distraction.

La lueur autour du contrôle lorsqu'il est mis au point, est le FocusVisualKind.Reveal et est contrôlé par le système. J'ai dû approximer à quoi cela ressemble car je n'ai pas les métriques pour correspondre exactement à l'opacité et à la taille.

Considérez mon utilisation comme une indication que je pense que la lueur rendra la mise au point beaucoup plus claire, que de simplement changer la couleur de la bordure.

@mdtauk , respectivement, pourriez-vous s'il vous plaît limiter la conversation dans ce problème au coin arrondi ? J'aimerais vraiment avoir des commentaires sur le coin arrondi en particulier et je crains que cette conversation ne devienne trop déroutante pour ceux qui pourraient être venus ici dans ce but.

Cela dit, ce que vous montrez me semble être un comportement Reveal Focus. Nous avons cherché à renforcer l'état de mise au point et avons effectué des recherches auprès des utilisateurs et nous avons confirmé qu'ils sont bien trop forts, tout comme @Felix-Dev le mentionne dans sa réponse.
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy Si la recherche montre que Reveal Focus sur le contrôle de texte est trop important, je l'accepterai. Mes exemples incluent les coins arrondis, le tout avec quelques légères modifications de la bordure, qui correspondent à la partie "... cohérente avec la direction du style Web et de l'application" de la proposition.

@mdtauk et @Felix-Dev , j'ai maintenant téléchargé des compositions visuelles des modifications proposées.

@chigy est-il possible de reconsidérer l'épaisseur des bordures des contrôles de texte, des zones de liste déroulante, des contrôles et des contrôles radio.

Fabric Web a opté pour une épaisseur de 1 epx et je pense que cela rend les contrôles plus élégants, notamment avec les nouveaux coins arrondis. À l'heure actuelle, ils se sentent un peu encombrants.

Les zones de texte en mode compact en bénéficieraient grandement. Mais lorsqu'il est concentré, la frontière peut être plus épaisse

Les boutons utilisent le remplissage d'arrière-plan avec une opacité de 20 % par défaut. Dans Fabric Web, ils utilisent une bordure de 1 epx et aucun remplissage. Je pense que cela peut être une meilleure solution et permettrait également aux boutons d'un contrôle de zone de texte de s'adapter parfaitement.

La proposition NumberBox avec des boutons rotatifs illustre cette combinaison de bouton et de champ de texte

Peut-être que si l'équipe n'est pas disposée à faire de ce style le nouveau style par défaut, alors un style/modèle peut être inclus pour celui-ci.

Pour faciliter la visualisation des compositions visuelles créées par ceci

Commentaires anecdotiques et non professionnels sur le sujet des coins arrondis.
En utilisant à la fois Edge et CrEdge, mon problème numéro un avec CrEdge est la sensation arrondie de l'ensemble de l'interface utilisateur. C'est hideux et ça me fait activement détester l'utiliser. Si vous ajoutez des coins arrondis aux choses, veuillez ajouter la possibilité de basculer les bords tranchants pour ceux d'entre nous qui ne veulent pas que quelque chose qui ressemble à un enfant avec des ciseaux de sécurité le découpe.

Pour faciliter la visualisation des compositions visuelles créées par

@mrlacey , merci beaucoup !!

@chigy est-il possible de reconsidérer l'épaisseur des bordures des contrôles de texte, des zones de liste déroulante, des contrôles et des contrôles radio.

@mdtauk , nous avons en ce moment quelques changements visuels à régler sur la façon de répartir le travail (nous voulons qu'ils soient adressables individuellement mais cohérents), l'un d'eux est ce que vous demandez, alors restez à l'écoute.

Commentaires anecdotiques et non professionnels sur le sujet des coins arrondis.
En utilisant à la fois Edge et CrEdge, mon problème numéro un avec CrEdge est la sensation arrondie de l'ensemble de l'interface utilisateur. C'est hideux et ça me fait activement détester l'utiliser. Si vous ajoutez des coins arrondis aux choses, veuillez ajouter la possibilité de basculer les bords tranchants pour ceux d'entre nous qui ne veulent pas que quelque chose qui ressemble à un enfant avec des ciseaux de sécurité le découpe.

@Zucce05 , Oui #684 répondra à votre préoccupation en pouvant revenir facilement à un coin non arrondi. Cela dit, comme vous pouvez le voir dans notre proposition de maquette, les coins ne sont pas si ronds pour rester professionnels.

@chigy
Je ne suis pas non plus fan du changement de conception des coins arrondis, donc je suis heureux d'apprendre qu'il existe une option pour revenir facilement en arrière. Je ne pense pas qu'il y aura une option de rayon d'angle à l'échelle du système, n'est-ce pas (semblable à la définition d'une couleur d'accentuation à l'échelle du système) ?

Au sujet de l'épaisseur de la bordure : j'aime l'épaisseur actuelle des boutons et l'épaisseur de la bordure me semble également assez unique dans le paysage actuel de l'interface utilisateur. Je vois rarement, voire pas du tout, cette épaisseur de bordure dans l'interface utilisateur différente de l'interface utilisateur UWP, elle agit donc toujours comme une belle distinction : "L'interface utilisateur que je regarde actuellement est UWP." J'aimerais que l'épaisseur reste telle qu'elle est actuellement.

En regardant vos compositions visuelles publiées, la seule zone où je trouve que l'épaisseur de la bordure semble étrange est dans le cas d'un TreeView avec des cases à cocher. Dans ce cas, l'épaisseur des cases à cocher me semble trop épaisse. Cela peut être un effet visuel trompeur, mais il me semble que les cases à cocher autonomes ont une épaisseur de bordure plus fine et cela leur semble bien. Ainsi, je réduirais l'épaisseur de la bordure des checkbixes dans un TreeView pour correspondre à l'effet visuel de l'épaisseur normale de la bordure de la case à cocher.

@mdtauk , nous avons en ce moment quelques changements visuels à régler sur la façon de répartir le travail (nous voulons qu'ils soient adressables individuellement mais cohérents), l'un d'eux est ce que vous demandez, alors restez à l'écoute.

@chigy J'ai fait des maquettes visuelles pour illustrer les changements que j'ai mentionnés et rapproche les contrôles des contrôles de Fabric Web - mais en utilisant toujours les métriques de contrôle Fluent.

Les ombres ajoutées au survol sont utilisées par les contrôles Web Fluent sur les vues Web du Microsoft Store, mais cela peut être omis par défaut, ou la traduction Z peut être obtenue par une animation de thème qui peut être supprimée.

En regardant certaines des propositions de conception de @mdtauk ci-dessus, je préfère clairement l'épaisseur actuelle de la bordure des boutons, etc.

J'aimerais également noter que je ne suis pas tellement fan de baser Windows Fluent Design sur Fabric Web ou d'autres composants d'interface utilisateur Web - je veux que Windows ait un look unique, dicté par ce qui se passe avec le Web. Prenez les navigateurs Internet, par exemple : Chrome est le navigateur le plus largement utilisé de nos jours, mais cela signifie-t-il que le navigateur basé sur Edge Chromium devrait avoir exactement la même apparence ou seulement légèrement différent ? Pas à mon avis. Comme je l'ai dit ci-dessus, les styles de contrôle par défaut UWP actuels donnent à UWP (et donc à Windows) un aspect unique et agréable. Quelque chose que j'aimerais que l'équipe Windows Fluent considère (c'est-à-dire ne changez pas simplement des choses pour le plaisir de changer).

@Felix-Dev Fabric Web est la conception de contrôles Web de Microsoft basée sur Fluent. Chromium Edge prévoit d'utiliser ces styles de contrôle par défaut. Mais bien sûr, les concepteurs Web peuvent reconcevoir leurs contrôles CSS, et les développeurs peuvent également choisir leurs propres modèles pour les contrôles XAML.

Je ne sais pas pourquoi les conceptions de contrôle de Microsoft doivent tellement différer du Web à Windows. Cela ressemble à des équipes différentes, qui ne parlent pas ensemble. Et les développeurs ont toujours la possibilité de passer outre. Et ces nouvelles valeurs par défaut ne prennent effet que si l'application est recompilée vers WinUI 3.0

En regardant vos compositions visuelles publiées, la seule zone où je trouve que l'épaisseur de la bordure semble étrange est dans le cas d'un TreeView avec des cases à cocher.

@Felix-Dev, pour ce problème particulier, je pense que c'est juste un bug étrange de Figma exportant un visuel avec une échelle quelque peu étrange. J'ai vérifié la version réelle et le fichier Figma réel à partir duquel j'ai exporté le PNG, ils ont l'air OK.

RE : Popularité du coin arrondi
@mdtauk et @Felix-Dev ,
Mon collègue a fait une requête informelle sur ce que les développeurs (ils étaient principalement des développeurs LOB/WPF/WinForms) pensaient de la mise à jour de nos contrôles avec un coin arrondi lors de leur avant-première et ils ont reçu des applaudissements du public avec un très bon accueil. Nous obtenons également des gens qui se plaignent que nous ne contournons pas souvent les virages sur Twitter pour Windows.

Ainsi, bien que je respecte vos commentaires (et j'espère que vous les recevrez), nous avons des données anecdotiques qui indiquent le contraire de ce que j'entends ici de votre part. Cela dit, c'est pourquoi nous réfléchissons à la manière de le modifier au cas où vous le souhaiteriez. Le design est délicat car ils sont plutôt subjectifs. Je ne peux pas vous forcer à porter une chemise rouge si vous n'aimez pas le rouge, mais si c'est un "portez un jour rouge", il pourrait être intéressant d'en porter une pour ne pas vous démarquer. Si vous comprenez ce que je veux dire... :)

Eh bien, en fin de compte, cela se résume à des préférences personnelles. Je pense que les styles de contrôle par défaut UWP actuels semblent très bien et une grande partie pour moi est qu'ils semblent uniques par rapport à ce que vous voyez sur le Web ou dans des applications populaires comme le navigateur Chrome ou les systèmes d'exploitation mobiles comme Android. C'est une bonne bouffée d'air frais.

Maintenant, je peux voir pourquoi MS veut avoir des styles "par défaut" différents pour Windows et Web pour leur langage de conception. Cependant, j'ai l'impression que la direction actuelle est de faire en sorte que Windows ressemble davantage à des applications mobiles / systèmes d'exploitation mobiles et je ne suis pas vraiment un fan de cela (voir "Les contrôles XAML sont incompatibles avec la façon dont les applications Web et mobiles évoluent" dans la proposition d'émission).

Les développeurs peuvent probablement facilement modifier les styles, mais le plus important pour moi est le style par défaut avec lequel MS ira, car ce style sera utilisé dans toutes les applications fournies par MS (c'est-à-dire les paramètres) et sera donc un style sur lequel les développeurs externes baseront également leur travail (certains plus, certains moins).

@chigy

Mon collègue a fait une requête informelle sur ce que les développeurs (ils étaient principalement des développeurs LOB/WPF/WinForms) pensaient de la mise à jour de nos contrôles avec un coin arrondi lors de leur avant-première et ils ont reçu des applaudissements du public avec un très bon accueil.

N'est-ce pas peut-être le mauvais auditoire à demander ? Qu'en est-il des utilisateurs quotidiens ? J'ai vu pas mal d'utilisateurs se plaindre des récents coins arrondis dans les canaux reddit et discord, par exemple (bien que vous ayez toujours des utilisateurs qui ne s'en soucieront pas ou ne soutiendront pas ce changement).

En ce qui concerne l'exemple de Twitter : il s'agit d'une application d'un tiers qui souhaite peut-être avoir son propre style de marque unique. Je serais d'accord avec ça (après tout, c'est là que votre équipe entre en jeu et ajoute la prise en charge de la personnalisation pour les styles de contrôle). Mais je n'utiliserais certainement pas une application externe pour réviser le langage de conception officiel de Windows.

Pour faire court, on dirait que l'équipe de conception de Windows est déterminée à styliser Windows plus près du monde mobile/web. Maintenant, j'espère seulement que ces changements ne seront pas trop radicaux et que Windows restera toujours un aspect unique, le rendant facilement distinguable des autres environnements.

@Felix-Dev Les contrôles Web Fabric sont uniques par rapport aux autres frameworks et aux contrôles Web par défaut. Ils ont été récemment mis à jour pour utiliser Fluent Design, par rapport à l'ancien aspect qui ressemblait un peu aux contrôles Windows 10 MDL2 et aux contrôles Windows 8/WinJS.

Les contrôles XAML utilisent toujours leurs conceptions de contrôle MDL2, certains éléments tels que les menus volants et les menus utilisent des éléments et des matériaux Fluent Design.

Les styles de texte dans Fluent et Fabric utilisent davantage les graisses Gras et Semibold. Les différents concepts de Windows 10 les ont également utilisés. Mais les applications Windows Shell et de la boîte de réception ne sont pas encore toutes passées à ce style.

Fabric Web et Fluent Web sont les modifications les plus récentes apportées aux contrôles de Microsoft depuis l'annonce de Fluent Design, et il est donc naturel que nous examinions ces conceptions pour nous aider à trouver une direction vers laquelle ces interfaces utilisateur iront. Avec WinUI 3.0 étant un grand changement pour la plate-forme et toutes les commandes ayant un nouveau look pour les faire se sentir mieux, plus fraîches et plus cohérentes avec la conception fluide de Microsoft.

RE : Cohérence Web, Fluent et unique à Windows
@Félix-Dev et @mdtauk ,
L'un des objectifs de l'équipe de conception de Windows est la « familiarité ». Ils ont fait beaucoup de recherches sur les utilisateurs avec nos clients (comme vous l'indiquez, pas nos développeurs mais nos utilisateurs quotidiens) et ont découvert qu'être différent sans raison valable n'est pas une bonne chose comme vous pouvez l'imaginer (je résume super ce n'est donc pas le test exact qu'ils ont fait, alors ne me citez pas ici). Windows doit attirer de nouveaux types d'utilisateurs dont l'expérience avec n'importe quelle technologie peut commencer avec le mobile ou le Web. Ces utilisateurs ressentent un énorme vide lorsqu'ils découvrent Windows et avoir une apparence « différente » ne les aide pas. Un petit changement comme un coin arrondi fait une énorme différence dans la perception. L'équipe Office a réalisé une étude similaire avec des résultats similaires, nous allons donc de l'avant avec le coin arrondi. Nous ne prenons pas cette décision à la légère ou dans le vide.

Cela ne veut pas dire que nous les rendons exactement identiques. S'il y a des endroits où nous pouvons nous améliorer, nous le voulons. Nous voulons également être uniques comme le mentionne Felix, mais ils doivent être significatifs, pas seulement des différences d'opinions. Ce sont des endroits où nous utilisons des traitements uniques Fluent.

Comme je l'ai mentionné plus tôt dans cette discussion, je travaille en étroite collaboration avec les équipes Office, Windows et Edge. Nos équipes de conception sont impatientes d'avoir une conception issue de Microsoft/Fluent, elles examinent donc très attentivement les différences et s'efforcent d'éliminer là où les différences n'ont pas de sens afin que nous ayons un point de départ où nous pouvons évoluer ensemble.

C'est très intéressant, cependant, beaucoup de ces changements étaient incubés par ces équipes séparément, mais ils arrivaient souvent à des endroits très similaires. L'amincissement de la frontière est quelque chose qu'Office a mis en œuvre en premier, mais Windows en discute depuis un certain temps maintenant. Et tout cela fait partie de la direction de Fluent Design, comme le suggère Martin.

_RE : Popularité du coin arrondi_
@mdtauk et @Felix-Dev ,
Mon collègue a fait une requête informelle sur ce que les développeurs (ils étaient principalement des développeurs LOB/WPF/WinForms) pensaient de la mise à jour de nos contrôles avec un coin arrondi lors de leur avant-première et ils ont reçu des applaudissements du public avec un très bon accueil. Nous obtenons également des gens qui se plaignent que nous ne contournons pas souvent les virages sur Twitter pour Windows.

Ainsi, bien que je respecte vos commentaires (et j'espère que vous les recevrez), nous avons des données anecdotiques qui indiquent le contraire de ce que j'entends ici de votre part. Cela dit, c'est pourquoi nous réfléchissons à la manière de le modifier au cas où vous le souhaiteriez. Le design est délicat car ils sont plutôt subjectifs. Je ne peux pas vous forcer à porter une chemise rouge si vous n'aimez pas le rouge, mais si c'est un "portez un jour rouge", il pourrait être intéressant d'en porter une pour ne pas vous démarquer. Si vous comprenez ce que je veux dire... :)

_RE : Cohérence Web, Fluent et unique à Windows_
@Félix-Dev et @mdtauk ,
L'un des objectifs de l'équipe de conception de Windows est la « familiarité ». Ils ont fait beaucoup de recherches sur les utilisateurs avec nos clients (comme vous l'indiquez, pas nos développeurs mais nos utilisateurs quotidiens) et ont découvert qu'être différent sans raison valable n'est pas une bonne chose comme vous pouvez l'imaginer (je résume super ce n'est donc pas le test exact qu'ils ont fait, alors ne me citez pas ici). Windows doit attirer de nouveaux types d'utilisateurs dont l'expérience avec n'importe quelle technologie peut commencer avec le mobile ou le Web. Ces utilisateurs ressentent un énorme vide lorsqu'ils découvrent Windows et avoir une apparence « différente » ne les aide pas. Un petit changement comme un coin arrondi fait une énorme différence dans la perception. L'équipe Office a réalisé une étude similaire avec des résultats similaires, nous allons donc de l'avant avec le coin arrondi. Nous ne prenons pas cette décision à la légère ou dans le vide.

Cela ne veut pas dire que nous les rendons exactement identiques. S'il y a des endroits où nous pouvons nous améliorer, nous le voulons. Nous voulons également être uniques comme le mentionne Felix, mais ils doivent être significatifs, pas seulement des différences d'opinions. Ce sont des endroits où nous utilisons des traitements uniques Fluent.

Comme je l'ai mentionné plus tôt dans cette discussion, je travaille en étroite collaboration avec les équipes Office, Windows et Edge. Nos équipes de conception sont impatientes d'avoir une conception issue de Microsoft/Fluent, elles examinent donc très attentivement les différences et s'efforcent d'éliminer là où les différences n'ont pas de sens afin que nous ayons un point de départ où nous pouvons évoluer ensemble.

C'est très intéressant, cependant, beaucoup de ces changements étaient incubés par ces équipes séparément, mais ils arrivaient souvent à des endroits très similaires. L'amincissement de la frontière est quelque chose qu'Office a mis en œuvre en premier, mais Windows en discute depuis un certain temps maintenant. Et tout cela fait partie de la direction de Fluent Design, comme le suggère Martin.

Je suis tout à fait favorable à la modification des contrôles par défaut, et les contrôles Fabric Web se sentent plus élégants et raffinés que les conceptions de contrôle XAML actuelles IMO.

Mais il ne s'agit pas seulement de modifier les modèles, il s'agit d'exposer davantage de propriétés qui permettent aux développeurs de remplacer facilement ces modifications sans avoir à re-modèler l'ensemble du contrôle.

Les nouvelles valeurs CornerRadius par défaut pourraient être ThemeResources, quelque chose comme
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

Ensuite, un développeur peut simplement les remplacer dans App.xaml - ou appliquer CornerRadius="0" sur les contrôles qu'ils souhaitent conserver au carré.

Suite à cela, je suggérerais également que BorderThickness ait ses valeurs par défaut définies sur 1epx au lieu de 2epx - mais tous les contrôles utiliseraient ThemeResources, quelque chose comme :
<Thickness x:Name="ControlBorderThickness" Value="1,1,1,1"
<Thickness x:Name="ControlFocusedBorderThickness" Value="2,2,2,2"
<Thickness x:Name="FlyoutInnerBorderThickness" Value="1,1,1,1"
<Thickness x:Name="FlyoutOuterBorderThickness" Value="1,1,1,1"

Ceux-ci peuvent donc être remplacés globalement dans App.xaml, ou simplement dans un style appliqué à quelques contrôles.

Définissez une nouvelle valeur par défaut, mais autorisez les remplacements qui ne nécessitent pas de nouveau modèle.

Mais il ne s'agit pas seulement de modifier les modèles, il s'agit d'exposer davantage de propriétés qui permettent aux développeurs de remplacer facilement ces modifications sans avoir à re-modèler l'ensemble du contrôle.

@mdtauk , C'est vrai et comme je l'ai mentionné, il est suivi par le changement proposé avec #684. Ajouter @kikisaints à ce fil afin qu'elle voie les bons commentaires que vous avez donnés (mais ne citez pas le tout car ce sera énorme. :)

@chigy Alors que je

J'aimerais en savoir plus sur les types de discussions que les équipes Windows UI ont eues. J'ai fait des idées de conception de contrôle au cours des dernières années pour mes propres besoins et pour les conversations sur Twitter, et certaines des choses maintenant dans Fabric Web et Office Xaml étaient des choses que je voulais changer. Épaisseurs de bordure, certaines incohérences avec les boutons radio, les cases à cocher, les listes déroulantes, etc.

Je suis ravi de voir ces changements se développer et je suis heureux de participer aux discussions en cours ici !

Merci d'avoir pris mon enthousiasme de la manière constructive que je voulais, même s'il peut sembler arrogant ou opiniâtre.

J'applaudis définitivement la décision de rendre la personnalisation des contrôles aussi simple que de définir une propriété au lieu d'avoir à re-modèler l'ensemble du contrôle pour un seul changement.

Cependant, au final, ce que je souhaite le plus, c'est une prise en charge accrue de la personnalisation dans le système d'exploitation : comme vous le savez maintenant, je ne suis pas un fan des changements proposés (le rayon de coin subtil est une chose, la réduction de l'épaisseur des bordures en est une autre) et j'aime le design actuel. D'un autre côté, nous avons des utilisateurs comme @mdtauk qui sont clairement un grand fan des changements proposés. Windows devrait utiliser la nouvelle flexibilité de ces contrôles et offrir des options pour personnaliser l'apparence à l'échelle du système - pour les cas où cela a du sens et donner également aux développeurs la possibilité de ne pas suivre les paramètres du système.

En ce qui concerne la réflexion sur les frontières en particulier, le système proposé permet de fournir une option à l'échelle du système pour les rayons d'angle extrêmement facile (tout comme avec la couleur d'accent actuelle, qui est exposée comme une ressource que les applications peuvent utiliser). Surtout vu que les changements de rayons d'angle proposés sont plutôt petits, cela pourrait également être faisable en termes de conception pour les applications (et si le développeur ne le pense pas, il peut toujours se retirer).

J'aimerais en savoir plus sur les types de discussions que les équipes Windows UI ont eues.

@mdtauk , nous avons l'intention d'apporter tous les changements visuels à venir via GitHub, alors attendez-vous à ce que d'autres arrivent. Je prévois également d'étendre la documentation pour inclure certains de ces antécédents, mais c'est quelque chose que j'expérimente, donc je ne sais pas si ce sera une chose sûre...

Cependant, au final, ce que je veux le plus voir, c'est une prise en charge accrue de la personnalisation dans le système d'exploitation...
Windows devrait utiliser la nouvelle flexibilité de ces contrôles et offrir des options pour personnaliser l'apparence à l'échelle du système - pour les cas où cela a du sens et donner également aux développeurs la possibilité de ne pas suivre les paramètres du système.

@Felix-Dev , le type de personnalisation que nous examinons actuellement pour Windows (je suppose que quelque chose que l'utilisateur peut modifier à partir des paramètres ?) est un élément qui a un impact sur la convivialité. Je ne sais pas si les coins arrondis ou l'épaisseur de la bordure en font partie. L'objectif de Windows n'est pas de faire en sorte que l'utilisateur puisse concevoir l'ensemble de l'interface utilisateur comme il le souhaite. Nous voulons toujours fournir la conception Windows et le coin arrondi est l'un des facteurs de conception clés que je ne pense pas être quelque chose destiné à la personnalisation... Au moins pour le moment selon la définition de la personnalisation. Merci pour vos commentaires et je vais chercher des endroits où il est logique d'exposer alors que nous pensons à d'autres changements de conception.

@Felix-Dev Avec la quantité de personnalisation que les développeurs peuvent apporter aux commandes, il serait impossible d'être cohérent avec les paramètres du système d'exploitation concernant les modifications de la conception des commandes.

@chigy Au

@mdtauk

Avec la quantité de personnalisation que les développeurs peuvent apporter aux commandes, il serait impossible d'être cohérent avec les paramètres du système d'exploitation concernant les modifications de la conception des commandes.

Je ne parle pas de la façon dont les développeurs externes honoreraient ce paramètre utilisateur - ils peuvent déjà styliser les contrôles aujourd'hui comme ils le souhaitent - mais de l'apparence des composants Windows. Cela signifie que l'application Paramètres, le Presse-papiers, Snip & Sketch, les éléments de l'interface utilisateur dans les menus volants de la barre des tâches (comme les boutons du panneau réseau), etc.

Pour ma part, j'utilise à peine des applications UWP en dehors de celles fournies par MS, donc je n'ai aucun problème avec les styles personnalisés par les développeurs externes. Cependant, j'interagis quotidiennement avec les éléments UWP dans le système Windows.

@chigy Correct, je cherchais un paramètre dans l'application Paramètres Win 10 où un utilisateur peut modifier - dans une certaine mesure - l'apparence de l'interface utilisateur. Il reste à voir ce qui aurait du sens et serait également viable en termes de travail supplémentaire rendant les caractéristiques de l'interface utilisateur modifiables par l'utilisateur. Je pense que plus les changements proposés sont petits (rayon de coin subtil), plus il sera viable d'ajouter une option pour revenir au style précédent (contrôles au carré).

Une dernière chose : Win 10 compte 800 millions d'utilisateurs et ce n'est pas fini. Tout le monde n'est pas aussi enthousiaste que Martin au sujet des changements proposés et ce serait bien si Windows essaie également d'accommoder ces utilisateurs. Comme vous l'avez dit, l'interface utilisateur est hautement subjective et s'il existe une possibilité d'ajouter de la flexibilité au système d'interface utilisateur, les États membres devraient au moins en tenir compte.
Pour les navigateurs Internet, par exemple, il existe toute une industrie de thèmes, où non seulement les couleurs sont modifiées mais aussi l'apparence des éléments de l'interface utilisateur tels que les onglets ou la barre de recherche : https://github.com/muckSponge/MaterialFox (assez drôle , ce projet particulier ajoute des coins arrondis à Firefox - et je ne suis pas un fan des coins arrondis.)
Pour le système Windows, cependant, les utilisateurs ne peuvent pas simplement créer leur propre thème, il serait donc bien que MS puisse fournir des options de personnalisation de l'interface utilisateur.

@mdtauk @chigy
Veuillez consulter ce post reddit pour voir qu'il n'y a pas que moi qui ne suis pas fan des coins arrondis. Nous avons des gens qui n'aiment pas l'ensemble du mouvement et également beaucoup qui demandent de donner aux utilisateurs des choix pour leur apparence Windows afin qu'ils puissent revenir à l'apparence actuelle.

D'accord, de nombreuses personnes m'ont exhorté à donner leur avis sur ce fil, car il y a une enquête sur les modifications proposées dans l'interface utilisateur, principalement l'idée de forcer des coins arrondis sur littéralement tout et en tant que quelqu'un qui est à la fois un concepteur d'interface graphique (principalement un concept et design) et j'ai utilisé Windows 10 depuis qu'il était même en développement, je vais absolument me ranger du côté de tous ceux qui n'aiment pas du tout le changement proposé pour ajouter des coins arrondis à l'ensemble du système d'exploitation, et j'insiste fortement pour que ces changements ne soient pas effectués ou soit laissés l'utilisateur a la préférence de vouloir des angles arrondis ou des angles vifs via une option de personnalisation.

En termes de lamentation : Il suffit de les garder carrés ou de les rendre facultatifs au niveau de l'utilisateur.

J'ai plus qu'assez de raisons, mais mes plus grandes sont simplement le fait que Windows depuis Windows 8 a des coins carrés et à peu près tout a été conçu autour de ça depuis des années, cette proposition est vraiment une tentative d'adopter les mêmes coins arrondis de l'iOS et les plates-formes Android pour une raison quelconque. Le plus gros problème est que cela augmenterait non seulement la quantité d'incohérences à l'échelle du système, mais forcerait un tel "petit" changement d'interface utilisateur qui, en réalité, est beaucoup plus important que ce que vous réalisez entraînerait également une incohérence dans l'ensemble de l'écosystème de l'application, car vous aurez les développeurs qui ne veulent pas mettre à jour leur application simplement à cause d'un simple changement comme celui-là.

À mon avis, cela ne devrait absolument PAS être un choix de développeur, non seulement pour les raisons indiquées ci-dessus, mais Windows a toujours été axé sur la personnalisation et la puissance, prenez le thème Windows 98 aka Classic par exemple. Lorsque Windows XP est apparu, de nombreuses personnes utilisaient encore Classic car il avait plus d'options de personnalisation que le thème Luna. XP n'a pas du tout imposé le thème Luna à tout le monde, vous aviez toujours la possibilité d'utiliser Classic. Ce changement proposé ne vous donne PAS la possibilité de conserver des coins carrés n'importe où, il oblige tout le monde à faire face à quelque chose qu'il n'aime peut-être pas, une très mauvaise chose à mon avis lorsqu'il s'agit de laisser un utilisateur personnaliser le système d'exploitation à sa guise.

Je sais que vous pensez probablement « un si petit changement n'est pas quelque chose qui intéresserait les utilisateurs » ou « laisser l'utilisateur personnaliser trop de choses les confondrait » mais je suis à peu près sûr que n'importe quel utilisateur serait capable de comprendre ce basculer entre des angles arrondis et pointus ou même un thème feraient l'affaire compte tenu de la description et du contexte appropriés. J'ajouterai également que de nombreuses personnes sont définitivement intéressées à avoir cette option au lieu de se voir imposer quelque chose d'autre contre leur gré, voir le post Reddit @Felix-Dev posté si vous avez besoin de plus de preuves que les gens n'aiment pas l'idée d'arrondi coins partout.

Beaucoup de gens n'aiment même pas la proposition de coins arrondis et beaucoup la considèrent comme un pas en arrière, vérifiez même les commentaires dans plusieurs vidéos de la prochaine interface utilisateur Hololens en cours d'arrondi, la majorité des commentaires portent encore une fois sur le fait de ne pas aimer fortement tous les coins arrondis et il y a même commentaires disant des variantes de "Microsoft jetant l'éponge dans le département de l'interface utilisateur et copiant Apple ou Google", même si ce n'est pas la première fois que Microsoft utilise des coins arrondis, les gens le voient maintenant comme une chose négative.

Encore une fois, cela devrait vraiment être une option ou même un thème, ce n'est même pas un nouveau concept puisque Windows a des thèmes pendant des années dans les versions précédentes, si quoi que ce soit, cela devrait être un message demandant le retour d'un thème robuste, au lieu de forcer à nouveau quelque chose sur tout le monde et réduire les options.

J'ai créé un article reddit lié à cette proposition afin que nous puissions recueillir plus de commentaires. En parcourant les commentaires jusqu'à présent, je peux dire que beaucoup de gens apprécient l'approche subtile avec les coins arrondis.

Les gens signalent également des incohérences de l'interface utilisateur - même dans les applications officielles Win 10 MS, voir l'application Paramètres et l'application Sécurité (NavigationView s'étendant dans la barre de titre) - ainsi que les différences entre les composants du système win32 et les éléments UWP plus récents. Comme @SavoySchuler l'a mentionné, cela sera, espérons-le, résolu avec WinUI 3.0. Il ne s'agit pas d'un point spécifique concernant cette proposition, mais plutôt d'un désir "global" parmi beaucoup d'entre nous, utilisateurs de Windows. Pas tellement sur les coins ronds ou non, mais sur la cohérence du système Windows.

La cohérence est la clé ici, et avait été ma principale préoccupation.

WinUI 3.0 concerne les modifications apportées aux contrôles XAML qui affectent les applications de la boîte de réception et l'interface utilisateur Windows.

Fabric Web est sa propre équipe, mais toutes les équipes communiquent ensemble et fondent leurs décisions sur Fluent Design. Je suppose donc que la conception de Fabric Web est la dernière réflexion de Microsoft et que la cohérence doit donc prévaloir.

Xbox Next, Windows Lite et Windows Core OS seront livrés avec de nouveaux shells, cela doit donc également être pris en compte par les équipes - avec Windows 10 pour la prise en charge héritée

Ce que @chigy a dit est exactement ce que moi et beaucoup d'autres venions de demander, un changement plus subtil qui permettrait également aux personnes au niveau de l'utilisateur plutôt qu'au niveau du développeur de décider simplement s'ils veulent voir des coins pointus ou des coins arrondis, de la même manière Les thèmes Windows fonctionnaient auparavant.

Sur la base de ce que @Nepxune a dit ci-dessus, il serait peut-être intéressant de donner aux utilisateurs une gamme sélectionnée de valeurs parmi lesquelles ils pourraient choisir pour un rayon d'angle à l'échelle du système. Au moins pour les petites valeurs comprises entre 0 et 2, je pense qu'il n'y aurait aucun impact négatif sur une interface utilisateur méticuleusement conçue. Après tout, ce sont des changements très subtils et devraient donc toujours préserver l'identité de l'interface utilisateur de Windows.

Je vois cependant que même si la personnalisation de l'interface utilisateur est ajoutée à Windows, il doit y avoir des limites, à la fois dans le nombre d'éléments modifiables par l'utilisateur et également dans l'ensemble de valeurs qu'un utilisateur peut choisir. Sinon, il existe un risque d'avoir un impact négatif sur l'interface utilisateur existante et de trop s'éloigner de l'apparence Windows souhaitée par l'équipe de conception.

J'ai un point de vue différent à ce sujet.
Plus tôt dans le fil, j'ai vu une discussion sur le rapprochement des styles Fabric UI (Web) et Windows (UWP), et cela m'inquiète un peu.

Voici un peu de contexte : je suis un utilisateur de Microsoft Edge depuis des années, et l'une de mes choses préférées à ce sujet était son apparence inspirée de UWP. Lorsque Edge Insider a été révélé, j'ai été très déçu de voir qu'il utilisait une conception modifiée de Chrome et de l'interface utilisateur Web au lieu du style UWP de son prédécesseur. Alors que les coins arrondis montrés sont très minimes, au point où je n'ai aucun problème avec eux, ce fil me donne le même sentiment de déception. Je ne veux pas que Windows perde son apparence unique (et supérieure !) au profit d'une correspondance avec des « normes Web » mal conçues. En fait, je préférerais voir des aspects de la conception Fluent UWP faire leur chemin vers Fabric !

Je pense que le plan pour Edge est de ramener à terme l'acrylique et de déplacer l'interface utilisateur davantage vers un style Windows/Fluent Design.

Mais Windows avance également légèrement pour, espérons-le, combler le fossé.

Il n'est pas impossible d'apporter un paramètre dans le système d'exploitation pour choisir entre des contrôles arrondis et non arrondis, il est impossible de l'imposer à toutes les applications et fonctionne d'une manière totalement différente des styles visuels de l'ère XP.

De plus, WinUI 3.0 consiste à séparer la plate-forme et les contrôles de l'application du système d'exploitation, et ce n'est donc peut-être pas une bonne décision d'en lier davantage.

Bien sûr, en tant que développeur d'applications, vous avez la possibilité de définir la valeur CornerRadius de vos contrôles sur 0 pour ramener les contrôles au carré.

Je prends en charge cette poussée pour les petits coins arrondis, mais je préfère le contrôle actuel du curseur à poignée verticale au contrôle du curseur à poignée circulaire. La poignée verticale est plus précise et permet de savoir plus facilement où elle se trouve en un coup d'œil. Du moins c'est comme ça que je le vois. Continuez votre bon travail quand même !

Y a-t-il une raison pour laquelle le pouce de la barre de brossage MediaTransport est rond avec un contour, alors que le nouveau pouce coulissant proposé est un cercle plein ?

Je pense que le pouce circulaire est beaucoup plus agréable que la forme gênante de pastille/pilule qui ne correspond à aucune des autres commandes.

Je ne sais pas si vous vous en souvenez, mais même faire des carreaux dans les coins arrondis était un gros problème pour beaucoup de fans de Windows à l'époque et ce n'était qu'un changement mineur. Pour moi, le fait d'avoir des coins arrondis partout signifierait que Windows perdrait son aspect distinctif depuis l'introduction du langage de conception métropolitain et d'un design fluide. Le langage de conception a toujours été une grande clé pour moi, ce qui a rendu le développement uwp attrayant pour moi. Ce serait vraiment triste de le voir partir et devenir générique.

En plus des concepts de conception TextBox et NumberBox que j'ai réalisés - en voici quelques-uns pour le ComboBox et le EditableComboBox

Bon travail!
J'ai quelques suggestions concernant les menus volants. Avec les ombres qui délimitent le menu, avons-nous vraiment besoin de la frontière ? Et IMO, la surbrillance de la sélection pourrait couvrir toute la largeur de la surface du flyout, sans laisser d'espaces.

J'apprécie les bordures floues plus fines et la lueur de révélation de la mise au point devrait permettre de voir plus facilement quel élément est mis au point lors de la tabulation dans l'interface utilisateur à l'aide d'un clavier (je préférerais en fait qu'il soit légèrement plus fort que ci-dessus).

Bon travail!
J'ai quelques suggestions concernant les menus volants. Avec les ombres qui délimitent le menu, avons-nous vraiment besoin de la frontière ? Et IMO, la surbrillance de la sélection pourrait couvrir toute la largeur de la surface du flyout, sans laisser d'espaces.

La surbrillance de la sélection couvre toute la largeur, mais j'ai placé une bordure intérieure plus claire sur les icônes volantes, ce qui l'aidera à se soulever de la surface avec l'effet acrylique et l'ombre - la bordure intérieure pourrait être rendue plus subtile si elle est trop forte - c'est plus une idée qu'une proposition de conception entièrement finale.

@mdtauk

Il n'est pas impossible d'apporter un paramètre dans le système d'exploitation pour choisir entre des contrôles arrondis et non arrondis, il est impossible de l'imposer à toutes les applications et fonctionne d'une manière totalement différente des styles visuels de l'ère XP.

C'est pourquoi j'ai dit de le rendre facultatif pour les développeurs. Honnêtement, rien ne changerait vraiment. Les applications tierces peuvent déjà être livrées avec l'apparence qu'elles souhaitent. Si une entreprise souhaite livrer son application avec une interface utilisateur arrondie (boutons circulaires,...), elle est libre de le faire.

De plus, WinUI 3.0 consiste à séparer la plate-forme et les contrôles de l'application du système d'exploitation, et ce n'est donc peut-être pas une bonne décision d'en lier davantage.

Comme je l'ai dit ci-dessus, je l'imagine de la même manière que la couleur d'accent (que l'utilisateur peut définir dans les paramètres) est gérée aujourd'hui. Exposez-le comme une ressource que les contrôles peuvent lier à leur rayon d'angle, de cette façon, les changements de rayon d'angle seront reflétés dans l'application sans travail supplémentaire pour les développeurs.

Je laisse simplement mes commentaires de reddit ici du point de vue des utilisateurs : « J'adore le look épuré des coins arrondis de la proposition. Comme tout le monde cependant (sur reddit), la cohérence autour de l'ensemble du système d'exploitation a encore besoin de beaucoup d'amour.

Y a-t-il une raison pour laquelle le pouce de la barre de brossage MediaTransport est rond avec un contour, alors que le nouveau pouce coulissant proposé est un cercle plein ?

@mdtauk , en fait, c'est quelque chose que nous examinons, mais cela ne signifie pas que nous apporterons le changement, donc je ne fixe pas d'attentes ...

J'ai quelques suggestions concernant les menus volants. Avec les ombres qui délimitent le menu, avons-nous vraiment besoin de la frontière ? Et IMO, la surbrillance de la sélection pourrait couvrir toute la largeur de la surface du flyout, sans laisser d'espaces.

@quantumfrost , Oui, en fait, nous le faisons. L'ombre est intelligente. Ainsi, lorsque le système est en mode basse consommation ou dans une autre situation dans laquelle nous désactivons l'ombre, la frontière entrera en jeu. Nous avons conçu la bordure de manière à ce qu'elle soit subtile. Nous avons évalué plusieurs options différentes, mais c'est ce qui était le plus robuste.

@nepxune , @mdtauk
Merci pour votre avis.
Permettez-moi de répondre à quelques-uns des points que vous avez soulevés ci-dessus.

L'option de fournir un paramètre utilisateur pour arrondir les angles, quelque chose que l'utilisateur peut choisir, est intéressante. Cependant, cela a également beaucoup à voir avec ces commentaires sur d'autres fonctionnalités importantes que nous devons peser dans le système Windows dans son ensemble.

En tant que développeurs d'applications, j'espère que vous êtes tous parfaitement conscients de la nécessité d'établir des priorités et de faire ce qui est juste pour votre client. Pour le cas de Windows, le client est l'utilisateur qui utilise le système d'exploitation. Bien sûr, les développeurs qui créent des applications sur ce système d'exploitation sont également des clients importants, et je pense qu'en offrant la facilité de changer de rayon d'angle, nous sommes en mesure de résoudre le principal problème que ce changement aurait introduit.

Quant aux utilisateurs qui utilisent l'OS, nos clients nous ont dit que Windows était trop intimidant. Les équipes Windows et Office ont toutes deux réalisé une étude d'utilisateurs où elles ont fini par conclure (indépendamment) que même aussi subtil qu'un coin arrondi fait une différence pour rendre le produit familier et accessible.

Donc, je sais que beaucoup de gens sur GitHub et d'autres forums mentionnent que nous suivons iOS et Android, mais ce n'est pas le cas. Nous arrivons à cette décision en comprenant nos utilisateurs. Oui, le fait qu'ils utilisent des coins arrondis ajoute à l'aspect de familiarité, mais nous ne suivons pas aveuglément ce que fait l'industrie.

J'ai un point de vue différent à ce sujet.
Plus tôt dans le fil, j'ai vu une discussion sur le rapprochement des styles Fabric UI (Web) et Windows (UWP), et cela m'inquiète un peu.

Voici un peu de contexte : je suis un utilisateur de Microsoft Edge depuis des années, et l'une de mes choses préférées à ce sujet était son apparence inspirée de UWP. Lorsque Edge Insider a été révélé, j'ai été très déçu de voir qu'il utilisait une conception modifiée de Chrome et de l'interface utilisateur Web au lieu du style UWP de son prédécesseur. Alors que les coins arrondis montrés sont très minimes, au point où je n'ai aucun problème avec eux, ce fil me donne le même sentiment de déception. Je ne veux pas que Windows perde son apparence unique (et supérieure !) au profit d'une correspondance avec des « normes Web » mal conçues. En fait, je préférerais voir des aspects de la conception Fluent UWP faire leur chemin vers Fabric !

@19lmyers
Merci pour vos commentaires sur votre inquiétude à propos de Windows perdant son propre aspect unique (et même supérieur). Comme mentionné dans le commentaire ci-dessus, nos utilisateurs n'apprécient pas nécessairement que Windows soit trop différent car ils ne leur sont pas familiers, il s'agit donc d'un exercice d'équilibre.

Sous Fluent Design System, les équipes de conception de l'entreprise discutent de nombreuses différences et tentent d'éliminer les différences inutiles introduites jusqu'à présent. Tout comme le commentaire que j'ai fait à propos d'iOS et d'Android ci-dessus, ces conceptions que nous proposons ne sont pas parce que nous copions Fabric, mais nos concepteurs Windows y sont arrivés en réévaluant leur propre système d'interface utilisateur. Ils aboutissent souvent à un design similaire, ce qui est assez intéressant... Cela dit, j'apprécie vraiment l'enthousiasme de beaucoup de gens pour garder Windows unique.

Bienvenue dans notre repo, @zag2me ! Nous sommes ravis que vous vous joigniez aux discussions ici. Je suis d'accord et c'est le bon endroit pour attirer l'attention sur les problèmes qui vous intéressent ! Vous pouvez trouver notre formulaire de demande de fonctionnalité ici : https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose

@chigy

L'option de fournir un paramètre utilisateur pour arrondir les angles, quelque chose que l'utilisateur peut choisir, est intéressante. Cependant, cela a également beaucoup à voir avec ces commentaires sur d'autres fonctionnalités importantes que nous devons peser dans le système Windows dans son ensemble.

Quant aux utilisateurs qui utilisent l'OS, nos clients nous ont dit que Windows était trop intimidant. Les équipes Windows et Office ont toutes deux réalisé une étude d'utilisateurs où elles ont fini par conclure (indépendamment) que même aussi subtil qu'un coin arrondi fait une différence pour rendre le produit familier et accessible.

Nous arrivons à cette décision en comprenant nos utilisateurs. Oui, le fait qu'ils utilisent des coins arrondis ajoute à l'aspect de familiarité, mais nous ne suivons pas aveuglément ce que fait l'industrie.

Merci pour vos commentaires sur votre inquiétude à propos de Windows perdant son propre aspect unique (et même supérieur). Comme mentionné dans le commentaire ci-dessus, nos utilisateurs n'apprécient pas nécessairement que Windows soit trop différent car ils ne leur sont pas familiers, il s'agit donc d'un exercice d'équilibre.

Et voici le problème que j'ai avec ça: vous mentionnez "utilisateurs Windows" mais si quoi que ce soit, ce fil et d'autres fils reddit liés ont montré jusqu'à présent qu'il n'y a pas un groupe homogène d'"utilisateurs Windows". En fin de compte, une entreprise peut toujours suivre la direction que la majorité de ses clients veulent qu'elle aille, mais même cela laisse des problèmes. Et si le ratio était plutôt petit (et derrière chaque nombre se trouverait un nombre absolu énorme d'utilisateurs) ? Sur la base des commentaires ici, sur reddit et d'autres endroits, je n'ai pas l'impression qu'il y a une majorité écrasante pour une interface utilisateur ou une autre.

Ce qui nous amène à la proposition que quelques-uns d'entre nous ont proposée : ajouter plus d'options de personnalisation de l'interface utilisateur à Windows.

Comme vous le dites à juste titre, les options de personnalisation données doivent être mesurées avec soin, mais la personnalisation en elle-même ne doit pas être simplement écartée en tant qu'option. Comme vous l'avez dit, et à ce stade, je commence à me répéter, le changement de rayon d'angle proposé est un petit changement, donc tout impact d'en faire un choix de l'utilisateur sur l'interface utilisateur devrait être négligeable ou carrément inexistant. D'autres et moi-même avons également souligné les limites de cet exemple, telles qu'un ensemble de valeurs comprises entre 0 et 2 pour les rayons d'angle, afin de garantir que les utilisateurs ne peuvent pas simplement personnaliser leur Windows d'une manière qui briserait le "Windows UI Identité" que votre équipe souhaite créer.

Pour faire court, des options de personnalisation soigneusement mesurées en plus de ces changements de conception

@chigy
La plupart des gens conviendraient que 2px serait un bon rayon. Donner au reste une option pour l'éteindre serait un bon idéal.

La plupart des utilisateurs veulent que Windows soit à la pointe de l'interface utilisateur, mais les autres utilisateurs hérités ne veulent pas changer.

Ne sacrifiez pas le changement pour quelques-uns, donnez-leur simplement la possibilité de le désactiver.

@shaheedmalik
Il n'y a pas d'utilisateurs "anciens" ici et je ne vois pas non plus comment vous arrivez à "la plupart des utilisateurs veulent [des coins arrondis]" ou que l'apparence actuelle de Windows n'est pas "à la pointe de la technologie".

L'interface utilisateur est très subjective, mais cela ne signifie pas que nous pouvons simplement passer sous silence des opinions divergentes en tant qu'"héritage", "ne voulant pas changer", etc.

N'essayons pas simplement de rejeter ce que les autres utilisateurs disent comme des opinions d'"utilisateurs qui ne veulent pas se réveiller du passé" et de garder la discussion en cours passionnée mais aussi respectueuse comme elle l'a été jusqu'à présent.

Les utilisateurs @Felix-Dev Legacy sont ceux qui seraient restés sur Windows 7 si l'occasion leur était donnée, ceux qui étaient résistants aux modifications apportées dans Windows 8, ceux qui sont résistants aux modifications de l'interface utilisateur du système d'exploitation.

Apple et Google ont copié des fonctionnalités de Windows 8.1, les ont implémentées et les utilisateurs ont sauté sur ces plates-formes car elles étaient considérées comme à la pointe de la technologie. Pendant ce temps, Microsoft écoutant les anciens utilisateurs, réduit en raison d'une minorité vocale forte.

Dans ce cas particulier, la majorité veut des coins arrondis comme liés (https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/)

Le fait est que je ne suis pas un ancien utilisateur et il m'a semblé que vous veniez de jeter tout le monde n'aimant pas la poussée actuelle des coins arrondis (et la réduction possible de l'épaisseur des bordures) dans cette catégorie exacte. Je ne reçois pas non plus votre vote négatif pour mon message.

À propos du cas majoritaire : je n'étais au courant d'aucune enquête de conception de MS sur ce même sujet et sur la base des réactions de nombreux utilisateurs il y a un mois, lorsque des détails sur cette poussée sont apparus pour la première fois sur Internet, de nombreux utilisateurs n'étaient pas non plus au courant ( donc probablement pas été demandé). Si vous consultez ce post de reddit (qui a d'ailleurs trois fois plus de commentaires que le fil de discussion reddit que vous avez lié ci-dessus jusqu'à présent), vous remarquerez que d'après ce que nous savons, l'image n'est pas exactement claire. Je ne suis pas en mesure de prétendre que « cette position est clairement majoritaire » et je m'abstiendrai de le faire également à l'avenir.

Si je me trompe à propos de votre message, alors je m'excuse, mais d'après la façon dont je l'ai lu, il était clairement dédaigneux de toute voix plaidant contre ce changement, déclarant qu'il s'agissait de la voix d'un "utilisateur hérité qui ne veut pas de changement ". C'est irrespectueux envers moi et tous les autres ajouteraient leur voix à ce débat.

@Felix-Dev N'essayons pas de lire des opinions personnelles dans ces votes et réponses haut/bas.

La réponse simple est que ces modifications ne sont pas apportées sur un coup de tête ou pour copier d'autres styles d'interface utilisateur de plate-forme - mais à la suite de consultations, de commentaires et d'une volonté exprimée des utilisateurs et des développeurs.

Nous devrions essayer de garder les discussions constructives, donc pas sur la question de savoir si les changements doivent être apportés ou non, mais de quelle manière doivent-ils être apportés.

Les gens détestaient les coins arrondis du message d'origine car ils étaient trop ronds.
Ce nouvel article renvoie à cette proposition GitHub mise à jour. Les commentaires les plus récents reflètent les réponses à la proposition mise à jour. De plus, le message d'origine d'il y a un mois était lié pour montrer aux utilisateurs les modifications de la proposition originale à la proposition révisée.

Je suis d'accord, nous devrions revenir à la proposition et oublier ces derniers messages.

Je pense qu'il est assez clair à ce stade que ces changements seront apportés et tout ce que j'essaie de faire est de convaincre @chigy qu'il existe un cas pour une personnalisation soigneusement mesurée, quelque chose que chaque participant ici pourrait trouver utile à un moment donné - qu'il comme le changement actuel de l'interface utilisateur ou non. Tout comme moi et d'autres l'avons dit, y compris @shaheedmalik , l'ajout d'une sorte de personnalisation du rayon d'angle pourrait être un bon idéal à atteindre.

À l'heure actuelle, il existe une proposition visant à permettre aux développeurs de définir facilement leur propre CornerRadius sur chaque contrôle (#684), ce qui permet également à l'équipe d'ajouter CornerRadii aux contrôles par défaut.

Le faire au niveau du système d'exploitation est une tâche compliquée, et la recherche ne justifie pas tout à fait le temps et les efforts d'ingénierie nécessaires à sa mise en œuvre.

Mais vous avez clairement exprimé votre point de vue @Felix-Dev et si, après que les nouveaux contrôles sont entre les mains d'une majorité d'utilisateurs de Windows, les commentaires reçus pourraient conduire à ce que cette idée soit explorée à l'avenir.

J'ai mis à jour les spécifications pour supprimer "AppBarSeparator" de l'arrondi depuis que j'ai confirmé qu'il s'agissait d'une ligne de 1px.

J'ai mis à jour les spécifications pour supprimer "AppBarSeparator" de l'arrondi depuis que j'ai confirmé qu'il s'agissait d'une ligne de 1px.

@chigy À une mise à l'échelle de 100 %, ce sera 1 epx - mais à une mise à l'échelle de 200 %, 300 %, 400 %, cela peut nécessiter une certaine attention.

S'il s'agit vraiment d'une ligne et non d'un rectangle, définissez peut-être StrokeStartLineCap et StrokeEndLineCap sur PenLineCap.Round

@mdtauk

Le faire au niveau du système d'exploitation est une tâche compliquée, et la recherche ne justifie pas tout à fait le temps et les efforts d'ingénierie nécessaires à sa mise en œuvre.

Cette proposition semble déjà faire la plupart du travail, en ajoutant une propriété CornerRadius aux contrôles. La seule chose qui reste alors serait la création de la ressource SystemCornerRadius à laquelle ces contrôles pourraient se lier pour leur rayon d'angle réel (semblable à la façon dont vous utilisez aujourd'hui une ressource SystemAccentColor pour colorer les éléments de votre interface utilisateur dans la couleur d'accentuation définie par l'utilisateur dans l'application Paramètres.

Quant à la quantité de travail qu'il faudrait pour créer une telle ressource et la rendre actualisable via l'application Paramètres, il reste à MS à commenter. Mais étant donné le travail que cette proposition fait déjà de toute façon et aussi le travail précédent sous la forme d'exposer une ressource AccentColor, je ne vois pas en quoi ce serait aussi exigeant que vous le dites. Le niveau du système d'exploitation ne fournirait littéralement qu'une valeur de rayon de coin qui peut être lue et écrite, puis utiliser le même système que vous avez déjà en place pour la ressource de couleur d'accentuation d'aujourd'hui.

@mdtauk

Le faire au niveau du système d'exploitation est une tâche compliquée, et la recherche ne justifie pas tout à fait le temps et les efforts d'ingénierie nécessaires à sa mise en œuvre.

Cette proposition semble déjà faire la plupart du travail, en ajoutant une propriété CornerRadius aux contrôles. La seule chose qui reste alors serait la création de la ressource SystemCornerRadius à laquelle ces contrôles pourraient se lier pour leur rayon d'angle réel (semblable à la façon dont vous utilisez aujourd'hui une ressource SystemAccentColor pour colorer les éléments de votre interface utilisateur dans la couleur d'accentuation définie par l'utilisateur dans l'application Paramètres.

Quant à la quantité de travail qu'il faudrait pour créer une telle ressource et la rendre actualisable via l'application Paramètres, il reste à MS à commenter. Mais étant donné le travail que cette proposition fait déjà de toute façon et aussi le travail précédent sous la forme d'exposer une ressource AccentColor, je ne vois pas en quoi ce serait aussi exigeant que vous le dites. Le niveau du système d'exploitation ne fournirait littéralement qu'une valeur de rayon de coin qui peut être lue et écrite, puis utiliser le même système que vous avez déjà en place pour la ressource de couleur d'accentuation d'aujourd'hui.

Serait-ce un curseur ou une bascule ?

[X] Coins arrondis sur les commandes

Il n'y aurait pas qu'une seule valeur de rayon d'angle à définir d'ailleurs. Certains éléments n'auraient l'arrondi que d'un côté, ou seuls les coins supérieurs seraient arrondis. Les commandes volantes et contextuelles auront un rayon de 4 epx, alors que les autres commandes n'auront que 2 epx.

Vous définiriez de nombreuses variables à mesure que ce paramètre change dans le système d'exploitation. Et les tests alors ? Il y aurait aussi des attentes. Comment les utilisateurs réagiront-ils aux applications qu'ils décident d'ignorer la préférence de l'utilisateur ?
Comment communiquez-vous avec les utilisateurs quels contrôles sont contournés et lesquels ne le sont pas ? Certains contrôles auront des éléments de bordure intérieure ou extérieure. Ceux-ci auraient besoin de leurs valeurs CornerRadius ajustées pour assurer le calage correct des bords des formes.

En fin de compte, cela peut être un changement qui est bien accueilli sans trop de bruit, et il pourrait donc être considéré comme une réaction excessive d'ajouter une autre option au système d'exploitation.

@mdtauk @chigy
Cela nécessiterait certainement une certaine planification, mais l'équipe souhaite clairement que les développeurs puissent créer très facilement des contrôles au carré. En tant que tel, au lieu d'un paramètre de valeur de rayon d'angle, je serais bien avec un simple commutateur booléen UserRoundedCorners . En fait, l'idée de définir des valeurs était simplement d'ajouter encore plus d'options alors que les utilisateurs en désaccord avec cette décision visaient toujours à leur donner simplement la possibilité de rétablir l'apparence des commandes. Donc, ce ne sera pas du tout un problème.

Quant à la partie « encore une autre option » : il semble qu'il y ait déjà trop d'options disponibles pour l'utilisateur, ce qui est un problème entièrement différent et ne devrait pas être utilisé comme point de départ pour ne pas ajouter ce simple commutateur.

Windows et l'équipe de conception expliquent quotidiennement (sur twitter) comment il souhaite inclure les utilisateurs et non les exclure . Voici une chance où je pense qu'il est relativement facile pour MS d'ajouter une seule option pour respecter la grande variété d'opinions de leurs utilisateurs.

Comment les utilisateurs réagiront-ils aux applications qu'ils décident d'ignorer la préférence de l'utilisateur ?

Je ne pense pas que ce soit un problème aussi, tant que les applications Windows/éléments d'interface utilisateur essentiels le respecteraient (c'est-à-dire l'application Paramètres, l'application Sécurité, le Presse-papiers, les boutons de connexion/déconnexion du menu contextuel de la barre des tâches....). Les applications tierces sont libres d'utiliser le style qu'elles souhaitent, une simple note dans l'application Paramètres indiquant que les applications tierces ne sont pas garanties de suivre ce paramètre utilisateur conviendrait.

@mdtauk @chigy
Je crois que @Felix-Dev a raison sur celui-ci, un commutateur booléen avec une simple bascule pourrait être la voie à suivre pour la personnalisation au niveau de l'utilisateur, je pense qu'un curseur pour la personnalisation de cela au niveau de l'utilisateur compliquerait trop les choses, cependant si c'est un curseur avec 3 positions prédéfinies fixes, les choses pourraient changer.

Un curseur avec 3 options fixes permettrait un réglage supplémentaire qui pourrait avoir un changement de rayons d'angle plus drastique comme celui qui était proposé à l'origine, vous pourriez donc avoir :

Sharp - Les coins pointus comme ils le sont maintenant
Option médiane - Les nouveaux rayons plus petits
Arrondi - Le changement de rayon proposé à l'origine ou quelque chose d'encore plus arrondi

Cette option a le potentiel de satisfaire tous les groupes et en plus c'est un changement assez drastique pour que vous puissiez réellement faire passer cela comme une nouvelle fonctionnalité "Theming" dans Windows, même s'il s'agit plus d'un changement pour les développeurs en le qualifiant de nouveau Fonctionnalité "Theming" avec la mise en œuvre à bascule ou le curseur 3 prédéfinis, vous pouvez également la faire passer pour une nouvelle fonctionnalité pour les consommateurs.

Comment les utilisateurs réagiraient-ils aux applications qui décident d'ignorer la préférence de l'utilisateur ?

Je pense que l'utilisateur le verrait simplement comme il le fait actuellement avec la couleur d'accent lorsqu'elle n'est pas disponible, les applications tierces devraient être libres de faire ce qu'elles veulent, mais comme @Felix-Dev a déclaré que les éléments d'applications/UI Windows auraient certainement besoin de honorer la variable de l'utilisateur.

Je ne pense pas qu'il soit nécessaire de mettre une note dans les paramètres indiquant que les applications tierces n'honoreront pas le paramètre, il n'était pas nécessaire de mettre un avertissement dans la section des couleurs d'accent, alors croyez que c'est la même chose que bien.

Le faire au niveau du système d'exploitation est une tâche compliquée, et la recherche ne justifie pas tout à fait le temps et les efforts d'ingénierie nécessaires à sa mise en œuvre.

Mais vous avez clairement exprimé votre point de vue @Felix-Dev et si, après que les nouveaux contrôles sont entre les mains d'une majorité d'utilisateurs de Windows, les commentaires reçus pourraient conduire à ce que cette idée soit explorée à l'avenir.

Je sens que je dois souligner quelque chose ici. Bien que je ne sois pas convaincu par les changements proposés de toute façon (je dois travailler avec trop de styles d'interface utilisateur sur différents écosystèmes chaque jour pour des incohérences ou des changements qui me dérangent plus), j'ai l'impression que cet état d'esprit n'est pas bon dans l'ordre pour créer une expérience utilisateur riche et conviviale.

Veuillez ne pas publier des fonctionnalités qui sont terminées à 80 % et qui pourraient ou non être portées à 100 % dans la prochaine version.
Ce qui arriverait probablement, c'est qu'aucun développeur ne passerait le temps à tester et développer ses applications pour les bordures arrondies ou non arrondies. Et pourquoi le feraient-ils. Le système utilise maintenant des arrondis, pourquoi quelqu'un voudrait-il que son application soit légèrement différente du système d'exploitation (sinon, il opterait de toute façon pour un thème complet)
S'il y avait une bascule à l'échelle du système, il y aurait une incitation à la mettre en œuvre.
Mais si vous faites les choses de cette façon, vous n'aurez jamais besoin d'une bascule, car aucune application ne verra le besoin de l'implémenter en premier lieu.

Sur le sujet d'origine :
Je pense que les bordures 2px sont superbes, à l'exception des zones de liste déroulante.
La surbrillance du dernier élément ne doit pas laisser de bordure blanche en dessous (ou du moins pas plus qu'à gauche et à droite, bien sûr, cela signifie que les coins de surbrillance inférieurs doivent également être arrondis) et peut-être qu'il ne devrait pas y avoir de coins arrondis dans le état développé entre la boîte et C'est le menu volant. J'ai l'impression que ça donne ce regard étrange et décousue entre eux.
Peut-être qu'il serait préférable de réduire le flyout de 2px de chaque côté et de le laisser sans coins arrondis sur le dessus. De cette façon, cela ressemblerait à un morceau de papier tiré d'un distributeur. (J'espère que vous pouvez comprendre ce que je veux dire :D malheureusement, je n'ai pas d'outils disponibles pour le moment pour l'esquisser)

Sur le sujet d'origine :
Je pense que les bordures 2px sont superbes, à l'exception des zones de liste déroulante.
La surbrillance du dernier élément ne doit pas laisser de bordure blanche en dessous (ou du moins pas plus qu'à gauche et à droite, bien sûr, cela signifie que les coins de surbrillance inférieurs doivent également être arrondis) et peut-être qu'il ne devrait pas y avoir de coins arrondis dans le état développé entre la boîte et C'est le menu volant. J'ai l'impression que ça donne ce regard étrange et décousue entre eux.
Peut-être qu'il serait préférable de réduire le flyout de 2px de chaque côté et de le laisser sans coins arrondis sur le dessus. De cette façon, cela ressemblerait à un morceau de papier tiré d'un distributeur. (J'espère que vous pouvez comprendre ce que je veux dire :D malheureusement, je n'ai pas d'outils disponibles pour le moment pour l'esquisser)

Je sais ce que vous décrivez et j'en ai tenu compte pour mes maquettes de conception. Le problème, c'est que cela signifie que ComboBox obtiendrait son propre modèle de menu volant, ce qui le rendrait différent des menus contextuels, des menus volants, des préfixes, des suffixes, des menus contextuels, etc.

C'est ce que je voulais dire (sauf que la boîte elle-même pouvait garder les coins inférieurs arrondis)
Oui, les différents flyouts seraient différents, mais là encore, il existe intrinsèquement deux types de flyout.
Ceux qui sont attachés à quelque chose et ceux qui ne le sont pas. Qu'ils devraient maintenant être différents n'est que le coût de faire des coins arrondis ;)
De plus, si le rayon du coin devenait stylable, ne pourrait-il pas simplement être défini par le contrôle parent.

Mon XAML est un peu rouillé mais un modèle Combobox comme :

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

De plus, si le rayon du coin devenait stylable, ne pourrait-il pas simplement être défini par le contrôle parent.

Mon XAML est un peu rouillé mais un modèle Combobox comme :

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

C'est similaire à la façon dont vous pouvez remplacer le style, mais pour une utilisation dans les modèles, vous aurez besoin de styles séparés pour chaque orientation.

<Thickness x:Name="FlyoutLooseCornerRadius" Value="4,4,4,4"/>

Orientations :

• Bas
• BasBordAlignéGauche
• BasBordAlignéDroite
• Complet
• La gauche
• Bord GaucheAlignementBas
• Bord gauchealigné en haut
• Droit
• Bord droitaligné en bas
• Bord droitaligné en haut
• Sommet
• HautBordAlignéGauche
• HautBordAlignéDroite

Le Flyout est incorporé à l'intérieur du contrôle ComboBox. Ainsi, le contrôle aurait une propriété CornerRadius qui affecterait uniquement le ComboBox, pas le menu volant inclus, ce qui aurait pour effet de remplacer un ThemeResource.

<ComboBox CornerRadius="2,2,2,2">  
      <x:String>Blue</x:String>
      <x:String>Green</x:String>
      <x:String>Red</x:String>
      <x:String>Yellow</x:String>
</ComboBox>  

Suite à l'ajustement de la propriété CornerRadius sur le Flyout lorsqu'il est aligné et attaché aux ComboBoxes (et à d'autres contrôles), il peut nécessiter l'ajout de TopEdgeAligned et BottomEdgeAligned à l'énumération FlyoutPlacementMode pour obtenir le résultat souhaité.

_(Image mise à jour)_

J'ai également inclus un examen plus approfondi à 800% du style Flyout. Les deux bordures garantiraient que les menus volants semblent élevés dans les thèmes clair et sombre avec ou sans l'ombre.

Cela a l'air très bien.
Bien sûr, l'apparence attachée semble un peu étrange lorsque l'élément auquel vous l'attachez est plus petit que le menu volant, mais c'est certainement quelque chose que l'application individuelle décide.
La mise en évidence des éléments de la rangée du bas ne devrait probablement pas être arrondie en bas (puisque le haut n'est pas pour la rangée du haut), mais ce n'est probablement pas intentionnel.

Soit dit en passant, je viens de remarquer que ce "look joint" est le fonctionnement de la barre de menu supérieure de MacOs, donc ce look ne semble pas être étrangement rare ;)

Cela a l'air très bien.
Bien sûr, l'apparence attachée semble un peu étrange lorsque l'élément auquel vous l'attachez est plus petit que le menu volant, mais c'est certainement quelque chose que l'application individuelle décide.
La mise en évidence des éléments de la rangée du bas ne devrait probablement pas être arrondie en bas (puisque le haut n'est pas pour la rangée du haut), mais ce n'est probablement pas intentionnel.

Soit dit en passant, je viens de remarquer que ce "look joint" est le fonctionnement de la barre de menu supérieure de MacOs, donc ce look ne semble pas être étrangement rare ;)

J'avais oublié l'arrondi, j'ai donc mis à jour l'image pour corriger cela, et j'ai également ajouté un peu plus de détails avec l'exemple Zoomed - oh et j'ai inclus l'état Hover

Je ne sais pas si je préfère que les éléments du milieu aient un reflet arrondi ou non, car d'un côté c'est plus cohérent, de l'autre cela laisse ces petits looks agressifs (Ok maintenant je fais juste des trucs :) ) blanc vif des espaces entre les éléments mis en évidence et la bordure.
Mais c'est quelque chose que je laisse aux vrais designers décider :D

Je ne sais pas si je préfère que les éléments du milieu aient un reflet arrondi ou non, car d'un côté c'est plus cohérent, de l'autre cela laisse ces petits looks agressifs (Ok maintenant je fais juste des trucs :) ) blanc vif des espaces entre les éléments mis en évidence et la bordure.
Mais c'est quelque chose que je laisse aux vrais designers décider :D

Je suis d'accord, je suis dans deux esprits à ce sujet aussi. Je pense que je l'aime bien droit, mais comme les contrôles invoquant le menu volant seront arrondis, et ce sont des contrôles dans un contrôle, ils devraient être arrondis.

Et certains menus contextuels contiendront des contrôles qui ne couvrent pas toute la largeur du menu volant, donc la sélection arrondie fonctionnera pour ceux

Je ne sais pas si je préfère que les éléments du milieu aient un reflet arrondi ou non, car d'un côté c'est plus cohérent, de l'autre cela laisse ces petits looks agressifs (Ok maintenant je fais juste des trucs :) ) blanc vif des espaces entre les éléments mis en évidence et la bordure.
Mais c'est quelque chose que je laisse aux vrais designers décider :D

Je ressens la même chose. Si la liste déroulante est de la même taille que la zone de liste déroulante, alors elles doivent rester droites au point d'origine, sinon le côté qui ne s'aligne pas doit être rond.

@mdtauk @Qowy @shaheedmalik vous serait-il possible de créer votre propre problème spécifique aux combobox ? Ce fil de discussion concerne le rayon d'angle en général et non certains cas spécifiques qui pourraient facilement engendrer une toute nouvelle conversation comme on le voit ici, et ainsi éclipser les points de discussion sur l'approche générale.

S'il vous plaît ne vous méprenez pas, mais si nous avons de telles discussions spécifiques pour de nombreux contrôles, ce fil perdra facilement son objectif général.

Très appréciée!

PS : À propos des éléments en surbrillance sans bordure : l'élément en surbrillance doit absolument être un rectangle. Faire en sorte qu'il ait des couleurs arrondies est juste bizarre.

Je suis probablement minoritaire ici avec mon avis, mais changer les rayons d'angle des commandes communes est honnêtement une idée terrible. En regardant l'exemple de menu ci-dessus de @mdtauk et en le comparant au menu Edge actuel, je suis un peu dégoûté. Les choses s'arrangent enfin avec le design Fluent et tout semble enfin cohérent et vraiment bon. Maintenant, changeons tout pour ressembler au Web ? Non... laissez le Web être le Web et laissez Windows (et les contrôles communs) tranquilles. Si les développeurs souhaitent implémenter des coins arrondis à l'aide de contrôles tiers dans leurs propres applications, qu'il en soit ainsi. Mais commencer à changer l'apparence par défaut maintenant n'est qu'une hérésie - qu'Apple soit Apple, Google soit Google et le Web soit le Web. Vous continuez simplement à être Microsoft et à faire votre truc - ça marche, alors laissez-le fonctionner. Pour ma part, j'adore l'apparence et la convivialité de Microsoft Windows 10 de la conception Fluent et je veux que mes applications ressemblent à Windows - pas à Apple, Google ou le Web. Je ne supporte pas l'apparence de Chrome - Edge est plus beau à des années-lumière et Windows est bien meilleur en termes de forme et de fonction que macOS. Et, TBH, ramenez Windows 10 Mobile sur le téléphone. Bon sang, arrête d'abandonner si vite et laisse le design Fluent tranquille et laisse-le faire son travail.

@mdtauk

Le faire au niveau du système d'exploitation est une tâche compliquée, et la recherche ne justifie pas tout à fait le temps et les efforts d'ingénierie nécessaires à sa mise en œuvre.

Cette proposition semble déjà faire la plupart du travail, en ajoutant une propriété CornerRadius aux contrôles. La seule chose qui reste alors serait la création de la ressource SystemCornerRadius à laquelle ces contrôles pourraient se lier pour leur rayon d'angle réel (semblable à la façon dont vous utilisez aujourd'hui une ressource SystemAccentColor pour colorer les éléments de votre interface utilisateur dans la couleur d'accentuation définie par l'utilisateur dans l'application Paramètres.
Quant à la quantité de travail qu'il faudrait pour créer une telle ressource et la rendre actualisable via l'application Paramètres, il reste à MS à commenter. Mais étant donné le travail que cette proposition fait déjà de toute façon et aussi le travail précédent sous la forme d'exposer une ressource AccentColor, je ne vois pas en quoi ce serait aussi exigeant que vous le dites. Le niveau du système d'exploitation ne fournirait littéralement qu'une valeur de rayon de coin qui peut être lue et écrite, puis utiliser le même système que vous avez déjà en place pour la ressource de couleur d'accentuation d'aujourd'hui.

Serait-ce un curseur ou une bascule ?
[X] Coins arrondis sur les commandes
Il n'y aurait pas qu'une seule valeur de rayon d'angle à définir d'ailleurs. Certains éléments n'auraient l'arrondi que d'un côté, ou seuls les coins supérieurs seraient arrondis. Les commandes volantes et contextuelles auront un rayon de 4 epx, alors que les autres commandes n'auront que 2 epx.
Vous définiriez de nombreuses variables à mesure que ce paramètre change dans le système d'exploitation. Et les tests alors ? Il y aurait aussi des attentes. Comment les utilisateurs réagiront-ils aux applications qu'ils décident d'ignorer la préférence de l'utilisateur ?
Comment communiquez-vous avec les utilisateurs quels contrôles sont contournés et lesquels ne le sont pas ? Certains contrôles auront des éléments de bordure intérieure ou extérieure. Ceux-ci auraient besoin de leurs valeurs CornerRadius ajustées pour assurer le calage correct des bords des formes.
En fin de compte, cela peut être un changement qui est bien accueilli sans trop de bruit, et il pourrait donc être considéré comme une réaction excessive d'ajouter une autre option au système d'exploitation.

Avoir un rayon de coin de 2epx ici, un rayon de coin de 4epx là-bas et un autre endroit différent parce que 2 ou 4 ne semblent pas tout à fait corrects est une UX terrible. Laissez les contrôles communs tels qu'ils sont - Travail terminé... passez à autre chose de grand.

@chigy
J'ai donc fait un décompte à partir des réponses dans le fil reddit que j'ai commencé il y a quelques jours et le voici (malheureusement, il ne semble pas y avoir de moyen évident de voir facilement le nombre total d'utilisateurs qui ont participé):

Opinions exprimées en faveur du rayon d'angle (UI à contre-courant) : 18
Opinions exprimées UI pro-current (et rayon de coin contra): 12 (+1 si je m'inclus en tant @shaheedmalik dans le

Le reste:

• Demander à MS de fournir des choix d'interface utilisateur
• Bien avec les deux
• N'a pas exprimé d'opinion sur la proposition
• A exprimé une frustration générale concernant les incohérences du système Windows (c'est-à-dire les programmes Win32 par rapport aux applications UWP)

Surtout le dernier groupe (frustration) était une bonne partie des personnes qui ont participé au fil.

En résumant le résultat, nous voyons que nous avons des factions importantes à la fois pour les coins arrondis (la proposition) et pour les coins carrés (UI actuelle). Ajoutez à cela le groupe de personnes qui ont exprimé leur souhait de pouvoir basculer entre ces deux styles dans le système.
Cependant, mis à part les coins arrondis ou non, la réponse la plus donnée - de loin - est d'apporter enfin de la cohérence au système Windows dans son ensemble. WinUI 3.0 et les équipes MS auront du pain sur la planche pour regrouper tous les différents composants du système Windows et les applications UWP sous un seul langage de conception d'interface utilisateur.

@chigy
Avec tous les discours de l'équipe de conception Microsoft pour "inclure" les utilisateurs au lieu de les "exclure", je pense que ce fil et le fil reddit ci-dessus montrent qu'il y a de bonnes raisons de fournir une option simple dans l'interface utilisateur pour basculer entre le coin arrondi proposé UI et l'UI actuelle (coins pointus).

@Felix-Dev Techniquement, le post que j'ai fait concernait le contrôle Flyout, le ComboBox n'est qu'un des contrôles qui a un composant flyout.

Il m'arrive de penser qu'arrondir à tous les coins de rue a du sens en toutes circonstances. Et l'équipe a décidé que les menus volants et les boîtes de dialogue utiliseraient 4 coins epx, et les autres contrôles utiliseraient 2 epx.

@mdtauk ,
comme je l'ai dit, s'il vous plaît ne vous méprenez pas. Je pense qu'il est tout à fait correct de souligner l'interface utilisateur de contrôle spécifique dans ce fil (comme j'ai posé des questions sur l'épaisseur de coin étrange pour les rayons de coin de case à cocher dans l'exemple d'arborescence).
Juste, s'il y a une conversation couvrant plusieurs publications concernant un élément d'interface utilisateur spécifique (tel que flyouts/comboboxes/...), je pense qu'il est préférable de créer un problème séparé pour ce particulier. Et comme vous l'avez vu, votre article sur les flyouts a rapidement conduit à une discussion sur les combobox. Imaginez maintenant que quelqu'un entame une conversation sur la façon dont les ombres de mise au point devraient ressembler et nous avons tout un "gâchis" (comme dans plusieurs éléments d'interface utilisateur spécifiques discutés à proximité) à partir de là où il sera difficile de ramener le fil au général proposition et comment y faire face.

@mdtauk ,
comme je l'ai dit, s'il vous plaît ne vous méprenez pas. Je pense qu'il est tout à fait correct de souligner l'interface utilisateur de contrôle spécifique dans ce fil (comme j'ai posé des questions sur l'épaisseur de coin étrange pour les rayons de coin de case à cocher dans l'exemple d'arborescence).
Juste, s'il y a une conversation couvrant plusieurs publications concernant un élément d'interface utilisateur spécifique (tel que flyouts/comboboxes/...), je pense qu'il est préférable de créer un problème séparé pour ce particulier. Imaginez simplement que quelqu'un entame une conversation sur la façon dont les ombres de mise au point devraient ressembler et que nous avons tout un gâchis qui commence où il sera difficile de ramener le fil à la proposition générale et comment y faire face.

Je n'ai pas l'intention de faire un problème séparé uniquement pour les flyouts, mais je parlais spécifiquement des rayons d'angle de ce contrôle.

Je me demande si @chigy pourrait nous offrir une sorte d'estimation quand nous pourrons voir une boîte à outils de conception mise à jour avec toutes les conceptions de contrôle mises à jour, afin que la conversation puisse passer à plus de détails que des plaintes générales concernant la décision de les modifier pour commencer avec.

Si vous comptez les publications, vous devez également compter les votes positifs.

@shaheedmalik
Ne pas compter explicitement les décomptes, car je ne sais pas exactement ce que ces votants pensent de ces types d'interface utilisateur (par exemple, ils pourraient convenir à l'un ou l'autre choix mais toujours comme la proposition de cordon arrondi tout comme l'interface utilisateur actuelle). Plus important encore, ils ont peut-être voté pour une publication en raison d'une certaine partie de cette publication, par exemple en soulignant les incohérences de l'interface utilisateur. Par conséquent, je n'ai compté que les messages réels où vous pouvez clairement voir une approbation pour l'une ou l'autre interface utilisateur dans la déclaration de l'auteur.

FWIW, "2px semble être l'endroit idéal." a obtenu le plus de votes positifs avec 54 points.

Il existe également un article très bien noté (+21 - 4e place) appelant à un "support thématique pour l'utilisateur final", bien que je ne puisse pas déterminer si tous ces votes positifs concernent la partie appel à la personnalisation ou la partie où l'auteur critique le manque cohérence dans le système.

Je me demande si @chigy pourrait nous offrir une sorte d'estimation quand nous pourrons voir une boîte à outils de conception mise à jour avec toutes les conceptions de contrôle mises à jour, afin que la conversation puisse passer à plus de détails que des plaintes générales concernant la décision de les modifier pour commencer avec.

Merci de demander. J'ai créé un lien vers les compositions de conception dans la section « Remarque importante » du problème, alors assurez-vous de vérifier cela.

En général, je veux m'assurer que nous maintenons la conversation ici centrée sur la façon dont nous pouvons faire fonctionner les coins arrondis dans WinUI. Je sais que les gens ont des opinions divergentes sur cette idée ou même si les coins arrondis sont une bonne idée en général. J'ai donc pensé qu'il valait la peine de mentionner que cela fait partie de l'orientation globale de la conception de Windows qui est en train d'être chassée d'une autre équipe de Microsoft. Nous essayons simplement de comprendre comment faire fonctionner WinUI avec cette nouvelle direction de conception, ce qui facilite la tâche des développeurs. Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une « chose » dans Windows. En d'autres termes, le coin arrondi est déjà un plan, et nous voulions donc vous informer et consulter notre communauté WinUI pour nous assurer que nous implémentons cette capacité de manière responsable. J'espère que cela a du sens.

Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une « chose » dans Windows. En d'autres termes, le coin arrondi est déjà un plan, et nous voulions donc vous informer et consulter notre communauté WinUI pour nous assurer que nous implémentons cette capacité de manière responsable.

Je soupçonne que beaucoup de gens ici aimeraient parler aux personnes ayant cette autorité, car c'est le problème majeur pour beaucoup d'entre nous.

Merci de demander. J'ai créé un lien vers les compositions de conception dans la section « Remarque importante » du problème, alors assurez-vous de vérifier cela.

En général, je veux m'assurer que nous maintenons la conversation ici centrée sur la façon dont nous pouvons faire fonctionner les coins arrondis dans WinUI. Je sais que les gens ont des opinions divergentes sur cette idée ou même si les coins arrondis sont une bonne idée en général. J'ai donc pensé qu'il valait la peine de mentionner que cela fait partie de l'orientation globale de la conception de Windows qui est en train d'être chassée d'une autre équipe de Microsoft. Nous essayons simplement de comprendre comment faire fonctionner WinUI avec cette nouvelle direction de conception, ce qui facilite la tâche des développeurs. Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une « chose » dans Windows. En d'autres termes, le coin arrondi est déjà un plan, et nous voulions donc vous informer et consulter notre communauté WinUI pour nous assurer que nous implémentons cette capacité de manière responsable. J'espère que cela a du sens.

Vous avez mentionné que des conversations sur certaines choses sont toujours en cours, telles que l'épaisseur de la bordure de TextBox, etc. J'ai donc supposé que ces conceptions étaient une _idée initiale_ plutôt qu'une finale. (Je suppose que j'espérais pouvoir toujours influencer des choses comme la zone de texte, les boutons, les cases à cocher, etc.)

Je pense connaître la réponse à cette question, mais je vais quand même demander : est-il prévu de partager ces conceptions d'interface utilisateur Windows que l'équipe a décidées ?

Ces modifications prévues par Windows s'appliqueront-elles également aux styles visuels Win32 et aux barres de titre de la fenêtre Shell, etc. Si tel est le cas, WPF devrait probablement également mettre à jour leurs contrôles par défaut lors de l'exécution sur les versions de Windows auxquelles ce nouveau style s'applique. (J'ai déjà suggéré que cela devrait arriver #699)

Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une « chose » dans Windows. En d'autres termes, le coin arrondi est déjà un plan, et nous voulions donc vous informer et consulter notre communauté WinUI pour nous assurer que nous implémentons cette capacité de manière responsable.

Je soupçonne que beaucoup de gens ici aimeraient parler aux personnes ayant cette autorité, car c'est le problème majeur pour beaucoup d'entre nous.

Je suppose que cela apparaîtra dans le Feedback Hub lorsque les modifications de conception seront mises en ligne - Cela atteindra très probablement l'équipe Windows.

Vous avez mentionné que des conversations sur certaines choses sont toujours en cours, telles que l'épaisseur de la bordure de TextBox, etc. J'ai donc supposé que ces conceptions étaient une _idée initiale_ plutôt qu'une finale. (Je suppose que j'espérais pouvoir toujours influencer des choses comme la zone de texte, les boutons, les cases à cocher, etc.)

Je pense connaître la réponse à cette question, mais je vais quand même demander : est-il prévu de partager ces conceptions d'interface utilisateur Windows que l'équipe a décidées ?

@mdtauk
Oui, et pour être très transparent ici... La réalité est que plus tôt la conversation sur ce problème particulier ralentit, plus tôt je pourrai m'y mettre... :)

@chigy Je m'excuse si j'ai contribué au déraillement de la conversation et au ralentissement des progrès. J'ai toujours voulu aider et m'assurer que WinUI 3.0 est aussi beau que possible !

@chigy
Je suis confus maintenant. Vous êtes une personne travaillant dans l'équipe de conception Windows Fluent, WinUI est dit "[...] plate-forme d'interface utilisateur native hautement optimisée utilisée pour créer Windows lui-même" (cité à partir d' ici , section "Avantages de WinUI 3". Donc, si ce n'est pas l'endroit pour influencer le langage de conception de Windows 10, alors qu'est-ce que c'est ?

Je ne sais pas quoi penser de ta réponse. En gros, vous nous demandez des commentaires, mais il s'avère que nous n'avons jamais eu beaucoup de chance d'influencer la proposition de toute façon ? S'il n'y a personne avec l'autorité réelle dans ce poste, alors tout ce que nous faisons ici est essentiellement de l'air chaud. Même dans des cas comme celui de Martin où il publie ses concepts de design dans l'espoir qu'ils soient mis en œuvre par l'équipe de conception. WinUI ne peut pas styliser les contrôles différemment de l'endroit où "l'autorité de conception de Windows" le souhaite, car comme l'équipe WinUI elle-même l'a dit: "WinUI 3.0+ sera L'interface utilisateur Windows".

@chigy
Moi et d'autres avons investi beaucoup de temps, d'énergie et de passion pour essayer de souligner que les "utilisateurs de Windows" n'est pas un groupe homogène comme certains de vos commentaires semblaient l'avoir suggéré. Nous vous avons montré qu'il y avait des voix en dehors de celles de Martin et d'autres qui n'aimaient pas la nouvelle mise à jour de l'interface utilisateur et voulaient donc plaider en faveur d'une personnalisation de l'interface utilisateur soigneusement mesurée.

Vous avez également l'impression d'ignorer cette demande même. Vous dites "Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une "chose" dans Windows.". Moi et d'autres n'appelions pas à rejeter cette poussée d'interface utilisateur ces derniers jours, mais à suivre votre propre discours de conception sur twitter "d'inclure les utilisateurs" et de ne pas les exclure. Nous avons demandé une option, pas une inversion du mouvement.
Pourtant, jusqu'à présent, nous n'avons pas eu beaucoup de reconnaissance en dehors de "L'option de fournir un paramètre utilisateur pour que l'utilisateur puisse choisir un angle d'arrondi est intéressante. Cependant, cela a aussi beaucoup à voir avec ce retour d'information sur d'autres caractéristiques importantes que nous devons peser dans le système Windows dans son ensemble.". Je suppose que c'est un début, mais où en sommes-nous maintenant ?

Vous dites que vous n'appartenez pas à l'équipe réelle ayant autorité sur la conception de Windows. Cela signifie que nous avons tous parlé à la mauvaise personne depuis le début ! Si nous n'avons jamais parlé à un membre qui fait partie de l'équipe, je me demande pourquoi vous n'auriez pas pu le dire plus tôt.

Je suis déçu, après toute l'énergie investie, d'apprendre maintenant que je n'ai jamais parlé avec quelqu'un d'autorité pour commencer. En gros, tous les commentaires et les autres que j'ai recueillis, plaidant en faveur de la personnalisation de l'interface utilisateur, n'aboutiront fondamentalement à rien (parce que vous n'êtes même pas une personne à convaincre).

Je suis désolé, je n'arrive pas à comprendre. Un membre de l'équipe de conception Windows Fluent du référentiel censé piloter l'interface utilisateur de Windoiws nous dit maintenant après des jours que nous n'avons jamais parlé à une personne qui comptait vraiment.

Désolé si cela ressemble à un coup de gueule, mais je suis un peu choqué ici. Vous ne savez peut-être pas combien j'ai investi dans cette discussion particulière (et d'autres qui ont écrit des réponses passionnées), mais j'aimerais demander des éclaircissements.

Où en est notre appel à la personnalisation de l'interface utilisateur ? Ce référentiel a-t-il vraiment plus d'importance pour les discussions sur l'interface utilisateur Windows ?

Je laisse avec :

" [WinUI 3.0] La plate-forme d'interface utilisateur native de WindowsWinUI est la plate-forme d'interface utilisateur native hautement optimisée utilisée pour créer Windows lui-même, désormais plus largement disponible pour que tous les développeurs puissent l'utiliser pour atteindre Windows.

@Felix-Dev J'espérais influencer, pas insister pour que mes conceptions deviennent les conceptions réelles. Je suis un designer passionné de Windows depuis l'époque de Windows Vista/7/Zune/Windows Phone.

@mdtauk
En effet, même si vous n'auriez certainement rien contre l'adoption par MS de vos idées, n'est-ce pas ? Après tout, vous en êtes convaincu !

Désolé si cela s'est produit parce que vous étiez arrogant (et pour être juste avec moi, vous avez également dit que vos propositions pourraient arriver comme ça), mais la réponse de @chigy a été assez

Équipe WinUI != Équipe de développement Windows.

Windows 10 est le système d'exploitation actuel, mais Windows Lite et Windows Core OS sont les orientations futures.

@chigy examine évidemment ce que l'équipe Windows prévoit de faire au shell du système d'exploitation et veut s'assurer que WinUI 3.0 y trouvera son compte. Les applications Windows telles que Calculatrice, Paramètres, Flyouts de la barre des tâches et Shell, etc., utiliseront probablement toutes WinUI 3.0, elles devront donc être sur la même page, en termes de conception.

L'équipe Fluent Design de Microsoft établit les règles (couleurs, styles et tailles de police, matériaux, etc.) que d'autres équipes Microsoft suivent comme WinUI, Windows, Xbox, Office, Bing, Teams, Fabric, Fluent Web avec leur travail de conception d'interface utilisateur.

Je suis sûr que je serai corrigé si j'ai mal compris la structure ici.

Mes idées sur lesquelles j'ai contribué à ce référentiel - j'ai essayé de combler le fossé entre Fabric Web et WinUI 3.0 - j'ai également inclus des réflexions sur lesquelles je réfléchis depuis l'époque de Win8.

Une précision serait en effet sympa, car voici comment je l'ai compris :

@chigy est membre de la Windows Fluent Design Team et avec FD (Fluent Design) étant le langage de conception de Windows 10, elle sera donc membre de la Windows Design Team.

Ensuite, il y a WinUI 3.0 qui a été officiellement décrit comme la plate-forme qui pilote Windows et est utilisée pour créer Windows lui-même. Les discussions sur la conception de l'interface utilisateur Windows se sentent donc chez elles ici.
Également sur la base de la description ci-dessus, cela signifierait que les équipes de développement Windows utiliseront WinUI pour réaliser à la fois les applications et l'interface utilisateur du système. Sinon, il doit être indiqué explicitement dans ces fils de discussion de proposition d'interface utilisateur que vous ne parlerez pas à une personne qui compte réellement et que la proposition concerne uniquement les commentaires sur les implémentations réelles et non sur la conception de l'interface utilisateur .

Et même si l'équipe de conception Windows Fluent et l'équipe WinUI ne sont @chigy ne nous a jamais informés que nous n'avions jamais parlé à quelqu'un qui compte vraiment. Nous avons investi du temps et de l'énergie (vous avec vos concepts de contrôle, moi pour essayer de recueillir des commentaires, nous avons tous les deux des discussions animées et sans oublier tous les autres qui ont participé avec passion) alors qu'en fin de compte, nous n'avons jamais parlé avec un véritable membre de l'équipe Windows UI, quelqu'un que nous pourrions réellement essayer de convaincre de nos idées et croyances.

Nous n'avons pas vraiment le pouvoir de conclure que les coins arrondis ne sont pas une « chose » dans Windows. En d'autres termes, le coin arrondi est déjà un plan, et nous voulions donc vous informer et consulter notre communauté WinUI pour nous assurer que nous implémentons cette capacité de manière responsable. J'espère que cela a du sens.

Eh bien, c'est une énorme déception pour moi, comme d'autres l'ont déclaré, c'est un énorme problème pour beaucoup d'entre nous, donc si vous n'avez aucun pouvoir sur cela, puis-je demander poliment à @chigy : à qui devrions-nous parler ? Sinon, comment pouvons-nous faire entendre notre voix sur ce changement d'interface utilisateur clairement controversé que beaucoup d'utilisateurs n'aiment pas ?

Ceci est très similaire au discours qui s'est produit lors du développement de Windows 10 il y a des années lorsqu'il y a eu une proposition de transformer les images de profil Square en images circulaires, de nombreuses personnes n'ont pas aimé cela et sont allées au hub de commentaires. Il y avait plusieurs messages dans le hub de commentaires avec plus de 1000000+ votes positifs de soutien, demandant que cela ne soit pas fait.

La réponse consistait essentiellement à dire à nouveau aux gens que le changement allait être effectué quelle que soit leur opinion...

Je reformulerais ce message pour qu'il soit moins condescendant et insultant @Felix-Dev

@mdtauk
où est mon post insultant ?

Je n'appelle personne de nom, je n'appelle pas de gros mots WinUI, je décris ce problème avec des mots insultants. Je n'attaque personne personnellement, en fait je n'attaque rien.

@mdtauk
où est mon post insultant ?

Je n'appelle personne de nom, je n'appelle pas de gros mots WinUI, je décris ce problème avec des mots insultants. Je n'attaque personne personnellement, en fait je n'attaque rien.

@chigy est la personne chargée de travailler sur la conception des contrôles WinUI. Si vous avez confondu son rôle avec celui des équipes Windows ou Fluent, vous ne devriez pas dire que son rôle n'a pas d'importance et vous ne devriez pas le rendre personnel.

@mdtauk
« Chigusa Sansen est responsable de programme principal dans l'équipe de la plate-forme d'interface utilisateur XAML et fait partie des membres principaux de Fluent Design System » (source : https://mybuild.techcommunity.microsoft.com/speaker/545575?source=sessions)

Elle a également tenu la partie FD liée à Windows dans cette session.

Et à propos de la partie "une personne qui compte vraiment". Je ne considère pas cela comme insultant car dans notre cas, elle a effectivement dit qu'elle ne faisait pas partie de l'équipe qui est en train de décider de la direction de l'interface utilisateur choisie pour Windows. Je n'ai pas attaqué Miss Chigusa Sansen, je ne l'ai pas ridiculisée ni l'ai insultée. J'ai simplement dit ce qu'elle nous a dit personnellement.

Et à propos de la partie "une personne qui compte vraiment". Je ne considère pas cela comme insultant car dans notre cas, elle dit en effet qu'elle ne fait pas partie de l'équipe qui décide en fait de la direction de l'interface utilisateur choisie pour
Les fenêtres.

Eh bien, je trouve ça insultant. D'autant plus que vous semblez avoir mal compris le but de la discussion, au lieu d'être "induit en erreur"

@mdtauk
nous sommes sur une longueur d'onde différente ici et cela ne sert à rien d'essayer de spéculer pourquoi cela pourrait être ...

Lorsque nous avons commencé cette discussion sur le mouvement général de l'interface utilisateur, Mlle Chigusa Sansen ou d'autres membres de l'équipe WinUI n'ont clairement indiqué que ce fil n'était pas le bon endroit pour cette discussion. Au lieu de cela, les gens ont commencé à discuter avec passion, arguant du pro-/contre- ce mouvement pensant qu'ils parlaient à quelqu'un qui serait - pour la nature de cette discussion - un poste pertinent en matière d'interface utilisateur chez Microsoft/Windows.

Chigusa y a même participé et vous avez également librement ajouté des images de contrôle dans l'espoir d'influencer la direction de l'interface utilisateur et sans que personne de MS n'intensifie davantage le sentiment que c'est l'endroit idéal pour discuter de la conception générale de l'interface utilisateur. Ma plainte est , et vous semblez avoir manqué cela, que @chigy a mis si longtemps pour simplement nous dire qu'il n'y a vraiment pas grand intérêt à avoir cette discussion ici, car elle ne fait apparemment même pas partie de l'équipe qui appelle le plans généraux.

Il ne s'agit pas de « induit en erreur » ou « incompris » comme vous le dites, mais qu'une information aussi essentielle nous a été cachée pendant des jours. Toute cette discussion aurait pu avancer depuis longtemps déjà si Mlle Chigusa Sansen l'avait déclaré plus tôt. Ce qui, d'ailleurs, est ce que vous et elle voulez voir.

@mdtauk
nous sommes sur une longueur d'onde différente ici et cela ne sert à rien d'essayer de spéculer pourquoi cela pourrait être ...

Lorsque nous avons commencé cette discussion sur le mouvement général de l'interface utilisateur, Mlle Chigusa Sansen ou d'autres membres de l'équipe WinUI n'ont clairement indiqué que ce fil n'était pas le bon endroit pour cette discussion. Au lieu de cela, les gens ont commencé à discuter avec passion, arguant du pour/contre- ce mouvement pensant qu'ils parlaient à quelqu'un qui occuperait un poste important dans l'interface utilisateur chez Microsoft/Windows. Chigusa y a même participé et vous avez également librement ajouté des images de contrôle dans l'espoir d'influencer la direction de l'interface utilisateur. Ma plainte est , et vous semblez avoir manqué cela, que @chigy a mis si longtemps pour simplement nous dire qu'il n'y a vraiment pas grand intérêt à avoir cette discussion ici, car elle ne fait apparemment même pas partie de l'équipe qui appelle le plans généraux.

Il ne s'agit pas de « induit en erreur » ou « incompris » comme vous le dites, mais qu'une information aussi essentielle nous a été cachée pendant des jours. Toute cette discussion aurait pu déjà évoluer depuis longtemps si Mlle Chigusa Sansen l'avait déclaré plus tôt, ce qui est ce que vous et elle voulez voir.

@Felix-Dev @Nepxune
Restons civils et positifs. Les images qui ont été publiées mettent en évidence les modifications apportées aux contrôles, qui impliquent les valeurs CornerRadius. Il y a un autre problème où les mécanismes spécifiques pour ajouter CornerRadius aux contrôles qui ne prennent pas en charge ou ne respectent pas la valeur actuellement, peuvent être faits pour les prendre en charge, et d'une manière où les développeurs peuvent remplacer la valeur pour les ajuster ou personnaliser les valeurs adaptées à leur marque et à leurs besoins. #684

Ce problème concerne la mise à jour de Corner Radius sur les contrôles communs, conformément à la direction du style Web et App.

Les idées que j'ai publiées prenaient les styles utilisés par Fabric Web et les apportaient aux contrôles XAML - et je pense donc qu'elles entrent dans le cadre de cette discussion. Les fonctionnalités du système d'exploitation qui contrôlent le contrôle XAML ThemeResource sont légèrement hors sujet, mais liées.

Les conversations étaient intéressantes et pertinentes jusqu'au point où certains ont essayé d'en faire une discussion sur les mérites ou l'absence de changement en premier lieu - plutôt que sur la manière de réussir les changements qu'il a déjà été décidé de faire Fabriquer.

Je suggérerais que si vous souhaitez renforcer une proposition visant à faire du montant arrondi un paramètre du système d'exploitation que l'utilisateur peut basculer ou modifier, cela devrait être fait comme une nouvelle suggestion.

Veuillez vous référer au code de conduite et essayer d'être respectueux. @chigy n'essayait pas de tromper ou d'induire en erreur.

Martin a raison de dire que nous sommes l'équipe de plate-forme chargée d'aider à produire les conceptions pour répondre aux besoins des futures versions de Windows. Nous voulons également nous assurer que notre plate-forme fonctionne bien avec tous les autres, y compris ceux qui apportent leur propre marque et leur propre style et ne veulent pas suivre le style Windows. Tous ces commentaires sont extrêmement précieux et nous les partagerons également avec l'équipe de conception de Windows pour nous assurer qu'ils entendent les commentaires spécifiques selon lesquels, au niveau du système d'exploitation, les gens veulent un bouton pour personnaliser cela.

Merci @Felix-Dev , @Nepxune et @mdtauk , pour avoir souligné quelque chose que je n'étais probablement pas très clair lorsque j'ai repris cet élément GitHub. Juste pour que vous le sachiez, il s'agit de notre tout premier problème lié à la conception dont nous discutons dans la communauté ouverte, nous apprenons donc au fur et à mesure…

Et tout d'abord, je m'excuse si je trompe quelqu'un dans ce groupe en disant que je suis un représentant du design qui a le pouvoir d'apporter des modifications qui n'étaient pas mon intention et désolé si vous avez l'impression d'avoir perdu votre temps.

Merci @jevansaks d' avoir résumé le rôle de WinUI par rapport au design.

Cela dit, permettez-moi de clarifier mon propos puisque je le dois à cette communauté. Je suis un gestionnaire de programme de l'équipe d'ingénierie WinUI. Je travaille en étroite collaboration avec les équipes de conception de l'entreprise pour m'assurer que WinUI représente la vérité de conception de la direction de conception de Windows ainsi que celle de Fluent. Par exemple, hier encore, j'étais assis avec l'équipe de conception Xbox pour discuter de certains des changements de conception proposés ici. S'assurer qu'ils sont toujours aussi utiles aux développeurs Xbox. Au sein de l'équipe WinUI, je supervise la conception de manière plus systématique horizontalement et globalement, en m'assurant que nous ne publions pas une fonctionnalité individuelle qui introduit une incohérence du point de vue UI/UX.

Je participe à l'effort du système de conception Fluent représentant Windows et j'essaie d'être une voix très forte pour la communauté des développeurs. Pour clarifier également, Fluent design system est un effort collectif où de nombreuses équipes de Microsoft (équipes de conception et d'ingénierie) travaillent ensemble pour réaliser un système cohérent où nous pouvons offrir une excellente expérience utilisateur en tant qu'entreprise et la mettre à la disposition des développeurs comme vous. Donc, le fait d'en faire partie ne signifie pas que je peux passer un appel… À mon avis, aucune personne seule dans ce collectif ne peut… C'est un effort collectif…

@Felix-Dev , juste pour vous faire savoir que j'ai personnellement discuté du concept que vous avez proposé concernant la configuration de l'utilisateur avec quelqu'un de l'organisation de conception Windows, afin de confirmer ma réponse (par exemple, aucun plan de fonctionnalité autour de cela ou intérêt à faire quelque chose autour de cette demande ). Votre opinion a été discutée. Je sais que ce n'est probablement pas satisfaisant, mais je voulais que vous sachiez que je me soucie de toutes vos opinions et que je fais de mon mieux pour être le représentant/le pont ici.

Tout le monde, je ne voulais pas clore le sujet. J'essayais de fermer le commentaire et je l'ai fait accidentellement !!

@mdtauk @jevansaks @chigy
Je suis tout à fait d'accord avec vous pour dire que cette discussion doit rester professionnelle. Nous sommes tous unis dans notre passion pour Windows et dans notre désir de voir Windows devenir le meilleur possible.

Pour être tout à fait clair une fois pour toutes, je n'ai jamais accusé Miss Chigusa Sansen de nous "tromper" ou de nous "induire en erreur", et ce n'était pas non plus mon intention. Je peux également affirmer sans équivoque que je n'ai jamais attaqué personne personnellement, et je ne le ferais pas non plus.

Ce que cette récente conversation montre aussi, cependant, c'est que ce projet Open-Source est encore dans sa phase d'apprentissage. Il y a encore du travail à faire pour réussir à réunir les deux mondes - la société Microsoft et ses utilisateurs passionnés et une compréhension claire de l'influence que cette nouvelle approche Open-Source donnera réellement à la communauté et comment les équipes Windows concernées géreront réellement les commentaires de la communauté. .

En général, je suis déjà assez impressionné par l'état actuel. Les commentaires sont émis et traités au sérieux par l'équipe WinUI, même s'il ne s'agit pas des commentaires liés au produit WinUI réel. J'apprécie ceci et vous avez mon respect pour cela!

Ce cas particulier ici a malheureusement probablement souffert de certains symptômes d'être un très jeune projet open source où toutes les parties participantes n'ont pas encore pleinement appris les unes des autres. Je suis optimiste que nous pouvons utiliser ce cas pour mieux comprendre les possibilités ET les limites de cette nouvelle approche pour nous tous !

Bonjour à tous!
Merci BEAUCOUP pour la conversation franche. J'ai beaucoup appris et j'espère que vous êtes prêt à continuer à travailler avec nous pour grandir ensemble en tant que communauté ouverte !

Comme certains d'entre vous l'ont souligné, je n'étais pas clair sur ce que l'équipe WinUI et moi pouvons et ne pouvons pas faire, alors laissez-moi essayer de résumer les grands points que vous avez tous soulevés et la conclusion de cela. Et si vous pensez que les problèmes sont toujours ouverts, sautez dessus !

Notez que je n'ai pas énuméré tous les problèmes dont nous avons discuté car j'ai considéré que certains d'entre eux étaient résolus au cours de notre discussion. Dites moi si vous pensez le contraire !!

• Assurez-vous que Xbox est pris en compte (@mdtauk)
  o La conception Xbox appartient à l'équipe Xbox.
  o Mais oui, nous travaillons en étroite collaboration avec eux. Je confirme qu'une réunion a eu lieu au cours de laquelle nous avons examiné cette proposition et les propositions de conception à venir avec l'équipe de conception Xbox.
• Envisagez d'apporter d'autres modifications liées au contrôle pour l'alignement, telles que l'affinement des lignes de bordure (@mdtauk)
  o L'équipe de conception Windows fait l'appel final pour Windows tout en se coordonnant avec le collectif Fluent Design System pour essayer de s'aligner sur les équipes de conception Microsoft.
  o L'équipe WinUI le fera mieux fonctionner pour les développeurs et aura une bonne histoire de développeur pour basculer (ou revenir en arrière).
  o Cela sera suivi dans les prochains numéros de GitHub.
• La communauté aimerait un endroit pour exprimer son opinion directement à Fluent Design Team ( @mdtauk , @Felix-Dev, @Nepxune)
  o Pour info, l'équipe Fluent a un groupe LinkedIn.
  o Cela n'appartient pas à l'équipe WinUI ou à moi-même.
  o Ceci est porté à leur attention, mais quelque chose que nous ne pouvons pas nous engager si quelque chose devait arriver.
  o Je ne manquerai pas de communiquer avec ce groupe si quelque chose se matérialise.
• Sortons-nous le thème Fluent pour WPF/WinForms ? (@Felix-Dev, @mdtauk)
  o C'est quelque chose que nous n'avons pas encore compris.
  o C'est un peu compliqué. Je suis une personne qui recherche des conseils de conception et une assistance à la conception pour les développeurs en général pour Windows, cela correspond donc à mon domaine de préoccupation. Cependant, franchement, ce n'est pas une priorité pour le moment car ce n'est pas du travail WinUI.
• Paramètre utilisateur où l'utilisateur peut activer/désactiver le coin arrondi et/ou apporter des modifications de valeur granulaires jusqu'à un certain point (@Felix-Dev) / Je n'aime pas le coin arrondi, ne le garde pas arrondi et donne à l'utilisateur une option ( @Nepxune et les gens sur Reddit)
  o Malheureusement, ce ne sont pas des décisions WinUI.
  o Le mieux que je puisse recommander pour le moment est d'ouvrir les problèmes de Feedback Hub une fois que ce changement s'est propagé au système d'exploitation Windows et que vous ne pensez toujours pas que la conception répond à vos besoins ?
  o Si une consolation, j'ai fait de mon mieux pour informer l'équipe Windows, mais il n'y a aucun plan de leur équipe.

Ceci résume notre plan actuel :

• Les contrôles que vous obtenez en utilisant WinUI 2.x mettront à jour les visuels par défaut pour utiliser des coins arrondis.
  o En d'autres termes, si vous n'utilisez pas WinUI 2.x, vous n'obtiendrez pas ce changement.
• La valeur des coins arrondis est de 2px pour la plupart des contrôles 4px pour l'interface utilisateur de type flyout. Pas d'arrondi lorsque l'interface utilisateur croise d'autres éléments de l'interface utilisateur
  o Comp visuel ici : https://github.com/mrlacey/microsoft-ui-xaml-specs/blob/RoundedCornerVisualizations/active/RoundedCorner/ImageFiles/index.md
  o Courte note à @mdtauk , @Qowy , @shaheedmalik qui ont eu une conversation à ce sujet. Nous n'arrondirons pas les lignes intérieures. Cela se reflète dans la composition visuelle qui est en place. L'équipe de conception de Windows a examiné et évalué différentes options ainsi que leurs avantages et inconvénients.
• Les développeurs ont un moyen de revenir en arrière facilement (#684).
• Il n'y aura pas de paramètre utilisateur permettant aux utilisateurs de basculer entre les deux ou d'apporter des modifications granulaires.

@chigy Merci pour le résumé que vous avez posté.

J'ai quelques questions sur la suite...

• Ces compositions de conception reflètent-elles les conceptions finales de tous les contrôles, ou y a-t-il d'autres changements en cours de discussion qui seront mis à jour ou publiés plus tard ?

• Comment suggérez-vous que nous, en tant que communauté, essayons d'influencer ou de faire des suggestions sur certains de ces choix de conception pour WinUI ?

• Quand pourrons-nous voir la vision de l'équipe de conception Windows pour l'interface utilisateur Windows, afin que nous puissions avoir un contexte pour les conceptions de contrôle sur lesquelles nous travaillons ?

• Y aura-t-il un effort pour persuader/cajoler/appliquer la cohérence entre les applications de la boîte de réception et les éléments du shell à l'aide de XAML, afin que tout corresponde dans la conception ?

• Les conceptions de contrôle modifiées par Xbox seront-elles incluses dans WinUI, ou ne viendront-elles que sur les prochains appareils Xbox (sans aucun moyen de tester ces modèles de contrôle tout en développant sous Windows ?

@mdtauk , oups, j'ai trop écrit mais je voulais m'assurer de bien m'expliquer...

• Ces compositions de conception reflètent-elles les conceptions finales de tous les contrôles, ou y a-t-il d'autres changements en cours de discussion qui seront mis à jour ou publiés plus tard ?

Ce que vous voyez dans les compositions est aussi définitif que possible pour le moment. Cela dit, au fur et à mesure que nous implémentons le changement dans les contrôles réels, des changements mineurs peuvent survenir, ce qui entraîne un léger décalage de la conception. Comme vous pouvez le voir, la composition ne couvre pas toutes les occurrences de l'interface utilisateur. Je ne m'attends pas à cela de cet effort particulier, cependant...

• Comment suggérez-vous que nous, en tant que communauté, essayons d'influencer ou de faire des suggestions sur certains de ces choix de conception pour WinUI ?

Ce que j'aimerais que la communauté nous dise, c'est où ces choix de conception échouent pour les applications. Y a-t-il des endroits pour la personnalisation que nous ne vous donnons pas ? Est-ce que cela casse complètement votre application pour une raison ou une autre ?

Comme je l'ai mentionné, les décisions de conception sont prises par l'équipe de conception, mais WinUI est toujours chargé de fournir une solution aux développeurs et de s'assurer qu'elle est solide. En conséquence, il pourrait y avoir une opportunité d'influencer le résultat de la conception. Je ne promets rien qui se passerait, mais de vrais exemples de la façon dont cela ne fonctionne pas et de la façon dont cela devrait être réparé fonctionnent le mieux dans ce cas...

• Quand pourrons-nous voir la vision de l'équipe de conception Windows pour l'interface utilisateur Windows, afin que nous puissions avoir un contexte pour les conceptions de contrôle sur lesquelles nous travaillons ?

Par vision, entendez-vous comme une histoire globale qui vous raconte le type de changements d'interface utilisateur introduits dans Windows dans son ensemble ? Qu'est-ce que tu as en tête en particulier ?

• Y aura-t-il un effort pour persuader/cajoler/appliquer la cohérence entre les applications de la boîte de réception et les éléments du shell à l'aide de XAML, afin que tout corresponde dans la conception ?

Ci-dessous est totalement ma propre opinion basée sur ce que je sais. Juste pour être clair... :)
Dans mon esprit, le problème est double.

Le premier problème est que nous avons actuellement le système de livraison pour la nouvelle interface utilisateur qui dépend des versions du système d'exploitation. À cause de cela, de nombreuses applications de la boîte de réception ne pouvaient pas adopter les nouveaux styles que Shell utilisait, etc., car elles devaient toujours prendre en charge l'ancienne version du système d'exploitation. Nous essayons de résoudre ce problème en fournissant la nouvelle interface utilisateur dans WinUI afin que vous puissiez adopter ces modifications quelle que soit la version du système d'exploitation.

Le deuxième problème est qu'il nécessite un changement culturel. J'ai travaillé sur différentes plates-formes d'interface utilisateur, y compris Windows Phone, où nous avons essayé d'utiliser de nombreuses approches différentes pour apporter de la cohérence aux produits. C'est comme ça... Même si vous avez une limitation de vitesse, tout le monde ne la respecte pas. Mais combien de policiers devons-nous envoyer pour faire appliquer ? Nous devons créer une culture où la limitation de vitesse est respectée. Il n'y a pas de solution magique ici. Et c'est quelque chose que j'espère que Fluent Design System contribuera à apporter. En faisant des décisions de conception davantage un système qu'une opinion personnelle.

• Les conceptions de contrôle modifiées par Xbox seront-elles incluses dans WinUI, ou ne viendront-elles que sur les prochains appareils Xbox (sans aucun moyen de tester ces modèles de contrôle tout en développant sous Windows ?

Nous n'avons pas l'intention de modifier les commandes spécifiquement pour Xbox. Nous ne l'avons pas fait dans le passé (nous avons publié une documentation ) et n'avons reçu aucune demande forte de la part de l'équipe Xbox ainsi que de la communauté (il s'agit de pré-open source).

@chigy Merci encore d'avoir été si franc et d'avoir répondu.

Je supposais que la prochaine Xbox prendrait également en charge les applications - et avec Core OS utilisant XAML pour son shell - cela signifierait également que Xbox aurait besoin des contrôles WinUI 3.0 autant que Windows. Donc, inclure des modèles conçus pour Xbox simplifierait le processus et rendrait le développement d'applications Xbox plus accessible - mais c'est évidemment une décision pour les autres équipes. ??

En ce qui concerne la vision - je veux dire "Voici à quoi ressembleront les futures applications Windows Shell et Inbox". et "Nous profitons de l'occasion pour mettre à jour notre conception Windows, voici quelques-uns des changements que nous apportons..."

Cue images et/ou vidéo 😃

Je pense aussi que Xbox et Windows devraient correspondre. Nous avons des applications sur Xbox qui ont été abandonnées sur Windows mais existent toujours sur Xbox (CBS, FOX Sports) ou n'ont jamais existé sur Windows 10 (Youtube).

Si vous évitez d'avoir à apporter des modifications à l'interface utilisateur, ces applications seront conservées sur la plate-forme.

Juste mes pensées.

Je pense aussi que Xbox et Windows devraient correspondre. Nous avons des applications sur Xbox qui ont été abandonnées sur Windows mais existent toujours sur Xbox (CBS, FOX Sports) ou n'ont jamais existé sur Windows 10 (Youtube).

Si vous évitez d'avoir à apporter des modifications à l'interface utilisateur, ces applications seront conservées sur la plate-forme.

Juste mes pensées.

Les applications Xbox nécessitent des styles de contrôle et des comportements différents. Mais ces applications devraient pouvoir s'exécuter sur Windows en incluant simplement une propriété qui permet à ces applications de s'exécuter sans avoir à utiliser les styles de contrôle Windows. Donc une approche Xbox First .

@shaheedmalik et @mdtauk , je suis un peu confus au sujet de la discussion sur Xbox et Windows qui devraient correspondre et que l'application devrait s'exécuter l'une sur l'autre.

Les conceptions du shell Xbox et du shell Windows sont différentes. C'est exprès car ce sont des produits uniques. Mais nous avons conçu les contrôles WinUI de manière à ce que les applications qui souhaitent utiliser un style puissent s'exécuter avec un travail mineur. Lorsque nous avons travaillé avec l'équipe Xbox il y a quelques années, nous avons cherché à nous assurer que nos contrôles XAML (pas de WinUI alors) apparaissent correctement à la télévision et avons également publié des conseils à ce sujet que j'ai mentionnés plus tôt.

L'application UWP correctement créée s'exécutera à la fois sur Windows et sur Xbox. Pour les applications comme celles des listes @shaheedmalik , elles sont très marquées que nous avons souvent vu la même marque rencontrer vers et depuis Xbox et Windows. Ainsi, une conception d'application s'exécute souvent sur ces appareils.

Encore une fois, il s'agit d'un sujet arrondi, alors ramenez-le...
Voici ce que le développeur devrait faire sur Xbox une fois les versions des coins arrondis. Si un développeur adopte WinUI 2.x doté d'une fonction de coin arrondi, le développeur devra alors désactiver le style de coin arrondi S'il souhaite correspondre au style du shell. Attention, beaucoup d'applications sur Xbox ne le font pas... C'est pourquoi nous publions une documentation d'orientation à la place pour ceux qui s'en soucient. Je m'assurerai que la documentation d'orientation de 10FT mentionne le coin arrondi lors de notre sortie.

En ce qui concerne la vision - je veux dire "Voici à quoi ressembleront les futures applications Windows Shell et Inbox". et "Nous profitons de l'occasion pour mettre à jour notre conception Windows, voici quelques-uns des changements que nous apportons..."

Cue images et/ou vidéo 😃

@mdtauk , c'est quelque chose que j'ai demandé à l'équipe de conception dans le passé, donc, en tant qu'équipe de plate-forme, pouvons l'utiliser pour communiquer la vision de la conception au public des développeurs. Pour autant que je sache, il n'y a pas de plan immédiat mais je peux vérifier à nouveau.

En ce qui concerne la vision - je veux dire "Voici à quoi ressembleront les futures applications Windows Shell et Inbox". et "Nous profitons de l'occasion pour mettre à jour notre conception Windows, voici quelques-uns des changements que nous apportons..."
Cue images et/ou vidéo 😃

@mdtauk , c'est quelque chose que j'ai demandé à l'équipe de conception dans le passé, donc, en tant qu'équipe de plate-forme, pouvons l'utiliser pour communiquer la vision de la conception au public des développeurs. Pour autant que je sache, il n'y a pas de plan immédiat mais je peux vérifier à nouveau.

Merci. //Build/ aurait été l'occasion idéale de partager les changements qui étaient prévus, surtout si le plan est de mettre ces modèles de contrôle à jour à la fin de l'été, avec la version initiale de WinUI 3.0.

Les conceptions du shell Xbox et du shell Windows sont différentes. C'est exprès car ce sont des produits uniques. Mais nous avons conçu les contrôles WinUI de manière à ce que les applications qui souhaitent utiliser un style puissent s'exécuter avec un travail mineur. Lorsque nous avons travaillé avec l'équipe Xbox il y a quelques années, nous avons cherché à nous assurer que nos contrôles XAML (pas de WinUI alors) apparaissent correctement à la télévision et avons également publié des conseils à ce sujet que j'ai mentionnés plus tôt.

Bien sûr, les coquilles seront différentes pour s'adapter à l'expérience. Mon seul commentaire est que si la prochaine Xbox veut encourager le développement d'applications, les contrôles WinUI par défaut devraient avoir des modèles et des ressources thématiques inclus dans WinUI. Ainsi, lors de l'exécution sur Xbox, ils correspondront aux instructions de conception des contrôles. Et il devrait être possible de tester à quoi ressembleront ces contrôles, pendant le développement. Dans Windows et le concepteur XAML.

Je suis tombé sur certaines des compositions de conception pour les commandes Xbox, mais elles n'étaient pas dans les documents UWP.

@mdtauk , je pense que cette conversation sur Xbox semble mieux adaptée avec #698 ? J'ai envoyé un ping à quelqu'un sur Xbox pour voir s'il peut commenter l'autre conversation (pas de promesse :)). Encore une fois, il s'agit d'une communauté open source, peut-être pourriez-vous créer ladite ressource et nous proposer de la consommer d'une manière ou d'une autre ? Je dis juste...

@chigy C'était un problème que j'avais soumis et qui visait à garantir que tous les contrôles que la communauté ajoute à WinUI devraient inclure des modèles pour s'exécuter sur les futures consoles Xbox. Si les développeurs voulaient utiliser WinUI 3.0+ pour leur application Xbox, toutes les commandes devraient s'adapter pour avoir l'air correctes lorsqu'elles s'exécutent sur un téléviseur.

Mais avec les conceptions à peu près finalisées, ce problème n'a pas beaucoup plus d'objectif - autre que d'être marqué comme terminé lorsque tous les modèles sont mis à jour.

J'ai soumis des idées dans la soumission du contrôle NumberBox, et nous voulions nous assurer que la conception du contrôle correspond à ce qui est prévu pour le reste des contrôles.

Si les développeurs voulaient utiliser WinUI 3.0+ pour leur application Xbox, toutes les commandes devraient s'adapter pour avoir l'air correctes lorsqu'elles s'exécutent sur un téléviseur.

@mdtauk , comme je l'avais mentionné précédemment, c'est une bonne suggestion mais ce n'est pas notre priorité car il n'y a eu aucune demande provenant à la fois de l'équipe Xbox elle-même ou de la communauté autre que vous-même.

Mis à jour le fait que ScrollIndicator de WebView ne sera pas mis à jour via XAML, mais nous utilisons le Web tel quel.

En regardant la barre de progression actuelle dans le MUXControlsTestApp - L'extrémité droite de la barre de valeur de progression sera-t-elle également arrondie ou conservera-t-elle son bord plat ?

Le curseur dans le menu déroulant du volume sera-t-il également stylisé

La révélation sera-t-elle ajoutée à tous les contrôles par défaut, ou devra-t-elle toujours être ajoutée par styles ?

Les curseurs utilisés dans le ColourPicker bénéficieraient-ils d'un style de contour similaire à celui du MediaPlayer - afin qu'il ne se perde pas parmi les couleurs plus sombres de la barre ?

En regardant la barre de progression actuelle dans le MUXControlsTestApp - L'extrémité droite de la barre de valeur de progression sera-t-elle également arrondie ou conservera-t-elle son bord plat ?

Par définition de conception, il devrait. Veuillez ouvrir un problème contre MUXControlsTestApp.

Le curseur dans le menu déroulant du volume sera-t-il également stylisé

Étant donné que l'interface utilisateur du shell utilise notre contrôle commun, cela devrait être le cas lorsque le changement de nos contrôles se produit. Cependant, si vous ne voyez pas cette mise à jour, veuillez ouvrir le problème FeedbackHub. Il s'agit d'un travail par équipe shell et ce n'est pas quelque chose que l'équipe WinUI fait l'appel final sur la priorité et les ressources.

La révélation sera-t-elle ajoutée à tous les contrôles par défaut, ou devra-t-elle toujours être ajoutée par styles ?

Ce n'est pas un sujet arrondi.
Si vous souhaitez que la révélation soit ajoutée à tous les contrôles par défaut, veuillez ouvrir un nouveau numéro.

Les curseurs utilisés dans le ColourPicker bénéficieraient-ils d'un style de contour similaire à celui du MediaPlayer - afin qu'il ne se perde pas parmi les couleurs plus sombres de la barre ?

MediaPlayer est prévu pour suivre la conception du nouveau curseur (#841). Donc, ce que vous proposez n'est pas dans le plan. Si vous pensez qu'il s'agit d'un problème d'utilisation, veuillez ouvrir un problème séparé.

Ouah ! Il y a beaucoup de commentaires ici.

Je pense que les angles aigus persistants donnent à Windows 10 un aspect unique. Si des coins arrondis devaient être introduits, il faudrait faire quelque chose concernant le logo Windows, le logo Microsoft et les tuiles. Une fois que vous vous êtes débarrassé des reliques du métro telles que les tuiles, vous devez également refaire des logos tels que Office qui ont une inclinaison. Je pourrais continuer encore et encore sur les effets de l'introduction de coins arrondis et de cohérence, mais je vais le couper ici.

@Poopooracoocoo, les nouvelles icônes/logos du bureau utilisent des coins arrondis, tout comme la nouvelle icône du terminal et les nouvelles icônes/logos du studio visuel.

Et FWIW, je ne veux pas qu'ils se débarrassent des tuiles, c'est déjà assez grave, l'interface utilisateur de la tablette Windows 10 a subi une forte dégradation par rapport à Windows 8.1

@Poopooracoocoo , @mdtauk ,
Merci pour votre avis. Vous avez tous les deux raison de dire que le changement doit être appliqué à tous les niveaux. Ainsi, cet effort commence l'alignement avec Fabric et d'autres interfaces utilisateur visibles comme Edge. Nous aimerions que la cohérence se produise du jour au lendemain, mais c'est un voyage. Et cela commence à partir de la valeur par défaut de la plate-forme d'interface utilisateur en jeu ici (c'est-à-dire WinUI).

Mise à jour du statut:

Le document pratique PR de rayon d'angle (alias coin arrondi) est créé.

Cela sera ajouté à docs.microsoft.com en tant que documentation.
Ce sera une nouvelle page sous https://docs.microsoft.com/en-us/windows/uwp/design/style/.

Demandez à la communauté :
J'essaie d'écrire un peu plus "d'explication de fond (pourquoi)" que nos clients ont exprimé que nous fournissons avec notre documentation dans certains de nos groupes de discussion. Je voudrais des commentaires car cela ne suit pas le modèle de documentation normal.

Ces informations supplémentaires sont-elles utiles/utiles, non pertinentes, d'autres informations sont-elles manquantes, etc. ?

@chigy la seule suggestion que j'ai à propos du document, c'est que vous n'avez pas mentionné pourquoi les contrôles recevront les coins arrondis.

@mdtauk , bonne prise. J'avais une section "à faire" (principes) qui attrapait cela, mais d'une manière ou d'une autre lors de l'édition, le contexte s'est perdu. Je travaille toujours pour remplir cette section.

Mise à jour du statut

Création d'un problème distinct pour suivre le travail au coin de la case à cocher dans List et GridView (#1096)

Les modifications des coins arrondis sont maintenant enregistrées, ce qui ferme ce problème.

@mdtauk

Et FWIW, je ne veux pas qu'ils se débarrassent des tuiles, c'est déjà assez grave, l'interface utilisateur de la tablette Windows 10 a subi une forte dégradation par rapport à Windows 8.1

désolé de ne répondre que maintenant. Ils se débarrassent vraiment des tuiles ! :(

C'est une décision intéressante car Android n'autorise désormais que les icônes adaptatives, de la même manière qu'iOS tandis que Windows passe aux icônes de forme libre. Les icônes "adaptatives" ont une meilleure apparence sur les écrans de démarrage car elles ont une icône monochrome, vous n'avez donc pas besoin d'avoir un écran de démarrage blanc aveuglant. D'un autre côté, les icônes de forme libre ont une bien meilleure apparence car elles donnent aux développeurs plus de contrôle sur l'icône et conviennent à la plate-forme de bureau (des éléments comme la barre de titre, la barre des tâches) ainsi qu'aux applications win32.

L'icône Office elle-même ne ressemble pas aux icônes de Word ou de PowerPoint. Avec ces changements, j'ai l'impression que Microsoft perd son identité

@Poopooracoocoo J'espère toujours qu'il y aura une option pour utiliser des tuiles au lieu d'icônes, même si les icônes sont la nouvelle valeur par défaut dans le nouveau shell.

@Poopooracoocoo et @mdtauk , veuillez soumettre vos commentaires sur Feedback Hub pour les discussions sur les tuiles, car l'équipe WinUI n'est pas impliquée dans les tuiles et n'a aucune connaissance des plans.

@Poopooracoocoo et @mdtauk , veuillez soumettre vos commentaires sur Feedback Hub pour les discussions sur les tuiles, car l'équipe WinUI n'est pas impliquée dans les tuiles et n'a aucune connaissance des plans.

J'ai soumis des commentaires sur la conservation des tuiles - il existe une collection avec beaucoup de votes positifs. Feedback Hub n'est pas aussi bon que GitHub car il y a peu ou pas de commentaires ou de contributions aux discussions des équipes de développement Windows

Bonjour, comment désactiver les arrondis ? Il a l'air moche lorsque le bouton rond a une info-bulle ronde.

@kikisaints @chigy Existe-t-il un moyen de désactiver le coin arrondi pour, par exemple, un élément spécifique comme le demande @mklemarczyk ?

Bonjour, comment désactiver les arrondis ? Il a l'air moche lorsque le bouton rond a une info-bulle ronde.

@mklemarczyk Avez-vous essayé de définir la valeur CornerRadius sur 0 dans le style du contrôle ? Vous devrez peut-être le faire dans App.xaml pour qu'il affecte tous les contrôles ToolTip.

@kikisaints @chigy Existe-t-il un moyen de désactiver le coin arrondi pour, par exemple, un élément spécifique comme le demande @mklemarczyk ?

@mklemarczyk , avez-vous vu notre document d'orientation ?
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk Vous pouvez utiliser la propriété ToolTip.CornerRadius ou OverlayControlResource comme deux options pour modifier le rayon d'angle d'un contrôle d'info-bulle.

La propriété Control.CornerRadius est disponible depuis Windows 1809 et vous pouvez l'utiliser comme ceci :

<Application.Resources>
    <Style TargetType="ToolTip">
        <Setter Property="CornerRadius" Value="0" />
    </Style>
</Application.Resources>

Cela définit le rayon du coin à 0 pour chaque info-bulle dans l'application.

Alternativement, vous pouvez utiliser

<Application.Resources>
    <CornerRadius x:Key="OverlayCornerRadius">0</CornerRadius>
</Application.Resources>

Attention, cela définit non seulement le rayon d'angle des contrôles d'info-bulle à l'échelle de l'application, mais également tous les autres contrôles qui utilisent cette ressource (comme ContentDialog et les contrôles consommant des fenêtres contextuelles comme ComboBox). C'est... en théorie, car le remplacement de la ressource ne semble pas affecter ces contrôles même s'il le devrait (l'info-bulle fonctionne).

Il y a tellement de va-et-vient qu'il est difficile de savoir ce qui a été décidé en ce qui concerne les autres entrées et le rayon d'angle, mais très rapidement, après avoir migré un projet UWP pour utiliser WinUI 3 exclusivement, j'ai remarqué que seuls les boutons avaient un rayon d'angle appliqué (avec les autres changements comme la révélation améliorée, etc.), mais mes autres contrôles d'entrée (par exemple, combobox) ont été laissés avec le look métro (bordure plus foncée/plus épaisse et angles de 90°). Est-ce intentionnel, un WIP ou un bug ? De plus, pour que la zone de liste déroulante corresponde aux boutons, j'ai dû utiliser un rayon d'angle de 3 epx bien que tout ce que je vois en ligne indique que le nouveau rayon d'angle par défaut est de 4 epx ?

Il y a tellement de va-et-vient qu'il est difficile de savoir ce qui a été décidé en ce qui concerne les autres entrées et le rayon d'angle, mais très rapidement, après avoir migré un projet UWP pour utiliser WinUI 3 exclusivement, j'ai remarqué que seuls les boutons avaient un rayon d'angle appliqué (avec les autres changements comme la révélation améliorée, etc.), mais mes autres contrôles d'entrée (par exemple, combobox) ont été laissés avec le look métro (bordure plus foncée/plus épaisse et angles de 90°). Est-ce intentionnel, un WIP ou un bug ? De plus, pour que la liste déroulante corresponde aux boutons, j'ai dû utiliser un rayon d'angle de 3 epx bien que tout ce que je vois en ligne indique que le nouveau rayon d'angle par défaut est de 4 epx ?

Si vous voyez une différence entre WinUI2 et WinUI3 en ce qui concerne les styles, pouvez-vous s'il vous plaît ouvrir un nouveau problème ? Il peut s'agir d'un bug concernant la fusion des styles de WinUI2 vers WinUI3.