これは、Fabricで使用されているボタンなどの丸みを帯びた角よりも広いプロジェクトである必要があります。

• ボタン
• スピナー/ ProgressRing
• 不確定なプログレスバー
• チェックボックスとラジオボタン
• ComboBoxesとTextFields
  等々。

Xboxには引き続きさまざまな要件がありますが、新しいXboxコンソールのセットが準備されているため、MicrosoftDesignチームが協力してWinUI3.0とXboxNextに間に合うようにすべてを調整できる可能性があります。

クロスプラットフォームとPWAのユースケースでは、ファブリックは現在多くの注目を集めているようです。 したがって、おそらくファブリックが青写真になります-少なくともコンパクト密度では、最小測定値として2pxから4pxに移動します-次に、タッチアフォーダンスを推定し、不足している制御状態を埋めます。

ThemeShadowsは、丸みを帯びた角を考慮する必要があります。 また、アクリルの表面には、背景から高く見えるように、内側と外側の境界線を含める必要があります。

@mdtauk要件番号4に記載されているように、Xboxでこの変更を合理化する計画があります。 とは言うものの、この特定の機能は、作業の範囲を明確に保つためだけに丸みを帯びた角に限定されています。 あなたが持っている他のデザインの提案については、個別のリクエストを自由に開いてください。

ところで、アクリル面の内側と外側の境界についてのフィードバックがよくわかりませんか？ 現在、指定した2つの境界線を使用していないため、言及しているのはXboxのデザインですか。

@chigy確かにXboxで、それはそれ自身のものです。 しかし、重要なのは、丸みを帯びた角がすべての関連するコントロールで機能する必要があるということです。

Fluentチームが合意したかどうかにかかわらず、内部のfigma設計仕様を認識していませんが、ボタン以上のものである必要があります。

Fluent Webは、丸みを帯びた角に2pxの角半径を使用しますが、FluentXAMLは基本測定値として4pxを使用する傾向があります。 次に、おそらくFluentWebと同じメトリックを使用するCompactDensityテンプレートがありますか？

Xbox FluentとFabricの共有コントロールの比較画像と、それらの外観の違いを作成しました。 したがって、これらのコントロールテンプレートを確認しているときに実行する必要があるのは、丸みを帯びた角だけではありません。

Xboxのものを無視する

@mdtauk 、これはボタンだけの印象を与えるために、私は明確に指定していないはずです...安心してください、そうではありません。 要件番号1とそのサブアイテムを参照してください。 これはすべてのコントロールについてです。

デザインファイルを公開する機会はありませんでしたが、計画しているコーナー半径は確かに2px（オーバーレイUIの場合は4px）です。 私は実際にFabricチーム（つまりFluent Web）と非常に緊密に連携しており、これらの変更を一緒に評価しています。 とはいえ、それらを完全に同じにすることは私たちの目標ではありませんが、ユーザーがそれらを並べて見るとき、私たちは首尾一貫して家族の一員であると感じる必要があります。 要件番号4を参照してください。

したがって、これらのコントロールテンプレートを確認しているときに実行する必要があるのは、丸みを帯びた角だけではありません。

作業中ですが、これを1つずつ/ケースバイケースで行っています。 変更のために物事を変更しないことが理にかなっている変更を行う際には注意が必要です。

@chigyありがとう、ありがとう、ありがとう！

これらのデザインをコミュニティと共有できれば幸いです。コントロールとUIがどこに行くのかを確認したいだけでなく、変更が実装されたときに不整合を指摘し、将来を確保できるようにするためです。コントロールの提案はくつろげるでしょう！

ファブリックWebとFluentWebはパックよりも進んでいるようであり、XAML、WPF、WinForms / VisualStylesもそれに続くはずです。

@ chigy @ mdtaukここで私の応答を参照して提案に関しても、ユーザーとフルーエントデザイン（FD）チームの間で活発なやり取りが行われることを望んでいます。

@mdtaukFDに一致するようにWPF / WinFormsコントロールを更新するポイントが
だから、 @ YuliKl @chigy @ pag3 ：これについてコメントできますか？ デフォルトのWinForms / WPFコントロールは、新しいFDの外観になるように更新されますか、それともWinUIコントロールは、私が理解しているように、最新かつ最高のデザイン機能を利用する方法になりますか？

この画像をNumberboxの提案に投稿しましたが、更新中のTextBoxコントロールとの関連性がある可能性があります。

BorderThickness 、 FocusReveal on Focused State、Border on DisabledState。

「スピンボタン」スタイルは、検索ボタン、パスワード表示ボタン、クリアテキストボタンに適用できます。

フォーカスされた状態の境界線/コントロール要素の周りの影は、私には強すぎるように見えます。 なぜ彼らは影さえ必要なのですか？ 現在のバージョン（境界線の色を変更するだけ）はまったく問題ありません。 影は、コントロール（要素）がフォアグラウンドに上げられていることを示唆している可能性があります。これは、3D環境では意味があるかもしれませんが、従来のデスクトップ環境では確かに必要ありません。

フォーカスされた状態の境界線/コントロール要素の周りの影は、私には強すぎるように見えます。 なぜ彼らは影さえ必要なのですか？ 現在のバージョン（境界線の色を変更するだけ）はまったく問題ありません。 影は、コントロール（要素）がフォアグラウンドに上げられていることを示唆している可能性があります。これは、3D環境では意味があるかもしれませんが、従来のデスクトップ環境では確かに必要ありません。

フォーカスされたときのコントロールの周りのグローは、FocusVisualKind.Revealであり、システムによって制御されます。 不透明度とサイズに正確に一致するメトリックがないため、外観を概算する必要がありました。

境界線の色を変更するだけでなく、グローによって焦点がはるかに明確になると思うことを示すものとして使用してください。

@mdtauk 、それぞれ、この問題の会話を丸みを帯びた角に限定して丸みを帯びた角についてのフィードバックを本当に受けたいのですが、この会話は、その目的のためにここに来たばかりの人にとっては混乱しすぎているのではないかと思います。

そうは言っても、あなたが見せているものは、RevealFocusの振る舞いのように私には見えます。 フォーカス状態をより強くすることを検討し、いくつかのユーザー調査を行い、@ Felix-Devが彼の応答で述べているようにそれらが強すぎることを確認しました。
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy調査の結果、テキストコントロールのフォーカスに焦点を当てるのが多すぎることが

@mdtaukと@ Felix-Dev、提案されている変更のビジュアルコンプをアップロードしました。

@chigyは、テキストコントロール、コンボボックス、チェック、およびラジオコントロールの境界線の太さを再検討する可能性があります。

FabricWebは1epxの厚さを選択しました。これにより、特に新しい丸みを帯びたコーナーで、コントロールがよりエレガントになると思います。 現在、彼らは少しかさばる感じがします。

コンパクトモードのテキストボックスには大きなメリットがあります。 しかし、焦点を合わせると、境界線が太くなる可能性があります

ボタンは、デフォルトで不透明度20％の背景塗りつぶしを使用します。 Fabric Webでは、1 epxの境界線を使用し、塗りつぶしは使用しません。 これはより良い解決策であり、テキストボックスコントロールのボタンがうまく収まるようになると思います。

スピンボタン付きのNumberBoxの提案は、ボタンとテキストフィールドのこの組み合わせを示しています

おそらく、チームがこのスタイルを新しいデフォルトにすることを望まない場合は、スタイル/テンプレートを含めることができます。

@chigyによって作成されたビジュアルコンプの表示を支援するために、これを作成しまし

角の丸いトピックに関する逸話的で専門的でないフィードバック。
EdgeとCrEdgeの両方を使用する場合、CrEdgeでの私の一番の問題は、UI全体の丸みを帯びた感触です。 それは恐ろしいものであり、積極的にそれを使用することを嫌います。 丸みを帯びた角を追加する場合は、安全はさみを持った子供のように見えるものを切り取りたくない私たちのために、鋭いエッジを切り替える機能を追加してください。

@chigyによって作成されたビジュアルコンプの表示を支援するために、これを作成しました

@mrlacey 、どうもありがとうございました!!

@chigyは、テキストコントロール、コンボボックス、チェック、およびラジオコントロールの境界線の太さを再検討する可能性があります。

@mdtauk 、作業をバケット化する方法について、現在いくつかの視覚的な変更が整理されています（個別にアドレス指定可能でありながら一貫性があるようにしたい）、そのうちの1つはあなたが求めているものですのでご期待ください。

角の丸いトピックに関する逸話的で専門的でないフィードバック。
EdgeとCrEdgeの両方を使用する場合、CrEdgeでの私の一番の問題は、UI全体の丸みを帯びた感触です。 それは恐ろしいものであり、積極的にそれを使用することを嫌います。 丸みを帯びた角を追加する場合は、安全はさみを持った子供のように見えるものを切り取りたくない私たちのために、鋭いエッジを切り替える機能を追加してください。

@ Zucce05 、はい＃684は、丸みのない角に簡単に戻すことができるため、懸念に対処します。 とは言うものの、私たちのコンプ提案でわかるように、コーナーはプロ並みの外観を維持するためにそれほど丸くはありません。

@chigy
私も角の丸いデザイン変更のファンではないので、簡単に元に戻すオプションがあると聞いてうれしいです。 システム全体のコーナー半径オプションはないと思いますが、（システム全体のアクセントカラーを設定するのと同様に）ありますか？

境界線の太さのトピックについて：私はボタンの現在の太さが好きで、境界線の太さも現在のUIランドスケープで私にかなり独特に感じます。 UIでこの境界線の太さがUWPUIと異なることはめったにありません。そのため、「現在見ているUIはUWPです」という優れた区別として常に機能します。 厚みはそのままにしてほしいです。

投稿されたビジュアルコンプを見ると、境界線の太さが奇妙に見えるのは、チェックボックスのあるTreeViewの場合だけです。 その場合、チェックボックスの厚さは私には厚すぎます。 誤解を招く視覚効果かもしれませんが、スタンドアロンのチェックボックスの境界線の太さは薄く、見栄えが良いようです。 したがって、TreeViewのチェックボックスの境界線の厚さを減らして、通常のチェックボックスの境界線の厚さの視覚効果と一致させます。

@mdtauk 、作業をバケット化する方法について、現在いくつかの視覚的な変更が整理されています（個別にアドレス指定可能でありながら一貫性があるようにしたい）、そのうちの1つはあなたが求めているものですのでご期待ください。

@chigy私が言及した変更を説明するためにいくつかの視覚的なモックアップを行い、コントロールをFabric Webのコントロールに近づけましたが、それでもFluentコントロールメトリックを使用しています。

ホバーに追加されたシャドウは、MicrosoftストアWebビューのFluent Webコントロールによって使用されますが、これはデフォルトで省略できます。または、削除可能なテーマアニメーションによってZ変換を実現できます。

上記の@mdtaukによるデザイン提案のいくつかを見ると、ボタンの現在の境界線の太さなどが明らかに好きです...

また、私はWindows FluentDesignをFabricWebやその他のWebUIコンポーネントに基づいたものにするのが好きではないことにも注意したいと思います。Windowsに、Webで何が起こっているかによって異なる独自の外観を持たせたいです。 インターネットブラウザを例にとると、Chromeは最近1マイルで最も広く使用されているブラウザですが、Edge Chromiumベースのブラウザはまったく同じように見えるわずかに異なるだけである必要がありますか？ 私の見解ではありません。 上で述べたように、現在のUWPのデフォルトのコントロールスタイルは、UWP（したがってWindows）に素晴らしいユニークな外観を与えます。 Windows Fluentチームに検討してもらいたいこと（つまり、変更のために変更するだけではありません）。

@ Felix-Dev Fabric Webは、Fluentに基づくMicrosoftのWebコントロールデザインです。 Chromium Edgeは、これらのコントロールスタイルをデフォルトで使用することを計画しています。 ただし、もちろん、WebデザイナーはCSSコントロールを再設計でき、開発者はXAMLコントロール用に独自のテンプレートを選択することもできます。

MicrosoftのコントロールデザインがWebごとに大きく異なる必要がある理由がわかりません。 一緒に話しているのではなく、異なるチームのように思えます。 そして、開発者はまだオーバーライドするオプションがあります。 また、これらの新しいデフォルトは、アプリがWinUI3.0に再コンパイルされない限り有効になりません。

投稿されたビジュアルコンプを見ると、境界線の太さが奇妙に見えるのは、チェックボックスのあるTreeViewの場合だけです。

@ Felix-Dev、この特定の問題については、Figmaがビジュアルをやや奇妙なスケールでエクスポートするという奇妙なバグだと思います。 PNGをエクスポートした実際のビルドと実際のFigmaファイルを再確認しましたが、問題ないようです。

RE：丸みを帯びた角の人気
@mdtaukおよび@ Felix-Dev、
私の同僚は、開発者（ほとんどがLOB / WPF / WinForms開発者）がスニークプレビュー中に丸みを帯びた角でコントロールを更新することについて私たちがどう思っているかについて非公式の質問をしました。 また、Twitter forWindowsで頻繁に角を曲がっていないという不満もあります。

ですから、私はあなたのフィードバックを尊重しますが（そしてあなたがそれらを来ることを願っています）、私があなたからここで聞いていることの反対を示す事例データがあります。 そうは言っても、あなたがそうすることを望む場合に備えて、それを元に戻す方法を検討しているのはそのためです。 デザインはかなり主観的であるため、注意が必要です。 赤が苦手な方は、無理やり赤いシャツを着させることはできませんが、それが「赤い日を着る」なら、目立たないように着てみてはいかがでしょうか。 私が言っていることを理解したら... :)

まあ、結局それは個人的な好みに帰着します。 現在のUWPのデフォルトのコントロールスタイルは見栄えがよく、私にとって大きな部分の1つは、ウェブやChromeブラウザなどの人気のあるアプリやAndroidなどのモバイルOSで見られるものと比べてユニークに見えることです。 新鮮な空気のいい息です。

これで、MSが設計言語としてWindowsとWebの両方で異なる「デフォルト」スタイルを使用したい理由がわかりました。 ただし、現在の方向性はWindowsをモバイルアプリ/モバイルOSのように見せることであり、私はそれほど好きではありません（「XAMLコントロールがWebアプリやモバイルアプリの進化と矛盾している」を参照）。問題の提案で）。

開発者はスタイルを簡単に変更できる可能性がありますが、私にとって最も重要なのは、MSが提供するすべてのアプリ（つまり設定）でスタイリングが使用されるため、外部開発者も作業のベースとなるデフォルトのスタイルです。 （もう少し、少し少なく）。

@chigy

私の同僚は、開発者（ほとんどがLOB / WPF / WinForms開発者）がスニークプレビュー中に丸みを帯びた角でコントロールを更新することについて私たちがどう思っているかについて非公式の質問をしました。

