Dies sollte ein breiteres Projekt sein als nur die abgerundeten Ecken an Knöpfen usw., wie sie von Fabric verwendet werden.

• Tasten
• Spinner/ProgressRing
• Unbestimmter Fortschrittsbalken
• Kontrollkästchen und Optionsfelder
• ComboBoxes und TextFields
  Und so weiter.

Xbox wird weiterhin andere Anforderungen haben, aber mit einer neuen Reihe von Xbox-Konsolen auf dem Weg können die Microsoft-Designteams vielleicht zusammenarbeiten, um alles rechtzeitig für WinUI 3.0 und Xbox Next abzustimmen.

Fabric scheint im Moment viel im Fokus zu stehen, was mit seinen plattformübergreifenden und PWA-Anwendungsfällen angeht. Vielleicht wird Fabric also zur Blaupause - zumindest für die Compact Density, und bewegen Sie sich von 2px auf 4px als Mindestmaß - und dann extrapolieren Sie die Berührungsangebote und füllen die fehlenden Kontrollzustände aus.

Die ThemeShadows müssen die abgerundeten Ecken berücksichtigen. Und Acryloberflächen sollten wahrscheinlich innere und äußere Ränder aufweisen, um sicherzustellen, dass sie vom Hintergrund abgehoben erscheinen.

@mdtauk Wie Anforderung Nummer 4 besagt, gibt es einen Plan, diese Änderung mit Xbox zu rationalisieren. Das heißt, diese spezielle Funktion ist nur auf abgerundete Ecken beschränkt, um die Arbeit klar abzugrenzen. Bitte zögern Sie nicht, separate Anfragen für andere Designvorschläge zu öffnen, die Sie haben.

Übrigens, ich verstehe Ihr Feedback zu inneren und äußeren Rändern für Acryloberflächen nicht ganz? Ist es das Xbox-Design, das Sie erwähnen, da wir derzeit keine zwei Grenzen verwenden, wie Sie es angeben.

@chigy Klar mit der Xbox, das ist seine eigene Sache. Aber der Punkt ist, dass die abgerundeten Ecken an allen relevanten Bedienelementen funktionieren müssen.

Mir sind die internen Designspezifikationen von figma nicht bekannt, auf die sich das Fluent-Team möglicherweise geeinigt hat oder nicht - aber es muss mehr als nur Buttons sein.

Fluent Web verwendet einen Eckradius von 2 px für seine abgerundeten Ecken, aber Fluent XAML verwendet in der Regel 4 px als Basismaß. Dann gibt es die CompactDensity-Vorlagen, die wahrscheinlich die gleichen Metriken wie FluentWeb verwenden würden?

Ich habe ein Vergleichsbild der gemeinsamen Steuerelemente von Xbox Fluent und Fabric erstellt und wie unterschiedlich sie aussehen. Es gibt also mehr als nur die abgerundeten Ecken, die gemacht werden müssen, während diese Steuerelementvorlagen betrachtet werden.

Ignoriere das Xbox-Zeug

@mdtauk , Damit Sie sich einen Eindruck

Ich hatte keine Gelegenheit, eine Designdatei zu veröffentlichen, aber der von uns geplante Eckenradius beträgt tatsächlich 2px (4px für die Overlay-Benutzeroberfläche). Ich arbeite tatsächlich sehr eng mit dem Fabric-Team (dh Fluent Web) zusammen und wir evaluieren diese Änderungen gemeinsam. Nichtsdestotrotz ist es nicht unser Ziel, dass sie genau gleich sind, aber wir müssen kohärent sein und uns als Teil der Familie fühlen, wenn die Benutzer sie nebeneinander sehen. Siehe Anforderungsnummer 4.

Es gibt also mehr als nur die abgerundeten Ecken, die gemacht werden müssen, während diese Steuerelementvorlagen betrachtet werden.

Es ist in Arbeit, aber wir tun dies von Fall zu Fall. Wir sind vorsichtig, wenn wir Veränderungen vornehmen, die Sinn machen, um Dinge nicht um der Veränderung willen zu ändern.

@chigy Danke, danke, danke!

Ich würde mich freuen, wenn Sie diese Designs mit der Community teilen könnten, nicht nur, weil wir alle sehen möchten, wohin die Steuerung und die Benutzeroberfläche gehen, sondern auch, um bei der Implementierung der Änderungen auf Inkonsistenzen hinzuweisen und die Zukunft sicherzustellen Kontrollvorschläge werden sich wie zu Hause fühlen!

Fabric Web sowie Fluent Web scheinen die Nase vorn zu haben, und XAML sowie WPF und WinForms/Visual Styles sollten folgen!

@chigy @mdtauk Siehe meine Antwort hier . Es reicht meiner Meinung nach nicht aus, nur die UI-Konzepte zu sehen, "um zu wissen, wohin Fluent Design geht" oder auf Inkonsistenzen hinzuweisen. Ich näher auf diesem Punkt weiter in der verknüpften Ausgabe oben, aber lange Geschichte kurz Ich möchte eine aktive Hin- und Herschalten zwischen den Nutzern und dem Fluent - Design (FD) Team sein , auch wenn es um Design - Vorschläge kommt.

@mdtauk Ich ansprechen , die WPF / WinForms-Steuerelemente so zu aktualisieren, dass sie mit FD übereinstimmen. Ich bin dagegen, da Sie WinUI haben werden, wenn Sie eine Nicht-UWP-App mit Win10-nativem Look & Feel ausliefern möchten und die Teams bei MS nur begrenzte Ressourcen haben, die am besten ausgegeben werden, um UWP / WinUI DAS definitive zu machen Windows-Präsentationsplattform.
Also, @YuliKl @chigy @pag3 : Kannst du das kommentieren? Werden die standardmäßigen WinForms/WPF-Steuerelemente aktualisiert, um ein neues FD-Design zu erhalten, oder sind die WinUI-Steuerelemente der Weg für die neuesten und besten Designfunktionen, wie ich sie verstehe?

Ich habe dieses Bild im Numberbox-Vorschlag gepostet, es kann jedoch eine gewisse Relevanz für die aktualisierten TextBox-Steuerelemente haben.

The BorderThickness , FocusReveal on Focused State, Border on Disabled State.

Der Stil "Spin-Buttons" könnte auf den Such-Button, den Passwort-Enthüllungs-Button und den Klartext-Button angewendet werden.

Der Schatten um die Ränder/Steuerelemente im fokussierten Zustand erscheint mir viel zu stark. Warum brauchen sie überhaupt Schatten? Aktuelle Version (nur Rahmenfarbe ändern) ist völlig in Ordnung. Schatten könnten darauf hindeuten, dass das Steuerelement (Element) in den Vordergrund gerückt wird, was in 3D-Umgebungen sinnvoll sein könnte, aber für klassische Desktop-Umgebungen sicherlich nicht benötigt wird und, wie man argumentieren könnte, etwas ablenken.

Der Schatten um die Ränder/Steuerelemente im fokussierten Zustand erscheint mir viel zu stark. Warum brauchen sie überhaupt Schatten? Aktuelle Version (nur Rahmenfarbe ändern) ist völlig in Ordnung. Schatten könnten darauf hindeuten, dass das Steuerelement (Element) in den Vordergrund gerückt wird, was in 3D-Umgebungen sinnvoll sein könnte, aber für klassische Desktop-Umgebungen sicherlich nicht benötigt wird und, wie man argumentieren könnte, etwas ablenken.

Das Leuchten um das Steuerelement herum, wenn es fokussiert ist, ist das FocusVisualKind.Reveal und wird vom System gesteuert. Ich musste ungefähr annähern, wie es aussieht, weil ich nicht die Metriken habe, um die Deckkraft und Größe genau zu entsprechen.

Nehmen Sie meine Verwendung als Hinweis darauf, dass das Leuchten meiner Meinung nach den Fokus viel klarer macht, als nur die Randfarbe zu ändern.

@mdtauk , könnten Sie die Konversation in dieser Ausgabe bitte auf abgerundete Ecken beschränken? Ich würde wirklich gerne Feedback zu abgerundeten Ecken bekommen, und ich fürchte, dieses Gespräch wird zu verwirrend für diejenigen, die vielleicht nur zu diesem Zweck hierher gekommen sind.

Das heißt, was Sie zeigen, sieht für mich wie ein Reveal Focus-Verhalten aus. Wir haben versucht, den Fokuszustand stärker zu machen, und haben einige Benutzerrecherchen durchgeführt und wir haben bestätigt, dass sie viel zu stark sind, genau wie @Felix-Dev in seiner Antwort erwähnt.
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy Wenn die Forschung zeigt, dass Reveal Focus auf den Fokus der

@mdtauk und @Felix-Dev , ich habe jetzt visuelle Kompositionen der vorgeschlagenen Änderungen hochgeladen.

@chigy gibt es eine Möglichkeit, die Radiosteuerelemente zu überdenken.

Fabric Web hat sich für 1 epx-Stärke entschieden und ich denke, dies macht die Steuerung eleganter, insbesondere mit den neuen abgerundeten Ecken. Derzeit fühlen sie sich etwas sperrig an.

Textfelder im kompakten Modus würden sehr profitieren. Aber wenn fokussiert, kann der Rand dicker sein

Schaltflächen verwenden standardmäßig die Hintergrundfüllung mit 20 % Deckkraft. In Fabric Web verwenden sie einen 1 epx-Rahmen und keine Füllung. Ich denke, dies könnte eine bessere Lösung sein und würde es auch ermöglichen, dass Schaltflächen in einem Textfeld-Steuerelement gut passen.

Der Vorschlag NumberBox mit Drehschaltflächen veranschaulicht diese Kombination von Schaltfläche und Textfeld

Wenn das Team nicht bereit ist, diesen Stil zum neuen Standard zu machen, kann ein Stil/eine Vorlage dafür hinzugefügt werden.

Zur Unterstützung der visuellen Kompositionen Ansehen von @chigy erstellt Ich habe diese

Anekdotisches und unprofessionelles Feedback zum Thema abgerundete Ecken.
Bei der Verwendung von Edge und CrEdge ist mein Hauptproblem bei CrEdge das abgerundete Gefühl der gesamten Benutzeroberfläche. Es ist abscheulich und macht mich aktiv dazu, es nicht zu mögen. Wenn Sie abgerundeten Ecken zu Dingen hinzufügen, fügen Sie bitte die Möglichkeit hinzu, scharfe Kanten umzuschalten, für diejenigen von uns, die nicht möchten, dass etwas aussieht, das wie ein Kind aussieht, mit einer Sicherheitsschere, die es ausschneidet.

Um das Betrachten der von @chigy erstellten visuellen Kompositionen zu

@mrlacey , vielen Dank!!

@chigy gibt es eine Möglichkeit, die Radiosteuerelemente zu überdenken.

@mdtauk , wir haben gerade ein paar weitere visuelle Änderungen in bündeln (wir möchten, dass sie einzeln ansprechbar, aber kohärent sind), eine davon ist das, was Sie fragen, also bleiben Sie dran.

Anekdotisches und unprofessionelles Feedback zum Thema abgerundete Ecken.
Bei der Verwendung von Edge und CrEdge ist mein Hauptproblem bei CrEdge das abgerundete Gefühl der gesamten Benutzeroberfläche. Es ist abscheulich und macht mich aktiv dazu, es nicht zu mögen. Wenn Sie abgerundeten Ecken zu Dingen hinzufügen, fügen Sie bitte die Möglichkeit hinzu, scharfe Kanten umzuschalten, für diejenigen von uns, die nicht möchten, dass etwas aussieht, das wie ein Kind aussieht, mit einer Sicherheitsschere, die es ausschneidet.

@Zucce05 , Ja, #684 wird Ihr

@chigy
Ich bin auch kein Fan der Designänderung der abgerundeten Ecken, daher bin ich froh zu hören, dass es eine Option zum einfachen Zurückschalten gibt. Ich glaube jedoch nicht, dass es eine systemweite Eckradiusoption geben wird, oder (ähnlich dem Festlegen einer systemweiten Akzentfarbe)?

Zum Thema Randdicke: Mir gefällt die aktuelle Dicke der Buttons und auch die Randdicke fühlt sich für mich in der aktuellen UI-Landschaft eher einzigartig an. Ich sehe diese Rahmendicke in der Benutzeroberfläche selten, wenn überhaupt, anders als in der UWP-Benutzeroberfläche, daher fungiert sie immer als ein nettes Unterscheidungsmerkmal: "Die Benutzeroberfläche, die ich derzeit betrachte, ist UWP." Ich würde gerne sehen, dass die Dicke so bleibt, wie sie derzeit ist.

Wenn ich mir Ihre geposteten visuellen Kompositionen anschaue, finde ich den einzigen Bereich, in dem die Randdicke seltsam aussieht, bei einer TreeView mit Kontrollkästchen. In diesem Fall erscheint mir die Dicke der Checkboxen zu dick. Es mag ein irreführender visueller Effekt sein, aber es scheint mir, dass eigenständige Kontrollkästchen eine dünnere Randdicke haben und für sie gut aussehen. Daher würde ich die Rahmendicke von Checkbixes in einer TreeView reduzieren, um dem visuellen Effekt der normalen Checkbox-Rahmendicke zu entsprechen.

@mdtauk , wir haben gerade ein paar weitere visuelle Änderungen in bündeln (wir möchten, dass sie einzeln ansprechbar, aber kohärent sind), eine davon ist das, was Sie fragen, also bleiben Sie dran.

@chigy Ich habe einige visuelle

Die dem Hover hinzugefügten Schatten werden von den Fluent Web-Steuerelementen in den Microsoft Store-Webansichten verwendet, aber dies kann standardmäßig weggelassen werden, oder die Z-Übersetzung kann durch eine Theme-Animation erreicht werden, die entfernt werden kann.

Wenn ich mir einige der Designvorschläge von @mdtauk oben

Ich möchte auch anmerken, dass ich kein Fan davon bin, Windows Fluent Design so sehr auf Fabric Web oder anderen Web-UI-Komponenten zu basieren - ich möchte, dass Windows ein einzigartiges Aussehen hat, das sich von den Vorgängen im Web unterscheidet. Nehmen wir zum Beispiel Internetbrowser: Chrome ist heutzutage der mit Abstand am häufigsten verwendete Browser, aber bedeutet das, dass der Edge Chromium-basierte Browser genau gleich oder nur geringfügig anders aussehen sollte? Aus meiner Sicht nicht. Wie ich bereits sagte, verleihen die aktuellen UWP-Standardsteuerelemente UWP (und damit Windows) ein schönes, einzigartiges Aussehen. Etwas, das das Windows Fluent-Team gerne berücksichtigen würde (dh nicht nur Dinge ändern, um der Veränderung willen).

@Felix-Dev Fabric Web ist Microsofts Web-Control-Design, das auf Fluent basiert. Chromium Edge plant, diese Steuerelementstile standardmäßig zu verwenden. Aber natürlich können Webdesigner ihre CSS-Steuerelemente neu gestalten und Entwickler können auch ihre eigenen Vorlagen für XAML-Steuerelemente auswählen.

Ich bin mir nicht sicher, warum sich die Steuerelementdesigns von Microsoft so sehr von Web zu Windows unterscheiden müssen. Es scheint nur so, als ob verschiedene Teams nicht miteinander reden. Und Entwickler haben immer noch die Option zum Überschreiben. Und diese neuen Standardeinstellungen werden nicht wirksam, es sei denn, die App wird neu auf WinUI 3.0 kompiliert

Wenn ich mir Ihre geposteten visuellen Kompositionen anschaue, finde ich den einzigen Bereich, in dem die Randdicke seltsam aussieht, bei einer TreeView mit Kontrollkästchen.

@Felix-Dev, für dieses spezielle Problem denke ich, dass es sich nur um einen seltsamen Fehler handelt, bei dem Figma Visuals mit etwas seltsamem Maßstab exportiert. Ich habe den tatsächlichen Build und die tatsächliche Figma-Datei, aus der ich das PNG exportiert habe, doppelt überprüft, sie sehen in Ordnung aus.

RE: Popularität von abgerundeten Ecken
@mdtauk und @Felix-Dev ,
Mein Kollege hat informell gefragt, was die Entwickler (sie waren hauptsächlich LOB/WPF/WinForms-Entwickler) darüber denken, dass wir unsere Steuerelemente mit abgerundeten Ecken während ihrer Sneak-Preview aktualisiert haben, und sie erhielten Applaus vom Publikum mit sehr gutem Empfang. Wir bekommen auch Leute, die sich darüber beschweren, dass wir bei Twitter für Windows nicht oft um die Ecke biegen.

Obwohl ich Ihr Feedback respektiere (und ich hoffe, dass Sie kommen), haben wir anekdotische Daten, die das Gegenteil von dem zeigen, was ich hier von Ihnen höre. Aus diesem Grund überlegen wir, wie Sie es wieder ändern können, falls Sie dies wünschen. Design ist schwierig, da sie eher subjektiv sind. Ich kann Sie nicht zwingen, ein rotes Hemd zu tragen, wenn Sie Rot nicht mögen, aber wenn das ein "tragen Sie einen roten Tag" ist, könnte es von Ihrem Interesse sein, eines zu tragen, um nicht aufzufallen. Wenn du verstehst was ich meine... :)

Nun, am Ende kommt es nur auf die persönlichen Vorlieben an. Ich denke , die aktuellen UWP Standardsteuer Stile hübsch aussehen und ein großer Teil für mich ist , dass sie einzigartig suchen im Vergleich zu dem, was Sie auf dem Netz sehen oder in der populären Anwendungen wie der Chrome - Browser oder mobile OSs wie Android. Es ist ein schöner Hauch frischer Luft.

Jetzt kann ich verstehen, warum MS unterschiedliche "Standard"-Stile für Windows und Web für ihre Designsprache haben möchte. Ich habe jedoch das Gefühl, dass die aktuelle Richtung darin besteht, Windows eher wie mobile Apps/mobile Betriebssysteme aussehen zu lassen, und ich bin nicht wirklich ein Fan davon (siehe „XAML-Steuerelemente stimmen nicht mit der Entwicklung von Web- und mobilen Apps überein“ im Ausgabevorschlag).

Entwickler können Stile wahrscheinlich leicht ändern, aber am wichtigsten ist für mich der Standardstil, den MS verwenden wird, da dieser Stil in allen von MS bereitgestellten Apps (dh Einstellungen) verwendet wird und daher auch ein Styling ist, auf dem externe Entwickler ihre Arbeit aufbauen (manche mehr, manche weniger).

@chigy

Mein Kollege hat informell gefragt, was die Entwickler (sie waren hauptsächlich LOB/WPF/WinForms-Entwickler) darüber denken, dass wir unsere Steuerelemente mit abgerundeten Ecken während ihrer Sneak-Preview aktualisiert haben, und sie erhielten Applaus vom Publikum mit sehr gutem Empfang.

Ist das nicht vielleicht das falsche Publikum? Was ist mit Alltagsnutzern? Ich habe zum Beispiel gesehen, wie sich einige Benutzer über die jüngsten abgerundeten Ecken in Reddit- und Discord-Kanälen beschwert haben (obwohl Sie auch immer Benutzer haben werden, die diese Änderung nicht interessieren oder unterstützen).

Was das Twitter-Beispiel betrifft: Das ist eine App von einem Drittanbieter, der vielleicht ein eigenes, einzigartiges Markenstyling haben möchte. Das würde mir gut tun (schließlich kommt Ihr Team hier ins Spiel und fügt Anpassungsunterstützung für Kontrollstile hinzu). Aber eine externe App würde ich sicherlich nicht als Anlass nehmen, die offizielle Designsprache von Windows zu überarbeiten.

Lange Rede, kurzer Sinn, es fühlt sich so an, als ob das Windows-Designteam darauf aus ist, Windows näher an die Mobile-/Web-Welt zu gestalten. Jetzt hoffe ich nur, dass diese Änderungen nicht zu radikal ausfallen und Windows weiterhin ein einzigartiges Aussehen behält, das es leicht von anderen Umgebungen unterscheiden lässt.

@Felix-Dev Die Fabric-Websteuerelemente unterscheiden sich von anderen Frameworks und den Standard-Websteuerelementen. Sie wurden kürzlich aktualisiert, um Fluent Design zu verwenden, verglichen mit dem älteren Aussehen, das den Windows 10 MDL2-Steuerelementen und den Windows 8 / WinJS-Steuerelementen ähnelt.

Die XAML-Steuerelemente verwenden derzeit noch ihre MDL2-Steuerelementdesigns, einige Elemente wie die Flyouts und Menüs verwenden Fluent Design-Elemente und -Materialien.

Textstile in Fluent und Fabric verwenden stärker die Strichstärken Fett und Halbfett. Auch die verschiedenen Windows 10-Konzepte haben diese verwendet. Aber die Windows-Shell- und Posteingangs-Apps sind noch nicht alle auf diesen Stil umgestellt.

Fabric Web und Fluent Web sind die jüngsten Änderungen an den Steuerelementen von Microsoft seit der Ankündigung von Fluent Design. WinUI 3.0 ist eine große Veränderung für die Plattform und alle Steuerelemente haben ein neues Aussehen, damit sie sich besser, frischer und konsistenter mit Microsofts Fluent Design anfühlen.

RE: Webkonsistenz, fließend und einzigartig für Windows
@Felix-Dev und @mdtauk ,
Eines der Ziele des Windows-Designteams ist „Vertrautheit“. Sie haben eine Menge Benutzerrecherchen mit unseren Kunden durchgeführt (wie Sie angeben, nicht mit unseren Entwicklern, sondern mit unseren täglichen Benutzern) und fanden heraus, dass es keine gute Sache ist, ohne guten Grund anders zu sein, wie Sie sich vorstellen können (ich fasse super zusammen .) Dies ist also nicht der genaue Test, den sie durchgeführt haben, also zitiere mich hier nicht). Windows muss neue Benutzertypen anziehen, deren Erfahrung mit jeder Technologie möglicherweise mit Mobile oder Web beginnt. Diese Benutzer spüren eine große Lücke, wenn sie mit Windows vertraut gemacht werden, und ein „anderes“ Erscheinungsbild hilft nicht. Kleine Änderungen wie abgerundete Ecken machen einen großen Unterschied in der Wahrnehmung. Das Office-Team hat eine ähnliche Studie mit ähnlichen Ergebnissen durchgeführt, daher kommen wir mit der abgerundeten Ecke voran. Wir treffen diese Entscheidung nicht leichtfertig oder im Vakuum.

Das bedeutet nicht, dass wir sie genau gleich machen. Wenn es Orte gibt, an denen wir uns verbessern können, wollen wir das. Wir wollen auch einzigartig sein, wie Felix es erwähnt, aber sie müssen aussagekräftig sein, nicht nur Meinungsverschiedenheiten. Dies sind Orte, an denen wir die einzigartigen Behandlungen von Fluent anwenden.

Wie ich bereits in dieser Diskussion erwähnt habe, arbeite ich sehr eng mit Office-, Windows- und Edge-Teams zusammen. Unsere Designteams sind bestrebt, ein Design zu haben, das aus Microsoft/Fluent kommt, daher prüfen sie die Unterschiede sehr sorgfältig und versuchen, die Unterschiede zu beseitigen, die keinen Sinn ergeben, damit wir einen Ausgangspunkt haben, an dem wir uns gemeinsam weiterentwickeln können.

Es ist jedoch sehr interessant, dass viele dieser Änderungen von diesen Teams separat inkubiert wurden, aber sie kamen oft an sehr ähnlichen Stellen an. Das Ausdünnen des Rahmens ist etwas, das Office zuerst implementiert hat, aber Windows diskutiert das seit einiger Zeit. Und diese sind alle Teil der Leitung von Fluent Design, wie Martin vorschlägt.

_RE: Popularität von abgerundeten Ecken_
@mdtauk und @Felix-Dev ,
Mein Kollege hat informell gefragt, was die Entwickler (sie waren hauptsächlich LOB/WPF/WinForms-Entwickler) darüber denken, dass wir unsere Steuerelemente mit abgerundeten Ecken während ihrer Sneak-Preview aktualisiert haben, und sie erhielten Applaus vom Publikum mit sehr gutem Empfang. Wir bekommen auch Leute, die sich darüber beschweren, dass wir bei Twitter für Windows nicht oft um die Ecke biegen.

Obwohl ich Ihr Feedback respektiere (und ich hoffe, dass Sie kommen), haben wir anekdotische Daten, die das Gegenteil von dem zeigen, was ich hier von Ihnen höre. Aus diesem Grund überlegen wir, wie Sie es wieder ändern können, falls Sie dies wünschen. Design ist schwierig, da sie eher subjektiv sind. Ich kann Sie nicht zwingen, ein rotes Hemd zu tragen, wenn Sie Rot nicht mögen, aber wenn das ein "tragen Sie einen roten Tag" ist, könnte es von Ihrem Interesse sein, eines zu tragen, um nicht aufzufallen. Wenn du verstehst was ich meine... :)

_RE: Webkonsistenz, fließend und einzigartig für Windows_
@Felix-Dev und @mdtauk ,
Eines der Ziele des Windows-Designteams ist „Vertrautheit“. Sie haben eine Menge Benutzerrecherchen mit unseren Kunden durchgeführt (wie Sie angeben, nicht mit unseren Entwicklern, sondern mit unseren täglichen Benutzern) und fanden heraus, dass es keine gute Sache ist, ohne guten Grund anders zu sein, wie Sie sich vorstellen können (ich fasse super zusammen .) Dies ist also nicht der genaue Test, den sie durchgeführt haben, also zitiere mich hier nicht). Windows muss neue Benutzertypen anziehen, deren Erfahrung mit jeder Technologie möglicherweise mit Mobile oder Web beginnt. Diese Benutzer spüren eine große Lücke, wenn sie mit Windows vertraut gemacht werden, und ein „anderes“ Erscheinungsbild hilft nicht. Kleine Änderungen wie abgerundete Ecken machen einen großen Unterschied in der Wahrnehmung. Das Office-Team hat eine ähnliche Studie mit ähnlichen Ergebnissen durchgeführt, daher kommen wir mit der abgerundeten Ecke voran. Wir treffen diese Entscheidung nicht leichtfertig oder im Vakuum.

Das bedeutet nicht, dass wir sie genau gleich machen. Wenn es Orte gibt, an denen wir uns verbessern können, wollen wir das. Wir wollen auch einzigartig sein, wie Felix es erwähnt, aber sie müssen aussagekräftig sein, nicht nur Meinungsverschiedenheiten. Dies sind Orte, an denen wir die einzigartigen Behandlungen von Fluent anwenden.

Wie ich bereits in dieser Diskussion erwähnt habe, arbeite ich sehr eng mit Office-, Windows- und Edge-Teams zusammen. Unsere Designteams sind bestrebt, ein Design zu haben, das aus Microsoft/Fluent kommt, daher prüfen sie die Unterschiede sehr sorgfältig und versuchen, die Unterschiede zu beseitigen, die keinen Sinn ergeben, damit wir einen Ausgangspunkt haben, an dem wir uns gemeinsam weiterentwickeln können.

Es ist jedoch sehr interessant, dass viele dieser Änderungen von diesen Teams separat inkubiert wurden, aber sie kamen oft an sehr ähnlichen Stellen an. Das Ausdünnen des Rahmens ist etwas, das Office zuerst implementiert hat, aber Windows diskutiert das seit einiger Zeit. Und diese sind alle Teil der Leitung von Fluent Design, wie Martin vorschlägt.

Ich befürworte die Änderung der Standardsteuerelemente, und die Fabric Web-Steuerelemente fühlen sich eleganter und ausgefeilter an als die aktuellen IMO-Designs für XAML-Steuerelemente.

Aber dies ist mehr als nur das Ändern von Vorlagen, es geht darum, mehr Eigenschaften bereitzustellen, die es Entwicklern ermöglichen, diese Änderungen einfach zu überschreiben, ohne das gesamte Steuerelement neu erstellen zu müssen.

Die neuen Standardwerte für CornerRadius könnten ThemeResources sein, so etwas wie
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

Dann kann ein Entwickler diese einfach in App.xaml überschreiben - oder CornerRadius="0" auf die Steuerelemente anwenden, die im

Im Anschluss daran würde ich auch vorschlagen, dass BorderThickness die Standardeinstellungen auf 1epx anstelle von 2epx gesetzt hat - aber alle Steuerelemente würden ThemeResources verwenden, etwa wie:
<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"

Diese können also global in App.xaml überschrieben werden oder nur in einem Stil, der auf einige Steuerelemente angewendet wird.

Legen Sie einen neuen Standard fest, aber lassen Sie Überschreibungen zu, die keine erneute Vorlage erfordern.

Aber dies ist mehr als nur das Ändern von Vorlagen, es geht darum, mehr Eigenschaften bereitzustellen, die es Entwicklern ermöglichen, diese Änderungen einfach zu überschreiben, ohne das gesamte Steuerelement neu erstellen zu müssen.

@mdtauk , Das ist richtig und wie ich bereits erwähnt habe, wird es durch die mit #684 vorgeschlagene Änderung verfolgt. Fügen Sie @kikisaints zu diesem Thread hinzu, damit sie das gute Feedback sieht, das Sie gegeben haben (aber nicht das Ganze zitieren, da es riesig sein wird. :) :)

@chigy Als ich diese letzte Antwort einfügen :)

Ich würde gerne mehr über die Diskussionen erfahren, die die Windows-UI-Teams geführt haben. Ich habe in den letzten Jahren Ideen für das Design von Steuerelementen für eigene Zwecke und für Twitter-Gespräche entwickelt, und einige der Dinge, die ich jetzt in Fabric Web und Office Xaml ändern wollte, wollten ich ändern. Randdicken, gewisse Inkonsistenzen bei Radio Buttons, Checkboxen, Dropdowns etc.

Ich bin gespannt, wie sich diese Veränderungen entwickeln, und freue mich, an den Diskussionen hier beteiligt zu sein!

Vielen Dank, dass Sie meinen Enthusiasmus in der von mir beabsichtigten konstruktiven Weise aufgenommen haben, auch wenn er aufdringlich oder eigensinnig rüberkommt.

Ich begrüße definitiv die Entscheidung, das Anpassen von Steuerelementen so einfach wie das Festlegen einer Eigenschaft zu machen, anstatt das gesamte Steuerelement für eine einzige Änderung neu erstellen zu müssen.

Was ich jedoch am Ende am meisten sehen möchte, ist eine verbesserte Personalisierungsunterstützung im Betriebssystem: Wie Sie inzwischen wissen, bin ich kein Fan der vorgeschlagenen Änderungen (subtiler Eckenradius ist eine Sache, Reduzierung der Randdicke eine andere). und ich mag das aktuelle design. Auf der anderen Seite haben wir Benutzer wie @mdtauk , die eindeutig ein großer Fan der vorgeschlagenen Änderungen sind. Windows sollte die neue Flexibilität in diesen Steuerelementen nutzen und Optionen bieten, um das Aussehen systemweit anzupassen - für Fälle, in denen es sinnvoll ist, und Entwicklern die Flexibilität geben, die Systemeinstellungen abzulehnen.

Insbesondere im Hinblick auf das Grenzdenken macht das vorgeschlagene System die Bereitstellung einer systemweiten Option für Eckradien extrem einfach (genau wie bei der Akzentfarbe heute, die als Ressource exponiert wird, die Apps verwenden können). Vor allem, da die vorgeschlagenen Eckradienänderungen eher klein sind, könnte dies auch designtechnisch für Apps machbar sein (und wenn der Entwickler nicht der Meinung ist, kann er sich jederzeit abmelden).

Ich würde gerne mehr über die Diskussionen erfahren, die die Windows-UI-Teams geführt haben.

@mdtauk , es ist unsere Absicht, alle kommenden visuellen Änderungen über GitHub

Was ich jedoch am Ende am meisten sehen möchte, ist eine verbesserte Personalisierungsunterstützung im Betriebssystem ...
Windows sollte die neue Flexibilität in diesen Steuerelementen nutzen und Optionen bieten, um das Aussehen systemweit anzupassen - für Fälle, in denen es sinnvoll ist, und Entwicklern die Flexibilität geben, die Systemeinstellungen abzulehnen.

@Felix-Dev , die Art der Personalisierung, die wir derzeit für Windows untersuchen (ich gehe davon aus, dass der Benutzer die Einstellungen ändern kann?) sind Dinge, die sich auf die Benutzerfreundlichkeit auswirken. Ich bin mir nicht sicher, ob abgerundete Ecken oder Randdicke eine davon sind. Es ist nicht das Ziel von Windows, es so zu gestalten, dass der Benutzer die gesamte Benutzeroberfläche nach seinen Wünschen gestalten kann. Wir wollen immer noch Windows-Design bieten und abgerundete Ecken sind einer der wichtigsten Designfaktoren, die meiner Meinung nach nicht für die Personalisierung gedacht sind ... Zumindest im Moment gemäß der Definition von Personalisierung. Vielen Dank für Ihr Feedback und ich werde nach Stellen suchen, an denen es sinnvoll ist, diese zu enthüllen, wenn wir über weitere Designänderungen nachdenken.

@Felix-Dev Bei der Menge an Anpassungen, die Entwickler an den Steuerelementen vornehmen können, wäre es unmöglich, mit den Betriebssystemeinstellungen in Bezug auf Änderungen des Steuerelementdesigns konsistent zu sein.

@chigy Wenn Sie die Designkompositionen für jedes der neuen Steuerelementdesigns auf GitHub bringen, wäre es nützlich, Informationen aufzunehmen, die Microsoft aus Forschungsstudien gesammelt hat, um zu erfahren, warum die Änderungen die Dinge verbessern. Anstelle von "Wir haben dies von einem Dreieck in ein Sechseck geändert" wäre es etwa "Bei der Durchführung eines Experiments zur Benutzerfreundlichkeit und Vertrautheit wurde festgestellt, dass es mehr Menschen einfacher fanden, dieses Tastendesign von einem Dreieck in ein Sechseck zu ändern". um es als Schaltfläche zu identifizieren, und im Vergleich zu anderen Plattform-UIs fühlte man sich mit diesem Design verbunden" usw

@mdtauk

Bei der Menge an Anpassungen, die Entwickler an den Steuerelementen vornehmen können, wäre es unmöglich, mit den Betriebssystemeinstellungen in Bezug auf Änderungen des Steuerelementdesigns konsistent zu sein.

Ich spreche nicht davon, wie externe Entwickler diese Benutzereinstellung respektieren würden – sie können die Steuerelemente bereits heute nach Belieben gestalten – sondern über das Aussehen von Windows-Komponenten. Das bedeutet, dass die Einstellungen-App, Zwischenablage, Snip & Sketch, UI-Elemente in Taskleisten-Flyouts (wie die Schaltflächen im Netzwerkbedienfeld) usw.

Ich für meinen Teil verwende kaum UWP-Apps außerhalb der von MS bereitgestellten, sodass ich keine Probleme mit benutzerdefinierten Stilen von externen Entwicklern habe. Ich interagiere jedoch täglich mit UWP-Elementen im Windows-System.

@chigy Richtig, ich habe mir eine Einstellung in der Win 10-Einstellungen-App angesehen, bei der ein Benutzer das Aussehen der Benutzeroberfläche bis zu einem gewissen

Eine letzte Sache: Win 10 hat 800 Millionen Benutzer, Tendenz steigend. Nicht alle sind von den vorgeschlagenen Änderungen so begeistert wie Martin und es wäre schön, wenn Windows auch versuchen würde, diesen Benutzern entgegenzukommen. Wie Sie sagten, ist die Benutzeroberfläche sehr subjektiv, und wenn es eine Möglichkeit gibt, das Benutzeroberflächensystem flexibler zu gestalten, sollte MS dies zumindest in Betracht ziehen.
Für Internetbrowser gibt es zum Beispiel eine ganze Branche der Themen, bei denen nicht nur Farben geändert werden, sondern auch das Aussehen von UI-Elementen wie Tabs oder der Suchleiste: https://github.com/muckSponge/MaterialFox (Lustig genug , dieses spezielle Projekt fügt Firefox abgerundete Ecken hinzu - und ich bin kein Fan von abgerundeten Ecken.)
Für das Windows-System können Benutzer jedoch nicht einfach ein eigenes Thema erstellen, daher wäre es schön, wenn MS UI-Anpassungsoptionen bereitstellen könnte.

@mdtauk @chigy
Bitte schau dir diesen Reddit-Post an, um zu sehen, dass nicht nur ich kein Fan von abgerundeten Ecken bin. Wir haben Leute, die den ganzen Umzug nicht mögen und auch viele fordern, den Benutzern die Wahl für ihr Windows-Design zu geben, damit sie zum aktuellen Aussehen zurückkehren können.

Okay, also wurde ich von vielen Leuten gedrängt, diesem Thread Feedback zu geben, weil es eine Anfrage zu vorgeschlagenen Änderungen in der Benutzeroberfläche gibt, hauptsächlich die Idee, buchstäblich alles abgerundete Ecken aufzuzwingen, und als jemand, der sowohl ein grafischer Interface-Designer ist (meist Konzept) und Design) und verwendet Windows 10, seit es sogar in der Entwicklung war Über eine Option in der Personalisierung hat der Benutzer die Präferenz, ob er abgerundete Ecken oder scharfe Ecken möchte.

Um es zu beklagen: Halten Sie sie einfach quadratisch oder machen Sie es auf Benutzerebene optional.

Ich habe mehr als genug Gründe, aber meine größten sind einfach die Tatsache, dass Windows seit Windows 8 quadratische Ecken hat und seit Jahren so ziemlich alles darum herum entwickelt wurde und Android-Plattformen aus irgendeinem Grund. Das größere Problem ist, dass dies nicht nur die Menge an Inkonsistenzen im gesamten System erhöhen würde, sondern eine so "kleine" Änderung der Benutzeroberfläche erzwingen würde, die in Wirklichkeit viel größer ist, als Sie wissen, würde auch Inkonsistenz im gesamten App-Ökosystem verursachen, weil Sie haben werden Entwickler, die ihre App nicht einfach wegen einer solchen einfachen Änderung aktualisieren möchten.