それはおそらく間違った聴衆に尋ねるのではないでしょうか？ 毎日のユーザーはどうですか？ たとえば、最近の丸みを帯びたコーナーがredditやdiscordチャネルを押し込んでいることに不満を言うユーザーはかなりいます（ただし、その変更を気にしない、またはサポートしないユーザーも常にいます）。

Twitterの例について：これは、独自のブランドスタイルを持ちたいと考えているサードパーティのアプリです。 私はそれで大丈夫です（結局のところ、それはあなたのチームがやって来て、コントロールスタイルのcutomizationサポートを追加するところです）。 しかし、私は確かに、Windowsの公式デザイン言語をオーバーホールする理由として外部アプリを使用しません。

簡単に言うと、Windowsデザインチームは、モバイル/ウェブの世界に近いWindowsのスタイリングに取り組んでいるように感じます。 さて、これらの変更がそれほど過激ではなく、Windowsが他の環境と簡単に区別できるように、独自の外観のままであることを願っています。

@ Felix-Dev Fabric Webコントロールは、他のフレームワークやデフォルトのWebコントロールとは異なります。 これらは最近、Windows 10MDL2コントロールやWindows8 / WinJSコントロールのような古い外観と比較して、FluentDesignを使用するように更新されました。

XAMLコントロールは現在もMDL2コントロールデザインを使用しており、フライアウトやメニューなどの一部の要素はFluentDesignの要素とマテリアルを使用しています。

FluentとFabricのテキストスタイルは、太字と半太字の重みをより多く利用しています。 さまざまなWindows10の概念でもこれらが使用されています。 ただし、Windowsシェルアプリと受信トレイアプリのすべてがまだこのスタイルに移行しているわけではありません。

ファブリックWebとフルーエントウェブは、フルーエントデザインが発表されて以来、マイクロソフトからのコントロールに対する最新の変更であるため、これらのUIの方向性を見つけるために、これらのデザインを確認するのは当然です。 WinUI 3.0はプラットフォームにとって大きな変更であり、すべてのコントロールは、MicrosoftのFluent Designとより良く、より新鮮に、より一貫性を持たせるために新鮮な外観を与えられました。

RE：Webの一貫性、流暢さ、そしてWindows独自のもの
@ Felix-Devおよび@mdtauk 、
Windows設計チームの目標の1つは、「親しみやすさ」です。 彼らは私たちの顧客（あなたが示すように、私たちの開発者ではなく私たちの日常のユーザー）と多くのユーザー調査を行い、正当な理由もなく異なることはあなたが想像できるように良いことではないことを発見しました（私は非常に要約していますしたがって、これは彼らが行った正確なテストではないので、ここで私を引用しないでください）。 Windowsは、あらゆるテクノロジーの経験がモバイルまたはWebから始まっている可能性のある新しいタイプのユーザーを引き付ける必要があります。 これらのユーザーは、Windowsを紹介したときに大きなギャップを感じ、「異なる」ルックアンドフィールを持っていても役に立ちません。 角が丸いような小さな変化は、知覚に大きな違いをもたらします。 オフィスチームも同様の調査を行い、同様の結果が得られたため、角を丸くして前進しています。 私たちは、この決定を軽々しく、または真空中で行っているわけではありません。

それは私たちがそれらを完全に同じにするという意味ではありません。 改善できるところがあれば、それが欲しいです。 また、フェリックスが言及したようにユニークでありたいと思っていますが、意見の違いだけでなく、意味のあるものである必要があります。 これらは、Fluent独自の処理を利用する場所です。

このディスカッションで前述したように、私はOffice、Windows、およびEdgeの各チームと非常に緊密に連携しています。 私たちの設計チームは、Microsoft / Fluentから出てくる1つの設計を望んでいるため、違いを非常に注意深く検討し、違いが意味をなさない部分を排除して、一緒に進化できる出発点を用意しています。

非常に興味深いのですが、これらの変更の多くはこれらのチームによって別々に培養されていましたが、非常によく似た場所に到着することがよくありました。 境界線を薄くすることはOfficeが最初に実装したものですが、Windowsはしばらくの間それについて議論してきました。 そして、マーティンが示唆するように、これらはすべてフルーエントデザインの方向性の一部です。

_RE：角の丸い人気_
@mdtaukおよび@ Felix-Dev、
私の同僚は、開発者（ほとんどがLOB / WPF / WinForms開発者）がスニークプレビュー中に丸みを帯びた角でコントロールを更新することについて私たちがどう思っているかについて非公式の質問をしました。 また、Twitter forWindowsで頻繁に角を曲がっていないという不満もあります。

ですから、私はあなたのフィードバックを尊重しますが（そしてあなたがそれらを来ることを願っています）、私があなたからここで聞いていることの反対を示す事例データがあります。 そうは言っても、あなたがそうすることを望む場合に備えて、それを元に戻す方法を検討しているのはそのためです。 デザインはかなり主観的であるため、注意が必要です。 赤が苦手な方は、無理やり赤いシャツを着させることはできませんが、それが「赤い日を着る」なら、目立たないように着てみてはいかがでしょうか。 私が言っていることを理解したら... :)

_RE：Webの一貫性、流暢さ、Windows独自の機能_
@ Felix-Devおよび@mdtauk 、
Windows設計チームの目標の1つは、「親しみやすさ」です。 彼らは私たちの顧客（あなたが示すように、私たちの開発者ではなく私たちの日常のユーザー）と多くのユーザー調査を行い、正当な理由もなく異なることはあなたが想像できるように良いことではないことを発見しました（私は非常に要約していますしたがって、これは彼らが行った正確なテストではないので、ここで私を引用しないでください）。 Windowsは、あらゆるテクノロジーの経験がモバイルまたはWebから始まっている可能性のある新しいタイプのユーザーを引き付ける必要があります。 これらのユーザーは、Windowsを紹介したときに大きなギャップを感じ、「異なる」ルックアンドフィールを持っていても役に立ちません。 角が丸いような小さな変化は、知覚に大きな違いをもたらします。 オフィスチームも同様の調査を行い、同様の結果が得られたため、角を丸くして前進しています。 私たちは、この決定を軽々しく、または真空中で行っているわけではありません。

それは私たちがそれらを完全に同じにするという意味ではありません。 改善できるところがあれば、それが欲しいです。 また、フェリックスが言及したようにユニークでありたいと思っていますが、意見の違いだけでなく、意味のあるものである必要があります。 これらは、Fluent独自の処理を利用する場所です。

このディスカッションで前述したように、私はOffice、Windows、およびEdgeの各チームと非常に緊密に連携しています。 私たちの設計チームは、Microsoft / Fluentから出てくる1つの設計を望んでいるため、違いを非常に注意深く検討し、違いが意味をなさない部分を排除して、一緒に進化できる出発点を用意しています。

非常に興味深いのですが、これらの変更の多くはこれらのチームによって別々に培養されていましたが、非常によく似た場所に到着することがよくありました。 境界線を薄くすることはOfficeが最初に実装したものですが、Windowsはしばらくの間それについて議論してきました。 そして、マーティンが示唆するように、これらはすべてフルーエントデザインの方向性の一部です。

私はすべてデフォルトのコントロールを変更することに賛成です。FabricWebコントロールは、現在のXAMLコントロールデザインのIMOよりもエレガントで洗練された感じがします。

ただし、これは単にテンプレートを変更するだけではなく、開発者がコントロール全体を再テンプレート化することなくこれらの変更を簡単にオーバーライドできるようにする、より多くのプロパティを公開することです。

新しいデフォルトのCornerRadius値は、ThemeResourcesのようになります。
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

次に、開発者はApp.xamlでこれらをオーバーライドするか、 CornerRadius = "0"を適用して四角にしたままにします。

これに続いて、BorderThicknessのデフォルトを2epxではなく1epxに設定することもお勧めしますが、すべてのコントロールは次のようなThemeResourcesを使用します。
<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"

したがって、これらはApp.xamlでグローバルにオーバーライドすることも、いくつかのコントロールに適用されるスタイルでオーバーライドすることもできます。

新しいデフォルトを設定しますが、再テンプレートを必要としないオーバーライドを許可します。

ただし、これは単にテンプレートを変更するだけではなく、開発者がコントロール全体を再テンプレート化することなくこれらの変更を簡単にオーバーライドできるようにする、より多くのプロパティを公開することです。

@mdtauk 、そう@kikisaintsを追加して、あなたからの良いフィードバックが表示されるようにします（ただし、全体が膨大になるため、引用しません。:)

@chigyその最後の応答を投稿していたときに、他のものが追加されたので、引用符を含める必要がありました:)

WindowsUIチームがこれまで行ってきた種類の議論についてもっと知りたいです。 私は過去数年間、自分の目的とTwitterの会話のためにコントロール設計のアイデアを作成してきましたが、FabricWebとOfficeXamlにあるもののいくつかは、私が変更したかったものでした。 境界線の太さ、ラジオボタン、チェックボックス、ドロップダウンなどとの特定の不一致。

これらの変化が進展するのを見るのを楽しみにしており、ここで行われている議論に参加できることを嬉しく思います！

たとえそれが強引なものや意見のあるものとして出くわしたとしても、私が意図した建設的な方法で私の熱意を持ってくれてありがとう。

コントロール全体を1回の変更で再テンプレート化するのではなく、プロパティを設定するのと同じくらい簡単にコントロールをカスタマイズできるようにするという決定を私は間違いなく称賛します。

ただし、最終的に私が最も見たいのは、OSでのパーソナライズサポートの強化です。ご存知のように、私は提案された変更のファンではありません（微妙なコーナー半径が1つであり、境界線の厚さがさらに減少します）そして私は現在のデザインが好きです。 一方、 @ mdtaukのような、提案された変更の大ファンであることは明らかなユーザーがいます。 Windowsは、これらのコントロールの新しい柔軟性を利用し、システム全体の外観をカスタマイズするオプションを提供する必要があります。これが理にかなっている場合や、開発者がシステム設定に従うことをオプトアウトする柔軟性を提供する必要があります。

特にボーダーの考え方を見ると、提案されたシステムは、コーナー半径のシステム全体のオプションを非常に簡単に提供します（リソースアプリが使用できるように公開されている今日のアクセントカラーと同じように）。 特に、提案されたコーナー半径の変更がかなり小さいことを考えると、これはアプリの設計的にも実現可能である可能性があります（開発者がそう感じない場合は、いつでもオプトアウトできます）。

WindowsUIチームがこれまで行ってきた種類の議論についてもっと知りたいです。

@ mdtauk 、GitHubを介して今後のすべての視覚的な変更をもたらすことが私たちの意図であるため、さらに多くの変更が行われることを期待してください。 私はまた、これらの背景のいくつかを含むようにドキュメントを拡張することを計画していますが、それは私が実験しているものなので、それが確実なことになるかどうかはわかりません...

しかし、結局のところ、私が最も見たいのは、OSでのパーソナライズサポートの強化です...
Windowsは、これらのコントロールの新しい柔軟性を利用し、システム全体の外観をカスタマイズするオプションを提供する必要があります。これが理にかなっている場合や、開発者がシステム設定に従うことをオプトアウトする柔軟性を提供する必要があります。

@ Felix-Dev、現在Windowsで検討しているパーソナライズのタイプ（ユーザーが設定から変更できるものを想定していますか？）は、使いやすさに影響を与えるものです。 丸みを帯びた角や境界線の太さがその1つであるかどうかはわかりません。 ユーザーがUI全体を自由に設計できるようにすることは、Windowsの目標ではありません。 私たちはまだWindowsデザインを提供したいと思っており、丸みを帯びた角はパーソナライズを目的としたものではないと私が思う重要なデザイン要素の1つです...少なくとも現時点では、パーソナライズの定義に従って。 フィードバックをお寄せいただきありがとうございます。今後の設計変更を検討する際に、公開することが理にかなっている場所を探します。

@ Felix-Dev開発者がコントロールに対して実行できるカスタマイズの量が多いため、コントロールの設計変更に関してOS設定と一貫性を保つことは不可能です。

@chigy新しいコントロールデザインのそれぞれのデザインコンプをGitHubに持ち込むときは、変更によって状況が改善される理由について、マイクロソフトが調査研究から収集した情報を含めると便利です。 つまり、「これを三角形から六角形に変更した」というよりも、「ユーザーの快適さと親しみやすさの実験を行ったときに、このボタンのデザインを三角形から六角形に変更した方が簡単だと感じる人が増えた」というようなものになります。ボタンとして識別し、他のプラットフォームと比較した場合、UIはこのデザインとの親和性を感じました」など

@mdtauk

開発者がコントロールに対して実行できるカスタマイズの量が多いため、コントロールの設計変更に関してOS設定と一貫性を保つことは不可能です。

私は、外部の開発者がそのユーザー設定をどのように尊重するかについて話しているのではなく、Windowsコンポーネントの外観について、今日すでに任意の方法でコントロールのスタイルを設定できます。 つまり、設定アプリ、クリップボード、切り取り＆スケッチ、タスクバーフライアウトのUI要素（ネットワークパネルのボタンなど）などです。

私は、MSが提供するアプリ以外のUWPアプリをほとんど使用していないため、外部開発者によるカスタムスタイルに問題はありません。 ただし、WindowsシステムのUWP要素と毎日やり取りしています。

@chigy正解です。私は、ユーザーがUIの外観を（ある程度まで）変更できるWin10設定アプリの設定を見ていました。 UIの特性をユーザーが変更できるようにする追加の作業の観点から、実際に何が意味をなし、実行可能であるかはまだわかりません。 提案されている変更が小さいほど（微妙なコーナー半径）、以前のスタイルに戻るオプション（正方形のコントロール）を追加する方が実行可能だと思います。

最後にもう1つ、Win10のユーザー数は8億人です。 提案された変更についてマーティンほど熱心な人は誰もいないので、Windowsもそれらのユーザーに対応しようとするとよいでしょう。 あなたが言ったように、UIは非常に主観的であり、UIシステムに柔軟性を追加する可能性がある場合、MSは少なくともそれを考慮する必要があります。
たとえば、インターネットブラウザの場合、色が変更されるだけでなく、タブや検索バーなどのUI要素の外観も変更されるテーマの業界全体があります： https ：
ただし、Windowsシステムの場合、ユーザーは独自のテーマを作成することはできないため、MSがUIのカスタマイズオプションを提供できれば便利です。

@mdtauk @chigy
このredditの投稿をチェックして、丸みを帯びた角のファンではないのは私だけではないことを確認してください。 全体の動きを嫌う人もいれば、ユーザーが現在の外観に戻れるようにWindowsの外観を選択できるようにすることを求める声も多くあります。

了解しました。UIの変更案について問い合わせがあり、主に文字通りすべてに丸みを帯びた角を強制するというアイデアと、グラフィックインターフェイスデザイナー（主にコンセプト）の両方であるため、多くの人からこのスレッドにフィードバックを求めるように促されました。とデザイン）そして開発中からWindows 10を使用してきました。提案された変更を強く嫌い、OS全体に丸みを帯びた角を追加することを強く嫌うすべての人の側に立ち、これらの変更を行わないか、または許可しないことを強くお勧めします。ユーザーは、パーソナライズのオプションを使用して、角を丸くするか鋭い角にするかを選択できます。