Meiner Meinung nach sollte dies absolut KEINE Entwicklerwahl sein, nicht nur aus den oben genannten Gründen, sondern bei Windows ging es immer um Anpassung und Leistung, nehmen Sie das Windows 98 alias Classic-Thema als Beispiel. Als Windows XP auf den Markt kam, verwendeten viele Leute noch Classic, weil es mehr Anpassungsoptionen hatte als das Luna-Thema. XP hat das Luna-Thema nicht jedem aufgezwungen, Sie hatten immer noch die Möglichkeit, Classic zu verwenden. Diese vorgeschlagene Änderung gibt Ihnen NICHT die Möglichkeit, eckige Ecken überall beizubehalten, sie zwingt jeden dazu, sich mit etwas zu befassen, das er möglicherweise nicht mag, meiner Meinung nach eine sehr schlechte Sache, wenn es darum geht, einen Benutzer das Betriebssystem nach seinen Wünschen anpassen zu lassen.

Ich weiß, dass du wahrscheinlich denkst, "so eine kleine Änderung wäre nicht etwas, an dem die Benutzer interessiert wären" oder "den Benutzer zu viele Dinge anpassen zu lassen, würde sie verwirren", aber ich bin ziemlich sicher, dass jeder Benutzer in der Lage wäre, zu verstehen, was zwischendurch umgeschaltet wird runde und scharfe Ecken oder sogar ein Thema würden bei der richtigen Beschreibung und dem richtigen Kontext ausreichen. Ich werde auch hinzufügen, dass viele Leute definitiv daran interessiert sind, die Option dafür zu haben, anstatt sich gegen ihren Willen etwas anderes aufdrängen zu lassen Ecken überall.

Viele Leute mögen sogar den Vorschlag für abgerundete Ecken sehr nicht und viele halten ihn für einen Rückschritt, sieh dir sogar die Kommentare in mehreren Videos an, in denen die kommende Hololens-Benutzeroberfläche abgerundet wird Kommentare mit Variationen von "Microsoft wirft das Handtuch in der UI-Abteilung und kopiert entweder Apple oder Google", obwohl es nicht das erste Mal ist, dass Microsoft abgerundete Ecken verwendet, wird dies jetzt als eine negative Sache angesehen.

Auch dies sollte nur wirklich eine Option oder sogar ein Thema sein, es ist nicht einmal ein neues Konzept, da Windows in früheren Versionen seit Jahren Themen hatte auf alle und reduzierte Optionen.

Ich habe einen Reddit-Post erstellt , der auf diesen Vorschlag verlinkt, damit wir mehr Feedback sammeln können. Wenn ich die bisherigen Kommentare durchschaue, kann ich sagen, dass viele Leute den dezenten Ansatz mit den abgerundeten Ecken schätzen.

Es wird auch auf Inkonsistenzen der Benutzeroberfläche hingewiesen – sogar in offiziellen Win 10 MS-Apps, siehe Einstellungen-App und Sicherheits-App (NavigationView erstreckt sich in die Titelleiste) – und auch die Unterschiede zwischen Win32-Systemkomponenten und den neueren UWP-Elementen. Wie @SavoySchuler erwähnt, wird dies hoffentlich mit WinUI 3.0 behoben. Es ist kein spezieller Punkt in Bezug auf diesen Vorschlag, sondern eher ein "übergreifender" Wunsch vieler von uns Windows-Benutzern. Nicht so sehr über Ecken, die rund sind oder nicht, sondern über die Konsistenz im Windows-System.

Konsistenz ist hier der Schlüssel und war mein Hauptanliegen.

Bei WinUI 3.0 geht es um Änderungen an den XAML-Steuerelementen, die sich auf Posteingangs-Apps und die Windows-Benutzeroberfläche auswirken.

Fabric Web ist ein eigenes Team, aber alle Teams kommunizieren gemeinsam und stützen ihre Entscheidungen auf Fluent Design. Daher gehe ich davon aus, dass das Design von Fabric Web die neuesten Erkenntnisse von Microsoft ist und daher Konsistenz vorherrschen sollte.

Xbox Next, Windows Lite und Windows Core OS werden mit neuen Shells kommen, das muss auch für die Teams eine Überlegung sein – mit Windows 10 für Legacy-Support

Was @chigy gesagt hat, ist genau das, wonach ich und viele andere gerade gefragt haben, eine subtilere Änderung, die es auch Benutzern auf Benutzerebene anstelle der Entwicklerebene ermöglichen würde, einfach zu entscheiden, ob sie scharfe Ecken oder abgerundete Ecken sehen möchten, ähnlich wie Früher funktionierten Windows-Designs.

Basierend auf dem, was @Nepxune oben gesagt hat, wäre es vielleicht cool, Benutzern einen ausgewählten Bereich von Werten zu geben, aus denen sie für einen systemweiten Eckenradius auswählen können. Zumindest für kleine Werte im Bereich von 0 - 2 denke ich, dass es keine negativen Auswirkungen auf eine sorgfältig gestaltete Benutzeroberfläche geben würde. Immerhin handelt es sich um sehr subtile Änderungen, die die UI-Identität von Windows dennoch bewahren sollen.

Ich sehe jedoch, dass selbst wenn die UI-Anpassung zu Windows hinzugefügt wird, es Grenzen geben muss, sowohl in der Anzahl der Elemente, die der Benutzer ändern kann, als auch in der Menge der Werte, aus denen ein Benutzer auswählen kann. Andernfalls besteht die Gefahr, dass sich die vorhandene Benutzeroberfläche negativ auswirkt und auch zu sehr vom gewünschten Windows-Look des Designteams abweicht.

Ich habe da eine andere Sichtweise.
Zuvor im Thread habe ich eine Diskussion darüber gesehen, wie die Stile Fabric UI (Web) und Windows (UWP) näher zusammengebracht werden, und das beunruhigt mich ein wenig.

Hier ist ein Kontext: Ich bin seit Jahren ein Benutzer von Microsoft Edge, und eines meiner Lieblingsdinge daran war das UWP-inspirierte Erscheinungsbild. Als Edge Insider enthüllt wurde, war ich sehr enttäuscht, dass es ein modifiziertes Chrome- und Web-UI-Design anstelle des UWP-Stylings seines Vorgängers verwendet. Während die gezeigten runden Ecken sehr minimal sind, bis ich kein Problem damit habe, gibt mir dieser Thread das gleiche Gefühl der Enttäuschung. Ich möchte nicht, dass Windows sein einzigartiges (und überlegenes!) Erscheinungsbild verliert, um schlecht gestaltete "Webstandards" abzugleichen. Tatsächlich würde ich lieber sehen, dass Aspekte des Fluent UWP-Designs ihren Weg zu Fabric finden!

Ich glaube, der Plan für Edge besteht darin, Acrylic schließlich zurückzubringen und die Benutzeroberfläche mehr in Richtung eines Windows/Fluent-Design-Stils zu bewegen.

Aber Windows bewegt sich auch leicht nach vorne, um die Kluft hoffentlich zu überbrücken.

Es ist nicht unmöglich, eine Einstellung im Betriebssystem herbeizuführen, um zwischen abgerundeten und nicht abgerundeten Steuerelementen zu wählen, es ist unmöglich, sie allen Apps aufzuzwingen, und funktioniert ganz anders als die Visual Styles der XP-Ära.

Auch bei WinUI 3.0 geht es darum, die App-Plattform und die Steuerelemente vom Betriebssystem zu trennen, und daher ist es möglicherweise keine gute Entscheidung, mehr davon zu verbinden.

Natürlich haben Sie als App-Entwickler die Möglichkeit, den CornerRadius-Wert auf Ihren Steuerelementen auf 0 zu setzen, um die quadratischen Steuerelemente zurückzubringen.

Ich unterstütze diesen Druck für kleine abgerundete Ecken, aber ich bevorzuge das aktuelle Schieberegler-Steuerelement für den vertikalen Ziehpunkt gegenüber dem Schieberegler-Steuerelement für den Kreis. Der vertikale Griff fühlt sich präziser an und ist auf einen Blick leichter zu erkennen, wo er sich befindet. Zumindest sehe ich das so. Mach weiter so!

Gibt es einen Grund, warum der Daumen der MediaTransport-Scrub-Leiste rund mit einem Umriss ist, während der vorgeschlagene neue Slider-Daumen ein ausgefüllter Kreis ist?

Ich denke, der Kreisdaumen ist viel angenehmer als die umständliche Rauten- / Pillenform, die zu keinem der anderen Bedienelemente passt.

Ich weiß nicht, ob Sie sich daran erinnern, aber selbst die Leute in abgerundeten Ecken zu kacheln, war für viele Windows-Fans damals ein großes Problem und das war nur eine kleine Änderung. Überall abgerundete Ecken würden für mich bedeuten, dass Windows sein unverwechselbares Aussehen verliert, das es seit der Einführung der Metro-Designsprache und des fließenden Designs hat. Die Designsprache war für mich immer ein wichtiger Schlüssel, was die uwp-Entwicklung für mich attraktiv machte. Es wäre wirklich traurig zu sehen, dass es weggeht und generisch wird.

Zusammen mit den Designkonzepten von TextBox und NumberBox, die ich erstellt habe - hier sind einige für die ComboBox und die EditableComboBox

Gut gemacht!
Ich habe ein paar Vorschläge zu den Flyout-Menüs. Brauchen wir bei den Schatten, die das Menü abgrenzen, wirklich den Rahmen? Und IMO könnte das Auswahlhighlight die gesamte Breite der Flyout-Fläche abdecken, ohne Lücken zu hinterlassen.

Ich schätze die dünneren, unfokussierten Ränder, und das Leuchten der Fokus-Enthüllung sollte es einfacher machen, zu erkennen, welches Element fokussiert ist, während Sie mit einer Tastatur durch die Benutzeroberfläche navigieren (ich würde es tatsächlich vorziehen, dass es etwas stärker ist als oben).

Gut gemacht!
Ich habe ein paar Vorschläge zu den Flyout-Menüs. Brauchen wir bei den Schatten, die das Menü abgrenzen, wirklich den Rahmen? Und IMO könnte das Auswahlhighlight die gesamte Breite der Flyout-Fläche abdecken, ohne Lücken zu hinterlassen.

Das Auswahlhighlight deckt die gesamte Breite ab, aber ich habe den Flyouts einen helleren inneren Rand platziert, der ihm hilft, sich zusammen mit dem Acryleffekt und dem Schatten von der Oberfläche zu heben - der innere Rand könnte jedoch dezenter gemacht werden, wenn er zu stark ist - es ist mehr eine Idee als ein vollständig endgültiger Designvorschlag.

@mdtauk

Es ist nicht unmöglich, eine Einstellung im Betriebssystem herbeizuführen, um zwischen abgerundeten und nicht abgerundeten Steuerelementen zu wählen, es ist unmöglich, sie allen Apps aufzuzwingen, und funktioniert ganz anders als die Visual Styles der XP-Ära.

Deshalb habe ich gesagt, es für Entwickler optional zu machen. Ehrlich gesagt würde sich nichts wirklich ändern. Apps von Drittanbietern können bereits mit jedem gewünschten Aussehen geliefert werden. Wenn ein Unternehmen seine App mit einer abgerundeten Benutzeroberfläche (Kreis-Buttons,...) ausliefern möchte, steht ihm dies frei.

Auch bei WinUI 3.0 geht es darum, die App-Plattform und die Steuerelemente vom Betriebssystem zu trennen, und daher ist es möglicherweise keine gute Entscheidung, mehr davon zu verbinden.

Wie oben gesagt, stelle ich mir das ähnlich vor, wie die Akzentfarbe (die der Benutzer in den Einstellungen einstellen kann) heute gehandhabt wird. Stellen Sie es als Ressource bereit, an die Steuerelemente ihren Eckenradius binden können. Auf diese Weise werden Änderungen des Eckenradius in der App ohne zusätzliche Arbeit für die Entwickler widergespiegelt.

Ich hinterlasse hier nur mein Feedback von reddit aus Benutzersicht: „Ich liebe den sauberen Look mit abgerundeten Ecken aus dem Vorschlag. Wie bei allen anderen (auf reddit) braucht die Konsistenz des gesamten Betriebssystems immer noch viel Liebe.“

Gibt es einen Grund, warum der Daumen der MediaTransport-Scrub-Leiste rund mit einem Umriss ist, während der vorgeschlagene neue Slider-Daumen ein ausgefüllter Kreis ist?

@mdtauk , das ist tatsächlich etwas, das wir uns vornehmen werden , also

Ich habe ein paar Vorschläge zu den Flyout-Menüs. Brauchen wir bei den Schatten, die das Menü abgrenzen, wirklich den Rahmen? Und IMO könnte das Auswahlhighlight die gesamte Breite der Flyout-Fläche abdecken, ohne Lücken zu hinterlassen.

@quantumfrost , Ja, das tun wir tatsächlich. Schatten ist klug. Wenn sich das System im Energiesparmodus befindet oder in einer anderen Situation, in der wir den Schatten ausschalten, kommt der Rand ins Spiel. Wir haben die Umrandung so gestaltet, dass sie dezent ist. Wir haben mehrere verschiedene Optionen evaluiert, aber diese war die robusteste.

@nepxune , @mdtauk
Vielen Dank für dein Feedback.
Lassen Sie mich auf einige der oben genannten Punkte eingehen.

Die Option, Benutzereinstellungen bereitzustellen, um eine Eckenrundung zu ermöglichen, aus der der Benutzer auswählen kann, ist interessant. Es hat jedoch auch viel mit diesem Feedback über andere wichtige Funktionen zu tun, die wir im gesamten Windows-System abwägen müssen.

Als Anwendungsentwickler hoffe ich, dass Sie sich alle der Notwendigkeit bewusst sind, Prioritäten zu setzen und das Richtige für Ihre Kunden zu tun. Im Fall von Windows ist der Kunde der Benutzer, der das Betriebssystem verwendet. Natürlich sind auch Entwickler, die Apps auf diesem Betriebssystem erstellen, wichtige Kunden, und ich glaube, dass wir durch das einfache Wechseln von Eckenradien das Hauptproblem lösen können, das diese Änderung mit sich gebracht hätte.

In Bezug auf die Benutzer, die das Betriebssystem verwenden, haben wir von unseren Kunden gehört, dass Windows zu einschüchternd ist. Sowohl das Windows- als auch das Office-Team führten eine Benutzerstudie durch, bei der sie (unabhängig voneinander) zu dem Schluss kamen, dass selbst eine so subtile wie eine abgerundete Ecke einen Unterschied darin macht, dass sich das Produkt vertraut und zugänglich anfühlt.

Ich weiß also, dass viele Leute auf GitHub und anderen Foren erwähnen, dass wir iOS und Android folgen, aber dem ist nicht so. Wir kommen zu dieser Entscheidung aus dem Verständnis unserer Nutzer. Ja, die Tatsache, dass sie abgerundete Ecken verwenden, trägt zum Vertrautheitsaspekt bei, aber wir verfolgen nicht blindlings, was die Branche tut.

Ich habe da eine andere Sichtweise.
Zuvor im Thread habe ich eine Diskussion darüber gesehen, wie die Stile Fabric UI (Web) und Windows (UWP) näher zusammengebracht werden, und das beunruhigt mich ein wenig.

Hier ist ein Kontext: Ich bin seit Jahren ein Benutzer von Microsoft Edge, und eines meiner Lieblingsdinge daran war das UWP-inspirierte Erscheinungsbild. Als Edge Insider enthüllt wurde, war ich sehr enttäuscht, dass es ein modifiziertes Chrome- und Web-UI-Design anstelle des UWP-Stylings seines Vorgängers verwendet. Während die gezeigten runden Ecken sehr minimal sind, bis ich kein Problem damit habe, gibt mir dieser Thread das gleiche Gefühl der Enttäuschung. Ich möchte nicht, dass Windows sein einzigartiges (und überlegenes!) Erscheinungsbild verliert, um schlecht gestaltete "Webstandards" abzugleichen. Tatsächlich würde ich lieber sehen, dass Aspekte des Fluent UWP-Designs ihren Weg zu Fabric finden!

@19lmyers
Vielen Dank für Ihr Feedback zu Ihrer Sorge, dass Windows sein eigenes einzigartiges (und sogar überlegenes) Aussehen verliert. Wie im obigen Kommentar erwähnt, schätzen unsere Benutzer nicht unbedingt, dass Windows zu unterschiedlich ist, weil sie ihnen nicht vertraut sind, daher ist dies ein Balanceakt.

Unter Fluent Design System diskutieren Designteams im gesamten Unternehmen viele Unterschiede und versuchen, bisher eingeführte unnötige Unterschiede zu beseitigen. Genau wie ich oben zu iOS und Android gesagt habe, sind die von uns vorgeschlagenen Designs nicht darauf zurückzuführen, dass wir Fabric kopieren, sondern unsere Windows-Designer sind auf der Grundlage einer Neubewertung ihres eigenen UI-Systems zu ihnen gekommen. Interessanterweise führen sie oft zu einem ähnlichen Design ... Allerdings schätze ich den Enthusiasmus vieler Leute wirklich, Windows einzigartig zu machen.

Willkommen in unserem Repo, @zag2me! Wir freuen uns, dass Sie sich hier an den Diskussionen beteiligen. Ich stimme zu und es ist der richtige Ort, um auf die Themen aufmerksam zu machen, die Ihnen wichtig sind! Unser Formular zur Funktionsanfrage finden Sie hier: https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose

@chigy

Die Option, Benutzereinstellungen bereitzustellen, um eine Eckenrundung zu ermöglichen, aus der der Benutzer auswählen kann, ist interessant. Es hat jedoch auch viel mit diesem Feedback über andere wichtige Funktionen zu tun, die wir im gesamten Windows-System abwägen müssen.

In Bezug auf die Benutzer, die das Betriebssystem verwenden, haben wir von unseren Kunden gehört, dass Windows zu einschüchternd ist. Sowohl das Windows- als auch das Office-Team führten eine Benutzerstudie durch, bei der sie (unabhängig voneinander) zu dem Schluss kamen, dass selbst eine so subtile wie eine abgerundete Ecke einen Unterschied darin macht, dass sich das Produkt vertraut und zugänglich anfühlt.

Wir kommen zu dieser Entscheidung aus dem Verständnis unserer Nutzer. Ja, die Tatsache, dass sie abgerundete Ecken verwenden, trägt zum Vertrautheitsaspekt bei, aber wir verfolgen nicht blindlings, was die Branche tut.

Vielen Dank für Ihr Feedback zu Ihrer Sorge, dass Windows sein eigenes einzigartiges (und sogar überlegenes) Aussehen verliert. Wie im obigen Kommentar erwähnt, schätzen unsere Benutzer nicht unbedingt, dass Windows zu unterschiedlich ist, weil sie ihnen nicht vertraut sind, daher ist dies ein Balanceakt.