嘆かわしい言葉で：それらを正方形に保つか、ユーザーレベルでオプションにします。

私には十分な理由がありますが、私の最大の理由は、Windows 8以降のWindowsには四角い角があり、ほとんどすべてが何年もの間これを中心に設計されているという事実です。この提案は、iOSからまったく同じ丸い角を採用する試みです。何らかの理由でAndroidプラットフォーム。 より大きな問題は、これを行うと、システム全体の不整合の量が増えるだけでなく、実際には実際には認識しているよりもはるかに大きいような「小さな」UIの変更を強制すると、アプリのエコシステム全体で不整合が発生することです。そのような単純な変更のためにアプリを更新したくない開発者。

私の意見では、これは開発者の選択ではありません。上記の理由だけでなく、Windowsは常にカスタマイズとパワーを重視してきました。たとえば、Windows98別名Classicテーマを取り上げます。 Windows XPが登場したとき、Lunaテーマよりも多くのカスタマイズオプションがあったため、多くの人がまだClassicを使用していました。 XPは、Lunaテーマをすべての人に強制することはありませんでしたが、Classicを使用するオプションがありました。 この提案された変更は、どこにでも四角い角を保持するオプションを提供しません。それは、ユーザーが自分の好みに合わせてOSをカスタマイズできるようにすることに関しては、私の意見では非常に悪いことです。

「このような小さな変更は、ユーザーが興味を持っているものではない」または「ユーザーにカスタマイズしすぎると混乱する」と思われるかもしれませんが、どのユーザーも、何を切り替えるかを理解できると確信しています。適切な説明とコンテキストがあれば、丸くて鋭い角やテーマでさえもうまくいくでしょう。 また、他の何かを彼らの意志に反して強制するのではなく、これのオプションを持つことに間違いなく興味を持っている多くの人々を追加します。丸めのアイデアを好まない人々の証拠がさらに必要な場合は、Redditの投稿@ Felix-Devを参照してくださいどこでもコーナー。

多くの人は、角を丸くするという提案でさえ非常に嫌いで、それを一歩後退させたと考えています。次のHololens UIが丸みを帯びているいくつかのビデオのコメントを確認しても、コメントの大部分は、角を丸くすることを強く嫌うことについてです。 「MicrosoftがUI部門にタオルを投げ込み、AppleまたはGoogleのいずれかをコピーする」のバリエーションは、Microsoftが丸みを帯びた角を使用したのは初めてではありませんが、今では否定的なものと見なされています。

繰り返しになりますが、これは本当にオプションまたはテーマである必要があります。Windowsには以前のバージョンで何年もテーマがあったため、新しい概念ではありません。どちらかといえば、これは何かを強制するのではなく、堅牢なテーマの復活を求めるメッセージである必要があります。みんなにそしてオプションを減らします。

より多くのフィードバックを収集できるように、この提案にリンクするreddit投稿を作成しました。 これまでのコメントを見ると、角を丸くした微妙なアプローチを高く評価している方も多いと思います。

また、公式のWin 10 MSアプリでも、UIの不整合や、設定アプリとセキュリティアプリ（タイトルバーに拡張されたNavigationView）を参照してください。また、win32システムコンポーネントと新しいUWP要素の違いも指摘されています。 @SavoySchulerが述べたように、これはWinUI3.0で対処されることを願っています。 これは、この提案に関する特定のポイントではありませんが、多くのWindowsユーザーの間での「包括的な」要望です。 角が丸いかどうかについてはそれほど重要ではありませんが、Windowsシステムの一貫性についてです。

ここでは一貫性が鍵であり、私の主な関心事でした。

WinUI 3.0は、受信トレイアプリとWindowsUIに影響を与えるXAMLコントロールの変更に関するものです。

Fabric Webは独自のチームですが、すべてのチームがコミュニケーションを取り、Fluent Designに基づいて決定を下しているため、Fabric Webの設計はMicrosoftの最新の考え方であり、一貫性が優先されるはずです。

Xbox Next、Windows Lite、およびWindows Core OSには新しいシェルが付属するため、チームにとっても考慮する必要があります。レガシーサポート用のWindows10を使用します。

@chigyが言ったことは、まさに私や他の多くの人が求めていたものです。これは、開発者レベルではなくユーザーレベルのユーザーが、シャープコーナーとラウンドコーナーのどちらを表示するかを簡単に決定できるようにする、より微妙な変更です。以前はWindowsのテーマが機能していました。

@Nepxuneが上で述べたことに基づいて、システム全体のコーナー半径に対してユーザーが選択できる値の範囲をユーザーに提供することはおそらくクールでしょう。 少なくとも0から2の範囲の小さな値については、細心の注意を払って設計されたUIに悪影響はないと思います。 結局のところ、これらは非常に微妙な変更であるため、WindowsのUIIDを保持する必要があります。

UIのカスタマイズがWindowsに追加される場合でも、ユーザーが変更できる要素の数とユーザーが選択できる値のセットの両方に制限が必要であることはわかります。 そうしないと、既存のUIに悪影響を及ぼし、設計チームが望むWindowsの外観から大きく外れるリスクがあります。

私はこれについてある種の異なる見方をしています。
スレッドの前半で、Fabric UI（Web）とWindows（UWP）のスタイルを近づけることについての議論を見ましたが、これは少し心配です。

ここにいくつかのコンテキストがあります。私は何年もの間MicrosoftEdgeのユーザーであり、それについての私のお気に入りの1つは、そのUWPに触発されたルックアンドフィールでした。 Edge Insiderが公開されたとき、前任者のUWPスタイルの代わりに変更されたChromeとWebUIデザインを使用しているのを見て非常に失望しました。 示されている丸い角はごくわずかですが、問題がないほど、このスレッドは私に同じ失望感を与えています。 私は、Windowsが独自の（そして優れた）ルックアンドフィールを失い、不適切に設計された「Web標準」と一致することを支持することを望んでいません。 実際、Fluent UWPデザインの側面がFabricに移行することを望んでいます！

Edgeの計画は、最終的にAcrylicを復活させ、UIをWindows / FluentDesignスタイルに移行することだと思います。

しかし、Windowsはまた、うまくいけば格差を埋めるために少し前進しています。

OSに設定を設定して、丸められたコントロールと丸められていないコントロールのどちらかを選択することは不可能ではありません。すべてのアプリに設定を課すことは不可能であり、XP時代のビジュアルスタイルとはまったく異なる方法で機能します。

また、WinUI 3.0は、アプリプラットフォームとコントロールをOSから分離することを目的としているため、それらをさらに結合することは適切な決定ではない可能性があります。

もちろん、アプリ開発者として、コントロールのCornerRadius値を0に設定して、2乗されたコントロールを元に戻すオプションがあります。

私は小さな丸い角のこのプッシュをサポートしますが、私は現在の垂直ハンドルスライダーコントロールを円ハンドルスライダーコントロールよりも好みます。 縦型のハンドルはより正確に感じられ、一目でどこにあるかがわかりやすくなります。 少なくともそれは私がそれを見る方法です。 良い仕事を続けてください！

MediaTransportスクラブバーサムが輪郭で丸いのに、提案された新しいスライダーサムが円で塗りつぶされている理由はありますか？

丸い親指は、他のどのコントロールにも合わない厄介なトローチ/ピルの形よりもはるかに楽しいと思います。

覚えているかどうかはわかりませんが、人々を丸みを帯びた角に並べて表示することでさえ、当時の多くのWindowsファンにとって大きな問題であり、それはほんの小さな変更でした。 私にとって、どこでも丸みを帯びているということは、メトロデザイン言語と流暢なデザインの導入以来、Windowsが独特の外観を失うことを意味します。 デザイン言語は常に私にとって大きな鍵であり、uwp開発を私にとって魅力的なものにしました。 それが進んで一般的になるのを見るのは本当に悲しいでしょう。

私が行ったTextBoxとNumberBoxの設計概念に加えて、ComboBoxとEditableComboBoxのいくつかを次に示します。

良くやった！
フライアウトメニューについていくつか提案があります。 メニューの境界を示す影があるので、本当に境界線が必要ですか？ また、IMOの選択ハイライトは、ギャップを残すことなく、フライアウトサーフェスの幅全体をカバーできます。

焦点の合っていない境界線が薄くなっていることに感謝します。フォーカスを表示すると、キーボードを使用してUIをタブで移動しているときに、どの要素に焦点が合っているかが簡単にわかります（実際には、上記よりも少し強くしたいと思います）。

良くやった！
フライアウトメニューについていくつか提案があります。 メニューの境界を示す影があるので、本当に境界線が必要ですか？ また、IMOの選択ハイライトは、ギャップを残すことなく、フライアウトサーフェスの幅全体をカバーできます。

選択のハイライトは幅全体をカバーしますが、フライアウトに明るい内側の境界線を配置しました。これにより、アクリル効果と影とともに表面から浮き上がるのに役立ちます。ただし、内側の境界線が強すぎると、より微妙になります。 -それは完全に最終的な設計提案というよりもアイデアです。

@mdtauk

OSに設定を設定して、丸められたコントロールと丸められていないコントロールのどちらかを選択することは不可能ではありません。すべてのアプリに設定を課すことは不可能であり、XP時代のビジュアルスタイルとはまったく異なる方法で機能します。

だから私はそれを開発者にとってオプションにすることを言ったの

また、WinUI 3.0は、アプリプラットフォームとコントロールをOSから分離することを目的としているため、それらをさらに結合することは適切な決定ではない可能性があります。

上で述べたように、私はそれをアクセントカラー（ユーザーが設定で設定できる）が今日どのように扱われるかに似ていると思います。 リソースコントロールがコーナー半径をバインドできるため、公開します。これにより、コーナー半径の変更がアプリに反映され、開発者が追加の作業を行う必要がなくなります。

redditからのフィードバックをユーザーの観点からここに残しておくだけです。 他のみんなと同じように（redditで）、OS全体の一貫性にはまだ多くの愛が必要です。」

MediaTransportスクラブバーサムが輪郭で丸いのに、提案された新しいスライダーサムが円で塗りつぶされている理由はありますか？

@mdtauk 、実際のところ、それは私たちが見ているものですが、それは私たちが変更を加えるという意味ではないので、私は期待を設定していません...

フライアウトメニューについていくつか提案があります。 メニューの境界を示す影があるので、本当に境界線が必要ですか？ また、IMOの選択ハイライトは、ギャップを残すことなく、フライアウトサーフェスの幅全体をカバーできます。

@quantumfrost 、はい、実際のところ、そうです。 影は賢い。 そのため、システムが低電力モードにある場合、またはシャドウをオフにするその他の状況にある場合、境界線が機能します。 境界線は微妙にデザインされています。 いくつかの異なるオプションを評価しましたが、これが最も堅牢なものです。

@ nepxune 、@ mdtauk
ご意見ありがとうございます。
上記のいくつかの点に答えさせてください。

ユーザーが選択できるものを丸めるためのユーザー設定を提供するオプションは興味深いものです。 ただし、Windowsシステム全体で検討しなければならない他の重要な機能に対するこのフィードバックとも関係があります。

アプリケーション開発者として、お客様に適切なことを優先して実行する必要性を皆さんが強く認識していることを願っています。 Windowsの場合、顧客はOSを使用するユーザーです。 もちろん、このOSでアプリを作成する開発者も重要な顧客であり、コーナー半径の切り替えを容易にすることで、この変更によってもたらされたであろう主要な問題に対処できると思います。

OSをご利用のお客様からは、Windowsが威圧的すぎるとのことでした。 WindowsチームとOfficeチームの両方がユーザー調査を行い、丸みを帯びた角のように微妙でも、製品を親しみやすく親しみやすいものにすることに違いがあると（独立して）結論付けました。

そのため、GitHubや他のフォーラムの多くの人が、iOSとAndroidをフォローしていると言っていることを知っていますが、そうではありません。 私たちは、ユーザーを理解することからこの決定に到達しています。 はい、彼らが丸みを帯びた角を使用しているという事実は親しみやすさの側面を追加しますが、私たちは業界が行っていることを盲目的に追跡していません。

私はこれについてある種の異なる見方をしています。
スレッドの前半で、Fabric UI（Web）とWindows（UWP）のスタイルを近づけることについての議論を見ましたが、これは少し心配です。

ここにいくつかのコンテキストがあります。私は何年もの間MicrosoftEdgeのユーザーであり、それについての私のお気に入りの1つは、そのUWPに触発されたルックアンドフィールでした。 Edge Insiderが公開されたとき、前任者のUWPスタイルの代わりに変更されたChromeとWebUIデザインを使用しているのを見て非常に失望しました。 示されている丸い角はごくわずかですが、問題がないほど、このスレッドは私に同じ失望感を与えています。 私は、Windowsが独自の（そして優れた）ルックアンドフィールを失い、不適切に設計された「Web標準」と一致することを支持することを望んでいません。 実際、Fluent UWPデザインの側面がFabricに移行することを望んでいます！

@ 19lmyers
Windowsが独自の（そしてさらに優れた）外観を失うことについてのあなたの心配についてのフィードバックをありがとう。 上記のコメントで述べたように、ユーザーはWindowsに慣れていないため、Windowsの違いが大きすぎることを必ずしも評価していません。したがって、これはバランスをとる行為です。

フルーエントデザインシステムでは、全社の設計チームが多くの違いについて話し合い、これまでに導入された不要な違いを排除しようとしています。 上記のiOSとAndroidについてのコメントと同じように、私たちが提案しているデザインは、Fabricをコピーしているためではなく、Windowsデザイナーが独自のUIシステムを再評価してそれらに到達しました。 興味深いことに、それらはしばしば同様のデザインになります...とはいえ、Windowsをユニークに保つことに対する多くの人々の熱意に本当に感謝しています。

私たちのレポ、@ zag2meへようこそ！ ここでのディスカッションにご参加いただき、ありがとうございます。 私は同意し、あなたにとって重要な問題に注意を引くのに適切な場所です！ 機能リクエストフォームはこちらにあります： https ：

@chigy

ユーザーが選択できるものを丸めるためのユーザー設定を提供するオプションは興味深いものです。 ただし、Windowsシステム全体で検討しなければならない他の重要な機能に対するこのフィードバックとも関係があります。

OSをご利用のお客様からは、Windowsが威圧的すぎるとのことでした。 WindowsチームとOfficeチームの両方がユーザー調査を行い、丸みを帯びた角のように微妙でも、製品を親しみやすく親しみやすいものにすることに違いがあると（独立して）結論付けました。

私たちは、ユーザーを理解することからこの決定に到達しています。 はい、彼らが丸みを帯びた角を使用しているという事実は親しみやすさの側面を追加しますが、私たちは業界が行っていることを盲目的に追跡していません。

Windowsが独自の（そしてさらに優れた）外観を失うことについてのあなたの心配についてのフィードバックをありがとう。 上記のコメントで述べたように、ユーザーはWindowsに慣れていないため、Windowsの違いが大きすぎることを必ずしも評価していません。したがって、これはバランスをとる行為です。

そして、これが私が抱えている問題です。あなたは「Windowsユーザー」について言及していますが、どちらかといえば、このスレッドと他のリンクされたredditスレッドは、「Windowsユーザー」の同種のグループがないことを示しています。 結局のところ、企業は顧客の大多数が望んでいる方向にいつでも従うことができますが、それでも問題が残ります。 比率がかなり小さい場合（そして各数の後ろに膨大な絶対数のユーザーがいる場合）はどうなりますか？ ここでのフィードバックに基づくと、redditやその他の場所では、UIの過半数が圧倒的に多いとは感じていません。

これは、私たちの何人かが浮かんでいる提案につながります：

あなたが正しく言うように、与えられたカスタマイズオプションは注意深く測定されるべきですが、カスタマイズそれ自体はオプションとして単に破棄されるべきではありません。 あなたが言ったように、そしてこの時点で私は繰り返し始めていますが、提案されたコーナー半径の変更は小さな変更であるため、UIに対するユーザーの選択による影響は無視できるか、まったく存在しないはずです。 私や他の人も、コーナー半径の0〜2の範囲の値のセットなど、この例の制限を指摘しました。これにより、ユーザーは「WindowsUI」を壊すような方法でWindowsをカスタマイズできないようになります。あなたのチームが作りたいアイデンティティ」。

簡単に言えば、これらの設計変更に加えて慎重に測定されたカスタマイズオプションは、Windowsユーザー間のさまざまなUI設定に対処するための優れた方法のようのに大いに役立ちます。 。

@chigy
ほとんどの人は、2pxが適切な半径になることに同意します。 残りの部分にそれをオフにするオプションを与えることは良い理想です。

ほとんどのユーザーはWindowsがUIの最先端にあることを望んでいますが、他のレガシーユーザーは変更したくないです。

少数の変更を犠牲にするのではなく、オフにするオプションを提供するだけです。

@shaheedmalik
ここには「レガシー」ユーザーは存在せず、「ほとんどのユーザーが[角の丸い]を望んでいる」とか、現在のWindowsの外観が「最先端」ではないこともわかりません。

UIは非常に主観的ですが、それは、「レガシー」、「変更したくない」など、さまざまな意見を単に理解できるという意味ではありません。

「過去から目覚めたくないユーザー」からの意見として他のユーザーの発言を捨てて、今までのように情熱的でありながら敬意を持って議論していきましょう。

@ Felix-Dev Legacyユーザーは、チャンスがあればWindows 7にとどまっていたユーザー、Windows 8で行われた変更に抵抗したユーザー、今後のOSUIの変更に抵抗したユーザーです。

AppleとGoogleはWindows8.1から機能をコピーして実装し、ユーザーは最先端と見なされていたため、これらのプラットフォームにジャンプしました。 その間、マイクロソフトはレガシーユーザーの話を聞いていましたが、声が小さいために縮小しました。

この特定のケースでは、大多数がリンクされたように角を丸くしたい場合（https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/）

問題は、私はレガシーユーザーではないのですが、現在の丸みを帯びた角がその正確なカテゴリにプッシュされる（そして境界線の厚みが薄くなる可能性がある）ことを好まないすべての人を投げたように見えました。 また、私の投稿に対するあなたの反対票も得ていません。

大多数のケースについて：私はこのトピックに関するMSによる設計調査を知りませんでした。また、このプッシュの詳細が最初にインターネットに表示された1か月前の多くのユーザーの反応に基づいて、多くのユーザーも気づいていませんでした（おそらく尋ねられていなかったでしょう）。 あなたは、このチェックした場合のredditポスト（ところで、あなたがこれまでに上記のリンク先のredditスレッドなど多くのコメントとして3回を持っている）あなたは私たちが知っていることから、画像が正確に明確ではないことに気づくでしょう。 私は「この立場は明らかに過半数を占めている」と主張する立場にはなく、将来もそうすることは控えます。

私があなたの投稿について間違えた場合は、お詫びしますが、私が読んだ方法から、この変更に反対する声は明らかに否定され、「変更を望まないレガシーユーザーの声」であると宣言しました"。 それは私には無礼であり、他のすべての人はこの議論に彼らの声を加えました。

@ Felix-Devこれらの賛成/反対の投票と返信に個人的な意見を読もうとしないでください。

簡単な答えは、これらの変更は気まぐれで行われたり、他のプラットフォームUIスタイルをコピーしたりするためではなく、ユーザーと開発者の協議、フィードバック、および表明された意志の結果であるということです。

変更を加える必要があるかどうかではなく、どのように行うべきかについては、議論を建設的に保つように努める必要があります。

元の投稿の角が丸すぎるので、人々は角が丸いのを嫌っていました。
この新しい投稿は、この更新されたGitHubプロポーザルにリンクしています。 新しいフィードバックは、更新された提案の応答を反映しています。 さらに、1か月前の元の投稿がリンクされ、元の提案から改訂された提案への変更がユーザーに表示されました。

私は同意します、私たちは提案に戻り、これらの最後の投稿を忘れるべきです。

この時点で、これらの変更が行われることはかなり明らかだと思います。私がやろうとしているのは、慎重に測定されたカスタマイズのケースがあることを@chigyに納得さいつか役立つと思うかもしれません。現在のUIの変更のように。 @shaheedmalikを含め、私や他の人が言ったように、ある種のコーナー半径のカスタマイズを追加することは、努力するのに良い理想かもしれません。

現在、開発者がすべてのコントロールに独自のCornerRadiusを簡単に設定できるようにする提案があります（＃684）。これにより、チームはデフォルトでCornerRadiiをコントロールに追加することもできます。

OSレベルでそれを行うことは複雑な作業であり、研究はそれを実装するために必要なエンジニアリングの時間と労力を完全に保証するものではありません。

しかし、あなたは@ Felix-Devの見解を明確にしました。新しいコントロールが大多数のWindowsユーザーの手に渡った後、受け取ったフィードバックは、将来このアイデアが探求されることにつながる可能性があります。

1pxの行であることを確認したので、丸めから「AppBarSeparator」を削除するように仕様を更新しました。

1pxの行であることを確認したので、丸めから「AppBarSeparator」を削除するように仕様を更新しました。

@chigy 100％のスケーリングでは1 epxになりますが、200％、300％、400％のスケーリングでは、これには注意が必要な場合があります。

長方形ではなく実際に線である場合-おそらくStrokeStartLineCapとStrokeEndLineCapをPenLineCap.Roundに設定し

@mdtauk

OSレベルでそれを行うことは複雑な作業であり、研究はそれを実装するために必要なエンジニアリングの時間と労力を完全に保証するものではありません。

この提案は、CornerRadiusプロパティをコントロールに追加して、すでにほとんどの作業を行っているようです。 残っているのは、これらのコントロールが実際のコーナー半径にバインドできるリソースSystemCornerRadiusの作成だけです（今日、SystemAccentColorリソースを使用して、ユーザーが設定アプリで設定したアクセントカラーでUIの要素に色を付ける方法と同様です。

そのようなリソースを作成し、設定アプリを介して更新可能にするのにどれだけの作業が必要かについては、MSがコメントする必要があります。 しかし、この提案がとにかくすでに行っている作業と、AccentColorリソースを公開するという形での以前の作業を考えると、あなたが言うほど厳しいものになるかどうかはわかりません。 OSレベルは、文字通り、読み取りと書き込みが可能なコーナー半径値のみを提供し、今日のアクセントカラーリソースにすでに配置されているのと同じシステムを使用します。

@mdtauk

OSレベルでそれを行うことは複雑な作業であり、研究はそれを実装するために必要なエンジニアリングの時間と労力を完全に保証するものではありません。

この提案は、CornerRadiusプロパティをコントロールに追加して、すでにほとんどの作業を行っているようです。 残っているのは、これらのコントロールが実際のコーナー半径にバインドできるリソースSystemCornerRadiusの作成だけです（今日、SystemAccentColorリソースを使用して、ユーザーが設定アプリで設定したアクセントカラーでUIの要素に色を付ける方法と同様です。

そのようなリソースを作成し、設定アプリを介して更新可能にするのにどれだけの作業が必要かについては、MSがコメントする必要があります。 しかし、この提案がとにかくすでに行っている作業と、AccentColorリソースを公開するという形での以前の作業を考えると、あなたが言うほど厳しいものになるかどうかはわかりません。 OSレベルは、文字通り、読み取りと書き込みが可能なコーナー半径値のみを提供し、今日のアクセントカラーリソースにすでに配置されているのと同じシステムを使用します。

スライダーですか、それともトグルですか？

[X]コントロールの角が丸い

ところで設定するコーナー半径の値は1つだけではありません。 一部の要素では、片側だけが丸みを帯びているか、上部の角だけが丸みを帯びています。 フライアウトとポップオーバーコントロールは4epxの半径を取得しますが、他のコントロールは2epxしかありません。

この設定はOSで変更されるため、多くの変数を設定することになります。 では、テストはどうですか？ また、期待があります。 ユーザーは、ユーザーの好みを無視することにしたアプリにどのように反応しますか？
どのコントロールが丸められ、どのコントロールが丸められないかをユーザーとどのように通信しますか？ 一部のコントロールには、内側の境界線または外側の境界線要素があります。 これらは、シェイプのエッジを適切にハグするために、CornerRadius値を調整する必要があります。

結局、これは大騒ぎせずに歓迎される変更である可能性があるため、OSにさらに別のオプションを追加することは過剰反応と見なされる可能性があります。

@mdtauk @chigy
確かにある程度の計画が必要ですが、チームは明らかに、開発者が2乗コントロールを非常に簡単に作成できるようにしたいと考えています。 そのため、コーナー半径値の設定の代わりに、単純なUserRoundedCornersブールスイッチで問題ありません。 実際、値を設定するというアイデアは、さらに多くのオプションを追加することでしたが、この移動に同意しないユーザーは、常にコントロールの外観を元に戻すオプションを提供するだけでした。 だから、それはまったく問題にはなりません。

「まだ別のオプション」の部分について：ユーザーが利用できるオプションが多すぎるようです。これはまったく別の問題であり、この単純なスイッチを追加しないための定義ポイントとして使用しないでください。

Windowsとデザインチームは、ユーザーを除外するのではなく含める方法について毎日（Twitterで）話し合っています。 これは、MSがユーザーの意見の多様性を尊重するための単一のオプションを追加するのが比較的簡単だと私が感じるチャンスです。

ユーザーは、ユーザーの好みを無視することにしたアプリにどのように反応しますか？

重要なWindowsアプリ/ UI要素（設定アプリ、セキュリティアプリ、クリップボード、タスクバーネットワークフライアウトの接続/切断ボタンなど）がそれを尊重する限り、これも問題ではないと思います。 サードパーティのアプリは自由に好きなスタイルを使用できます。設定アプリに、サードパーティのアプリがこのユーザー設定に従うことが保証されていないという簡単なメモがあれば問題ありません。

@mdtauk @chigy
@ Felix-Devはこれにぴったりだと思います。単純なトグルを備えたブールスイッチは、ユーザーレベルでカスタマイズする方法になる可能性があります。ただし、ユーザーレベルでこれをカスタマイズするためのスライダーは、物事を複雑にしすぎると思います。 3つの固定プリセット位置を持つスライダーの場合、状況が変わる可能性があります。

3つの固定オプションを備えたスライダーを使用すると、最初に提案されたもののように、より大幅なコーナー半径の変更を行うことができる追加の設定が可能になります。

シャープ-今のようなシャープなコーナー
中央のオプション-新しい小さい半径
丸みを帯びた-最初に提案された半径の変更またはさらに丸みを帯びたもの

このオプションは、すべてのグループを満足させる可能性があります。さらに、これはWindowsの新しい「テーマ」機能として実際に渡すことができるほど大幅な変更ですが、基本的には、これは開発者にとっては新しいものとしてブランド化することでより多くの変更になります。トグルの実装または3つのプリセットスライダーのいずれかを備えた「テーマ設定」機能は、消費者向けの新機能として渡すこともできます。

ユーザーの好みを無視することを決定したアプリに対して、ユーザーはどのように反応しますか？

ユーザーは、アクセントカラーが利用できない場合、現在のようにそれを簡単に見ることができると思います。サードパーティのアプリは自由にやりたいことができるはずですが、@ Felix-DevのようにWindowsアプリ/ UI要素は間違いなく必要だと言いましたユーザーの変数を尊重します。

サードパーティのアプリは設定を尊重しないという設定にメモを入れる必要はないと思います。アクセントカラーのセクションに免責事項を入れる必要はなかったので、これについても同じだと思います。良い。

OSレベルでそれを行うことは複雑な作業であり、研究はそれを実装するために必要なエンジニアリングの時間と労力を完全に保証するものではありません。

しかし、あなたは@ Felix-Devの見解を明確にしました。新しいコントロールが大多数のWindowsユーザーの手に渡った後、受け取ったフィードバックは、将来このアイデアが探求されることにつながる可能性があります。

ここで何か指摘しなければならないような気がします。 どちらの方法でも提案された変更については強く感じていませんが（矛盾や変更のために毎日異なるエコシステムであまりにも多くのUIスタイルを使用する必要があります）、この考え方は適切ではないと感じています豊かなユーザーフレンドリーな体験を作成します。

80％完了し、次のリリースで100％になる場合とならない場合がある機能をリリースしないでください。
おそらく起こることは、丸みを帯びた境界線と丸みを帯びていない境界線の両方について、開発者が自分のアプリをテストおよび開発するために時間を費やすことはないということです。 そして、なぜ彼らはそうするでしょう。 システムは現在、丸みを帯びたものを使用していますが、なぜ誰かが自分のアプリをOSと少し異なって見せたいのですか（そうでなければ、とにかく完全なテーマを選択します）
システム全体の切り替えがあった場合、それを実装するインセンティブがあります。
ただし、この方法で作業を行っている場合、最初から実装する必要があると判断するアプリがないため、切り替えの必要はありません。

元のトピックについて：
コンボボックスを除いて、2pxの境界線は見栄えが良いと思います。
最後の要素のハイライトは、その下に白い境界線を残してはなりません（または、少なくとも左右を超えないようにします。もちろん、これは、下部のハイライトの角も丸くする必要があることを意味します）。ボックスとフライアウトの間の拡張状態。 私はそれが彼らの間でこの奇妙なばらばらの外観を与えるように感じます。
フライアウトを両側で2px小さくし、上部に丸い角がないようにする方がよいかもしれません。 このように、それは一枚の紙がディスペンサーから引き出されているように見えます。 （私が何を意味するのか理解していただければ幸いです：D残念ながら、現在、スケッチするためのツールはありません）