Und hier ist das Problem, das ich damit habe: Sie erwähnen "Windows-Benutzer", aber wenn überhaupt, dieser Thread und andere verlinkte Reddit-Threads haben bisher gezeigt, dass es keine homogene Gruppe von "Windows-Benutzern" gibt. Am Ende des Tages kann ein Unternehmen immer der Richtung folgen, die die Mehrheit seiner Kunden haben möchte, aber selbst das hinterlässt Probleme. Was ist, wenn das Verhältnis eher klein ist (und hinter jeder Zahl eine riesige absolute Anzahl von Benutzern steht)? Aufgrund des Feedbacks hier, auf reddit und anderen Stellen habe ich nicht das Gefühl, dass es eine überwältigende Mehrheit für die eine oder andere Benutzeroberfläche gibt.

Was uns zu dem Vorschlag führt, den einige von uns in Umlauf gebracht haben: Hinzufügen weiterer UI-Anpassungsoptionen zu Windows.

Wie Sie zu Recht sagen, sollten die gegebenen Anpassungsoptionen sorgfältig abgewogen werden, aber die Anpassung an sich sollte nicht einfach als Option verworfen werden. Wie Sie sagten, und an dieser Stelle fange ich an, mich zu wiederholen, ist die vorgeschlagene Änderung des Eckenradius eine kleine Änderung, daher sollten alle Auswirkungen einer Benutzerauswahl auf die Benutzeroberfläche vernachlässigbar oder gar nicht vorhanden sein. Ich und andere haben auch für dieses Beispiel auf Einschränkungen hingewiesen, wie z Identität", die Ihr Team schaffen möchte.

Lange Rede, kurzer sorgfältig gemessene Anpassungsoptionen zusätzlich zu diesen Designänderungen klingen nach einer großartigen Möglichkeit, die vielen verschiedenen UI-Präferenzen unter uns Windows-Benutzern zu Beitrag zur Schaffung einer zufriedenstellenden Benutzeroberfläche für die gesamte Familie von uns leidenschaftlichen Windows-Benutzern leisten .

@chigy
Die meisten Leute würden zustimmen, dass 2px ein guter Radius wäre. Dem Rest eine Option zum Ausschalten zu geben, wäre ein gutes Ideal.

Die meisten Benutzer möchten, dass Windows auf dem neuesten Stand der Benutzeroberfläche ist, und andere ältere Benutzer möchten sich nicht ändern.

Opfern Sie das Wechselgeld nicht für die Wenigen, sondern geben Sie ihnen einfach die Möglichkeit, es auszuschalten.

@shaheedmalik
Es gibt hier keine "alten" Benutzer und ich sehe auch nicht, wie Sie zu "die meisten Benutzer wollen [abgerundete Ecken]" kommen oder dass der aktuelle Windows-Look nicht "aktuell" ist.

Die Benutzeroberfläche ist sehr subjektiv, aber das bedeutet nicht, dass wir unterschiedliche Meinungen einfach als "Erbschaft", "nicht willens zur Änderung" usw. beschönigen können ...

Lassen Sie uns nicht versuchen, das, was andere Benutzer sagen, als Meinungen von "Benutzern, die nicht aus der Vergangenheit aufwachen wollen" einfach zu verwerfen und die aktuelle Diskussion leidenschaftlich, aber auch respektvoll zu führen, wie sie bisher war.

@Felix-Dev Legacy-Benutzer sind diejenigen, die bei der Gelegenheit auf Windows 7 geblieben wären, diejenigen, die gegen Änderungen in Windows 8 resistent waren, diejenigen, die gegen die zukünftigen Änderungen der Betriebssystem-Benutzeroberfläche resistent waren.

Apple und Google kopierten Funktionen von Windows 8.1, implementierten sie und die Benutzer sprangen zu diesen Plattformen, weil sie als innovativ angesehen wurden. In der Zwischenzeit hört Microsoft auf Legacy-Benutzer, die aufgrund einer lautstarken Minderheit zurückgefahren wurden.

In diesem speziellen Fall möchte die Mehrheit abgerundete Ecken als verlinkt (https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/)

Die Sache ist die, ich bin kein Legacy-Benutzer und es schien mir, dass Sie gerade alle, die den aktuellen Push der abgerundeten Ecken (und die mögliche Reduzierung der Randdicke) nicht mögen, in genau diese Kategorie geworfen haben. Ich bekomme auch keine negative Stimme für meinen Beitrag.

Zum Mehrheitsfall: Mir war keine Design-Umfrage von MS zu genau diesem Thema bekannt und aufgrund der Reaktionen vieler Nutzer vor einem Monat, als Details zu diesem Push erstmals im Internet auftauchten, waren auch viele Nutzer nicht bekannt ( so wahrscheinlich war nicht gefragt worden). Wenn Sie sich diesen Reddit-Post ansehen (der übrigens dreimal so viele Kommentare hat wie der oben verlinkte Reddit-Thread), werden Sie feststellen, dass das Bild nach unserem Kenntnisstand nicht ganz eindeutig ist. Ich kann nicht behaupten "diese Position ist eindeutig in der Mehrheit" und werde dies auch in Zukunft unterlassen.

Wenn ich mich in Ihrem Beitrag irre, dann entschuldige ich mich, aber so wie ich ihn gelesen habe, war es eindeutig ablehnend gegenüber jeder Stimme, die sich gegen diese Änderung einsetzt und sie als die Stimme eines "alten Benutzers, der keine Änderung will" erklärte ". Das ist mir gegenüber respektlos, und alle anderen würden sich an dieser Debatte beteiligen.

@Felix-Dev Versuchen wir nicht, persönliche Meinungen in diese Auf- und Abstimmen und Antworten hineinzulesen.

Die einfache Antwort ist, dass diese Änderungen nicht aus einer Laune heraus vorgenommen werden oder um andere UI-Stile der Plattform zu kopieren, sondern als Ergebnis von Beratung, Feedback und dem ausdrücklichen Willen von Benutzern und Entwicklern.

Wir sollten versuchen, die Diskussionen konstruktiv zu halten, also nicht darüber, ob die Änderungen vorgenommen werden sollen oder nicht, sondern auf welche Weise.

Die Leute hassten die abgerundeten Ecken im ursprünglichen Beitrag, da sie zu rund waren.
Dieser neuere Beitrag verlinkt auf diesen aktualisierten GitHub-Vorschlag. Das neuere Feedback spiegelt die Antworten auf den aktualisierten Vorschlag wider. Darüber hinaus wurde der ursprüngliche Beitrag von vor einem Monat verlinkt, um Benutzern die Änderungen vom ursprünglichen Angebot zum überarbeiteten Angebot anzuzeigen.

Ich stimme zu, wir sollten auf den Vorschlag zurückkommen und diese letzten Beiträge einfach vergessen.

Ich denke, es ist an dieser Stelle ziemlich klar, dass diese Änderungen vorgenommen werden und alles, was ich versuche, @chigy davon zu überzeugen, dass es einen @shaheedmalik , gesagt haben, Eckradiusanpassung ein gutes Ideal sein.

Im Moment gibt es einen Vorschlag, den Entwicklern zu erleichtern, ihren eigenen CornerRadius für jedes Steuerelement festzulegen ( #684) , wodurch das Team auch standardmäßig CornerRadii zu den Steuerelementen hinzufügen kann.

Dies auf Betriebssystemebene zu tun, ist eine komplizierte Aufgabe, und die Forschung rechtfertigt nicht ganz den Engineering-Zeit- und -Aufwand, der mit der Implementierung verbunden ist.

Aber Sie haben Ihre Ansichten klar gemacht @Felix-Dev und wenn die neuen Steuerelemente in den Händen der Mehrheit der Windows-Benutzer sind, könnte das erhaltene Feedback dazu führen, dass diese Idee in Zukunft untersucht wird.

Ich habe die Spezifikation aktualisiert, um "AppBarSeparator" aus der Rundung zu entfernen, da ich bestätigt habe, dass dies eine 1px-Zeile ist.

Ich habe die Spezifikation aktualisiert, um "AppBarSeparator" aus der Rundung zu entfernen, da ich bestätigt habe, dass dies eine 1px-Zeile ist.

@chigy Bei einer Skalierung von 100 % ist es 1 epx - aber bei einer Skalierung von 200 %, 300 %, 400 % kann dies etwas Aufmerksamkeit erfordern.

Wenn es wirklich eine Linie und kein Rechteck ist - vielleicht StrokeStartLineCap und StrokeEndLineCap auf PenLineCap.Round setzen

@mdtauk

Dies auf Betriebssystemebene zu tun, ist eine komplizierte Aufgabe, und die Forschung rechtfertigt nicht ganz den Engineering-Zeit- und -Aufwand, der mit der Implementierung verbunden ist.

Dieser Vorschlag scheint bereits die meiste Arbeit zu erledigen, indem er eine CornerRadius-Eigenschaft zu Steuerelementen hinzufügt. Dann wäre nur noch die Erstellung der Ressource SystemCornerRadius, an die sich diese Steuerelemente für ihren tatsächlichen Eckenradius binden könnten (ähnlich wie Sie heute eine SystemAccentColor-Ressource verwenden, um Elemente Ihrer Benutzeroberfläche in der Akzentfarbe zu färben, die der Benutzer in der Einstellungs-App festlegt.

Wie viel Arbeit es wäre, eine solche Ressource zu erstellen und über die Einstellungs-App aktualisierbar zu machen, bleibt für MS zu kommentieren. Aber angesichts der Arbeit, die dieser Vorschlag sowieso bereits leistet, und auch der vorherigen Arbeit in Form der Bereitstellung einer AccentColor-Ressource, sehe ich nicht, wie anspruchsvoll dies sein sollte, wie Sie es sich vorstellen. Die Betriebssystemebene würde buchstäblich nur einen Eckradiuswert bereitstellen, der gelesen und geschrieben werden kann und dann dasselbe System verwenden kann, das Sie bereits für die heutige Akzentfarbenressource verwenden.

@mdtauk

Dies auf Betriebssystemebene zu tun, ist eine komplizierte Aufgabe, und die Forschung rechtfertigt nicht ganz den Engineering-Zeit- und -Aufwand, der mit der Implementierung verbunden ist.

Dieser Vorschlag scheint bereits die meiste Arbeit zu erledigen, indem er eine CornerRadius-Eigenschaft zu Steuerelementen hinzufügt. Dann wäre nur noch die Erstellung der Ressource SystemCornerRadius, an die sich diese Steuerelemente für ihren tatsächlichen Eckenradius binden könnten (ähnlich wie Sie heute eine SystemAccentColor-Ressource verwenden, um Elemente Ihrer Benutzeroberfläche in der Akzentfarbe zu färben, die der Benutzer in der Einstellungs-App festlegt.

Wie viel Arbeit es wäre, eine solche Ressource zu erstellen und über die Einstellungs-App aktualisierbar zu machen, bleibt für MS zu kommentieren. Aber angesichts der Arbeit, die dieser Vorschlag sowieso bereits leistet, und auch der vorherigen Arbeit in Form der Bereitstellung einer AccentColor-Ressource, sehe ich nicht, wie anspruchsvoll dies sein sollte, wie Sie es sich vorstellen. Die Betriebssystemebene würde buchstäblich nur einen Eckradiuswert bereitstellen, der gelesen und geschrieben werden kann und dann dasselbe System verwenden kann, das Sie bereits für die heutige Akzentfarbenressource verwenden.

Wäre es ein Schieberegler oder ein Umschalter?

[X] Abgerundete Ecken an den Bedienelementen

Es würde nicht nur einen einzelnen Eckenradiuswert geben, der übrigens eingestellt werden könnte. Einige Elemente hätten nur die Rundung auf einer Seite oder nur die oberen Ecken wären abgerundet. Die Flyouts und Pop-Over-Steuerelemente erhalten einen Radius von 4 epx, während andere Steuerelemente nur 2 epx haben.

Sie würden viele Variablen festlegen, da sich diese Einstellung im Betriebssystem ändert. Was ist dann mit dem Testen? Außerdem würden Erwartungen geweckt. Wie werden Benutzer auf Apps reagieren, von denen sie entscheiden, die Präferenzen des Benutzers zu ignorieren?
Wie kommunizieren Sie mit den Benutzern, welche Steuerelemente abgerundet werden und welche nicht? Einige Steuerelemente verfügen über innere oder äußere Rahmenelemente. Diese müssten ihre CornerRadius-Werte angepasst werden, um sicherzustellen, dass die Kanten der Formen richtig umschlossen werden.

Am Ende kann dies eine Änderung sein, die ohne viel Aufhebens begrüßt wird, und daher könnte es als Überreaktion angesehen werden, dem Betriebssystem eine weitere Option hinzuzufügen.

@mdtauk @chigy
Es würde sicherlich etwas Planung erfordern, aber das Team möchte es den Entwicklern eindeutig sehr einfach machen, quadratische Steuerelemente zu erstellen. Als solche Werteinstellung anstelle einer Eckenradius, würde ich gut mit einem einfachen UserRoundedCorners boolean Schalter sein. Tatsächlich bestand die Idee, Werte festzulegen, nur darin, noch mehr Optionen hinzuzufügen, während die Benutzer, die mit diesem Schritt nicht einverstanden waren, ihnen immer nur die Möglichkeit gaben, das Aussehen der Steuerelemente zurückzusetzen. Das wird also überhaupt kein Problem sein.

Was den Teil "noch eine andere Option" angeht: Das klingt so, als ob dem Benutzer bereits zu viele Optionen zur Verfügung stehen, was ein ganz anderes Thema ist und nicht als entscheidender Punkt verwendet werden sollte, um diesen einfachen Schalter nicht hinzuzufügen.

Fenster und das Design - Team Gespräche täglich (auf Twitter) , wie es will Benutzer einschließen und ausschließen sie nicht. Hier ist eine Chance, bei der es meiner Meinung nach relativ einfach für MS ist, eine einzige Option hinzuzufügen, um die schiere Vielfalt der Meinungen ihrer Benutzer zu respektieren.

Wie werden Benutzer auf Apps reagieren, von denen sie entscheiden, die Präferenzen des Benutzers zu ignorieren?

Ich glaube nicht, dass dies auch ein Problem ist, solange wesentliche Windows-Apps / UI-Elemente dies berücksichtigen würden (z. Apps von Drittanbietern können einen gewünschten Stil verwenden.

@mdtauk @chigy
Ich glaube, dass @Felix-Dev hier richtig liegt, ein boolescher Schalter mit einem einfachen Umschalter könnte der Weg für die Anpassung auf Benutzerebene sein Wenn es sich um einen Schieberegler mit 3 festen Preset-Positionen handelt, können sich die Dinge ändern.

Ein Schieberegler mit 3 festen Optionen würde eine zusätzliche Einstellung ermöglichen, die eine drastischere Änderung der Eckenradien wie die ursprünglich vorgeschlagene bewirken könnte, so dass Sie Folgendes haben könnten:

Scharf - Scharfe Ecken wie jetzt
Mittlere Option - Die neuen kleineren Radien
Abgerundet - Die ursprünglich vorgeschlagene Radienänderung oder etwas noch Abgerundeteres

Diese Option hat das Potenzial, alle Gruppen zufrieden zu stellen, und außerdem ist es eine drastische Änderung, die Sie tatsächlich als neues "Theming" -Feature in Windows ausgeben könnten, obwohl dies im Grunde genommen eher eine Änderung für Entwickler ist, indem Sie es als neues brandmarken "Theming"-Funktion mit entweder der Toggle-Implementierung oder dem 3-Preset-Slider, Sie könnten es auch als neues Feature für Verbraucher ausgeben.

Wie würden Benutzer auf Apps reagieren, die die Präferenzen des Benutzers ignorieren?

Ich habe das Gefühl, dass der Benutzer es einfach so sehen würde, wie er es derzeit mit der Akzentfarbe tut, wenn sie nicht verfügbar ist die Variable des Benutzers berücksichtigen.

Ich glaube nicht, dass es notwendig ist, in den Einstellungen eine Notiz zu setzen, die besagt, dass Apps von Drittanbietern die Einstellung nicht berücksichtigen Gut.

Dies auf Betriebssystemebene zu tun, ist eine komplizierte Aufgabe, und die Forschung rechtfertigt nicht ganz den Engineering-Zeit- und -Aufwand, der mit der Implementierung verbunden ist.

Aber Sie haben Ihre Ansichten klar gemacht @Felix-Dev und wenn die neuen Steuerelemente in den Händen der Mehrheit der Windows-Benutzer sind, könnte das erhaltene Feedback dazu führen, dass diese Idee in Zukunft untersucht wird.

Ich habe das Gefühl, hier etwas anmerken zu müssen. Auch wenn mir die vorgeschlagenen Änderungen in keiner Weise sehr am Herzen liegen (ich muss jeden Tag mit zu vielen UI-Stilen in verschiedenen Ökosystemen arbeiten, um Inkonsistenzen oder Änderungen zu stören), habe ich das Gefühl, dass diese Denkweise nicht gut ist. um eine reichhaltige benutzerfreundliche Erfahrung zu schaffen.

Bitte veröffentlichen Sie keine Funktionen, die zu 80 % fertig sind und in der nächsten Version möglicherweise auf 100 % gebracht werden.
Was wahrscheinlich passieren würde, ist, dass kein Entwickler die Zeit aufwenden würde, seine Apps sowohl für abgerundete als auch für nicht abgerundete Grenzen zu testen und zu entwickeln. Und warum sollten sie. Das System verwendet jetzt gerundet, warum sollte jemand wollen, dass seine App etwas anders aussieht als das Betriebssystem (sonst würden sie sowieso ein vollständiges Thema verwenden)
Wenn es einen systemweiten Umschalter gäbe, gäbe es einen Anreiz, ihn zu implementieren.
Aber wenn Sie die Dinge auf diese Weise tun, wird kein Umschalter erforderlich sein, da keine App die Notwendigkeit sieht, ihn überhaupt zu implementieren.

Zum ursprünglichen Thema:
Ich denke, die 2px-Rahmen sehen toll aus, außer den Combo-Boxen.
Das Highlight des letzten Elements sollte keinen weißen Rand darunter lassen (oder zumindest nicht mehr als links und rechts, das bedeutet natürlich, dass auch die unteren Highlight-Ecken abgerundet sein müssen) und eventuell keine abgerundeten Ecken im erweiterter Zustand zwischen der Box und dem Flyout. Ich habe das Gefühl, dass es diesen seltsamen zusammenhanglosen Blick zwischen ihnen gibt.
Vielleicht wäre es besser, das Flyout auf jeder Seite 2px kleiner zu machen und oben keine abgerundeten Ecken zu haben. Auf diese Weise würde es aussehen, als würde ein Stück Papier aus einem Spender gezogen. (Ich hoffe ihr versteht was ich meine :D leider habe ich gerade kein Werkzeug zur Verfügung um es zu skizzieren)

Zum ursprünglichen Thema:
Ich denke, die 2px-Rahmen sehen toll aus, außer den Combo-Boxen.
Das Highlight des letzten Elements sollte keinen weißen Rand darunter lassen (oder zumindest nicht mehr als links und rechts, das bedeutet natürlich, dass auch die unteren Highlight-Ecken abgerundet sein müssen) und eventuell keine abgerundeten Ecken im erweiterter Zustand zwischen der Box und dem Flyout. Ich habe das Gefühl, dass es diesen seltsamen zusammenhanglosen Blick zwischen ihnen gibt.
Vielleicht wäre es besser, das Flyout auf jeder Seite 2px kleiner zu machen und oben keine abgerundeten Ecken zu haben. Auf diese Weise würde es aussehen, als würde ein Stück Papier aus einem Spender gezogen. (Ich hoffe ihr versteht was ich meine :D leider habe ich gerade kein Werkzeug zur Verfügung um es zu skizzieren)

Ich weiß, was Sie beschreiben, und ich habe das für meine Designmodelle berücksichtigt. Das Problem dabei ist, dass ComboBox eine eigene Flyout-Vorlage erhält, die sie von Kontextmenüs, Menü-Flyouts, Präfix, Suffix, AutoVervollständigen-Flyouts usw. unterscheidet.

Das meinte ich (außer dass die Box selbst die unteren Ecken abgerundet halten könnte)
Ja, die verschiedenen Flyouts wären unterschiedlich, aber andererseits gibt es von Natur aus zwei Arten von Flyouts.
Diejenigen, die an etwas gebunden sind und diejenigen, die es nicht sind. Dass sie jetzt anders sein müssten, ist nur der Preis für abgerundete Ecken ;)
Außerdem könnte der Eckenradius nicht einfach von der übergeordneten Steuerung eingestellt werden, wenn er gestaltbar wäre.

Mein XAML ist etwas eingerostet, aber eine Combobox-Vorlage wie:

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

Außerdem könnte der Eckenradius nicht einfach von der übergeordneten Steuerung eingestellt werden, wenn er gestaltbar wäre.

Mein XAML ist etwas eingerostet, aber eine Combobox-Vorlage wie:

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

Dies ist vergleichbar mit dem Überschreiben von Stilen, aber für die Verwendung in Vorlagen benötigen Sie separate Stile für jede Ausrichtung.

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

Ausrichtungen:

• Unterseite
• BottomEdgeAlignedLeft
• BottomEdgeAlignedRight
• Voll
• Links
• LeftEdgeAlignedBottom
• LeftEdgeAlignedTop
• Rechts
• RightEdgeAlignedBottom
• RightEdgeAlignedTop
• Oberteil
• TopEdgeAlignedLeft
• ObenEdgeAlignedRight

Das Flyout ist in das ComboBox-Steuerelement eingebettet. Das Steuerelement hätte also eine CornerRadius-Eigenschaft, die sich nur auf die ComboBox auswirkt, nicht auf das Flyout, bei dem eine ThemeResource überschrieben wird.

<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>  

Im Anschluss an das Anpassen der CornerRadius-Eigenschaft im Flyout, wenn es ausgerichtet und an ComboBoxes (und andere Steuerelemente) angefügt wird. Möglicherweise müssen TopEdgeAligned und BottomEdgeAligned zur FlyoutPlacementMode- Enumeration hinzugefügt werden , um das gewünschte Ergebnis zu erzielen.

_(Aktualisiertes Bild)_

Ich habe auch das Flyout-Styling zu 800% genauer unter die Lupe genommen. Die zwei Ränder würden sicherstellen, dass die Flyouts sowohl in hellen als auch in dunklen Themen mit oder ohne Schatten erhöht aussehen.

Das sieht sehr gut aus.
Natürlich sieht das angehängte Aussehen etwas seltsam aus, wenn das Element, an das Sie es anhängen, kleiner ist als das Flyout, aber das muss definitiv die jeweilige App entscheiden.
Die Fokushervorhebung der Elemente in der unteren Reihe sollte wahrscheinlich nicht unten abgerundet werden (da das obere nicht für die obere Reihe ist), aber das ist wahrscheinlich nicht beabsichtigt.

Übrigens ist mir gerade aufgefallen, dass dieser "angehängte Look" die Funktionsweise der MacOs-Top-Menüleiste ist, daher scheint dieser Look nicht ungewöhnlich ungewöhnlich zu sein ;)

Das sieht sehr gut aus.
Natürlich sieht das angehängte Aussehen etwas seltsam aus, wenn das Element, an das Sie es anhängen, kleiner ist als das Flyout, aber das muss definitiv die jeweilige App entscheiden.
Die Fokushervorhebung der Elemente in der unteren Reihe sollte wahrscheinlich nicht unten abgerundet werden (da das obere nicht für die obere Reihe ist), aber das ist wahrscheinlich nicht beabsichtigt.

Übrigens ist mir gerade aufgefallen, dass dieser "angehängte Look" die Funktionsweise der MacOs-Top-Menüleiste ist, daher scheint dieser Look nicht ungewöhnlich ungewöhnlich zu sein ;)

Ich hatte die Rundung vergessen, also habe ich das Bild aktualisiert, um das zu beheben, und auch mit dem gezoomten Beispiel etwas mehr Details hinzugefügt - oh und den Hover-Zustand enthalten

Ich bin mir nicht sicher, ob ich es vorziehe, mittlere Gegenstände mit einem abgerundeten Highlight zu haben oder nicht, da es einerseits konsistenter ist, andererseits diese etwas aggressiv aussehenden (Ok, jetzt erfinde ich nur Sachen :) ) scharfes Weiß Leerzeichen zwischen markierten Elementen und der Umrandung.
Aber das überlasse ich echten Designern zu entscheiden :D