元のトピックについて：
コンボボックスを除いて、2pxの境界線は見栄えが良いと思います。
最後の要素のハイライトは、その下に白い境界線を残してはなりません（または、少なくとも左右を超えないようにします。もちろん、これは、下部のハイライトの角も丸くする必要があることを意味します）。ボックスとフライアウトの間の拡張状態。 私はそれが彼らの間でこの奇妙なばらばらの外観を与えるように感じます。
フライアウトを両側で2px小さくし、上部に丸い角がないようにする方がよいかもしれません。 このように、それは一枚の紙がディスペンサーから引き出されているように見えます。 （私が何を意味するのか理解していただければ幸いです：D残念ながら、現在、スケッチするためのツールはありません）

私はあなたが何を説明しているのか知っています、そして私は私のデザインのモックアップのためにそれを考慮しました。 それに関する問題は、ComboBoxが独自のフライアウトテンプレートを取得することを意味します。これにより、コンテキストメニュー、メニューフライアウト、プレフィックス、サフィックス、オートコンプリートフライアウトなどとは異なります。

それが私が意味したことです（ボックス自体が下の角を丸く保つことができることを除いて）
はい、フライアウトは異なりますが、本質的に2種類のフライアウトがあります。
何かに付いているものと付いていないもの。 それらが今異なっていなければならないということは、丸みを帯びた角を作るためのコストです;）
さらに、コーナー半径がスタイリング可能になる場合は、親コントロールで設定することはできません。

私のXAMLは少し錆びていますが、次のようなコンボボックステンプレートです。

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

さらに、コーナー半径がスタイリング可能になる場合は、親コントロールで設定することはできません。

私のXAMLは少し錆びていますが、次のようなコンボボックステンプレートです。

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

これは、スタイルをオーバーライドする方法と似ていますが、テンプレートで使用するには、方向ごとに個別のスタイルが必要になります。

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

オリエンテーション：

• 下
• BottomEdgeAlignedLeft
• BottomEdgeAlignedRight
• 満杯
• 左
• LeftEdgeAlignedBottom
• LeftEdgeAlignedTop
• 右
• RightEdgeAlignedBottom
• RightEdgeAlignedTop
• 上
• TopEdgeAlignedLeft
• TopEdgeAlignedRight

Flyoutは、ComboBoxコントロール内に埋め込まれています。 したがって、コントロールには、ComboBoxのみに影響し、フライアウトは含まれず、ThemeResourceがオーバーライドされるCornerRadiusプロパティがあります。

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

FlyoutがComboBox（およびその他のコントロール）に配置およびアタッチされているときに、FlyoutのCornerRadiusプロパティを調整した後、目的の結果を得るには、 FlyoutPlacementMode列挙型にTopEdgeAlignedおよびBottomEdgeAlignedを追加する必要がある場合があります。

_（更新された画像）_

また、フライアウトのスタイリングを800％詳しく見ていきました。 2つの境界線により、シャドウの有無にかかわらず、ライトテーマとダークテーマの両方でフライアウトが高く見えるようになります。

とても良さそうです。
もちろん、アタッチされた外観は、アタッチしたアイテムがフライアウトよりも小さい場合は少し奇妙に見えますが、それは間違いなく個々のアプリが決定するものです。
下の行のアイテムのフォーカスハイライトは、おそらく下の丸みを帯びてはいけません（上の行は上の行用ではないため）が、それはおそらく意図的なものではありません。

ちなみに、この「アタッチされた外観」がMacOのトップメニューバーの動作方法であることに気付いたので、この外観は異常に珍しいことではないようです;）

とても良さそうです。
もちろん、アタッチされた外観は、アタッチしたアイテムがフライアウトよりも小さい場合は少し奇妙に見えますが、それは間違いなく個々のアプリが決定するものです。
下の行のアイテムのフォーカスハイライトは、おそらく下の丸みを帯びてはいけません（上の行は上の行用ではないため）が、それはおそらく意図的なものではありません。

ちなみに、この「アタッチされた外観」がMacOのトップメニューバーの動作方法であることに気付いたので、この外観は異常に珍しいことではないようです;）

丸めを忘れていたので、画像を更新して修正し、ズームされた例でもう少し詳細を追加しました-ああ、ホバー状態を含めました

真ん中のアイテムが丸みを帯びたハイライトを持つことを好むかどうかはわかりません。なぜなら、一方ではより一貫性があり、他方ではそれらの少し攻撃的な外観を残すからです（OK今私はただ物を作っているだけです:)）シャープな白ハイライトされた要素と境界線の間のスペース。
しかし、それは私が実際のデザイナーに決定を任せるものです：D

真ん中のアイテムが丸みを帯びたハイライトを持つことを好むかどうかはわかりません。なぜなら、一方ではより一貫性があり、他方ではそれらの少し攻撃的な外観を残すからです（OK今私はただ物を作っているだけです:)）シャープな白ハイライトされた要素と境界線の間のスペース。
しかし、それは私が実際のデザイナーに決定を任せるものです：D

私も同意します。私もそれについて2つの考えを持っています。 ストレートエッジが好きだと思いますが、フライアウトを呼び出すコントロールは丸められ、これらはコントロール内のコントロールであるため、丸める必要があります。

また、一部のコンテキストメニューには、フライアウトの幅全体に及ばないコントロールが含まれているため、丸みを帯びた選択が機能します。

真ん中のアイテムが丸みを帯びたハイライトを持つことを好むかどうかはわかりません。なぜなら、一方ではより一貫性があり、他方ではそれらの少し攻撃的な外観を残すからです（OK今私はただ物を作っているだけです:)）シャープな白ハイライトされた要素と境界線の間のスペース。
しかし、それは私が実際のデザイナーに決定を任せるものです：D

私もそう感じた。 コンボリストがコンボボックスと同じサイズの場合は、原点でまっすぐに保つ必要があります。そうでない場合は、整列しない側が丸くなります。

@mdtauk @Qowy @shaheedmalikコンボボックスに固有の独自の問題を作成することは可能ですか？ このスレッドは一般的にコーナー半径に関するものであり、ここに見られるようにまったく新しい会話を簡単に生み出す可能性のある特定のケースではないため、一般的なアプローチに関する論点を覆い隠します。

これを誤解しないでください。ただし、多くのコントロールについてこのような特定の議論があると、このスレッドは簡単に一般的な焦点を失うことになります。

とても有難い！

PS：境界線以外の強調表示された要素について：要素の強調表示は間違いなく長方形である必要があります。 丸みを帯びた色にするのは変です。

私の意見ではおそらくここでは少数派ですが、共通のコントロールのコーナー半径を変更することは正直なところひどい考えです。 上記の@mdtaukのメニュー例を見て、それを現在のEdgeメニューと比較すると、少しうんざりします。 物事はようやくFluentデザインで解決され、すべてがようやく一貫性があり、本当に良さそうに見えます。 では、すべてをWebのように変更しましょう。 いいえ... WebをWebとし、Windows（および共通コントロール）はそのままにしておきます。 開発者が独自のアプリでサードパーティのコントロールを使用して丸みを帯びたコーナーを実装したい場合は、そうしてください。 しかし、今すぐデフォルトのルックアンドフィールを変更し始めるのは異端です。AppleをApple、GoogleをGoogle、WebをWebとします。 Y'allはMicrosoftであり続け、あなたのことをします-それは機能しているので、機能させてください。 私は、実際にはFluentデザインのMicrosoft Windows 10のルックアンドフィールが大好きで、アプリをApple、Google、WebではなくWindowsのように見せたいと思っています。 Chromeの見た目は我慢できません-EdgeはmacOSよりも光年良く、Windowsはフォームと機能がはるかに優れています。 そして、TBH、Windows 10Mobileを電話に戻します。 良い悲しみ、すぐに物事をあきらめるのをやめて、フルーエント・デザインを放っておいて、それをやらせてください。

@mdtauk

OSレベルでそれを行うことは複雑な作業であり、研究はそれを実装するために必要なエンジニアリングの時間と労力を完全に保証するものではありません。

この提案は、CornerRadiusプロパティをコントロールに追加して、すでにほとんどの作業を行っているようです。 残っているのは、これらのコントロールが実際のコーナー半径にバインドできるリソースSystemCornerRadiusの作成だけです（今日、SystemAccentColorリソースを使用して、ユーザーが設定アプリで設定したアクセントカラーでUIの要素に色を付ける方法と同様です。
そのようなリソースを作成し、設定アプリを介して更新可能にするのにどれだけの作業が必要かについては、MSがコメントする必要があります。 しかし、この提案がとにかくすでに行っている作業と、AccentColorリソースを公開するという形での以前の作業を考えると、あなたが言うほど厳しいものになるかどうかはわかりません。 OSレベルは、文字通り、読み取りと書き込みが可能なコーナー半径値のみを提供し、今日のアクセントカラーリソースにすでに配置されているのと同じシステムを使用します。

スライダーですか、それともトグルですか？
[X]コントロールの角が丸い
ところで設定するコーナー半径の値は1つだけではありません。 一部の要素では、片側だけが丸みを帯びているか、上部の角だけが丸みを帯びています。 フライアウトとポップオーバーコントロールは4epxの半径を取得しますが、他のコントロールは2epxしかありません。
この設定はOSで変更されるため、多くの変数を設定することになります。 では、テストはどうですか？ また、期待があります。 ユーザーは、ユーザーの好みを無視することにしたアプリにどのように反応しますか？
どのコントロールが丸められ、どのコントロールが丸められないかをユーザーとどのように通信しますか？ 一部のコントロールには、内側の境界線または外側の境界線要素があります。 これらは、シェイプのエッジを適切にハグするために、CornerRadius値を調整する必要があります。
結局、これは大騒ぎせずに歓迎される変更である可能性があるため、OSにさらに別のオプションを追加することは過剰反応と見なされる可能性があります。

ここに2epxのコーナー半径があり、そこに4epxのコーナー半径があり、2または4が正しく見えないために別の場所で異なるのは、ひどいUXです。 CommonControlsをそのままにしておきます-JobDone ...何か他のものを素晴らしいものにすることに移ります。

@chigy
そこで、数日前に開始したredditスレッドの応答からカウントしました。これは、次の

プロコーナー半径を表す意見（現在のUIとは対照的）：18
意見は、プロカレントUI（およびコントラコーナー半径）を表現しました：12（redditポスターとして私を含めると+1、プロコーナー半径カウントに@shaheedmalikも含まれます）

残り：

• MSにUIの選択肢を提供するように依頼する
• 両方で大丈夫
• 提案について意見を述べなかった
• Windowsシステムの不整合（つまり、Win32プログラムとUWPアプリ）に対する一般的な不満を表明しました

特に最後のグループ（欲求不満）は、スレッドに参加した人々のかなりの部分でした。

結果を要約すると、丸い角（提案）と四角い角（現在のUI）の両方にかなりの派閥があることがわかります。 それに加えて、システム内でこれら2つのスタイルを切り替えられるようにしたいという希望を表明した人々のグループ。
ただし、角が丸いかどうかは別として、最も与えられた応答（1マイル）は、最終的にWindowsシステム全体に一貫性をもたらすことです。 WinUI 3.0とMSチームは、すべての異なるWindowsシステムコンポーネントとUWPアプリを単一のUIデザイン言語にまとめるための作業を削減します。

@chigy
ユーザーを「除外」するのではなく「含める」というMicrosoftDesign Teamのすべての話を踏まえると、このスレッドと上記のredditスレッドは、提案された丸みを帯びたコーナーを切り替えるためのシンプルなオプションをUIに提供する正当な理由があることを示していると思います。 UIと現在のUI（鋭い角）。

@ Felix-Dev技術的には、Flyoutコントロールに関する投稿でしたが、ComboBoxはFlyoutコンポーネントを備えたコントロールの1つにすぎません。

たまたま、すべての状況で四隅を丸めることは理にかなっていると思います。 そして、チームはフライアウトとダイアログが4 epxコーナーを使用し、他のコントロールが2epxを使用することを決定しました。

@mdtauk 、
私が言ったように、これを誤解しないでください。 このスレッドで特定のコントロールUIを指摘するのはまったく問題ないと思います（ツリービューの例でチェックボックスのコーナー半径の奇妙な外観のコーナーの厚さについて尋ねた場合など）。
ただ、特定のUI要素（flyouts / comboboxes / ...など）に関して複数の投稿にまたがる会話が発生している場合は、この特定の問題について個別の問題を作成するのが最善だと思います。 そして、あなたが見たように、フライアウトについてのあなたの投稿はすぐにコンボボックスに関する議論につながりました。 誰かがフォーカスシャドウがどのように見えるべきかについて会話を始め、スレッドを一般に戻すのが難しいところから始まる全体的な「混乱」（複数の特定のUI要素が近接して議論されているように）があると想像してみてください提案とそれに対処する方法。

@mdtauk 、
私が言ったように、これを誤解しないでください。 このスレッドで特定のコントロールUIを指摘するのはまったく問題ないと思います（ツリービューの例でチェックボックスのコーナー半径の奇妙な外観のコーナーの厚さについて尋ねた場合など）。
ただ、特定のUI要素（flyouts / comboboxes / ...など）に関して複数の投稿にまたがる会話が発生している場合は、この特定の問題について個別の問題を作成するのが最善だと思います。 誰かがフォーカスシャドウがどのように見えるべきかについて会話を始めると想像してみてください。スレッドを一般的な提案に戻すのが難しいところから始めて、それをどのように処理するかが混乱します。

フライアウトのためだけに別の問題を作成するつもりはありませんが、そのコントロールのコーナー半径について具体的に話し合っていました。

更新されたすべてのコントロールデザインを含む更新されたデザインツールキットを見ることができるようになると、 @ chigyが何らかの

投稿を数える場合は、賛成票も数える必要があります。

@shaheedmalik
これらの賛成票がこれらのUIタイプについてどのように感じているか正確にはわからないため、アップカウントを明示的にカウントしません（たとえば、どちらの選択でも問題ない可能性がありますが、現在のUIと同じように丸められたコーダーの提案が好きです）。 さらに重要なことに、UIの不整合を指摘するなど、投稿の特定の部分が原因で投稿に賛成した可能性があります。 したがって、著者の声明でどちらかのUIの承認を明確に確認できる実際の投稿のみをカウントしました。

FWIW、「2pxがスイートスポットのようです。」 54ポイントで最も多くの賛成票を獲得しました。

「エンドユーザーのテーマサポート」を求める高評価の投稿（+ 21-4位）もありますが、これらの賛成票がすべてカスタマイズの呼びかけの部分なのか、作者が行方不明を批判する部分なのかはわかりません。システムの一貫性。

更新されたすべてのコントロールデザインを含む更新されたデザインツールキットを見ることができるようになると、 @ chigyが何らかの