Ich bin mir nicht sicher, ob ich es vorziehe, mittlere Gegenstände mit einem abgerundeten Highlight zu haben oder nicht, da es einerseits konsistenter ist, andererseits diese etwas aggressiv aussehenden (Ok, jetzt erfinde ich nur Sachen :) ) scharfes Weiß Leerzeichen zwischen markierten Elementen und der Umrandung.
Aber das überlasse ich echten Designern zu entscheiden :D

Ich stimme zu, ich bin auch da zweier Meinung. Ich denke, ich mag es geradlinig, aber da die Steuerelemente, die das Flyout aufrufen, abgerundet werden, und dies sind Steuerelemente innerhalb eines Steuerelements, _sollten_ sie abgerundet werden.

Und einige Kontextmenüs enthalten Steuerelemente, die nicht die gesamte Breite des Flyouts umfassen, sodass die abgerundete Auswahl für diese funktioniert

Ich bin mir nicht sicher, ob ich es vorziehe, mittlere Gegenstände mit einem abgerundeten Highlight zu haben oder nicht, da es einerseits konsistenter ist, andererseits diese etwas aggressiv aussehenden (Ok, jetzt erfinde ich nur Sachen :) ) scharfes Weiß Leerzeichen zwischen markierten Elementen und der Umrandung.
Aber das überlasse ich echten Designern zu entscheiden :D

Ich fühle das gleiche. Wenn die Kombinationsliste die gleiche Größe wie das Kombinationsfeld hat, sollten sie am Ausgangspunkt gerade bleiben, ansonsten sollte die Seite, die nicht ausgerichtet ist, rund sein.

@mdtauk @Qowy @shaheedmalik wäre es möglich ein eigenes Issue speziell für Comboboxen zu erstellen? In diesem Thread geht es um Eckenradius im Allgemeinen und nicht um einige spezielle Fälle, die leicht eine ganz neue Konversation hervorbringen könnten, wie hier zu sehen, und somit die Diskussionspunkte über den allgemeinen Ansatz überschatten.

Bitte nicht falsch verstehen, aber wenn wir so spezifische Diskussionen für viele der Steuerelemente haben, wird dieser Thread leicht seinen allgemeinen Fokus verlieren.

Sehr geschätzt!

PS: Über nicht umrandete hervorgehobene Elemente: Die Elementhervorhebung sollte auf jeden Fall ein Rechteck sein. Es ist einfach seltsam, abgerundete Farben zu haben.

Ich bin hier mit meiner Meinung wahrscheinlich in der Minderheit, aber die Eckradien der gemeinsamen Bedienelemente zu ändern ist ehrlich gesagt eine schreckliche Idee. Wenn ich mir das obige Menübeispiel von bin ich etwas angewidert. Mit Fluent-Design wird endlich alles geregelt und alles sieht endlich konsistent und wirklich gut aus. Lassen Sie uns jetzt alles so ändern, dass es wie das Web aussieht? Nein ... lassen Sie das Web das Web sein und lassen Sie Windows (und die Common Controls) in Ruhe. Wenn Entwickler abgerundete Ecken mithilfe von Steuerelementen von Drittanbietern in ihren eigenen Apps implementieren möchten, dann sei es so. Aber jetzt damit anzufangen, das Standard-Look and Feel zu ändern, ist nur Ketzerei - lass Apple Apple sein, Google Google und das Web das Web. Sie bleiben einfach weiterhin Microsoft und machen Ihr Ding – es funktioniert, also lassen Sie es laufen. Ich für meinen Teil liebe das Erscheinungsbild von Microsoft Windows 10 im Fluent-Design und möchte, dass meine Apps wie Windows aussehen – nicht wie Apple, Google oder das Web. Ich kann das Aussehen von Chrome nicht ertragen - Edge sieht Lichtjahre besser aus und Windows in Form und Funktion viel besser als macOS. Und, TBH, bringen Sie Windows 10 Mobile zurück auf das Telefon. Alles Gute, hör auf, Dinge so schnell aufzugeben und lass Fluent Design in Ruhe und lass es sein Ding machen.

@mdtauk

Dies auf Betriebssystemebene zu tun, ist eine komplizierte Aufgabe, und die Forschung rechtfertigt nicht ganz den Engineering-Zeit- und -Aufwand, der mit der Implementierung verbunden ist.

Dieser Vorschlag scheint bereits die meiste Arbeit zu erledigen, indem er eine CornerRadius-Eigenschaft zu Steuerelementen hinzufügt. Dann wäre nur noch die Erstellung der Ressource SystemCornerRadius, an die sich diese Steuerelemente für ihren tatsächlichen Eckenradius binden könnten (ähnlich wie Sie heute eine SystemAccentColor-Ressource verwenden, um Elemente Ihrer Benutzeroberfläche in der Akzentfarbe zu färben, die der Benutzer in der Einstellungs-App festlegt.
Wie viel Arbeit es wäre, eine solche Ressource zu erstellen und über die Einstellungs-App aktualisierbar zu machen, bleibt für MS zu kommentieren. Aber angesichts der Arbeit, die dieser Vorschlag sowieso bereits leistet, und auch der vorherigen Arbeit in Form der Bereitstellung einer AccentColor-Ressource, sehe ich nicht, wie anspruchsvoll dies sein sollte, wie Sie es sich vorstellen. Die Betriebssystemebene würde buchstäblich nur einen Eckradiuswert bereitstellen, der gelesen und geschrieben werden kann und dann dasselbe System verwenden kann, das Sie bereits für die heutige Akzentfarbenressource verwenden.

Wäre es ein Schieberegler oder ein Umschalter?
[X] Abgerundete Ecken an den Bedienelementen
Es würde nicht nur einen einzelnen Eckenradiuswert geben, der übrigens eingestellt werden könnte. Einige Elemente hätten nur die Rundung auf einer Seite oder nur die oberen Ecken wären abgerundet. Die Flyouts und Pop-Over-Steuerelemente erhalten einen Radius von 4 epx, während andere Steuerelemente nur 2 epx haben.
Sie würden viele Variablen festlegen, da sich diese Einstellung im Betriebssystem ändert. Was ist dann mit dem Testen? Außerdem würden Erwartungen geweckt. Wie werden Benutzer auf Apps reagieren, von denen sie entscheiden, die Präferenzen des Benutzers zu ignorieren?
Wie kommunizieren Sie mit den Benutzern, welche Steuerelemente abgerundet werden und welche nicht? Einige Steuerelemente verfügen über innere oder äußere Rahmenelemente. Diese müssten ihre CornerRadius-Werte angepasst werden, um sicherzustellen, dass die Kanten der Formen richtig umschlossen werden.
Am Ende kann dies eine Änderung sein, die ohne viel Aufhebens begrüßt wird, und daher könnte es als Überreaktion angesehen werden, dem Betriebssystem eine weitere Option hinzuzufügen.

Hier einen Eckradius von 2epx, dort einen Eckradius von 4epx und an anderer Stelle einen anderen zu haben, weil 2 oder 4 nicht ganz richtig aussehen, ist eine schreckliche UX. Lassen Sie die Common Controls so, wie sie sind - Job erledigt ... machen Sie etwas anderes großartiges.

@chigy
Also habe ich die Antworten im Reddit-Thread, den ich vor ein paar Tagen gestartet habe, gezählt und hier ist es (leider scheint es keine offensichtliche Möglichkeit zu geben, die Gesamtzahl der Benutzer, die teilgenommen haben, einfach zu sehen):

Meinungen pro-Corner-Radius (gegenläufige UI): 18
Meinungen pro-current UI (und Contra Corner Radius): 12 (+1 wenn ich mich als Reddit-Poster einbeziehe , auch

Der Rest:

• Aufforderung an MS, UI-Optionen bereitzustellen
• Gut mit beidem
• Keine Meinung zu dem Vorschlag abgegeben
• Äußerte eine allgemeine Frustration über die Inkonsistenzen im Windows-System (zB Win32-Programme vs. UWP-Apps)

Vor allem die letzte Gruppe (Frust) war ein guter Teil der Leute, die am Thread teilgenommen haben.

Wenn wir das Ergebnis zusammenfassen, sehen wir, dass wir sowohl für abgerundete Ecken (der Vorschlag) als auch für eckige Ecken (aktuelle Benutzeroberfläche) beträchtliche Fraktionen haben. Hinzu kommt die Gruppe von Personen, die den Wunsch geäußert haben, zwischen diesen beiden Stilen im System wechseln zu können.
Abgesehen von abgerundeten Ecken oder nicht, ist die häufigste Reaktion - bei weitem -, endlich Konsistenz in das Windows-System als Ganzes zu bringen. WinUI 3.0 und die MS-Teams werden ihre Arbeit abschneiden, um alle verschiedenen Windows-Systemkomponenten und UWP-Apps unter einer einzigen UI-Designsprache zu vereinen.

@chigy
Bei all dem Gerede des Microsoft Design Teams, Benutzer "einzubeziehen", anstatt sie "auszuschließen", denke ich, dass dieser Thread und der obige Reddit-Thread gute Gründe gibt, eine einfache Option in der Benutzeroberfläche bereitzustellen, um zwischen den vorgeschlagenen abgerundeten Ecken zu wechseln UI und die aktuelle UI (scharfe Ecken).

@Felix-Dev Technisch gesehen ging es in meinem Beitrag um das Flyout-Steuerelement, die ComboBox ist nur eines der Steuerelemente, die eine Flyout-Komponente haben.

Ich denke zufällig, dass das Runden an allen Ecken unter allen Umständen sinnvoll ist. Und das Team entschied, dass Flyouts und Dialoge 4 epx-Ecken verwenden und andere Steuerelemente 2 epx verwenden.

@mdtauk ,
wie gesagt, bitte nicht falsch verstehen. Ich denke, es ist absolut in Ordnung, in diesem Thread auf eine bestimmte Steuerelement-Benutzeroberfläche hinzuweisen (wie ich zum Beispiel nach der seltsam aussehenden Eckendicke für Kontrollkästchen-Eckradien im Baumansichtsbeispiel gefragt habe).
Wenn es zu einem bestimmten UI-Element (z. Und wie Sie gesehen haben, führte Ihr Beitrag zu Flyouts bald zu einer Diskussion über Comboboxen. Stellen Sie sich jetzt vor, jemand beginnt ein Gespräch darüber, wie Fokusschatten aussehen sollten, und wir haben ein ganzes "Durcheinander" (wie in mehreren spezifischen UI-Elementen, die in unmittelbarer Nähe besprochen werden) beginnend, wo es schwierig sein wird, den Thread wieder auf das Allgemeine zurückzubringen Vorschlag und wie man damit umgeht.

@mdtauk ,
wie gesagt, bitte nicht falsch verstehen. Ich denke, es ist absolut in Ordnung, in diesem Thread auf eine bestimmte Steuerelement-Benutzeroberfläche hinzuweisen (wie ich zum Beispiel nach der seltsam aussehenden Eckendicke für Kontrollkästchen-Eckradien im Baumansichtsbeispiel gefragt habe).
Wenn es zu einem bestimmten UI-Element (z. Stellen Sie sich vor, jemand beginnt dann ein Gespräch darüber, wie Fokusschatten aussehen sollten, und wir haben ein ganzes Durcheinander, wo es schwierig wird, den Thread wieder auf den allgemeinen Vorschlag und den Umgang damit zurückzubringen.

Ich beabsichtige nicht, ein separates Thema nur für Flyouts zu erstellen, aber ich habe speziell die Eckenradien dieses Steuerelements besprochen.

Ich frage mich, ob @chigy uns eine Schätzung geben könnte, wann wir ein aktualisiertes Design-Toolkit mit allen aktualisierten Steuerelementdesigns sehen können, damit das Gespräch auf mehr Details als auf allgemeine Beschwerden über die Entscheidung, sie zu ändern, übergehen kann mit.

Wenn Sie die Beiträge zählen möchten, sollten Sie auch die Upvotes zählen.

@shaheedmalik
Die Aufwärtszählungen werden nicht explizit gezählt, da ich nicht genau weiß, wie diese Aufwärtswähler über diese UI-Typen denken (z. Noch wichtiger ist, dass sie einen Beitrag möglicherweise aufgrund eines bestimmten Teils in diesem Beitrag positiv bewertet haben, z. B. durch den Hinweis auf Inkonsistenzen der Benutzeroberfläche. Daher habe ich nur die tatsächlichen Beiträge gezählt, bei denen Sie in der Erklärung des Autors eindeutig eine Genehmigung für eine der Benutzeroberflächen sehen können.

FWIW, "2px scheint der Sweet Spot zu sein." mit 54 Punkten die meisten Up-Stimmen.

Es gibt auch einen hoch bewerteten Beitrag (+21 - 4. Platz), der "Endbenutzer-Themen-Unterstützung" fordert, obwohl ich nicht feststellen kann, ob alle diese positiven Stimmen für den Teil mit der Aufforderung zur Anpassung oder für den Teil, in dem der Autor das Fehlen kritisiert, sind Konsistenz im System.

Ich frage mich, ob @chigy uns eine Schätzung geben könnte, wann wir ein aktualisiertes Design-Toolkit mit allen aktualisierten Steuerelementdesigns sehen können, damit das Gespräch auf mehr Details als auf allgemeine Beschwerden über die Entscheidung, sie zu ändern, übergehen kann mit.

Danke für die Nachfrage. Ich habe die Design-Kompositionen im Abschnitt „Wichtiger Hinweis“ der Ausgabe verlinkt, also schau dir das bitte an.

Im Allgemeinen möchte ich sicherstellen, dass wir uns hier darauf konzentrieren, wie wir abgerundete Ecken in WinUI zum Laufen bringen können. Ich weiß, dass die Leute unterschiedliche Meinungen zu dieser Idee haben oder sogar, ob abgerundete Ecken im Allgemeinen eine gute Idee sind. Ich hatte also das Gefühl, dass es sich lohnt zu erwähnen, dass dies Teil der allgemeinen Windows-Designrichtung ist, die von einem anderen Team bei Microsoft vorangetrieben wird. Wir versuchen nur herauszufinden, wie WinUI mit dieser neuen Designrichtung funktioniert, um es für Entwickler einfacher zu machen. Wir haben nicht wirklich die Autorität, zu dem Schluss zu kommen, dass abgerundete Ecken in Windows kein „Ding“ sind. Mit anderen Worten, abgerundete Ecken sind bereits ein Plan, und deshalb wollten wir Sie darauf aufmerksam machen und unsere WinUI-Community konsultieren, um sicherzustellen, dass wir diese Funktion verantwortungsvoll implementieren. Hoffe das macht Sinn.

Wir haben nicht wirklich die Autorität, zu dem Schluss zu kommen, dass abgerundete Ecken in Windows kein „Ding“ sind. Mit anderen Worten, abgerundete Ecken sind bereits ein Plan, und deshalb wollten wir Sie darauf aufmerksam machen und unsere WinUI-Community konsultieren, um sicherzustellen, dass wir diese Funktion verantwortungsvoll implementieren.

Ich vermute, dass viele Leute hier gerne mit den Leuten mit dieser Autorität sprechen würden, weil dies für viele von uns das Hauptproblem ist.

Danke für die Nachfrage. Ich habe die Design-Kompositionen im Abschnitt „Wichtiger Hinweis“ der Ausgabe verlinkt, also schau dir das bitte an.

Im Allgemeinen möchte ich sicherstellen, dass wir uns hier darauf konzentrieren, wie wir abgerundete Ecken in WinUI zum Laufen bringen können. Ich weiß, dass die Leute unterschiedliche Meinungen zu dieser Idee haben oder sogar, ob abgerundete Ecken im Allgemeinen eine gute Idee sind. Ich hatte also das Gefühl, dass es sich lohnt zu erwähnen, dass dies Teil der allgemeinen Windows-Designrichtung ist, die von einem anderen Team bei Microsoft vorangetrieben wird. Wir versuchen nur herauszufinden, wie WinUI mit dieser neuen Designrichtung funktioniert, um es für Entwickler einfacher zu machen. Wir haben nicht wirklich die Autorität, zu dem Schluss zu kommen, dass abgerundete Ecken in Windows kein „Ding“ sind. Mit anderen Worten, abgerundete Ecken sind bereits ein Plan, und deshalb wollten wir Sie darauf aufmerksam machen und unsere WinUI-Community konsultieren, um sicherzustellen, dass wir diese Funktion verantwortungsvoll implementieren. Hoffe das macht Sinn.

Sie haben erwähnt, dass Gespräche über einige Dinge noch im Gange sind, z. (Ich glaube, ich hatte gehofft, Dinge wie die TextBox, Buttons, CheckBoxes usw. noch beeinflussen zu können)

Ich glaube, ich kenne die Antwort darauf, aber ich werde trotzdem fragen: Gibt es Pläne, diese Windows-UI-Designs zu teilen, für die sich das Team entschieden hat?

Werden diese Änderungen von Windows geplant, gelten sie auch für die Win32 Visual Styles und die Shell-Fenster TitleBars usw. Wenn ja, sollte WPF wahrscheinlich auch ihre Standardsteuerelemente aktualisieren, wenn sie auf den Windows-Versionen ausgeführt werden, für die dieser neue Stil gilt. (Ich habe bereits vorgeschlagen, dass dies passieren sollte #699)

Wir haben nicht wirklich die Autorität, zu dem Schluss zu kommen, dass abgerundete Ecken in Windows kein „Ding“ sind. Mit anderen Worten, abgerundete Ecken sind bereits ein Plan, und deshalb wollten wir Sie darauf aufmerksam machen und unsere WinUI-Community konsultieren, um sicherzustellen, dass wir diese Funktion verantwortungsvoll implementieren.

Ich vermute, dass viele Leute hier gerne mit den Leuten mit dieser Autorität sprechen würden, weil dies für viele von uns das Hauptproblem ist.

Ich denke, dies wird im Feedback-Hub erscheinen, wenn die Designänderungen live gehen - das wird höchstwahrscheinlich das Windows-Team erreichen.

Sie haben erwähnt, dass Gespräche über einige Dinge noch im Gange sind, z. (Ich glaube, ich hatte gehofft, Dinge wie die TextBox, Buttons, CheckBoxes usw. noch beeinflussen zu können)

Ich glaube, ich kenne die Antwort darauf, aber ich werde trotzdem fragen: Gibt es Pläne, diese Windows-UI-Designs zu teilen, für die sich das Team entschieden hat?

@mdtauk
Ja, und um hier sehr transparent zu sein... Die Realität ist, je früher die Diskussion über dieses spezielle Thema verlangsamt wird, desto eher kann ich daran arbeiten... :)

@chigy Ich entschuldige mich, wenn ich dazu beigetragen habe, das Gespräch zu entgleisen und den Fortschritt zu verlangsamen. Ich wollte immer nur helfen und sicherstellen, dass WinUI 3.0 so gut wie möglich aussieht!

@chigy
Jetzt bin ich verwirrt. Sie sind eine Person, die im Windows Fluent Design Team arbeitet, WinUI soll "[...] hochoptimierte native UI-Plattform sein, die verwendet wird, um Windows selbst zu erstellen" (zitiert hier , Abschnitt "Vorteile von WinUI 3". Wenn dies nicht der Ort ist, um die Windows 10 Design Language zu beeinflussen, was ist es dann?

Ich weiß nicht, was ich von deiner Antwort halten soll. Sie bitten uns grundsätzlich um Feedback, aber es stellte sich heraus, dass wir sowieso nie viel Einfluss auf den Vorschlag hatten? Wenn in diesem Beitrag niemand mit wirklicher Autorität vorkommt, dann ist alles, was wir hier tun, im Grunde heiße Luft. Sogar in Fällen wie denen von Martin, in denen er seine Designkonzepte veröffentlicht, in der Hoffnung, dass sie vom Designteam umgesetzt werden. WinUI kann die Steuerelemente nicht anders gestalten, als es die "Windows Design Authority" will, denn wie das WinUI-Team selbst sagte: "WinUI 3.0+ wird DIE Windows-Benutzeroberfläche sein".

@chigy
Ich und andere haben viel Zeit, Energie und Leidenschaft investiert, um hervorzuheben, dass "Windows-Benutzer" keine homogene Gruppe sind, wie einige Ihrer Kommentare andeuten schienen. Wir haben Ihnen gezeigt, dass es Stimmen außerhalb von Martins und anderen gibt, die das neue UI-Update nicht mögen und daher für eine sorgfältig abgewogene UI-Anpassung plädieren wollten.

Es fühlt sich auch so an, als würden Sie genau diese Forderung ignorieren. Sie sagen: "Wir haben nicht wirklich die Autorität zu dem Schluss, dass abgerundete Ecken in Windows kein "Ding" sind.". Ich und andere riefen in den letzten Tagen nicht dazu auf, diesen UI-Push zu verwerfen, sondern Ihrem eigenen Design-Talk auf Twitter zu folgen, in dem es darum geht, "Benutzer einzubeziehen" und sie nicht auszuschließen. Wir haben nach einer Option gefragt, nicht nach einer Rückabwicklung.
Bisher haben wir jedoch keine große Anerkennung erhalten, außer "Die Option, Benutzereinstellungen bereitzustellen, um Eckenrundungen zu ermöglichen, aus denen der Benutzer auswählen kann, ist interessant. Es hat jedoch auch viel mit diesem Feedback gegenüber anderen zu tun." wichtige Funktionen, die wir im Windows-System als Ganzes abwägen müssen.". Ich denke, das ist ein Anfang, aber wo stehen wir jetzt?

Sie sagen, Sie gehören nicht zum eigentlichen Team mit Autorität über das Windows-Design. Das bedeutet, dass wir alle die ganze Zeit mit der falschen Person gesprochen haben! Wenn wir nie mit einem Mitglied des Teams gesprochen hätten, das tatsächlich das Sagen hat, frage ich mich, warum Sie das nicht früher hätten sagen können.

Ich bin enttäuscht, nach all der investierten Energie, jetzt zu erfahren, dass ich nie mit jemandem mit Autorität gesprochen habe. Dass im Grunde all das Feedback und ich andere gesammelt haben und die UI-Anpassung plädieren, führt im Grunde zu nichts (weil Sie nicht einmal eine Person sind, die überzeugen muss).

Es tut mir leid, ich kann mich einfach nicht darum kümmern. Ein Mitglied des Windows Fluent Design Teams im Repository, das angeblich die Windoiws-Benutzeroberfläche steuert, sagt uns jetzt nach Tagen, dass wir nie mit einer Person gesprochen haben, die wirklich wichtig war.

Tut mir leid, wenn das als Schimpfwort rüberkommt, aber ich bin hier etwas schockiert. Sie wissen vielleicht nicht, wie viel ich in diese spezielle Diskussion investiert habe (und andere, die leidenschaftliche Antworten geschrieben haben), aber ich möchte um Klarstellungen bitten.

Wo steht eigentlich unser Ruf nach UI-Anpassung? Ist dieses Repository für Diskussionen über die Windows-Benutzeroberfläche wirklich noch von Bedeutung?

Ich belasse es bei:

" [WinUI 3.0] Die native UI-Plattform von WindowsWinUI ist die stark optimierte native UI-Plattform, die zum Erstellen von Windows selbst verwendet wird und jetzt allen Entwicklern breiter zur Verfügung gestellt wird, um Windows zu erreichen.

@Felix-Dev Ich hoffte, zu beeinflussen, nicht darauf zu bestehen, dass meine Designs die tatsächlichen Designs werden. Ich bin ein Designer, der seit den Tagen von Windows Vista/7/Zune/Windows Phone ein Windows-Enthusiast ist.

@mdtauk
Obwohl Sie sicherlich nichts dagegen hätten, dass MS Ihre Ideen aufgreift, oder? 😉 Schließlich bist du davon überzeugt!

Tut mir leid, wenn es so gekommen ist, dass du aufdringlich bist (und um fair zu mir zu sein, hast du auch gesagt, dass deine Vorschläge so rüberkommen könnten), aber die Antwort von Schock für mich. Hoffe du kannst es verstehen!

WinUI-Team != Windows-Entwicklerteam.

Windows 10 ist das aktuelle Betriebssystem, aber Windows Lite und Windows Core OS sind die zukünftigen Richtungen.

@chigy schaut sich offensichtlich an, was das Windows-Team mit der OS-Shell plant, und möchte sicherstellen, dass WinUI 3.0 dort zu Hause ist. Windows-Apps wie Rechner, Einstellungen, Taskleisten-Flyouts und Shell usw. werden wahrscheinlich alle WinUI 3.0 verwenden, sodass sie sich in Bezug auf das Design auf derselben Seite befinden müssen.

Das Fluent Design-Team bei Microsoft erstellt die Regeln (Farben, Schriftstile und -größen, Materialien usw.), die andere Microsoft-Teams wie WinUI, Windows, Xbox, Office, Bing, Teams, Fabric, Fluent Web beim UI-Design befolgen.

Ich bin sicher, dass ich korrigiert werde, wenn ich die Struktur hier falsch verstanden habe.

Meine Ideen, die ich zu diesem Repo beigetragen habe - habe versucht, die Lücke zwischen Fabric Web und WinUI 3.0 zu schließen - ich habe auch Gedanken aufgenommen, über die ich seit den Win8-Tagen nachgedacht habe.

Klarstellung wäre in der Tat schön, denn so habe ich es verstanden:

@chigy ist Mitglied des Windows Fluent Design Teams und wird mit FD (Fluent Design) als Designsprache von Windows 10 Mitglied des Windows Design Teams.

Dann gibt es WinUI 3.0, das offiziell als die Plattform beschrieben wurde, die Windows antreibt und verwendet wird, um Windows selbst zu erstellen. Diskussionen über das Windows-UI-Design fühlen sich hier also zu Hause.
Auch basierend auf der obigen Beschreibung würde dies bedeuten, dass die Windows-Entwicklerteams WinUI verwenden werden, um sowohl Apps als auch die System-UI zu realisieren. Ansonsten muss in diesen UI-Proposal-Threads ausdrücklich darauf hingewiesen werden, dass Sie nicht mit einer Person sprechen, die wirklich wichtig ist, und es sich bei dem Vorschlag wirklich nur um Feedback zu den tatsächlichen Implementierungen und nicht um das UI-Design handelt .

Und auch wenn das Windows Fluent Design Team und das WinUI Team nicht die Teams sind, in denen native Windows UI entworfen und realisiert wird, ändert das nichts an der Tatsache, dass @chigy uns nie darüber informiert hat, dass wir nie mit jemandem gesprochen haben, der wirklich wichtig ist. Wir haben Zeit und Energie investiert (Sie mit Ihren Steuerungskonzepten, ich mit dem Versuch, Feedback zu sammeln, wir beide haben lebhafte Diskussionen und nicht zu vergessen alle anderen, die leidenschaftlich teilgenommen haben), als wir am Ende nie mit einem echten Windows UI-Teammitglied gesprochen haben, jemand, den wir tatsächlich versuchen könnten, von unseren Ideen und Überzeugungen zu überzeugen.

Wir haben nicht wirklich die Autorität, zu dem Schluss zu kommen, dass abgerundete Ecken in Windows kein „Ding“ sind. Mit anderen Worten, abgerundete Ecken sind bereits ein Plan, und deshalb wollten wir Sie darauf aufmerksam machen und unsere WinUI-Community konsultieren, um sicherzustellen, dass wir diese Funktion verantwortungsvoll implementieren. Hoffe das macht Sinn.

Nun, das ist eine große Enttäuschung für mich, wie andere sagten, es ist für viele von uns ein großes Problem. Wenn Sie also keinen Einfluss darauf haben, darf ich

Dies ist dem Diskurs sehr ähnlich, der während der Entwicklung von Windows 10 vor Jahren stattfand, als es einen Vorschlag gab, quadratische Profilbilder in runde Bilder umzuwandeln. Viele Leute mochten dies wieder nicht und gingen zum Feedback-Hub. Es gab mehrere Posts im Feedback-Hub mit mehr als 1000000+ positiven Stimmen, in denen darum gebeten wurde, dies nicht zu tun.

Die Antwort war im Wesentlichen nur noch einmal, den Leuten zu sagen, dass die Änderung unabhängig von ihrer Meinung erfolgen wird ...

Ich würde diesen Beitrag so umformulieren, dass er weniger herablassend und beleidigend ist @Felix-Dev

@mdtauk
wo ist mein post beleidigend?

Ich nenne niemanden irgendwelche Namen, nenne WinUI schlechte Worte und beschreibe dieses Problem in beleidigenden Worten. Ich greife niemanden persönlich an, tatsächlich greife ich nichts an.

@mdtauk
wo ist mein post beleidigend?

Ich nenne niemanden irgendwelche Namen, nenne WinUI schlechte Worte und beschreibe dieses Problem in beleidigenden Worten. Ich greife niemanden persönlich an, tatsächlich greife ich nichts an.

@chigy ist die Person, die für die Arbeit am Design der WinUI-Steuerelemente verantwortlich ist. Wenn Sie seine Rolle mit einer in den Windows- oder Fluent-Teams verwechseln, sollten Sie nicht sagen, dass seine Rolle keine Rolle spielt, und Sie sollten sie nicht persönlich machen.

@mdtauk
„Chigusa Sansen ist Principal Program Manager im XAML-UI-Plattform-Team und Teil der Kernmitglieder von Fluent Design System “ (Quelle: https://mybuild.techcommunity.microsoft.com/speaker/545575?source=sessions)

Sie hielt auch den FD-Teil in Bezug auf Windows in dieser Sitzung.

Und über den Teil "eine Person, auf die es wirklich ankommt". Ich halte es nicht für beleidigend, denn in unserem Fall sagte sie tatsächlich, dass sie nicht zu dem Team gehört, das tatsächlich den Ton für die für Windows gewählte UI-Richtung angibt. Ich habe Miss Chigusa Sansen weder angegriffen, noch habe ich sie verspottet oder sie beschimpft. Ich habe einfach gesagt, was sie uns persönlich erzählt hat.

Und über den Teil "eine Person, auf die es wirklich ankommt". Ich halte es nicht für beleidigend, weil sie in unserem Fall tatsächlich sagt, dass sie nicht in dem Team ist, das tatsächlich das Sagen für die gewählte UI-Richtung hat
Fenster.

Nun, ich finde es beleidigend. Zumal Sie den Zweck der Diskussion anscheinend missverstanden haben, im Gegensatz dazu, dass Sie "in die Irre geführt" werden.

@mdtauk
Wir sind hier auf einer anderen Wellenlänge und es macht keinen Sinn, zu spekulieren, warum das so sein könnte ...

Als wir diese Diskussion über die allgemeine UI-Umstellung begannen, wurde von Miss Chigusa Sansen oder anderen Mitgliedern des WinUI-Teams klar gesagt, dass dieser Thread nicht der richtige Ort für diese Diskussion ist. Stattdessen fingen die Leute leidenschaftlich an zu diskutieren und argumentierten für/gegen diesen Schritt, weil sie dachten, sie würden mit jemandem sprechen, der in einer - für die Art dieser Diskussion - relevanten UI-Position bei Microsoft/Windows sein würde.

Chigusa hat sogar daran teilgenommen und Sie haben auch frei Steuerbilder hinzugefügt, in der Hoffnung, die Richtung der Benutzeroberfläche zu beeinflussen, und ohne dass jemand von MS weiter vorgeht, um das Gefühl zu verstärken, dass dies der Ort ist, um das allgemeine UI-Design zu diskutieren. Meine Beschwerde ist , und Sie scheinen das übersehen zu haben, dass @chigy so lange

Es geht nicht um "irregeführt" oder "missverstanden", wie Sie es nennen, sondern dass uns eine so wesentliche Info tagelang vorenthalten wurde. Diese ganze Diskussion hätte schon lange weitergehen können, wenn Miss Chigusa Sansen das früher gesagt hätte. Was übrigens das ist, was Sie und sie sehen wollen.

@mdtauk
Wir sind hier auf einer anderen Wellenlänge und es macht keinen Sinn, zu spekulieren, warum das so sein könnte ...

Als wir diese Diskussion über die allgemeine UI-Umstellung begannen, wurde von Miss Chigusa Sansen oder anderen Mitgliedern des WinUI-Teams klar gesagt, dass dieser Thread nicht der richtige Ort für diese Diskussion ist. Stattdessen begannen die Leute leidenschaftlich zu diskutieren und argumentierten, dass sie pro-/kontra- diesen Schritt machten, weil sie dachten, sie würden mit jemandem sprechen, der eine wichtige UI-Position bei Microsoft/Windows einnehmen würde. Chigusa hat sogar daran teilgenommen und Sie haben auch frei Steuerbilder hinzugefügt, in der Hoffnung, die Richtung der Benutzeroberfläche zu beeinflussen. Meine Beschwerde ist , und Sie scheinen das übersehen zu haben, dass @chigy so lange

Es geht nicht um "irregeführt" oder "missverstanden", wie Sie es nennen, sondern dass uns eine so wichtige Info tagelang vorenthalten wurde. Diese ganze Diskussion hätte schon lange weitergehen können, wenn Miss Chigusa Sansen das früher gesagt hätte, was Sie und sie sehen wollen.

@Felix-Dev @Nepxune
Bleiben wir höflich und positiv. 😃 Diese Bilder, die gepostet wurden, heben die Änderungen hervor, die an den Steuerelementen vorgenommen werden, die CornerRadius-Werte betreffen. Es gibt ein weiteres Problem, bei dem die spezifischen Mechanismen zum Hinzufügen von CornerRadius zu den Steuerelementen, die den Wert derzeit nicht unterstützen oder respektieren, so gestaltet werden können, dass sie sie unterstützen, und auf eine Weise, bei der Entwickler den Wert überschreiben können, um sie entweder zu quadrieren oder anzupassen die Werte, die zu ihrer Marke und ihren Bedürfnissen passen. #684

Dieses Problem bezieht sich auf das Aktualisieren des Eckenradius für allgemeine Steuerelemente, in Übereinstimmung mit der Web- und App-Stilrichtung.

Die Ideen, die ich gepostet habe, waren die von Fabric Web verwendeten Stile und brachten sie in die XAML-Steuerelemente – und ich glaube, dass sie in dieser Diskussion enthalten sind. Betriebssystemfeatures, die das XAML-Steuerelement ThemeResource steuern, sind etwas vom Thema abgekommen, aber verwandt.

Die Gespräche waren interessant und sachdienlich, bis zu dem Punkt, an dem einige versuchten, sie in eine Diskussion über die Vorzüge oder das Fehlen der Änderung zu lenken – anstatt die Änderungen, die bereits beschlossen wurden, erfolgreich durchzuführen machen.

Ich würde vorschlagen, dass, wenn Sie einen Vorschlag verstärken möchten, um den Rundungsbetrag zu einer Betriebssystemeinstellung zu machen, die der Benutzer umschalten oder ändern kann, dies als neuer Vorschlag gemacht werden sollte.

Bitte beachten Sie den Verhaltenskodex und versuchen Sie, respektvoll zu sein. @chigy hat nicht versucht, zu täuschen oder in die Irre zu führen.

Martin hat Recht, dass wir das Plattformteam sind, das dafür verantwortlich ist, die Designs so zu produzieren, dass sie die Anforderungen zukünftiger Windows-Versionen erfüllen. Wir möchten auch sicherstellen, dass unsere Plattform für alle anderen gut funktioniert, auch für diejenigen, die ihre eigene Marke und ihren eigenen Stil mitbringen und nicht dem Windows-Stil folgen möchten. All dieses Feedback ist immens wertvoll und wir werden es auch mit dem Windows-Designteam teilen, um sicherzustellen, dass sie das spezifische Feedback hören, dass die Leute auf Betriebssystemebene einen Drehregler wünschen, um dies anzupassen.

Vielen Dank, @Felix-Dev , @Nepxune und @mdtauk , für den Hinweis auf etwas, das mir wahrscheinlich nicht ganz klar war, als ich dieses GitHub-Element übernahm. Nur damit Sie es wissen, dies ist unser allererstes designbezogenes Thema, das wir in der offenen Community diskutieren, also lernen wir ständig dazu…

Und zuallererst entschuldige ich mich, wenn ich jemanden in dieser Gruppe irreführen sollte, dass ich ein Designvertreter bin, der die Autorität hat, Änderungen vorzunehmen, die nicht meine Absicht waren, und es tut mir leid, wenn Sie das Gefühl haben, Ihre Zeit verschwendet zu haben.

Vielen Dank, @jevansaks , für die Zusammenfassung der Rolle von WinUI in Bezug auf das Design.

Lassen Sie mich jedoch etwas zu meiner Person sagen, da ich es dieser Gemeinschaft verdanke. Ich bin ein Programmmanager vom WinUI-Engineering-Team. Ich arbeite sehr eng mit Designteams im gesamten Unternehmen zusammen, um sicherzustellen, dass WinUI die Designwahrheit der Windows-Designrichtung sowie die von Fluent repräsentiert. Zum Beispiel saß ich erst gestern mit dem Xbox-Designteam zusammen, um einige der hier vorgeschlagenen Designänderungen zu besprechen. Stellen Sie sicher, dass sie für Xbox-Entwickler immer noch genauso nützlich sind. Innerhalb des WinUI-Teams beaufsichtige ich das Design auf systematischere Weise sowohl horizontal als auch insgesamt, um sicherzustellen, dass wir kein einzelnes Feature veröffentlichen, das Inkohärenz aus der UI/UX-Perspektive einführt.

Ich nehme an den Bemühungen des Fluent-Designsystems teil, die Windows repräsentieren, und versuche, eine sehr starke Stimme für die Entwickler-Community zu sein. Um das klarzustellen, Fluent Design System ist eine gemeinsame Anstrengung, bei der viele Teams von Microsoft (sowohl Design- als auch Engineering-Teams) zusammenarbeiten, um ein kohärentes System zu realisieren, mit dem wir als Unternehmen großartige UX liefern und Entwicklern wie Ihnen zur Verfügung stellen können. Mein Teil davon zu sein bedeutet also nicht, dass ich telefonieren kann… Meiner Meinung nach kann keine einzelne Person in diesem Kollektiv… Es ist eine kollektive Anstrengung…

@Felix-Dev , nur um Sie darauf aufmerksam zu machen, dass ich persönlich das von Ihnen vorgeschlagene Konzept zur Benutzereinstellung mit jemandem in der Windows-Designorganisation besprochen habe, um meine Antwort zu bestätigen (z ). Ihre Meinung wurde diskutiert. Ich weiß, dass es wahrscheinlich nicht zufriedenstellend ist, aber ich wollte Sie wissen lassen, dass mir alle Ihre Meinungen wichtig sind und ich mein Bestes tue, um hier der Vertreter/die Brücke zu sein.

Alle, ich wollte das Thema nicht schließen. Ich habe versucht, den Kommentar zu schließen, und habe dies versehentlich getan !!

@mdtauk @jevansaks @chigy
Ich stimme Ihnen absolut zu, dass diese Diskussion professionell bleiben sollte. Uns alle verbindet unsere Leidenschaft für Windows und unser Wunsch, Windows so gut wie möglich zu machen.

Um es ein für allemal klarzustellen, ich habe Miss Chigusa Sansen nie der "Täuschung" oder "Täuschung" beschuldigt, und das war auch nicht meine Absicht. Ich kann auch unmissverständlich sagen, dass ich nie jemanden persönlich angegriffen habe und würde es auch nicht tun.

Was dieses jüngste Gespräch aber auch zeigt, ist, dass sich dieses Open-Source-Projekt noch in der Lernphase befindet. Es gibt noch viel zu tun, um beide Welten erfolgreich zusammenzubringen - das Unternehmen Microsoft und seine leidenschaftlichen Benutzer und ein klares Verständnis dafür, wie viel Einfluss dieser neue Open-Source-Ansatz der Community tatsächlich geben wird und wie die zugehörigen Windows-Teams tatsächlich mit Community-Feedback umgehen werden .

Generell bin ich vom aktuellen Stand schon ziemlich beeindruckt. Feedback wird ausgegeben und vom WinUI-Team ernst genommen, auch wenn es sich nicht um Feedback zum eigentlichen WinUI-Produkt handelt. Das weiß ich zu schätzen und dafür hast du meinen Respekt!

Dieser Sonderfall hier litt leider wohl unter einigen Symptomen eines noch sehr jungen Open-Source-Projekts, bei dem alle Beteiligten sich noch nicht vollständig kennengelernt haben. Ich bin optimistisch, dass wir diesen Fall nutzen können, um die Möglichkeiten UND Grenzen dieses neuen Ansatzes für uns alle besser zu verstehen!

Hallo alle!
VIELEN DANK für das offene Gespräch. Ich habe viel gelernt und hoffe, dass Sie bereit sind, weiterhin mit uns zusammenzuarbeiten, um als offene Gemeinschaft zusammenzuwachsen!

Wie einige von Ihnen betonten, war mir nicht klar, was das WinUI-Team und ich tun kann und was nicht, also lassen Sie mich versuchen, die großartigen Punkte, die Sie alle angesprochen haben, und die Schlussfolgerung daraus zusammenzufassen. Und wenn Sie das Gefühl haben, dass noch Fragen offen sind, springen Sie bitte weiter!

Beachten Sie, dass ich nicht alle von uns besprochenen Probleme aufgelistet habe, da ich einige davon während unserer Diskussion als gelöst betrachtet habe. Lass es mich wissen, wenn du anders denkst!!

• Stellen Sie sicher, dass Xbox berücksichtigt wird (@mdtauk)
  o Das Xbox-Design ist Eigentum des Xbox-Teams.
  o Aber ja, wir arbeiten eng mit ihnen zusammen. Hiermit bestätige ich, dass ein Treffen stattgefunden hat, bei dem wir diese und kommende Designvorschläge mit dem Xbox-Designteam besprochen haben.
• Ziehen Sie in Erwägung, andere steuerungsbezogene Änderungen für die Ausrichtung vorzunehmen, z. B. das Verdünnen von Grenzlinien (@mdtauk)
  o Das Windows-Designteam macht den letzten Aufruf für Windows, während es sich mit dem Fluent Design System-Kollektiv abstimmt, um zu versuchen, sich zwischen den Microsoft-Designteams abzustimmen.
  o Das WinUI-Team wird dafür sorgen, dass es für Entwickler besser funktioniert und eine gute Entwicklergeschichte zum Wechseln (oder Zurückwechseln) hat.
  o Dies wird in kommenden GitHub-Ausgaben nachverfolgt.
• Die Community möchte einen Ort, an dem sie ihre Meinung direkt an das Fluent Design Team ( @mdtauk , @Felix-Dev, @Nepxune) äußern kann.
  o Zu Ihrer Information, das Fluent-Team hat eine LinkedIn-Gruppe.
  o Dies ist nicht Eigentum des WinUI-Teams oder mir.
  o Sie werden darauf aufmerksam gemacht, aber wir können uns nicht festlegen, wenn etwas passiert.
  o Ich werde dieser Gruppe sicher mitteilen, wenn sich etwas ergibt.
• Veröffentlichen wir Fluent-Themen für WPF/WinForms? (@Felix-Dev, @mdtauk)
  o Das haben wir noch nicht herausgefunden.
  o Das ist etwas kompliziert. Ich bin eine Person, die sich mit Designanleitungen und Designunterstützung für Entwickler insgesamt für Windows befasst, daher passt dies zu meinem Problembereich. Dies hat jedoch, ehrlich gesagt, derzeit keine Priorität, da dies keine WinUI-Arbeit ist.
• Benutzereinstellung, bei der der Benutzer abgerundete Ecken ein- / ausschalten und / oder bis zu einem gewissen Punkt granulare Wertänderungen vornehmen kann (@Felix-Dev) / Abgerundete Ecken nicht mögen, nicht abgerundet lassen und dem Benutzer eine Option geben (
  o Leider sind dies keine WinUI-Entscheidungen.
  o Das Beste, was ich jetzt empfehlen kann, ist, Feedback-Hub-Probleme zu öffnen, sobald diese Änderung auf das Windows-Betriebssystem übertragen wurde und Sie immer noch nicht das Gefühl haben, dass das Design Ihren Anforderungen entspricht?
  o Wenn es ein Trost ist, ich habe mein Bestes getan, um das Windows-Team zu benachrichtigen, aber es gibt keinen Plan von seinem Team.

Dies fasst unseren aktuellen Plan zusammen:

• Die Steuerelemente, die Sie mit WinUI 2.x erhalten, aktualisieren die Standardvisuals so, dass sie abgerundete Ecken verwenden.
  o Mit anderen Worten, wenn Sie WinUI 2.x nicht verwenden, erhalten Sie diese Änderung nicht.
• Der Wert der abgerundeten Ecken beträgt 2px für die meisten Steuerelemente 4px für die Flyout-Benutzeroberfläche. Keine Rundung, wenn sich die Benutzeroberfläche mit anderen Benutzeroberflächenelementen schneidet
  o Visuelle Zusammenstellung hier: https://github.com/mrlacey/microsoft-ui-xaml-specs/blob/RoundedCornerVisualizations/active/RoundedCorner/ImageFiles/index.md
  o Kurze Nachricht an @mdtauk , @Qowy , @shaheedmalik, die sich darüber
• Entwickler haben eine Möglichkeit, dies einfach zurückzuschalten (#684).
• Es gibt keine Benutzereinstellung, mit der Benutzer dies hin- und herschalten oder granulare Änderungen vornehmen können.

@chigy Vielen Dank für die Zusammenfassung, die Sie gepostet haben.

Ich habe ein paar Fragen, was als nächstes passiert...

• Spiegeln diese Designkompositionen die endgültigen Designs für alle Bedienelemente wider oder werden weitere Änderungen diskutiert, die später aktualisiert oder veröffentlicht werden?

• Wie schlagen Sie vor, dass wir als Community versuchen, einige dieser Designentscheidungen für WinUI zu beeinflussen oder Vorschläge zu machen?

• Wann werden wir die Vision des Windows-Designteams für die Windows-Benutzeroberfläche sehen können, damit wir einen Kontext für die Steuerelemententwürfe haben, an denen gearbeitet wird?

• Wird es Bemühungen geben, die Konsistenz zwischen den Posteingangs-Apps und den Shell-Elementen mithilfe von XAML zu überzeugen/zu erzwingen/durchzusetzen, damit im Design alles übereinstimmt?

• Werden die Xbox-modifizierten Steuerelementdesigns in WinUI enthalten sein oder werden sie nur auf den nächsten Xbox-Geräten verfügbar sein (ohne Möglichkeit, diese Steuerelementvorlagen während der Entwicklung unter Windows zu testen?

@mdtauk , oops, ich habe zu viel geschrieben, aber ich wollte sicherstellen, dass ich mich gut erklärt habe ...

• Spiegeln diese Designkompositionen die endgültigen Designs für alle Bedienelemente wider oder werden weitere Änderungen diskutiert, die später aktualisiert oder veröffentlicht werden?

Was Sie in den Comps sehen, ist so endgültig, wie wir es im Moment bekommen können. Allerdings kann es bei der Implementierung der Änderung in den eigentlichen Steuerelementen zu geringfügigen Änderungen kommen, die dazu führen, dass sich das Design etwas verschiebt. Wie Sie sehen, deckt comp nicht alle UI-Vorkommen ab. Das erwarte ich von diesem besonderen Aufwand aber nicht...

• Wie schlagen Sie vor, dass wir als Community versuchen, einige dieser Designentscheidungen für WinUI zu beeinflussen oder Vorschläge zu machen?

Was ich von der Community gerne mitteilen würde, ist, wo diese Designentscheidungen für Anwendungen versagen. Gibt es Möglichkeiten zur Anpassung, die wir Ihnen nicht geben? Unterbricht es Ihre App aus irgendeinem Grund vollständig?

Wie bereits erwähnt, werden die Designentscheidungen vom Designteam getroffen, aber WinUI ist immer noch dafür verantwortlich, Entwicklern eine Lösung bereitzustellen und sicherzustellen, dass diese eine solide ist. Als Ergebnis könnte es eine Möglichkeit geben, das Design-Output zu beeinflussen. Ich verspreche nicht, dass etwas passieren würde, aber echte Beispiele dafür, wie es nicht funktioniert und wie es behoben werden sollte, funktionieren in diesem Fall am besten ...

• Wann werden wir die Vision des Windows-Designteams für die Windows-Benutzeroberfläche sehen können, damit wir einen Kontext für die Steuerelemententwürfe haben, an denen gearbeitet wird?

Meinen Sie mit Vision eine allgemeine Geschichte, die Ihnen die Art der UI-Änderungen zeigt, die insgesamt in Windows eingeführt werden? Was haben Sie konkret im Sinn?

• Wird es Bemühungen geben, die Konsistenz zwischen den Posteingangs-Apps und den Shell-Elementen mithilfe von XAML zu überzeugen/zu erzwingen/durchzusetzen, damit im Design alles übereinstimmt?

Unten ist meine eigene Meinung basierend auf dem, was ich weiß. Nur um es klar auszudrücken... :)
Meiner Meinung nach ist das Problem zweifach.

Das erste Problem ist, dass wir derzeit das Bereitstellungssystem für neue Benutzeroberflächen haben, das von Betriebssystemversionen abhängt. Aus diesem Grund konnten viele Posteingangsanwendungen keine neuen Stile übernehmen, die Shell verwendet usw., da sie noch die alte Betriebssystemversion unterstützen mussten. Wir versuchen, dies zu lösen, indem wir die neue Benutzeroberfläche in WinUI bereitstellen, damit Sie diese Änderungen unabhängig von der Betriebssystemversion übernehmen können.

Das zweite Problem ist, dass es einen kulturellen Wandel erfordert. Ich arbeitete auf verschiedenen UI-Plattformen, einschließlich Windows Phone, wo wir versuchten, viele verschiedene Ansätze zu verwenden, um Konsistenz in die Produkte zu bringen. Es ist so... Selbst wenn Sie eine Geschwindigkeitsbegrenzung haben, halten sich nicht alle daran. Aber wie viele Polizisten müssen wir zur Durchsetzung schicken? Wir müssen eine Kultur schaffen, in der Geschwindigkeitsbegrenzungen eingehalten werden. Hier gibt es keine magische Lösung. Und das ist etwas, von dem ich hoffe, dass Fluent Design System dabei helfen wird. Indem Designentscheidungen eher zu einem System und nicht zu einer persönlichen Meinung gemacht werden.

• Werden die Xbox-modifizierten Steuerelementdesigns in WinUI enthalten sein oder werden sie nur auf den nächsten Xbox-Geräten verfügbar sein (ohne Möglichkeit, diese Steuerelementvorlagen während der Entwicklung unter Windows zu testen?

Wir haben nicht vor, die Steuerelemente speziell für Xbox zu ändern. Wir haben dies in der Vergangenheit nicht getan (wir haben eine Dokumentation veröffentlicht ) und haben weder vom Xbox-Team noch von der Community (dies ist Pre-Open Source) dringende Anfragen erhalten.

@chigy Nochmals vielen Dank, dass Sie so offen sind und geantwortet haben.

Ich ging davon aus, dass die nächste Xbox auch Apps unterstützen würde – und mit Core OS, das XAML für die Shell verwendet –, würde dies auch bedeuten, dass Xbox WinUI 3.0-Steuerelemente genauso benötigt wie Windows. Das Einbinden von Vorlagen für Xbox würde den Prozess vereinfachen und die Xbox-App-Entwickler zugänglicher machen – aber das ist offensichtlich eine Entscheidung für andere Teams. 😄

Was die Vision betrifft, meine ich: "So werden zukünftige Windows Shell- und Inbox-Apps aussehen." und "Wir nutzen die Gelegenheit, unser Windows-Design zu aktualisieren, hier sind einige der Änderungen, die wir vornehmen..."

Cue Bilder und oder Video 😃

Ich denke auch, dass Xbox und Windows zueinander passen sollten. Wir haben Apps auf Xbox, die unter Windows eingestellt wurden, aber noch auf Xbox (CBS, FOX Sports) existieren oder unter Windows 10 (Youtube) nie existiert haben.

Wenn Sie keine Änderungen an der Benutzeroberfläche vornehmen müssen, bleiben diese Apps auf der Plattform.

Nur meine Gedanken.

Ich denke auch, dass Xbox und Windows zueinander passen sollten. Wir haben Apps auf Xbox, die unter Windows eingestellt wurden, aber noch auf Xbox (CBS, FOX Sports) existieren oder unter Windows 10 (Youtube) nie existiert haben.

Wenn Sie keine Änderungen an der Benutzeroberfläche vornehmen müssen, bleiben diese Apps auf der Plattform.

Nur meine Gedanken.

Xbox Apps erfordern unterschiedliche Steuerungsstile und Verhaltensweisen. Diese Apps sollten jedoch unter Windows ausgeführt werden können, indem Sie nur einige Eigenschaften hinzufügen, die es diesen Apps ermöglichen, ausgeführt zu werden, ohne die Windows-Steuerelementstile verwenden zu müssen. Also ein Xbox First- Ansatz.

@shaheedmalik und @mdtauk , ich bin etwas verwirrt darüber, dass die Diskussion über Xbox und Windows zusammenpassen sollte und die App aufeinander laufen sollte.

Die Designs der Xbox-Shell und der Windows-Shell sind unterschiedlich. Das ist mit Absicht, weil es sich um einzigartige Produkte handelt. Aber wir haben WinUI-Steuerelemente so konzipiert, dass Apps, die einen Stil verwenden möchten, mit geringfügigem Aufwand ausgeführt werden können. Als wir vor einigen Jahren mit dem Xbox-Team zusammengearbeitet haben, haben wir darauf geachtet, dass unsere XAML-Steuerelemente (damals noch keine WinUI) korrekt im Fernsehen angezeigt werden, und haben auch die bereits erwähnten Anleitungen dazu veröffentlicht.

Eine ordnungsgemäß erstellte UWP-App wird sowohl unter Windows als auch auf der Xbox ausgeführt. Für Apps wie die @shaheedmalik- Listen sind sie sehr stark gebrandmarkt, so dass wir oft dieselbe Marke auf Xbox und Windows gesehen haben. Daher läuft ein App-Design oft auf diesen Geräten.

Auch dies ist ein Thema mit abgerundeten Ecken, also bringen Sie es zurück ...
Hier ist, was Entwickler auf der Xbox tun müssen, sobald die Veröffentlichung von abgerundeten Ecken erfolgt. Wenn ein Entwickler WinUI 2.x mit der Funktion für abgerundete Ecken verwendet, muss der Entwickler den Stil für abgerundete Ecken deaktivieren, wenn er dem Stil der Shell entsprechen möchte. Wohlgemerkt, viele Apps auf der Xbox tun dies nicht... Deshalb veröffentlichen wir stattdessen Anleitungsdokumente für diejenigen, die es interessiert. Ich werde sicherstellen, dass die 10FT-Anleitungsdokumentation bei der Veröffentlichung die abgerundeten Ecken erwähnt.

Was die Vision betrifft, meine ich: "So werden zukünftige Windows Shell- und Inbox-Apps aussehen." und "Wir nutzen die Gelegenheit, unser Windows-Design zu aktualisieren, hier sind einige der Änderungen, die wir vornehmen..."

Cue Bilder und oder Video 😃

@mdtauk , darum habe ich das Designteam in der Vergangenheit gebeten, damit wir als Plattformteam dies nutzen können, um die Designvision für das Entwicklerpublikum zu kommunizieren. Soweit ich weiß, gibt es keinen sofortigen Plan, aber ich kann es noch einmal überprüfen.

Was die Vision betrifft, meine ich: "So werden zukünftige Windows Shell- und Inbox-Apps aussehen." und "Wir nutzen die Gelegenheit, unser Windows-Design zu aktualisieren, hier sind einige der Änderungen, die wir vornehmen..."
Cue Bilder und oder Video 😃

@mdtauk , darum habe ich das Designteam in der Vergangenheit gebeten, damit wir als Plattformteam dies nutzen können, um die Designvision für das Entwicklerpublikum zu kommunizieren. Soweit ich weiß, gibt es keinen sofortigen Plan, aber ich kann es noch einmal überprüfen.

Dankeschön. //Build/ wäre die perfekte Gelegenheit gewesen, die geplanten Änderungen zu teilen, insbesondere wenn geplant ist, diese Steuerelementvorlagen Ende Sommer zusammen mit der ersten Version von WinUI 3.0 zu aktualisieren.

Die Designs der Xbox-Shell und der Windows-Shell sind unterschiedlich. Das ist mit Absicht, weil es sich um einzigartige Produkte handelt. Aber wir haben WinUI-Steuerelemente so konzipiert, dass Apps, die einen Stil verwenden möchten, mit geringfügigem Aufwand ausgeführt werden können. Als wir vor einigen Jahren mit dem Xbox-Team zusammengearbeitet haben, haben wir darauf geachtet, dass unsere XAML-Steuerelemente (damals noch keine WinUI) korrekt im Fernsehen angezeigt werden, und haben auch die bereits erwähnten Anleitungen dazu veröffentlicht.

Sicher werden die Schalen unterschiedlich sein, um der Erfahrung zu entsprechen. Mein einziger Kommentar ist, dass, wenn die nächste Xbox die Entwicklung von Apps fördern möchte, die standardmäßigen WinUI-Steuerelemente Vorlagen und Themenressourcen in WinUI enthalten sollten, damit sie bei der Ausführung auf der Xbox den Anleitungen für das Steuerelementdesign entsprechen. Und es sollte möglich sein, während der Entwicklung zu testen, wie diese Kontrollen aussehen werden. Sowohl in Windows als auch im XAML-Designer.

Ich bin auf einige der Design-Kompositionen für die Xbox-Steuerung gestoßen, aber sie waren nicht in den UWP-Dokumenten enthalten.

@mdtauk , ich

@chigy Das war ein Problem, das ich eingereicht habe, und es ging darum, sicherzustellen, dass alle Steuerelemente, die die Community zu WinUI hinzufügt, Vorlagen für die Ausführung auf den zukünftigen Xbox-Konsolen enthalten sollten. Wenn Entwickler WinUI 3.0+ für ihre Xbox-App verwenden wollten, sollten sich alle Steuerelemente so anpassen, dass sie beim Ausführen auf einem Fernseher korrekt aussehen.

Aber da die Designs so gut wie fertig sind, hat diese Ausgabe nicht viel mehr Zweck - außer als abgeschlossen markiert zu werden, wenn alle Vorlagen aktualisiert sind.

Ich habe Ideen bei der Einreichung von NumberBox-Steuerelementen eingereicht, und wir wollten sicherstellen, dass das Design des Steuerelements mit dem übereinstimmt, was für die restlichen Steuerelemente geplant ist.

Wenn Entwickler WinUI 3.0+ für ihre Xbox-App verwenden wollten, sollten sich alle Steuerelemente so anpassen, dass sie beim Ausführen auf einem Fernseher korrekt aussehen.

@mdtauk , wie ich bereits erwähnt habe, ist dies ein guter Vorschlag, der jedoch nicht unsere Priorität hat, da

Die Tatsache, dass der ScrollIndicator von WebView nicht über XAML aktualisiert wird, wurde aktualisiert, aber wir verwenden Webs unverändert.

Betrachten Sie den aktuellen Fortschrittsbalken in der MUXControlsTestApp - Wird das rechte Ende des Fortschrittswertbalkens auch abgerundet oder behält er seine flache Kante?

Wird der Slider im Lautstärke-Flyout auch gestylt

Wird die Anzeige standardmäßig zu allen Steuerelementen hinzugefügt oder muss sie immer noch nach Stilen hinzugefügt werden?

Würden die im ColourPicker verwendeten Slider von einem Umrissstil profitieren, ähnlich dem des MediaPlayers - damit er nicht in den dunkleren Farben des Balkens verloren geht?

Betrachten Sie den aktuellen Fortschrittsbalken in der MUXControlsTestApp - Wird das rechte Ende des Fortschrittswertbalkens auch abgerundet oder behält er seine flache Kante?

Per Design-Definition sollte es. Bitte öffnen Sie ein Problem gegen MUXControlsTestApp.

Wird der Slider im Lautstärke-Flyout auch gestylt

Da die Shell-Benutzeroberfläche unser gemeinsames Steuerelement verwendet, sollte dies erfolgen, wenn die Änderung in unseren Steuerelementen erfolgt. Wenn dies jedoch nicht aktualisiert wird, öffnen Sie bitte das FeedbackHub-Problem. Dies ist eine Arbeit des Shell-Teams, und es ist nicht etwas, was das WinUI-Team in Bezug auf Priorität und Ressourcenausstattung abschließt.

Wird die Anzeige standardmäßig zu allen Steuerelementen hinzugefügt oder muss sie immer noch nach Stilen hinzugefügt werden?

Dies ist kein Thema mit abgerundeten Ecken.
Wenn Sie möchten, dass die Enthüllung standardmäßig zu allen Steuerelementen hinzugefügt wird, öffnen Sie bitte eine neue Ausgabe.

Würden die im ColourPicker verwendeten Slider von einem Umrissstil profitieren, ähnlich dem des MediaPlayers - damit er nicht in den dunkleren Farben des Balkens verloren geht?

MediaPlayer soll dem Design des neuen Sliders (#841) folgen. Was Sie vorschlagen, ist also nicht im Plan. Wenn Sie der Meinung sind, dass es sich um ein Usability-Problem handelt, öffnen Sie bitte ein separates Problem.

Woah! Hier gibt es viele Kommentare.

Ich denke, dass die hartnäckigen scharfen Ecken Windows 10 einzigartig aussehen lassen. Würden abgerundete Ecken eingeführt, müsste etwas am Windows-Logo, dem Microsoft-Logo und den Kacheln gemacht werden. Sobald Sie U-Bahn-Relikte wie Kacheln loswerden, müssen Sie auch Logos wie Office, die eine Neigung haben, neu erstellen. Ich könnte immer weiter über die Auswirkungen der Einführung von abgerundeten Ecken und Konsistenz sprechen, aber ich werde es hier schneiden.

@Poopooracoocoo Die neuen Office-Symbole/Logos verwenden abgerundete Ecken, ebenso wie das neue Terminal-Symbol und die neuen Visual Studio-Symbole/Logos.

Und FWIW, ich möchte nicht, dass sie die Kacheln loswerden, es ist schon schlimm genug, dass die Windows 10-Tablet-Benutzeroberfläche ein großes Downgrade im Vergleich zu Windows 8.1 vorgenommen hat

@Poopooracoocoo , @mdtauk ,
Vielen Dank für dein Feedback. Sie haben beide Recht, dass die Änderung flächendeckend umgesetzt werden muss. Daher beginnt diese Anstrengung mit der Ausrichtung auf Fabric und andere sichtbare Benutzeroberflächen wie Edge. Wir möchten, dass Konsistenz über Nacht geschieht, aber dies ist eine Reise. Und es beginnt mit dem Standardwert der hier verwendeten UI-Plattform (dh WinUI).

Status-Update:

Eckenradius (auch bekannt als Abgerundete Ecke) How-To-Dokument PR wird erstellt.

Dies wird docs.microsoft.com als Dokumentation hinzugefügt.
Es wird eine neue Seite unter https://docs.microsoft.com/en-us/windows/uwp/design/style/ sein.

Fragen Sie an die Community:
Ich versuche, ein wenig mehr "Hintergrunderklärung (WARUM)" zu schreiben, die unsere Kunden mit unserer Dokumentation in einigen unserer Fokusgruppen zum Ausdruck gebracht haben. Ich hätte gerne Feedback, da dies nicht dem normalen Dokumentationsmuster folgt.

Sind diese zusätzlichen Informationen nützlich/hilfreich, nicht relevant, fehlen andere Informationen usw.?

@chigy Der einzige Vorschlag, den ich zu dem Dokument habe, ist, dass Sie nicht erwähnt haben, warum die Steuerelemente die abgerundeten Ecken erhalten.

@mdtauk , guter Fang. Ich hatte den Abschnitt "todo" (Prinzipien), der das auffängt, aber irgendwie ging der Kontext während der Bearbeitung verloren. Ich arbeite noch daran, diesen Abschnitt auszufüllen.

Status-Update

Es wurde ein separates Problem erstellt, um die Arbeit zu verfolgen, um die Ecke des Kontrollkästchens in List and GridView (#1096) abzurunden

Änderungen an abgerundeten Ecken werden jetzt eingecheckt, wodurch dieses Problem geschlossen wird.

@mdtauk

Und FWIW, ich möchte nicht, dass sie die Kacheln loswerden, es ist schon schlimm genug, dass die Windows 10-Tablet-Benutzeroberfläche ein großes Downgrade im Vergleich zu Windows 8.1 vorgenommen hat

sorry das ich erst jetzt antworte. Sie werden wirklich Fliesen los! :(

Es ist eine interessante Entscheidung, da Android jetzt nur noch adaptive Symbole zulässt, ähnlich wie bei iOS, während Windows auf Freiformsymbole umsteigt. "Adaptive" Symbole sehen auf Begrüßungsbildschirmen besser aus, da sie ein monochromes Symbol haben, sodass Sie keinen blendend weißen Begrüßungsbildschirm benötigen. Auf der anderen Seite sehen Freiformsymbole viel besser aus, da sie Entwicklern mehr Kontrolle über das Symbol geben und es sowohl für die Desktop-Plattform (z. B. Titelleiste, Taskleiste) als auch für Win32-Apps geeignet ist.

Das Office-Symbol selbst sieht nicht wie die Symbole von Word oder PowerPoint aus. Mit diesen Änderungen habe ich das Gefühl, dass Microsoft seine Identität verliert

@Poopooracoocoo Ich hoffe immer noch, dass es eine Option geben wird, Kacheln anstelle von

@Poopooracoocoo und @mdtauk , bitte senden Sie Feedback zum Feedback-Hub für Kachel-Diskussionen, da das WinUI-Team weder an Kacheln beteiligt ist noch von den Plänen Kenntnis hat.

@Poopooracoocoo und @mdtauk , bitte senden Sie Feedback zum Feedback-Hub für Kachel-Diskussionen, da das WinUI-Team weder an Kacheln beteiligt ist noch von den Plänen Kenntnis hat.

Ich habe Feedback zur Beibehaltung der Kacheln abgegeben - es gibt eine Sammlung mit vielen Upvotes. Feedback Hub ist nicht so gut wie GitHub, da es wenig bis gar keine Feedbacks oder Diskussionsbeiträge von den Windows Dev-Teams gibt

Hallo, wie kann man die Rundungen deaktivieren? Es sieht hässlich aus, wenn die runde Schaltfläche einen runden Tooltip hat.

@kikisaints @chigy Gibt es eine Möglichkeit, die abgerundete Ecke zu deaktivieren, um beispielsweise ein bestimmtes Element wie @mklemarczyk anzufordern ?

Hallo, wie kann man die Rundungen deaktivieren? Es sieht hässlich aus, wenn die runde Schaltfläche einen runden Tooltip hat.

@mklemarczyk Haben Sie versucht, den CornerRadius-Wert im Stil des Steuerelements auf 0 zu setzen? Möglicherweise müssen Sie dies in App.xaml tun, damit es sich auf alle ToolTip-Steuerelemente auswirkt.

@kikisaints @chigy Gibt es eine Möglichkeit, die abgerundete Ecke zu deaktivieren, um beispielsweise ein bestimmtes Element wie @mklemarczyk anzufordern ?

@mklemarczyk , haben Sie unsere Anleitung gesehen?
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk Sie können die ToolTip.CornerRadius- Eigenschaft oder die OverlayControlResource als zwei Optionen verwenden, um den Eckenradius eines QuickInfo-Steuerelements zu ändern.

Die Eigenschaft Control.CornerRadius ist seit Windows 1809 verfügbar und kann wie folgt verwendet werden:

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

Dadurch wird der Eckenradius für jeden Tooltip in der App auf 0 gesetzt.

Alternativ können Sie

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

Beachten Sie, dass dies nicht nur den Eckenradius von Tooltip-Steuerelementen App-weit festlegt, sondern auch alle anderen Steuerelemente, die diese Ressource verwenden (wie ContentDialog und Steuerelemente, die Popups wie ComboBox verbrauchen). Das heißt ... theoretisch, da das Überschreiben der Ressource diese Steuerelemente nicht zu beeinflussen scheint, obwohl es sollte (ToolTip funktioniert).

Es gibt so viel Hin und Her, dass es schwer zu wissen ist, was in Bezug auf andere Eingaben und Eckenradien beschlossen wurde, aber sehr schnell, nachdem ich ein UWP-Projekt migriert hatte, um ausschließlich WinUI 3 zu verwenden, stellte ich fest, dass nur Schaltflächen ein Eckenradius zugewiesen wurde (zusammen mit den anderen Änderungen wie verbesserter Enthüllung usw.), aber meine anderen Eingabesteuerungen (zB Combobox) wurden beim Metro-Look belassen (dunkler / dickerer Rahmen und 90°-Winkel). Ist das beabsichtigt, ein WIP oder ein Fehler? Um die Combobox an die Schaltflächen anzupassen, muss ich einen Eckenradius von 3epx verwenden, obwohl alles, was ich online sehe, besagt, dass der neue Standard-Eckenradius 4epx beträgt.

Es gibt so viel Hin und Her, dass es schwer zu wissen ist, was in Bezug auf andere Eingaben und Eckenradien beschlossen wurde, aber sehr schnell, nachdem ich ein UWP-Projekt migriert hatte, um ausschließlich WinUI 3 zu verwenden, stellte ich fest, dass nur Schaltflächen ein Eckenradius zugewiesen wurde (zusammen mit den anderen Änderungen wie verbesserter Enthüllung usw.), aber meine anderen Eingabesteuerungen (zB Combobox) wurden beim Metro-Look belassen (dunkler / dickerer Rahmen und 90°-Winkel). Ist das beabsichtigt, ein WIP oder ein Fehler? Um die Combobox an die Schaltflächen anzupassen, muss ich einen Eckenradius von 3epx verwenden, obwohl alles, was ich online sehe, _sagt_, dass der neue Standard-Eckenradius 4epx beträgt?

Wenn Sie einen Unterschied zwischen WinUI2 und WinUI3 in Bezug auf die Stile feststellen, können Sie bitte eine neue Ausgabe eröffnen? Es könnte sich um einen Fehler in Bezug auf das Zusammenführen von Stilen von WinUI2 in WinUI3 handeln.