尋ねていただきありがとうございます。 号の「重要事項」のデザインコンプにリンクしましたので、ぜひチェックしてみてください。

一般的に、ここでの会話は、WinUIで丸みを帯びた角を機能させる方法に焦点を当てて維持したいと思います。 私は人々がこの考えについて異なる意見を持っていることを知っています、あるいは丸い角が一般的に良い考えであるとしても。 ですから、これはマイクロソフトの別のチームから追い出されているWindowsの全体的な設計の方向性の一部であることに言及する価値があると感じました。 私たちは、WinUIをこの新しい設計の方向性で機能させ、開発者にとってより簡単にする方法を見つけようとしています。 Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません。 言い換えれば、丸みを帯びた角はすでに計画されているので、この機能を責任を持って実装することを確認するために、WinUIコミュニティに気づいて相談したいと思いました。 それが理にかなっていることを願っています。

Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません。 言い換えれば、丸みを帯びた角はすでに計画されているので、この機能を責任を持って実装することを確認するために、WinUIコミュニティに気づいて相談したいと思いました。

これは私たちの多くにとって大きな問題であるため、ここの多くの人々がその権威を持つ人々と話したいと思うのではないかと思います。

尋ねていただきありがとうございます。 号の「重要事項」のデザインコンプにリンクしましたので、ぜひチェックしてみてください。

一般的に、ここでの会話は、WinUIで丸みを帯びた角を機能させる方法に焦点を当てて維持したいと思います。 私は人々がこの考えについて異なる意見を持っていることを知っています、あるいは丸い角が一般的に良い考えであるとしても。 ですから、これはマイクロソフトの別のチームから追い出されているWindowsの全体的な設計の方向性の一部であることに言及する価値があると感じました。 私たちは、WinUIをこの新しい設計の方向性で機能させ、開発者にとってより簡単にする方法を見つけようとしています。 Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません。 言い換えれば、丸みを帯びた角はすでに計画されているので、この機能を責任を持って実装することを確認するために、WinUIコミュニティに気づいて相談したいと思いました。 それが理にかなっていることを願っています。

TextBoxの境界線の太さなど、まだ進行中のいくつかのことについての会話について言及されたので、それらのデザインは最終的なものではなく、「最初のアイデア」であると思いました。 （TextBox、Buttons、CheckBoxesなどに影響を与えることができることを望んでいたと思います）

私はこれに対する答えを知っていると思いますが、とにかく尋ねます-チームが決定したこれらのWindows UIデザインを共有する計画はありますか？

これらの変更はWindowsによって計画されていますか？Win32ビジュアルスタイルやシェルウィンドウのタイトルバーなどにも適用されます。その場合、WPFは、この新しいスタイルが適用されるバージョンのWindowsで実行するときに、デフォルトのコントロールも更新する必要があります。 （私はすでにそれが起こるべきだと提案しました＃699）

Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません。 言い換えれば、丸みを帯びた角はすでに計画されているので、この機能を責任を持って実装することを確認するために、WinUIコミュニティに気づいて相談したいと思いました。

これは私たちの多くにとって大きな問題であるため、ここの多くの人々がその権威を持つ人々と話したいと思うのではないかと思います。

これは、設計変更が公開されたときにフィードバックHubに表示されると思います。これは、Windowsチームに届く可能性が高いです。

TextBoxの境界線の太さなど、まだ進行中のいくつかのことについての会話について言及されたので、それらのデザインは最終的なものではなく、「最初のアイデア」であると思いました。 （TextBox、Buttons、CheckBoxesなどに影響を与えることができることを望んでいたと思います）

私はこれに対する答えを知っていると思いますが、とにかく尋ねます-チームが決定したこれらのWindows UIデザインを共有する計画はありますか？

@mdtauk
はい、そしてここで非常に透明にするために...現実には、この特定の問題の会話が遅くなるのが早ければ早いほど、私はそれに取り組むことができます... :)

@chigy会話の脱線と進行の遅れに貢献したことをお詫びします。 私はこれまで助けたかっただけで、WinUI3.0が可能な限り見栄えがするようにしました。

@chigy
今、混乱しています。 あなたはWindowsFluent Design Teamで働いている人で、WinUIは「[...] Windows自体を作成するために使用される高度に最適化されたネイティブUIプラットフォーム」と言われています（ここから引用、「WinUI3の利点」のセクション。これがWindows10 Design Languageに影響を与える場所ではない場合、それは何ですか？

私はあなたの返事についてどう感じるかわかりません。 あなたは基本的に私たちにフィードバックを求めていますが、とにかく提案に影響を与える機会があまりなかったことがわかりましたか？ この投稿に実際の権限を持つ人がいない場合、ここで行うのは基本的に熱風だけです。 マーティンのように、設計チームによって実装されることを期待して設計コンセプトを投稿している場合でも。 WinUIチーム自体が言ったように、「WinUI3.0以降はWindowsUIになる」ため、WinUIは、「Windows設計機関」が望む場所とは異なる方法でコントロールのスタイルを設定することはできません。

@chigy
私や他の人たちは、あなたのコメントのいくつかが示唆しているように、「Windowsユーザー」は同種のグループではないことを強調することに多くの時間、エネルギー、情熱を費やしてきました。 マーティン以外の声や、新しいUIの更新が気に入らないため、慎重に測定されたUIのカスタマイズを主張したいという声があることを示しました。

また、あなたはこの要求そのものを無視しているように感じます。 「Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません」とあなたは言います。 私や他の人たちは、最近このUIプッシュを捨てることを求めていませんでしたが、Twitterで「ユーザーを含む」という独自のデザイントークをフォローし、それらを除外しないようにしました。 私たちは、動きの逆転ではなく、オプションを求めました。
それでも、これまでのところ、「ユーザーが選択できるものを丸めるためのユーザー設定を提供するオプションは興味深いものです。しかし、他のフィードバックよりもこのフィードバックと関係があります。 Windowsシステム全体で検討しなければならない重要な機能。」 それが始まりだと思いますが、私たちは今どこにいますか？

あなたは、Windowsの設計に対する権限を持つ実際のチームに所属していないと言います。 それは、私たち全員がずっと間違った人に話しかけられてきたことを意味します！ チームのメンバーが実際にショットを呼んでいるのに話をしたことがなければ、なぜそんなに早く話せなかったのだろうか。

すべてのエネルギーが投資された後、私は今、私が最初から権威のある人と話したことがないことを知ってがっかりしています。 基本的にすべてのフィードバックと私の他の人が集めたもので、UIのカスタマイズを主張しても、基本的には何も起こりません（あなたは説得する必要のある人でさえないため）。

すみません、頭を包むことができません。 WindoiwsUIを駆動していると思われるリポジトリのWindowsFluent Design Teamのメンバーは、数日後、本当に重要な人とは話をしたことがないと言っています。

これが暴言として下がったら申し訳ありませんが、私はここで少しショックを受けています。 私がこの特定の議論（および情熱的な返信を書いた他の人）にどれだけ投資したかはわからないかもしれませんが、説明を求めたいと思います。

UIのカスタマイズに対する私たちの要求は、実際にはどこにあるのでしょうか。 このリポジトリは、Windows UIの議論にとってもはや本当に重要ですか？

私はそれを残しておきます：

" [WinUI 3.0] WindowsのネイティブUIプラットフォームWinUIは、Windows自体の作成に使用される高度に最適化されたネイティブUIプラットフォームであり、すべての開発者がWindowsにアクセスするために使用できるようになりました。

@ Felix-Dev自分のデザインが実際のデザインになると主張するのではなく、影響を与えたいと思っていました。 私は、Windows Vista / 7 / Zune / WindowsPhoneの時代からWindows愛好家であるデザイナーです。

@mdtauk
確かに、MSがあなたのアイデアを採用することに反対することは確かにありませんが、そうですか？ 😉結局のところ、あなたはそれらを確信しています！

あなたが強引であるときにそれが起こった場合は申し訳ありませんが（そして私に公平を期すためにあなたはあなたの提案がそのようにやってくることができるように言った）、しかし@chigyの返事は私にとってかなりショックでした。 あなたが理解することを願って！

WinUIチーム！= WindowsDevチーム。

Windows 10が現在のOSですが、WindowsLiteとWindowsCoreOSが将来の方向性です。

@chigyは明らかに、WindowsチームがOSシェルに対して何を計画しているのかを調べており、WinUI3.0がそこで家にいることを確認したいと考えています。 電卓、設定、タスクバーフライアウト、シェルなどのWindowsアプリは、おそらくすべてWinUI 3.0を使用するため、デザイン的に同じページに配置する必要があります。

MicrosoftのFluentDesignチームは、WinUI、Windows、Xbox、Office、Bing、Teams、Fabric、Fluent Webなどの他のMicrosoftチームが従うルール（色、フォントのスタイルとサイズ、素材など）を作成し、UIデザインを機能させます。

ここの構造を誤解してしまったら訂正されると思います。

私がこのリポジトリに貢献しているという私の考えは、FabricWebとWinUI3.0の間のギャップを埋めようとしていますが、Win8の時代から熟考してきた考えも含まれています。

これが私がそれをどのように理解したかであるため、明確化は確かに素晴らしいでしょう：

@chigyはDesignTeamのメンバーになります。

次に、Windowsを駆動し、Windows自体を作成するために使用されるプラットフォームとして公式に説明されているWinUI3.0があります。 したがって、Windows UIの設計に関する議論は、ここでくつろいでいます。
また、上記の説明に基づくと、Windows開発チームはWinUIを使用してアプリとシステムUIの両方を実現することを意味します。 それ以外の場合は、UI提案スレッドで、実際に重要な人とは話さないことを明示的に指摘する必要があります。提案は、実際には実際の実装に関するフィードバックのみであり、UIデザインに関するものではありません。

また、Windows Fluent DesignチームとWinUIチームが、ネイティブのWindows UIが設計および実現されているチームでなくても、@ chigyが、実際に重要な人と話をしたことがないことを通知しなかったという事実は

Windowsでは、角の丸みは「もの」ではないと結論付ける権限は実際にはありません。 言い換えれば、丸みを帯びた角はすでに計画されているので、この機能を責任を持って実装することを確認するために、WinUIコミュニティに気づいて相談したいと思いました。 それが理にかなっていることを願っています。

他の人が私たちの多くにとって大きな問題であると述べたように、これは私にとって大きな失望です。したがって、これを活用できない場合は、 @ chigyに丁寧に尋ねて

これは、数年前のWindows 10の開発中に、Squareのプロフィール写真をCircularの写真にする提案があったときに起こった談話と非常によく似ています。多くの人がこれを嫌い、フィードバックHubにアクセスしました。 フィードバックハブには複数の投稿があり、1000000以上の賛成票があり、これを行わないように求めています。

応答は本質的に、彼らの意見に関係なく変更が行われることを人々に告げるだけでした...

私はその投稿を、@ Felix-Devを軽蔑したり侮辱したりしないように言い換えます

@mdtauk
私の投稿はどこで侮辱されていますか？

私は誰にも名前を呼んでおらず、WinUIの悪い言葉を呼んで、この問題を侮辱的な言葉で説明しています。 私は個人的に誰かを攻撃していません。実際、私は何も攻撃していません。

@mdtauk
私の投稿はどこで侮辱されていますか？

私は誰にも名前を呼んでおらず、WinUIの悪い言葉を呼んで、この問題を侮辱的な言葉で説明しています。 私は個人的に誰かを攻撃していません。実際、私は何も攻撃していません。

@chigyは、WinUIコントロールの設計に取り組む責任者です。 彼の役割をWindowsまたはFluentチームの役割と間違えた場合は、彼の役割は重要ではないと言ったり、個人的なものにしたりしないでください。

@mdtauk
「ChigusaSansenは、XAML UIプラットフォームチームのプリンシパルプログラムマネージャーであり、Fluent Design Systemのコアメンバーの一部です」（出典：https：//mybuild.techcommunity.microsoft.com/speaker/545575？source = sessions）

彼女はまた、そのセッションでWindowsに関連するFDパートを開催しました。

そして、「実際に重要な人」の部分について。 私たちの場合、彼女は実際にWindows用に選択されたUI方向のショットを実際に呼び出しているチームにはいないと言ったので、私はそれを侮辱的とは見なしません。 私はミス・チグサ・サンセンを攻撃したり、彼女を嘲笑したり、彼女の名前を呼んだりしませんでした。 私は彼女が私たちに個人的に言ったことを簡単に述べました。

そして、「実際に重要な人」の部分について。 私たちの場合、彼女は実際に選択されたUI方向のショットを実際に呼び出しているチームにいないと言っているので、私はそれを侮辱的とは見なしません
ウィンドウズ。

まあそれは侮辱的だと思います。 特に、あなたが「誤解されている」のではなく、議論の目的を誤解しているように見えるので

@mdtauk
ここでは異なる波長を使用しているので、なぜそうなるのかを推測しようとしても意味がありません...

一般的なUIの移動についてこのディスカッションを開始したとき、Miss Chigusa SansenまたはWinUIチームの他のメンバーは、このスレッドはこのディスカッションに適した場所ではないと明確に述べていました。 代わりに、人々は熱心に議論を始め、賛成/反対を主張し、Microsoft / Windowsで-この議論の性質上-関連するUIの位置にいるだろう誰かと話していると考えて動きました。

千草も参加し、UIの方向性に影響を与えることを期待して自由にコントロール画像を追加し、MSの誰もがすることなく、ここが一般的なUIデザインについて議論する場所であるという感覚を追加しました。 私の苦情があり、あなたはその@chigyは、単に彼女がapparantlyでも呼び出すチームではないので、本当に、ここでその議論を有することを多くのポイントの存在しないことを私たちに伝えるためにそう時間がかかった、ということ見逃しているように見えます

それはあなたが言うように「誤解された」または「誤解された」ことについてではありませんが、そのような重要な情報が何日も私たちから守られていたということです。 千草三泉さんが以前にそう言っていたとしたら、この議論全体はすでに長い間進んでいた可能性があります。 ところで、これはあなたと彼女の両方が見たいものです。

@mdtauk
ここでは異なる波長を使用しているので、なぜそうなるのかを推測しようとしても意味がありません...

一般的なUIの移動についてこのディスカッションを開始したとき、Miss Chigusa SansenまたはWinUIチームの他のメンバーは、このスレッドはこのディスカッションに適した場所ではないと明確に述べていました。 代わりに、人々は熱心に議論を始め、Microsoft / Windowsの重要なUIポジションにいる誰かと話していると考えて賛成/反対を主張しました。 Chigusaも参加し、UIの方向性に影響を与えることを期待してコントロール画像を自由に追加しました。 私の苦情があり、あなたはその@chigyは、単に彼女がapparantlyでも呼び出すチームではないので、本当に、ここでその議論を有することを多くのポイントの存在しないことを私たちに伝えるためにそう時間がかかった、ということ見逃しているように見えます

それはあなたが言うように「誤解された」または「誤解された」ことについてではありませんが、そのような重要な情報は何日も私たちから遠ざけられていました。 ミス・チグサ・サンセンがあなたと彼女の両方が見たいと思っていることを以前に述べていたとしたら、この議論全体はすでに長い間進んでいた可能性があります。

@ Felix-Dev @Nepxune
礼儀正しく前向きであり続けましょう。 😃投稿されたこれらの画像は、CornerRadius値を含むコントロールに加えられた変更を強調しています。 現在値をサポートまたは尊重していないコントロールにCornerRadiusを追加するための特定のメカニズムを作成して、それらをサポートし、開発者が値をオーバーライドして値を二乗するか、カスタマイズできるという別の問題があります。彼らのブランドとニーズに合う価値。 ＃684

この問題は、Webおよびアプリスタイルの方向性と一致する、共通コントロールのコーナー半径の更新に関するものです。

私が投稿したアイデアは、Fabric Webで使用されているスタイルを採用し、それらをXAMLコントロールに取り込むことでした。したがって、それらはこの議論の範囲内にあると感じています。 XAMLコントロールThemeResourceを制御するOS機能は少し話題から外れていますが、関連しています。

会話は面白くて適切であり、最初に変更を加える際に、すでに決定されている変更をどのように成功させるかではなく、長所または短所についての議論にそれを振り向けようとしたところまででした。作る。

丸め量をユーザーが切り替えたり変更したりできるOS設定にする提案を後押ししたい場合は、新しい提案として作成することをお勧めします。

行動規範を参照し、敬意を払うようにしてください。 @chigyは欺いたり誤解を与えたりしようとしていませんでした。

マーティンは、私たちがWindowsの将来のバージョンのニーズを満たすために設計を製品化するのを支援する責任があるプラットフォームチームであることは正しいです。 また、独自のブランドとスタイルを持ち、Windowsスタイルに従わないプラットフォームを含め、他のすべてのユーザーがプラットフォームを適切に機能させるようにしたいのです。 このフィードバックはすべて非常に価値があり、Windows設計チームとも共有して、OSレベルの人々がノブでカスタマイズしたいという特定のフィードバックを確実に聞くようにします。

@ Felix-Dev、@ Nepxune 、および@mdtaukに感謝します。このGitHubアイテムを引き継いだとき、私はおそらくあまり明確ではなかった何かを指摘してくれました。 ご存知のとおり、これはオープンコミュニティで話し合っている最初のデザイン関連の問題であり、学習しながら進めています…

そしてまず、このグループの誰かに、私が私の意図ではない変更を加える権限を持っている設計担当者であると誤解した場合はお詫び申し上げます。時間を無駄にしたと感じた場合は申し訳ありません。

デザインに関連するWinUIの役割を要約してくれた@jevansaksに感謝します。

そうは言っても、私はこのコミュニティのおかげなので、自分自身について明確にしましょう。 私はWinUIエンジニアリングチームのプログラムマネージャーです。 私は会社全体の設計チームと緊密に協力して、WinUIがFluentの設計方向だけでなくWindowsの設計方向の設計の真実を表すようにしています。 たとえば、ちょうど昨日、私はXboxの設計チームと一緒に座って、ここで提案されている設計変更のいくつかについて話し合っていました。 それらがXbox開発者にとって引き続き有用であることを確認します。 WinUIチーム内では、UI / UXの観点から一貫性のないものを導入する個々の機能をリリースしないように、全体的にも水平的にもより体系的な方法でデザインを監督しています。

私は、Windowsを代表するフルーエントデザインシステムの取り組みに参加しているだけでなく、開発者コミュニティにとって非常に強力な声になるよう努めています。 また、明確にするために、フルーエントデザインシステムは、マイクロソフト全体の多くのチーム（デザインチームとエンジニアリングチーム）が協力して、企業として優れたUXを提供し、自分のような開発者が利用できるようにする一貫したシステムを実現するための共同作業です。 ですから、私がその一部であるということは、私が電話をかけることができるという意味ではありません…私の意見では、この集団の誰一人としてできません…それは集団の努力です…

@ Felix-Dev、ユーザー設定について提案したコンセプトについてWindowsデザイン組織の誰かと個人的に話し合ったことをお知らせするために、私の回答を確認します（たとえば、その周りの機能計画がない、またはそのリクエストの周りで何かをすることに興味がない） ）。 あなたの意見は議論されました。 おそらく満足のいくものではないことは承知していますが、私はあなたの意見をすべて気にかけ、ここの代表者/橋になるために最善を尽くしていることを知ってほしいと思いました。

皆さん、私は問題を解決するつもりはありませんでした。 コメントを閉じようとしていたのですが、うっかりしてしまいました!!

@mdtauk @jevansaks @chigy
私は、この議論が専門家であり続けるべきであることに完全に同意します。 私たちは皆、Windowsへの情熱と、Windowsが可能な限り最高のものになることを望んでいます。

完全に明確にするために、私は千草三泉さんが私たちを「だましている」または「誤解している」と非難したことはありませんでしたし、それは私の意図でもありませんでした。 私はまた、私が個人的に誰かを攻撃したことは一度もないとはっきりと述べることができます。

しかし、この最近の会話でも示されているのは、このオープンソースプロジェクトはまだ学習段階にあるということです。 マイクロソフト社とその情熱的なユーザー、そしてこの新しいオープンソースアプローチが実際にコミュニティに与える影響の大きさと、関連するWindowsチームが実際にコミュニティのフィードバックを処理する方法を明確に理解することで、両方の世界をうまく統合するためにやるべきことがまだあります。 。

一般的に、私はすでに現在の状態にかなり感銘を受けています。 フィードバックは、実際のWinUI製品に関連するフィードバックでなくても、WinUIチームによって発行され、真剣に扱われます。 私はこれに感謝し、あなたはそれを尊重しています！

ここでのこの特別なケースは、残念ながら、すべての参加者がまだお互いについて完全に学ぶことができない、非常に若いオープンソースプロジェクトであるといういくつかの症状に苦しんでいた可能性があります。 私は、このケースを使用して、この新しいアプローチの可能性と限界を私たち全員がよりよく理解できるようになると楽観視しています。

皆さんこんにちは！
率直な会話をありがとうございました。 私はたくさんのことを学びました。オープンコミュニティとして一緒に成長するために、私たちと一緒に働き続けてくれることを願っています。

ご指摘のとおり、WinUIチームが何ができるのか、何ができないのかわからなかったので、皆さんが提起した素晴らしい点とその結論をまとめてみましょう。 また、問題がまだ解決されていないと感じた場合は、ジャンプしてください。

話し合いの中でいくつかの問題が解決したと考えたため、話し合ったすべての問題をリストアップしなかったことに注意してください。 そう思わない場合はお知らせください!!

• Xboxが検討されていることを確認してください（@mdtauk）
  oXboxデザインはXboxチームが所有しています。
  oしかし、はい、私たちは彼らと緊密に協力しています。 Xboxデザインチームとこれと今後のデザイン提案を検討する会議が行われたことを確認しています。
• 境界線を細くするなど、他のコントロール関連の配置変更を行うことを検討してください（@mdtauk）
  o Windows設計チームは、Fluent Design Systemの集合体と調整しながら、Windowsの最終的な呼びかけを行い、Microsoftの設計チーム間での調整を試みます。
  o WinUIチームは、開発者にとってより適切に機能し、切り替える（または元に戻す）ための優れた開発者ストーリーを提供します。
  oこれは、今後のGitHubの問題で追跡されます。
• コミュニティは、フルーエントデザインチーム（@ mdtauk 、@ Felix-Dev、@ Nepxune）に直接意見を述べる場所を望んでいます。
  o参考までに、FluentチームにはLinkedInグループがあります。
  oこれはWinUIチームまたは私自身が所有しているものではありません。
  oこれは彼らの注意を引いていますが、何かが起こった場合、私たちは自分自身をコミットすることはできません。
  o何かが実現した場合は、必ずこのグループに連絡します。
• WPF / WinFormsのFluentテーマをリリースしますか？ （@ Felix-Dev、@ mdtauk）
  oこれは私たちがまだ理解していないことです。
  oこれは少し複雑です。 私は、Windowsの開発者全体の設計ガイダンスと設計サポートを検討しているので、これは私の関心領域に適合します。 ただし、率直に言って、これはWinUIの作業ではないため、現時点では優先事項ではありません。
• ユーザーが丸みを帯びた角をオン/オフにしたり、ある時点まで細かい値を変更したりできるユーザー設定（@ Felix-Dev）/丸みを帯びた角が気に入らない、丸みを帯びないようにして、ユーザーにオプションを与える（ @Nepxune and people on Reddit）
  o残念ながら、これはWinUIの決定ではありません。
  o現時点でお勧めできる最善の方法は、この変更がWindows OSに反映された後、フィードバックハブの問題を開くことですが、それでもデザインがニーズを満たしているとは感じませんか？
  o慰めがあれば、私はWindowsチームに通知するために最善を尽くしましたが、彼らのチームによる計画はありません。

これは私たちの現在の計画を要約しています：

• WinUI 2.xを使用して取得したコントロールは、丸みを帯びた角を使用するようにデフォルトのビジュアルを更新します。
  oつまり、WinUI 2.xを使用しない場合、この変更は行われません。
• 丸みを帯びた角の値は、ほとんどのコントロールで2px、フライアウトタイプのUIで4pxです。 UIが他のUI要素と交差する場合の丸めはありません
  oビジュアルコンプはこちら： https ：
  oこれについて話し合った@ mdtauk 、 @ Qowy 、 @ shaheedmalikへの短いメモ。 内側の線は丸めません。 これは、実施されているビジュアルコンプに反映されます。 Windows設計チームは、さまざまなオプションと長所と短所を調べて評価しました。
• 開発者はこれを簡単に元に戻す方法があります（＃684）。
• ユーザーがこれを前後に切り替えたり、きめ細かい変更を加えたりできるユーザー設定はありません。

@chigy投稿していただきありがとうございます。

次に何が起こるかについていくつか質問があります...

• これらのデザインコンプは、すべてのコントロールの最終的なデザインを反映していますか、それとも後で更新または投稿される変更について話し合っていますか？

• コミュニティとして、WinUIに来るこれらのデザインの選択のいくつかに影響を与えたり、提案したりすることをどのように提案しますか？

• WindowsデザインチームがWindowsUIに対して持っているビジョンをいつ見ることができるので、作業中のコントロールデザインのコンテキストを把握できますか？

• XAMLを使用して、受信トレイアプリとシェル要素の間の一貫性を説得/キャジョル/強制して、すべてが設計で一致するようにする努力はありますか？

• Xboxで変更されたコントロールデザインはWinUIに含まれますか、それとも次のXboxデバイスでのみ提供されますか（Windowsでの開発中にこれらのコントロールテンプレートをテストする方法はありませんか？

@mdtauk 、おっと、書きすぎましたが、自分自身をうまく説明したかったのですが...

• これらのデザインコンプは、すべてのコントロールの最終的なデザインを反映していますか、それとも後で更新または投稿される変更について話し合っていますか？

コンプに表示されるものは、現時点で入手できる限り最終的なものです。 とはいえ、実際のコントロールに変更を実装すると、デザインが少しシフトする原因となる小さな変更が発生する可能性があります。 ご覧のとおり、compはすべてのUIオカレンスを網羅しているわけではありません。 しかし、私はこの特定の努力からそれを期待していません...

• コミュニティとして、WinUIに来るこれらのデザインの選択のいくつかに影響を与えたり、提案したりすることをどのように提案しますか？

コミュニティに教えてもらいたいのは、これらの設計の選択がアプリケーションで失敗する場所です。 私たちが提供していないカスタマイズの場所はありますか？ なんらかの理由でアプリが完全に壊れてしまいますか？

先に述べたように、設計の決定は設計チームによって行われますが、WinUIは、開発者にソリューションを提供し、それが健全なものであることを確認する責任があります。 その結果、設計出力に影響を与える機会が生じる可能性があります。 何も起こらないとは約束しませんが、この場合、どのように機能せず、どのように修正する必要があるかの実際の例が最も効果的です...

• WindowsデザインチームがWindowsUIに対して持っているビジョンをいつ見ることができるので、作業中のコントロールデザインのコンテキストを把握できますか？

ビジョンとは、Windows全体に導入されているUIの変更の種類を示す全体的なストーリーのようなものですか？ 具体的に何を考えていますか？

• XAMLを使用して、受信トレイアプリとシェル要素の間の一貫性を説得/キャジョル/強制して、すべてが設計で一致するようにする努力はありますか？

以下は私が知っていることに基づいた完全に私自身の意見です。 ただ明確にします... ：）
私の考えでは、問題は2つあります。

最初の問題は、現在、OSのリリースに依存する新しいUIの配信システムがあることです。 そのため、多くの受信トレイアプリは、古いOSバージョンをサポートする必要があるため、Shellが使用していた新しいスタイルなどを採用できませんでした。 WinUIで新しいUIを提供することでこれを解決しようとしているので、OSのバージョンに関係なくこれらの変更を採用できます。

第二の問題は、文化の転換が必要なことです。 私はWindowsPhoneを含むさまざまなUIプラットフォームで作業し、製品に一貫性を持たせるためにさまざまなアプローチを使用しようとしました。 こんな感じ…制限速度があっても、誰もがそれに従うわけではありません。 しかし、執行するために何人の警察を送る必要がありますか？ 制限速度を守る文化を作っていかなければなりません。 ここには魔法の解決策はありません。 そして、これはフルーエントデザインシステムがもたらすのに役立つことを私が期待しているものです。 個人的な意見ではなく、システムの設計上の決定を行うことによって。

• Xboxで変更されたコントロールデザインはWinUIに含まれますか、それとも次のXboxデバイスでのみ提供されますか（Windowsでの開発中にこれらのコントロールテンプレートをテストする方法はありませんか？

Xbox専用のコントロールを変更する予定はありません。 過去にこれを行ったことがなく（ドキュメントをリリースしました）、Xboxチームとコミュニティの両方から強いリクエストを受け取っていません（これはプレオープンソースです）。

@chigy率直に対応していただき、ありがとうございます。

次のXboxもアプリをサポートすると想定していました-そしてコアOSがシェルにXAMLを使用している場合-それはまた、XboxがWindowsと同じくらいWinUI3.0コントロールを必要とすることを意味します。 したがって、Xbox用に設計されたテンプレートを含めると、プロセスが簡素化され、Xboxアプリの開発がより親しみやすくなりますが、それは明らかに他のチームの決定です。 😄

ビジョンについては、 「将来のWindowsShellおよびInboxアプリは次のようになります」という意味「私たちはWindowsのデザインを更新する機会を利用しています。これが、私たちが行っている変更の一部です...」

キューの画像やビデオ😃

また、XboxとWindowsは一致しているべきだと思います。 Xboxには、Windowsで廃止されたが、Xbox（CBS、FOX Sports）にはまだ存在するか、Windows 10（Youtube）には存在しなかったアプリがあります。

UIを変更する必要がなくなると、これらのアプリはプラットフォーム上に保持されます。

ただ私の考え。

また、XboxとWindowsは一致しているべきだと思います。 Xboxには、Windowsで廃止されたが、Xbox（CBS、FOX Sports）にはまだ存在するか、Windows 10（Youtube）には存在しなかったアプリがあります。

UIを変更する必要がなくなると、これらのアプリはプラットフォーム上に保持されます。

ただ私の考え。

Xboxアプリには、さまざまな制御スタイルと動作が必要です。 ただし、これらのアプリは、Windowsのコントロールスタイルを使用せずにアプリを実行できるようにするプロパティを含めるだけで、Windowsで実行できるはずです。 つまり、 XboxFirstのアプローチです。

@shaheedmalikと@ mdtauk 、XboxとWindowsが一致し、アプリが相互に実行される必要があるという議論について少し混乱しています。

XboxシェルとWindowsシェルのデザインは異なります。 彼らはユニークな製品であるため、それは意図的です。 ただし、WinUIコントロールは、1つのスタイルを使用したいアプリがわずかな作業で実行できるように設計されています。 数年前にXboxチームと協力したとき、XAMLコントロール（WinUIがない場合）がテレビに正しく表示されることを確認し、前述のガイダンスもリリースしました。

適切に作成されたUWPアプリは、WindowsとXboxの両方で実行されます。 @shaheedmalikがリストしているようなアプリの場合、それらは非常にブランド化されており、XboxとWindowsとの間で同じブランドが頻繁に見られます。 そのため、多くの場合、1つのアプリデザインがこれらのデバイス間で実行されています。

繰り返しますが、これは角の丸いトピックなので、元に戻します...
角を曲がったリリースが終わったら、開発者がXboxで行う必要があることは次のとおりです。 開発者が角の丸い機能を備えたWinUI2.xを採用する場合、開発者はシェルのスタイルと一致させたいのであれば、角の丸いスタイルをオフにする必要があります。 ちなみに、Xboxの多くのアプリはそうではありません...そのため、気になる人のために代わりにガイダンスドキュメントをリリースしています。 リリース時に、10FTガイダンスドキュメントに丸みを帯びた角について記載されていることを確認します。

ビジョンについては、 「将来のWindowsShellおよびInboxアプリは次のようになります」という意味「私たちはWindowsのデザインを更新する機会を利用しています。これが、私たちが行っている変更の一部です...」

キューの画像やビデオ😃

@mdtaukは、私が過去に設計チームに尋ねたことがあるので、プラットフォームチームとして、開発者の聴衆に設計ビジョンを伝えるためにそれを使用できます。 私の知る限り、当面の計画はありませんが、もう一度確認することができます。

ビジョンについては、 「将来のWindowsShellおよびInboxアプリは次のようになります」という意味「私たちはWindowsのデザインを更新する機会を利用しています。これが、私たちが行っている変更の一部です...」
キューの画像やビデオ😃

@mdtaukは、私が過去に設計チームに尋ねたことがあるので、プラットフォームチームとして、開発者の聴衆に設計ビジョンを伝えるためにそれを使用できます。 私の知る限り、当面の計画はありませんが、もう一度確認することができます。

ありがとうございました。 // Build /は、計画されていた変更を共有する絶好の機会でした。特に、WinUI 3.0の初期リリースとともに、夏の終わりにこれらのコントロールテンプレートを更新する計画の場合はそうです。

XboxシェルとWindowsシェルのデザインは異なります。 彼らはユニークな製品であるため、それは意図的です。 ただし、WinUIコントロールは、1つのスタイルを使用したいアプリがわずかな作業で実行できるように設計されています。 数年前にXboxチームと協力したとき、XAMLコントロール（WinUIがない場合）がテレビに正しく表示されることを確認し、前述のガイダンスもリリースしました。

確かに、シェルは経験に合わせて異なります。 私の唯一のコメントは、次のXboxがアプリの開発を奨励したい場合、デフォルトのWinUIコントロールにはWinUIにテンプレートとThemeResourcesが含まれている必要があるため、Xboxで実行すると、コントロール設計のガイダンスと一致します。 また、開発中に、これらのコントロールがどのように表示されるかをテストできるようにする必要があります。 WindowsとXAMLデザイナの両方。

Xboxコントロールのデザインコンプのいくつかに出くわしましたが、それらはUWPドキュメントにはありませんでした。

@ mdtauk 、Xboxについてのこの会話は＃698に適しているように思われますか？ Xboxの誰かにpingを送信して、他の会話にコメントできるかどうかを確認しました（約束はありません:)）。 繰り返しになりますが、これはオープンソースコミュニティです。おそらく、上記のリソースを作成して、何らかの方法で消費することを提案できますか？ ただ言って...

@chigyこれは私が提出した問題であり、コミュニティがWinUIに追加するすべてのコントロールに、将来のXboxコンソールで実行するためのテンプレートを含める必要があることを確認することでした。 開発者がXboxアプリにWinUI3.0 +を使用したい場合は、テレビで実行したときにすべてのコントロールが正しく表示されるように調整する必要があります。

しかし、設計がほぼ完成しているため、この問題には、すべてのテンプレートが更新されたときに完了としてマークされることを除いて、それほど多くの目的はありません。

私はNumberBoxコントロールの提出でアイデアを提出してきましたが、コントロールのデザインが残りのコントロールで計画されているものと一致することを確認したかったのです。

開発者がXboxアプリにWinUI3.0 +を使用したい場合は、テレビで実行したときにすべてのコントロールが正しく表示されるように調整する必要があります。

@mdtauk 、前に述べたように、これは良い提案ですが、Xboxチーム自体または自分以外のコミュニティからのリクエストがないため、これは優先事項ではありません。

WebViewのScrollIndicatorはXAMLを介して更新されないという事実を更新しましたが、Webはそのまま使用します。

MUXControlsTestAppで現在のプログレスバーを見る-プログレス値バーの右端も丸められますか、それともフラットエッジを維持しますか？

ボリュームフライアウト内のスライダーもスタイリングされますか

リビールはデフォルトですべてのコントロールに追加されますか、それともスタイルごとに追加する必要がありますか？

ColourPickerで使用されるスライダーは、MediaPlayerと同様のアウトラインスタイルを持つことでメリットがありますか？そのため、バーの暗い色の中で失われることはありませんか？

MUXControlsTestAppで現在のプログレスバーを見る-プログレス値バーの右端も丸められますか、それともフラットエッジを維持しますか？

設計上の定義により、そうすべきです。 MUXControlsTestAppに対して問題を開いてください。

ボリュームフライアウト内のスライダーもスタイリングされますか

シェルUIは共通のコントロールを使用するため、コントロールの変更が発生したときに使用する必要があります。 ただし、これが更新されていない場合は、FeedbackHubの問題を開いてください。 これはシェルチームによる作業であり、WinUIチームが優先順位とリソースについて最終的な呼びかけをするものではありません。

リビールはデフォルトですべてのコントロールに追加されますか、それともスタイルごとに追加する必要がありますか？

これは角の丸いトピックではありません。
デフォルトですべてのコントロールにリビールを追加する場合は、新しい問題を開いてください。

ColourPickerで使用されるスライダーは、MediaPlayerと同様のアウトラインスタイルを持つことでメリットがありますか？そのため、バーの暗い色の中で失われることはありませんか？

MediaPlayerは、新しいスライダー（＃841）の設計に従うように計画されています。 したがって、あなたが提案していることは計画に含まれていません。 使いやすさの問題だと思われる場合は、別の問題を開いてください。

うわー！ ここにはたくさんのコメントがあります。

しつこい鋭い角がWindows10をユニークに見せていると思います。 丸みを帯びた角が導入された場合、Windowsロゴ、Microsoftロゴ、およびタイルについて何かを行う必要があります。 タイルなどのメトロの遺物を取り除いたら、傾斜のあるOfficeなどのロゴもやり直す必要があります。 丸みを帯びた角と一貫性を導入することの効果については何度も続けることができましたが、ここでそれを切り取ります。

@Poopooracoocoo新しいオフィスアイコン/ロゴは、新しいターミナルアイコン、および新しいビジュアルスタジオアイコン/ロゴと同様に、丸みを帯びた角を使用します。

そしてFWIW、私は彼らにタイルを取り除いてほしくない、それはWindows10タブレットUIが十分に悪い、Windows8.1と比較して大幅なダウングレードをした

@ Poopooracoocoo 、 @ mdtauk 、
ご意見ありがとうございます。 変更を全面的に適用する必要があることは、どちらも正しいことです。 したがって、この取り組みは、FabricおよびEdgeなどの他の表示可能なUIとの調整を開始しています。 一貫性を一晩で実現したいのですが、これは旅です。 そして、ここでプレイしているUIプラットフォーム（つまりWinUI）のデフォルト値から始まります。

ステータスアップデート：

コーナー半径（別名丸みを帯びたコーナー）ハウツードキュメントPRが作成されます。

これは、ドキュメントとしてdocs.microsoft.comに追加されます。
https://docs.microsoft.com/en-us/windows/uwp/design/style/の下の新しいページになり

コミュニティに尋ねる：
いくつかのフォーカスグループでドキュメントを提供することをお客様が表明した、もう少し「背景説明（WHY）」を書いてみています。 これは通常のドキュメントパターンに従っていないため、フィードバックをお願いします。

それらの追加情報は有用/有用、関連性がない、他の情報が欠落しているなどですか？

@chigyこのドキュメントについて私が持っている唯一の提案は、コントロールが丸みを帯びた角を受け取る理由について言及していないということです。

@mdtauk 、いいキャッチ。 それを捉えた「やること」のセクション（原則）がありましたが、どういうわけか編集中にコンテキストが失われました。 私はまだそのセクションを埋めるために働いています。

ステータスアップデート

ListとGridView内のチェックボックスの角を曲​​がる作業を追跡するための別の問題を作成しました（＃1096）

角の丸い変更がチェックインされ、この問題は解決しました。

@mdtauk

そしてFWIW、私は彼らにタイルを取り除いてほしくない、それはWindows10タブレットUIが十分に悪い、Windows8.1と比較して大幅なダウングレードをした

今だけ返信してすみません。 彼らは本当にタイルを取り除きます！ :(

Windowsが自由形式のアイコンに切り替えている間、iOSと同様に、Androidは現在アダプティブアイコンのみを許可しているため、これは興味深い決定です。 「アダプティブ」アイコンはモノクロのアイコンであるため、スプラッシュスクリーンで見栄えが良くなり、目がくらむような白いスプラッシュスクリーンを用意する必要がありません。 一方、自由形式のアイコンは、開発者がアイコンをより細かく制御できるため、見栄えがよく、デスクトッププラットフォーム（タイトルバー、タスクバーなど）やwin32アプリに適しています。

Officeアイコン自体は、WordやPowerPointのアイコンのようには見えません。 これらの変更により、マイクロソフトはアイデンティティを失っているように感じます

@Poopooracoocooアイコンが新しいシェルの新しいデフォルトであっても、アイコンの代わりにタイルを使用するオプションがあることを私はまだ望んでいます。

@Poopooracoocooと@ mdtauk 、WinUIチームはタイルに関与しておらず、計画についての知識もないため、タイルのディスカッションについてはフィードバックHubにフィードバックを送信してください。

@Poopooracoocooと@ mdtauk 、WinUIチームはタイルに関与しておらず、計画についての知識もないため、タイルのディスカッションについてはフィードバックHubにフィードバックを送信してください。

タイルの保持についてフィードバックを送信しました。賛成票がたくさんあるコレクションがあります。 フィードバックHubは、Windows Devチームからのフィードバックやディスカッションへの貢献がほとんどないため、GitHubほど良くありません。

こんにちは、丸めを無効にする方法は？ 丸いボタンに丸いツールチップがあると見苦しくなります。

@kikisaints @chigy @mklemarczykなどの特定の要素が求めていると言うために丸みを帯びたコーナーを無効にする方法はありますか？

こんにちは、丸めを無効にする方法は？ 丸いボタンに丸いツールチップがあると見苦しくなります。

@mklemarczykコントロールのスタイルでCornerRadius値を0に設定してみましたか？ すべてのToolTipコントロールに影響を与えるには、App.xamlでこれを行う必要がある場合があります。

@kikisaints @chigy @mklemarczykなどの特定の要素が求めていると言うために丸みを帯びたコーナーを無効にする方法はありますか？

@mklemarczyk 、私たちのガイダンスドキュメントを見たことがありますか？
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk ToolTip.CornerRadiusプロパティまたはOverlayControlResourceを2つのオプションとして使用して、ツールチップコントロールのコーナー半径を変更できます。

Control.CornerRadiusプロパティはWindows 1809以降で使用可能であり、次のように使用できます。

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

これにより、アプリのすべてのツールチップのコーナー半径が0に設定されます。

または、

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

これにより、アプリ全体のツールチップコントロールのコーナー半径が設定されるだけでなく、このリソースを使用する他のすべてのコントロール（ContentDialogやComboBoxなどのポップアップを消費するコントロールなど）も設定されることに注意してください。 つまり...理論的には、リソースのオーバーライドは、必要な場合でもこれらのコントロールに影響を与えないようです（ToolTipは機能します）。

他の入力とコーナー半径に関して何が決定されたかを知るのは非常に多くのやりとりがありますが、WinUI 3のみを使用するようにUWPプロジェクトを移行した後、ボタンだけにコーナー半径が適用されていることに気付きました。 （強化されたリビールなどの他の変更とともに）しかし、他の入力コントロール（コンボボックスなど）はメトロの外観（暗い/厚い境界線と90°の角度）のままになりました。 これは意図的なものですか、WIPですか、それともバグですか？ また、コンボボックスをボタンに一致させるには、3epxのコーナー半径を使用する必要がありますが、オンラインで表示されているものはすべて、新しいデフォルトのコーナー半径は4epxであると表示されていますか？

他の入力とコーナー半径に関して何が決定されたかを知るのは非常に多くのやりとりがありますが、WinUI 3のみを使用するようにUWPプロジェクトを移行した後、ボタンだけにコーナー半径が適用されていることに気付きました。 （強化されたリビールなどの他の変更とともに）しかし、他の入力コントロール（コンボボックスなど）はメトロの外観（暗い/厚い境界線と90°の角度）のままになりました。 これは意図的なものですか、WIPですか、それともバグですか？ また、コンボボックスをボタンに一致させるには、3epxのコーナー半径を使用する必要がありますが、オンラインで表示されているものはすべて、新しいデフォルトのコーナー半径は4epxであると_言います_？

WinUI2とWinUI3のスタイルに違いがある場合は、新しい号を開いてください。 WinUI2からWinUI3へのスタイルのマージに関するバグである可能性があります。