@sapallie 、デザインのモックアップを公開してアクセスできるようにできますか？ この時点で共有されない場合を除きます。

現在XAML開発を行っており、このようなものが見たいです。 または、素敵なスクロールメッセージコントロールのようなもの。

Microsoftのブランディングの観点からは、標準化されたエラーバナーはひどく間違っているように見えます。 エンドユーザーがすべてのアプリケーションエラーをMicrosoftブランドに関連付けることを恐れています。 私はその提案を読んだばかりで、最初に頭に浮かんだのは、派手な死の旗についてツイートしているmemelordsでした。

@sapallie 、デザインのモックアップを公開してアクセスできるようにできますか？ この時点で共有されない場合を除きます。

申し訳ありませんが@adrientetar 、まだ共有できません。 デザインは今のところマイクロソフトだけです。

@sapallie 、この驚異的な機能のアイデアをありがとう！ 私はWinUIのプログラムマネージャーであり、これをチームに売り込むことに興奮しています。

私たちのプロセスについて少し書きたかったので、ここからの進め方にあなたが同調できるようになりました。 今から、この提案のハイレベルな範囲/要件と開発の正当性を改善するために取り組みます。 次に、それをWinUIチームの他のメンバーに売り込み、ロードマップ（＃717）と一致するかどうか、および比較的早く実行できると思われるかどうかを検討します。 もしそうなら、私は詳細を理解し、機能が開発者のために準備できるように仕様書を書き始めることを承認されます。

ここに私がすでに知っているいくつかの事柄があります私はもう少しアイデアを得る必要があります...

• 視覚的行動

エッジツーバナーの提案はありますか？ または、Windows通知のような通知タイルですが、中央、下端、隅などのアプリウィンドウにありますか？

申し訳ありませんが@adrientetar 、まだ共有できません。 デザインは今のところマイクロソフトだけです。

リクエストのパブリックビジュアルを含めることができなければ、この提案を承認することはできないと思います。レポはオープンソースであり、会話のビジュアル側をクローズソーシングすると、コミュニティのプロセスと経験が絡み合うことになります。 。 以上の回答を踏まえ、提案のモックアップを作成してみました。 これを希望しますか、それともデザインを公開する許可を与えるためのタイムラインを想定していますか？ 私はあなたのモックアップが大好きで、ここでのブレインストーミングにそれらを含めてもらいたいと思っています。 私にお知らせください！ ：赤面：

バナーは、ユーザーがアプリ/機能を使用できない原因となるエラーをユーザーに認識させます

重大でないエラーの場合、バナーは非表示になります

これらのステートメントを読んで正しいのは、重大なエラーに対して却下できないバナーのオプションも必要であることを意味しますか？ もしそうなら、却下できないバナーを持っているという点から、1つを受け取る/続行するための特定のアプリのシナリオについて詳しく教えてください。 問題が解決しない限り、ユーザーはアプリを閉じるように追いやられていますか？ それとも、ボタンがネットワークとインターネットの設定ページに移動するなど、ボタンが表示される場所ですか？

改めて感謝します。このアイデアを洗練することを楽しみにしています。

皆さん、この会話にあなたのニーズ、デザイン、視点を貢献することをお勧めします！ ：赤面：

私が言いたいのは、すべてが同様のことを求めるいくつかの提案があります。 これを具体的にエラーバナーにするのではなく、CommunityToolkitからアプリ内通知を取り込んでみませんか。 エラーアイコンや確認アイコンなどを表示するアイコンプロパティが追加されている可能性があります。

@SavoySchuler –ご意見をお聞かせください。 私はあなたのすべての質問に答えようとしましたが、他に何か必要なことがあれば教えてください。

視覚的行動：
理想的には、バナーはWindows通知タイルに似ており、アプリウィンドウの上部または下部に固定されます。 固定される場所は、アプリ内の他の視覚要素とフォーカスがどこにあるかによって異なります。 この決定は、設計者が行う必要があります。
@mdtaukが投稿したGIFは素晴らしい出発点になると思います。

却下：
重大なエラーと重大でないエラーの意味を深く掘り下げることは理にかなっていると思います。

• 重大なエラー=システム全体の問題（インターネット接続の喪失など）が原因でアプリの機能が損なわれている–これらは、ユーザーが問題を修正できるシステム設定にリンクしている必要があります
• 重大ではないエラー=一部の機能が損なわれているか、1つの機能が機能しないが、ユーザーはアプリで他のことを実行できます
• また、アプリの更新や新機能が利用可能であることをユーザーに知らせるために使用できる、バナーの純粋な情報の反復を導入することもクールです。

そして、私はこれらすべてを却下すべきだと思います（私は提案の説明でもそれを更新しました）

ビジュアルの例
ビジュアルにいくつかの変更を加え、次のように共有することができます。

これらの例は、バナー全体が基本的に大きなボタンである反復です。 ユーザーはそれを閉じるかクリックしてシステム設定に移動し（重大なエラー）、機能の修正に関する詳細が記載されたWebページを開き（警告1）、アプリページを再読み込みし（警告2）、Microsoftストアにアクセスして更新します。アプリ（情報）。
この概念を拡張して、バナー内に複数のボタンを追加することができます。

私はバナーのそれらのビジュアルが本当に好きです。 テキストとアイコンを4ピクセル上に移動して、白と色のバーではなく、白の領域の中央に配置します。

同意しました。 投稿されたビジュアルはとても素敵に見えます。

私はバナーのそれらのビジュアルが本当に好きです。 テキストとアイコンを4ピクセル上に移動して、白と色のバーではなく、白の領域の中央に配置します。

ピクセルは数えていませんが、エックスハイトより上の発音区別符号のスペースを考慮すると、ピクセルが中央に配置されているように見えます。

@sapallieこれらのコントロールを自動的に、またはプログラムで閉じることを許可することについて考えたことはありますか？

オフラインになる/オフラインになることについてプロンプトを表示する場合は、再びオンラインになったときにそのようなプロンプトをプログラムで削除するのが理にかなっています。 （私はアプリがこれを行わないのを見てきました、そしてそれは混乱する経験につながる可能性があります。）

同様に、重要でないメッセージを無期限に表示しないようにすると、不要なUIの乱雑さを回避でき、パワーユーザーがメッセージを読んだ後、手動で通知を閉じるように強制しないことで、フローから抜け出す必要がなくなります。

私は、そのようなコントロールとこれらの動作の周りに潜在的な追加のアクセシビリティの考慮事項があることを理解していますが、コントロールを却下するこれらの方法は不可欠であると信じています。

このようなコントロールは、アプリ内の一般的なメッセージングを目的としたものではないことを強調することが重要だと思います。 それが本当に望ましいユースケースでない限り。

アプリが一度に複数のバナーを表示できるようにする必要がありますか？
もしそうなら、それらはどのように配置されますか？ そして、これはアプリが制御できるものですか？

これは、アプリの通知制御でAndroid Toastスタイルを要求した人を満足させるでしょう。また、フォームのスペースが限られている場所にエラーテキストを表示することは、検証シナリオにも役立つ可能性があります。

また、 StatusTipやStatusNotificationのようなものと呼ぶので、否定的な使用に関連付けられるだけではありません。

ウィンドウの下部に配置されたときに無地のバーの配置を変更することで、デザインが適応すると思いますか？

おそらくタイムアウトプロパティが必要であり、エラーメッセージの確認に切り替える前に、進行状況の呼び出し音や「今すぐログイン」などのテキストなどの保留中のメッセージを表示する機能もあります。

私はバナーのそれらのビジュアルが本当に好きです。 テキストとアイコンを4ピクセル上に移動して、白と色のバーではなく、白の領域の中央に配置します。

ピクセルは数えていませんが、エックスハイトより上の発音区別符号のスペースを考慮すると、ピクセルが中央に配置されているように見えます。

色付きのバーを考慮せずに、テキストがボックスの垂直方向の中央に配置された可能性が高いと思います

コントロールの配置によって、色付きのバーの配置がどのように変化するかを次に示します。

@mrlaceyはい、バナーが関連しなくなった場合のプログラム的/自動の却下は非常に重要です–私はそれを提案の説明に追加しました。

ステータスの変更とエラー：それがバナーの使用目的です。 一般的なメッセージではありません–私はそれに同意します。

そして、私は複数のバナーが機能するはずだと思います。 それらはただ積み重ねられるべきです。

@mdtauk名前を「ステータスバナー」に変更しました–ご提案ありがとうございます。

読み込み状態について–私はそれがバナーで起こるべきではないと思います。 読み込み中のコンテンツは、コンテンツが実際に表示されるアプリに表示される必要があります。

また、色付きのバーの配置を変更する場合は、アプリウィンドウのどこにエラーバナーを配置するかに応じて、柔軟性を持たせることができれば便利です。 👍

問題＃622および＃792も、ビルドされる場合は、このコントロールでカバーできます。

@sapallie重大なエラーの状況に関するメモは、ステータスバナーがユーザーに解決策を示すという推奨ガイダンスに関して興味深いものです。 私の直感では、無効にするためのAPI、または少なくとも一時的に却下するためのAPIも必要になる可能性があると言っていますか？

私は、そのようなコントロールとこれらの動作の周りに潜在的な追加のアクセシビリティの考慮事項があることを理解していますが、コントロールを却下するこれらの方法は不可欠であると信じています。

@mrlacey 、素晴らしいコールアウト！ 幸い、TeachingTipでの時間指定の自動却下を考慮して、この大部分を処理しました。ユーザー補助設定を所有するチームとの提携が必要になる場合もありますが、ユーザー補助の問題のためにこの機能がブロックされるとは思いません。 他のすべてのポイントで+1！

ソリューション、またはネットワークなどの設定ショートカットにリンクするHyperlinkBut​​tonを追加する機能はありますか？

ソリューション、またはネットワークなどの設定ショートカットにリンクするHyperlinkBut​​tonを追加する機能はありますか？

アプリ内または設定アプリ（TeachingTipのXaml Controlのギャラリーコードを参照）ページへのハイパーリンクを含むサブテキストを想定していました。 もっと標準化された@mdtaukを考えていましたか？

MessageTextの代わりに@SavoySchulerContentプロパティ？

重大なエラーの状況に関するメモは、ステータスバナーがユーザーに解決策を示すという推奨ガイダンスに関して興味深いものです。 私の直感では、無効にするためのAPI、または少なくとも一時的に却下するためのAPIも必要になる可能性があると言っていますか？

ええ、多分私は推測します…それを追加することは間違いなく害はありません。 結局のところ、柔軟性が追加され、一部のユースケースではおそらく非常に役立ちます。

@mdtauk-はい、私は確かにコンテンツプロパティを意味します！

@sapallie

重大なエラーの状況に関するメモは、ステータスバナーがユーザーに解決策を示すという推奨ガイダンスに関して興味深いものです。 私の直感では、無効にするためのAPI、または少なくとも一時的に却下するためのAPIも必要になる可能性があると言っていますか？

ええ、多分私は推測します…それを追加することは間違いなく害はありません。 結局のところ、柔軟性が追加され、一部のユースケースではおそらく非常に役立ちます。

一方では、UIをカバーする非表示のポップアップがあり（そして、そうすることで独自のシナリオベースのエラーが発生する可能性があります）、他方では、永続的ではないアプリの警告/重大なエラーが発生します。私のスパイシーな感覚がうずきます。

おそらく、オーバーUI +チップスタイルのポップアップではなく、インUI +エッジツーエッジバナー（Office Suiteが更新について通知するために使用するものなど-以下を参照）は、ニーズを満たしながら、 UIに永続的なスペースを提供しましたか？

@SavoySchulerコントロールの幅が十分に広い場合、コントロールにヘッダーとコンテンツを1行に配置する動作が発生する可能性があります。

さまざまな配置レイアウトを使用した以前の提案は、コントロールがウィンドウやパネル内だけでなく、別のコントロールの端からスライドする場合にも機能します。

おそらく、オーバーUI +チップスタイルのポップアップではなく、インUI +エッジツーエッジバナー（Office Suiteが更新について通知するために使用するものなど-以下を参照）は、ニーズを満たしながら、 UIに永続的なスペースを提供しましたか？

ええ、それもうまくいきます。 👍

振り返ってみると、Office Suiteはリボンを備えたすべてのアプリに依存できるため、インラインオプションとオーバーレイオプションの両方を用意することが理想的であるように思われます。 @mdtauk私は、私たちが出現/消失行動についてどのように考えるかを示唆し始めているあなたの提案が好きです。

@all 、このコントロールが使用されることを想定している実際のアプリの特定のシナリオを誰かが私と共有できますか？ 具体的には、視覚的な入り口と、解雇を促すために必要なユーザーの操作についての考えに興味がありますか？ ここでの要件は、このコントロールから必要なコア動作をカバーしていますか？

@SavoySchuler入口と出口を考慮すると、端からスライドインすることができますが、開発者が選択した場合は、フローティングオーバーレイとしてアニメーション化することもできます。 OSレベルで画面の右端からスライドイン（アプリウィンドウの右端から、またはコントロールまたはUI要素の端から外側にスライド）。

閉じるための閉じるボタンがありますが、タッチディスプレイの場合は、表示された場所から逆方向にスライドする機能も機能する可能性があります。 一貫性を確保するには、これをコントロールに組み込む必要があります。

コントロールをタップすると、メッセージテキストで指定されるアクションがトリガーされる可能性があります。
例外は、アクションの進行状況を表示する場合です。これは、エラーでタイムアウトするか、正常に完了するまで却下できません。

アニメーションの例

入力、更新、終了-YouTubeリンク

アニメーション化-YouTubeリンク

TeachingTipは存在し、特定のコントロールまたはUI要素をターゲットにするための優れた方法であり、アプリの新機能を強調するために適しています。 技術的には、このStatusBannerと同じ目的で使用できるため、これらのそれぞれのセマンティックな使用法を検討し、それぞれが一意である理由を特定する必要があります。

以下は、ステータスバナーと教育のヒントの違いについての私の個人的な考えです

• ステータスバナーは、実際に実行可能なステータスを推奨する必要があるため、タップすると1つのアクションを呼び出す必要があります。

  • Teaching Tipは、アクションをボタンまたはハイパーリンクとして表示します。これは通常、簡単に却下できる情報に使用されます。

• アプリまたはOSの状態が変化すると、それがアプリに必要になり、ステータスバナーが表示されます。

  • Teaching Tipは重要な情報を提供せず、一度却下されたものは、何か新しいものが追加されて呼び出されない限り、再び表示されることはありません。

• ステータスバナーは、[閉じる]ボタンで閉じない限り、表示している間は持続するか、タッチしているときにスワイプする必要があります。 進行中の進行状況シナリオが完了するか、OSステータスが解決する（ネットワークが復元される）場合を除きます。

  • ティーチングヒントにはタイムアウト機能が含まれている可能性があり、アプリの実行中にランダムに表示されることはなく、主にアプリの起動時またはページ/画面へのナビゲーション時に表示されます。

• ステータスバナーは、OSシェルで一貫した方法で使用する必要があります。列挙型として、コンテンツ、アイコン、色を含む標準のローカライズされたバナーのセットが存在する可能性があります。

• アプリウィンドウにステータスバナーを追加するOSロジックがいくつかある可能性があります。
  たとえば、アプリがネットワークにアクセスしようとして利用できない場合、OSは、画面スペースではなく、アプリウィンドウ内に標準のステータスバナーを表示したり、開発者に実装を任せたりすることができます。

  • 教育のヒントはアプリ固有であり、定義された標準コンテンツはなく、開発者だけが含めることができます。

@mdtauk 、ビデオの素晴らしい作品！ 🎉これらのアイデアに命を吹き込むのに役立つだけではありません。

永続性の必要性は優れた点であり、却下機能は、重要な場合は通知ペインでステータス通知を永続的に利用できるようにすること、または問題が続く場合は非侵襲的な間隔でステータス通知を再表示することを提案するガイドラインによっても軽減できると思います。 これらは明確な主張ではなく、このソリューションがシナリオソリューションで適切に包括的であることを保証するための考慮事項にすぎません。

TeachingTipをこの機能と区別する必要性は明確であり、私はあなたの意見に同意します。 このコントロールは、TeachingTipが解決するように設計されていないという明確なニーズに対応しますが、一部の共有機能またはコードの機会がある場合があります。

@mdtaukが上記で共有したようなものによってニーズが満たされない利害関係者はいますか？

OPでモックアップされたステータスバナーと、Office（以前のコメントの上の画像）またはVisual Studio（下の画像）に見られる全幅通知との間には違いがあるようです。

2つの違いは、それらが同じコントロールなのか、それとも別々のコントロールなのか疑問に思うことを意味します。

それぞれに必要なプロパティのクイックリストを次に示します。 （たとえば、名前は固定されていませんが、意味を推測することを目的としています）

ステータスバナー

• _アイコン_
• メッセージテキスト
• 追加テキスト（2行目）
• タイプ（重要、警告、または情報）
• 色
• 位置
• アニメーションの方向性
• [イベント/コマンド]をタップします
• タイムアウト

全幅通知

• _アイコン（おそらく）_
• メッセージテキスト
• リンクスタイル（ボタンまたはハイパーリンク）
• リンク（テキストおよびタップイベント/コマンド-複数）
• タイムアウト

太字のプロパティのみが両方に存在します。 _Icon_は、タイプごとに異なるタイプのアイコン（円またはアウトライン）が必要なため、混乱を招く可能性があります。
使用するスタイルを示すプロパティも必要になります。

私には、これは単一のコントロールにはあま​​りにも多くの違いがあるように感じ、このすべての機能をまとめることは混乱を招き、複雑になります。
私はこれらの2つの概念を考えます：

• 0個以上の実用的なサブ要素を持つ却下可能な全幅バナー
• ステータスの変更を示すことを目的とした、単一のボタンとして機能するバナー

個別のコントロールとして、最大の価値と最小の混乱を提供します。

アニメーション化されたステータスバナーは、一度に複数の通知を表示することをどのようにサポートしますか？
それとも、これは現在範囲外ですか？

• ステータスバナーは、OSシェルで一貫した方法で使用する必要があります。列挙型として、コンテンツ、アイコン、色を含む標準のローカライズされたバナーのセットが存在する可能性があります。
• アプリウィンドウにステータスバナーを追加するOSロジックがいくつかある可能性があります。
  たとえば、アプリがネットワークにアクセスしようとして利用できない場合、OSは、画面スペースではなく、アプリウィンドウ内に標準のステータスバナーを表示したり、開発者に実装を任せたりすることができます。

このレベルのOS統合は、単一のコントロールやWinUIを超えた野心を示しています。

「標準のローカライズされたバナー」が利用できるすべてでしょうか、それとも完全にカスタマイズ可能なものを使用できることに加えて、これらは利用できるのでしょうか。
デフォルトでいくつか提供する場合、それらは何になりますか？
限られたオプションのセットを提供するだけでは、そのような制御の可能性が不必要に制限されるのではないかと心配しています。

ネットワーク接続の喪失などのシステム全体のシナリオで、オープンアプリにOSにバナーを表示させると、多くの懸念が生じます。

• アクションセンターは、システム全体に通知を提供する方法をすでに提供しています。
• 複数のウィンドウが開いていると、それぞれに表示されるバナーを見るのは不必要に邪魔になります。
• アプリ内でシステムに通知（バナー）を表示させることは、開発者が制御または無効化することを期待するものです。
• アプリがたまにしかネットワーク接続を必要としない場合、接続の喪失に関するプロンプトが表示されると、ユーザーが現在行っていることに関係がない場合、ユーザーを当惑させたり、気を散らしたりする可能性があります。
• これにより、アプリがOSの特定のバージョンに関連付けられ、更新や目的の動作が得られます。 OS機能の将来の変更により、望ましくない方法でアプリが破損または変更される可能性があります。
• アップデートとバグ修正は、OSレベルのリリーススケジュールでのみ利用可能です。 WinUIの存在の背後にある理由の一部は、OSおよびアプリの機能との結合を断ち切ることです。

• ここで説明するようなコントロールの目標の1つは、開発者が簡単に実装できるようにすることです。 それを制御する機能を削除すると、特定のシナリオをカスタムの方法で処理する必要があるアプリで問題が発生します。

アニメーションのモックアップに関するTwitterの投稿からこの問題を見つけました。 これは、ツールキットのInAppNotificationコントロールで行った作業の多くと重複しているようです。 複数のメッセージの処理方法などを含みます。

これは単純なコントロールのように見えますが、かなり複雑であることを学びました。 これらすべてのケースをカバーするために、WinUIに組み込むことができる全体的なソリューションがあると便利です。 次に、ツールキットコントロールを廃止できます。

@ryandemopoulosと話し合い、この最初の会話を少しリファクタリングして、解決策（エラーUIの特定の部分）の前に問題（エラーUIが必要）に焦点を当てたいと思います。

この目的のために、私の最初の目標は、エラーUIのシナリオと要件をロックダウンすることです（ @sapallie 、「重要：Wi-Fi接続が失われました」シナリオは完璧なスタートです）。 そこから、ソリューションに1つのエラー通知UIが含まれるのか、エラーUIコンポーネントのセットが含まれるのかを共同で決定できます。 そこから、 @ mrlaceyのAPI類似性の内訳を拡張して（これを開始していただきありがとうございます）、この会話の出力が複数ある場合に、派生アプローチと個別のコントロールに十分な共通性があるかどうかを判断します。 私は自分より先に進みたくはありませんが、 @ mrlaceyの明確な解決策に対する議論は、すでに鮮明に見えており、それで問題ありません。 私の焦点は、ここにいるすべての人に適したソリューションのセットを作成することです。

したがって、このコントロールが特に関係する人（@ sapallie 、@ adrientetar 、@ EverydayApps @ Felix-Dev、@ mdtauk 、および@mrlacey）については、ここまたはdm@ saschule @microsoft.comに次の情報を提供してください。

• アプリのタイトル
• シナリオの説明（エラー、クリティカル/非クリティカル、およびそれをどのように提示したいかの説明）
• エラーが発生するアプリ画面のスクリーンショット（利用可能な場合）

この問題に焦点を当てたアプローチを反映するように問題を更新し、これまでに説明した要件、シナリオ、およびソリューションの可能性をカタログ化しました。

@sapallie私はあなたの最初の仕事を維持するために、できる限り礼儀正しくしようとしました。 バージョン履歴は、問題の上部にある[編集者...]ドロップダウンで表示できます。 何も正しくキャプチャできなかった場合はお知らせください。

私はこれをWinUIチームに売り込みました。ここで定義された機能は、エラーメッセージだけでなく、アプリ全体の長期的なステータスメッセージ全体を提供できると考えています。 これには、エラー固有のシナリオに加えて、「更新可能」および「バックアップ完了」の種類のステータスメッセージが含まれます。

このより包括的なアプローチを反映するように問題を更新しました。 これらのメッセージを表示するために必要なUI出力部分を検討できるように、今後数週間で要件とシナリオを完成させたいと思っています。

上記のリクエストを言い換えます。 @ sapallie 、@ adrientetar 、@ EverydayApps @ Felix-Dev、@ mdtauk 、および@mrlacey 、アプリケーションに表示したいステータス/エラーメッセージについては、ここまたは[email protected]で次の情報を提供してください。

• アプリのタイトル
• シナリオの説明（ステータスメッセージ、クリティカル/非クリティカル、およびそれをどのように提示したいかの説明）
• エラーが発生するアプリ画面のスクリーンショット（利用可能な場合）

可能であれば、imo、ポップアップダイアログは避ける必要があることに注意してください。 ウェブはいたるところにポップアッププロンプトでいっぱいで、目を引くように流れを中断します。 たとえば、コントロールに何かをロードできなかった場合など、空のステータス（例）を優先する必要があると思います。

@mdtaukが投稿したビジュアルに関して、画面/アプリの4つの端すべてからポップアップを表示する必要が本当にありますか？ WinUIのポイントは、そのようなアイテムの位置と外観を標準化して、すべてのアプリが同じものを使用するようにすることです。その点で、Androidスナックバーは明らかなリファレンスです。 Snackbarで注意すべきもう一つのことは、真っ赤な色などでエラーを表示しないことです。それは落ち着いた外観であり、ユーザーがしていることにあまり気を取られないようにするのに再び有益だと思います。

たとえば、ダイアログの代わりにこのポップアップをいつ使用するかについてのガイダンスも必要です。そうしないと、断片化が発生するだけです（さまざまな方法でメッセージングコントロールを使用するさまざまなアプリ）。

フライアウトには配置の概念があり、このコントロールは同じことを行うことができます。 ページまたはタブのコンテンツなど、コンテナコントロールの内側の端から表示されます。

@adrientetarすべてのアプリが同じであるとは限らないため、このコントロールにはデフォルトがありますが、開発者がコントロールを再テンプレート化または再設計することなく、この場所を変更する方法が必要です。

Officeはリボンの下のスペースを使用します。 Edgeは画面の下部を使用します。 Windows自体のみが、シェルまたは画面の端にアタッチできます。アプリがシステムレベルのアラートを模倣するのを防ぐのには、おそらく十分な理由があります。

さらに、開発者は独自のアラートコントロールのスタイルを変更できるため、この段階では、可能な限り柔軟である必要があります。その後、シェルチームは、コントロールの使用にどのような制限が適用されるかについて意見を述べます。

あなたの電話チームはこれらの種類のコントロールの1つを持っているので、彼らが遭遇した問題を尋ねて、それが完了して含まれたときにWinUIコントロールの使用に移行するように説得することができますか？

Dropboxもデザインシステムでスナックバーを使用しています（下にスクロールして、画像の最後から2番目の行）。

最近、アプリ全体の長期的なステータスメッセージの例をさらにいくつか見つけました。

（Teamsでの「録音開始」メッセージ）

（Dota 2の「ゲームコーディネーターに接続しようとしています」）

申し訳ありませんが、これらは小さいです。最初の写真は、超ワイドモニターを使用してデスクトップからスナップしたものです。 :)

一部のドロップボックススナックバーには、下部にプログレスバーがあります。 これをここに含める必要がありますか？ たとえば、アップロード、ダウンロード、更新、進行状況の同期などの場合に意味があります。 それは必須のイモではありませんが、多分できるか、すべきですか？

これらは丸める必要がありますか？ またはいいえ？

ええ、ここでのTeaching Tipとの主な違いは、アプリがメッセージングスペースを調整する必要があり、同時に（または連続して）表示する複数のエラー/ステータスの更新がある可能性があることです。

理想的には、これは開発者が構成してアプリ内に配置し、メッセージもパイプする1つのコントロールだと思います（エラー、ステータス、警告、またはその他の一般的なメッセージを示す何らかのタイプがあると思います）。

バナーとポップアップの両方の場合で、複数のメッセージが含まれる可能性のあるアプリを見てきました。 場合によっては、バナーをスタックしてUI領域を支配することがあるので、このソリューションがそれを回避できれば便利です（ただし、開発者がコントロールの複数のインスタンスを使用してその動作を再作成することを妨げるものは何もありません）。

右下にスタッキングポップアップ通知パネルがあり、追加のアクションボタンもあるので（たとえば、設定にジャンプするために）、VSCodeも呼び出されていないことに驚いています。

VSコード例のスクリーンショット：

左上に表示されるさまざまな種類のアイコン、カスタマイズ可能なボタンアクション、および「歯車」アイコンを使用して、拡張子ごとの通知に関する設定を構成する機能があります。

コルタナのこのスクリーンショットを見たばかりです...

Office UIファブリックのMessageBarは見栄えがします、IMO：

私は、Samsung Notes for Windows 10が通知トーストを使用して、メモが何も入っていなかったためにメモが破棄されたことを説明していることに気づきました。

皆さんこんにちは！ 私はWinUIのプログラムマネージャーであり、@SavoySchulerからこの提案を取り戻しています。 このスレッドでは、すでに多くの素晴らしい議論とアイデアの共有が行われています。すべての提案に感謝します。

ここでいくつかの活動があったので数ヶ月が経ちましたので、私は皆と一緒にチェックインして、私たちが現在いるところを繰り返したいと思いました。

提案の上部にある現在の範囲の要約として：

• 通知は、アプリケーション全体に関連する重要な情報をユーザーに警告するためのものです。
• カスタムコンテンツとスタイリングをサポートします
• 自動的かつプログラムで却下できるようになります
• 通知はユーザーが却下できる必要があります
• アプリの指定方法に応じて積み重ねることができる複数の通知をサポートする必要があります
• アプリのサイズ変更とUIの変更に対応する必要があります
• 通知は、システム全体の通知を表示するためのものではありません

スコープの概要で何かを見逃した場合、または同意できない場合は、遠慮なくコメントしてお知らせください。 先に進む前に、全員が同じページにいることを確認したいです😊

スコープを定義したので、まだ定義する必要のある特定のシナリオとユーザーエクスペリエンスがいくつかあります。 私の希望は、これらのエクスペリエンスを定義することが、コントロールのUIアフォーダンスのガイドに役立つことです。 あなたのシナリオについてどう思いますか？
CC：@ sapallie 、@ adrientetar 、@ EverydayApps @ Felix-Dev、@ mdtauk 、@ mrlacey

経験は次のとおりです。

• 通知がビューを離れる方法
  
  
  
  • ユーザーが手動で通知を閉じる
  
  
  • 通知は自動的にタイムアウトになり、自動的に閉じられます
  
  
  • 通知は、ユーザーが最初に通知が表示された理由に関連するアクションを実行した後にのみ消えます。
    
    
    
    
    
    • つまり、インターネットが切断されたという通知を受け取った後、通知はインターネットが切断されたときにのみ消えます
    
    
    
  
  
  • 他の？
  
  
• ユーザーが通知にどのように反応するか
  
  
  
  • 通知に関連するアクションをすぐに実行します
  
  
  • 通知に関連するアクションを後で延期する
  
  
  • 通知を完全に無視および/または却下する
  
  
  • 他の？
  
  
• 通知が表示されるタイミング
  
  
  
  • アプリの起動時
  
  
  • アプリのステータスからプログラムで
  
  
  • ユーザーがアクションを実行した後（つまり、ドキュメントのバックアップを選択した後）
  
  
  • 他の？
  
  
• 複数の通知を一度に表示できる場合とその理由

いつもお世話になっております。これをお伝えできることを楽しみにしております。

この提案が忘れられていないことを嬉しく思います@gabbybilkaそしてそれを引き受けてくれてありがとう！

可能であれば、これらの種類の通知UIを含むファーストパーティアプリで作業しているユーザーに連絡して、カスタムソリューションからWinUIネイティブコントロールに移行するための要件のリストを作成することができます。 彼らのニーズは、コミュニティの要望やニーズと組み合わされて、このコントロールのV1を十分にカバーする必要があります。

@chigyは、Fluent Designチームと協力しているため、最終的な設計仕様について話し合う人になるでしょう。

他の人が一貫したWinUIコントロールを使用することを奨励される場合、Microsoftはこれを例として先導する必要があります。

• コルタナ
• Grooveミュージック
• 映画とテレビ
• あなたの電話

それらが頭に浮かぶアプリです。

@gabbybilkaは、Windows Community Toolkitにもコントロールがあるので、いつでも喜んで話し合います。 ここにユーザー用のアップグレードパスがあり、それをToolkitからWinUIに移行するのは本当に素晴らしいことです。

最初の要約から、ほとんどのことをカバーしていると思いますが、オプションの実用的なボタンもあることについて何かを呼びかけるのは良いことでしょうか？ それとも、それは常にカスタムコンテンツでしょうか？

ツールキットからの制御の履歴を含むツールキットからのフォローアップ（しばらく経ちました）：

• 元の問題
• 最初のPRレビュー
• GitHubの履歴-1ページで完全なリストを取得する方法がわからないため、下にスクロールして[古い]をクリックし続けます

ツールキットのスタイルは、元のMicrosoftEdgeおよびVSCode通知スタイル（両方ともそれ以降更新されています）をモデルにしています。 ただし、示されているように、柔軟性があり、再テンプレート化可能であり、トップレベルのステータスバーのOfficeスタイルの警告または一般的なポップアップスタイルの通知の両方で機能します。

また会いましたね！ これに関する最新情報として、私は最近、この提案をチームに再提案し、この機能をさらに定義するための先に進むことを受け取りました。

前に概説したシナリオでは、現在InformationBar （略してInfoBar）というタイトルのコントロールを作成して、長期にわたるアプリ全体の重要なステータスメッセージを表すことを目指しています。 最初のビジュアルデザイン思考は、FluentUIのMessageBarと、Teamsが「NowRecording」および「Internetdisconnected」メッセージを表示する方法に触発されています。
具体的には、アイコン、タイトル、柔軟なメッセージ領域、および閉じるボタンを、コンテナ内の主要な最小のビジュアルコンポーネントとして含めます。これは、デフォルトで、それが存在するコンテンツ領域の幅に合わせます。前述のように、InfoBarは次の方法で閉じることができます。ユーザーまたはプログラムでステータスに影響を与えるアプリの機能が解決されたとき、つまりインターネット接続が復元されたとき、イントロ/エグジットアニメーションはありません。

チーム（現在録音中）

Office（互換モード）

チーム（インターネットなし）

APIが結晶化し始めたら、仕様について話し合いを始めます。 それまでの間、InfoBarを使用するシナリオと、必要な機能を引き続き共有してください😊

議論の前半で、 @ mrlaceyと他の人は、言及されたシナリオをカバーできる2つの別々のコントロールを持つ可能性を持ち出しました。

私はこれらの2つの概念を考えます：

• 0個以上の実用的なサブ要素を持つ却下可能な全幅バナー
• ステータスの変更を示すことを目的とした、単一のボタンとして機能するバナー

個別のコントロールとして、最大の価値と最小の混乱を提供します。

InfoBarの視覚的なスタイルとコンポーネントは、以前に共有されたユースケースの一部に適合しない可能性があることを認識しています。 特定のアプリのシナリオと機能で異なる視覚スタイルが必要な場合は、このスレッドでそれらの状況を共有し続けてください。

みなさん、ありがとうございました！

コントロールは、テンプレートとスタイリングでうまく機能するように設計する必要があります。これにより、すべての動作がコントロールのプロパティである一方で、ニーズに合わせて成形できます。
アニメーション化するか、アニメーション化しないでください。
[閉じる]ボタンを表示するか、非表示にします。
位置。
アイコンを表示するかどうか。

等

InfoBarの視覚的なスタイルとコンポーネントは、以前に共有されたユースケースの一部に適合しない可能性があることを認識しています。 特定のアプリのシナリオと機能で異なる視覚スタイルが必要な場合は、このスレッドでそれらの状況を共有し続けてください。

みなさん、ありがとうございました！

今後は素晴らしいことです。 示されているような視覚的なスタイルは、私がアプリを使いたくないという点で、多くの要望を残します。

@mdtaukが投稿したデザイン、または上記のCortanaスクリーンショットの方がはるかに望ましいでしょう。 アプリのデザインは、プログラムにとらわれずに前進する必要があります。

これは、プレゼンテーション/デスクトップ共有中に使用されるような非表示のCommandBarとしても機能しますか？ 例えば

すべてのオーバーレイをサポートするわけではないことはわかっていますが、幅を固定してアプリのオーバーレイレイヤーに配置するという点では、この方向でデザイン/機能のオーバーラップが類似していることがわかりました。

@mdtauk

コントロールは、テンプレートとスタイリングでうまく機能するように設計する必要があります。これにより、すべての動作がコントロールのプロパティである一方で、ニーズに合わせて成形できます。
アニメーション化するか、アニメーション化しないでください。
[閉じる]ボタンを表示するか、非表示にします。
位置。
アイコンを表示するかどうか。

@shaheedmalik

今後は素晴らしいことです。 示されているような視覚的なスタイルは、私がアプリを使いたくないという点で、多くの要望を残します。

@mdtaukが投稿したデザイン、または上記のCortanaスクリーンショットの方がはるかに望ましいでしょう。 アプリのデザインは、プログラムにとらわれずに前進する必要があります。

フィードバックをありがとうございます。 Fluent Designシステムでのこの基本的な動作とカスタマイズ性に対して、コントロールは十分に柔軟でなければならないことに同意します。 私が共有したビジュアルは、主に以前に実装された例の参照でした。
カスタマイズ可能で、アプリ全体のさまざまなステータスメッセージのシナリオに十分に役立つことを保証しながら、機能が多すぎる単一のコントロールのオーバーロードのバランスを取り続けるよう努めます。

これは、プレゼンテーション/デスクトップ共有中に使用されるような非表示のCommandBarとしても機能しますか？ 例えば

@ michael-hawker

これはまだスレッドで取り上げられていない興味深いシナリオであり、このコントロールによってサポートされる可能性があると思います。 私たちの注意を引いてくれてありがとう！ スコーピングに関しては、これは優先度の低いシナリオのようですが、オーバーレイの優先順位付け以外では、設計/機能が類似していることに同意します。

この問題に関する更新はありますか？ 現在、Files UWPでファイル操作のステータスを表示するUIを計画しています。私たちが傾倒している設計は、ここで提案されているそのような機能の恩恵を受けることができます。

こんにちは@yaichenbaum 、チェックインしてくれてありがとう！ この提案の最新情報として、ドラフトを開始している仕様書を共有できることをうれしく思います。

これまでに定義された内容の要約として、「バー」と「トースト」または「カード」の2つの視覚モードを備えた単一のコントロールを作成することを選択しています。 現在の取り組みは、「バー」モードの定義とプロトタイピングです。 これら2つのモードのコンポーネントは同じであり、視覚的なレイアウトのみが異なるように計画されています。 複数の視覚モードがあるので、私は現在、InformationBarの代わりにこのコントロールStatusBannerを単一の「バー」スタイルに制限しないと考えていますが、名前の付け方についてのアイデアを自由に共有してください😊

レイアウトの左から右へのStatusBannerの主なコンポーネントは次のとおりです。

• ステータスカラー
• アイコン
• タイトル
• メッセージ
• アクションボタン
• 閉じるボタン

これらのプロパティはオプションであり、「Content」プロパティを介したカスタムコンテンツは引き続きオプションです。

さらに、開発者が設定できるさまざまなBannerTypeを定義し、ステータスに応じてアイコンと色の組み合わせを事前設定することを計画しています。 これにより、通知の重要度に基づいて正しいアイコンまたはBannerColorを簡単に選択でき、アプリケーション間で一貫性を保つことができます。 IconまたはBannerColorのカスタマイズもサポートされています。

アクションボタンまたはカスタムクローズボタンのない「バー」モードのStatusBannerのペーパープロトタイプ。

StatusBannerバーのレイアウトの現在のデザインは、 @mdtaukのステータスカードのデザインに大きく影響を受けています。ありがとうございます。

仕様の現在の状態に関するフィードバックを共有したい場合は、この問題にコメントしてください。 次のステップは、デザインとコードスニペットを固め（そしてより多くのユースケースをカバーするように拡張し）、スタッキングやメッセージラッピングなどの機能を定義することです。 みんなありがとう！

その間、 @yaichenbaumにはツールキットのInAppNotificationコントロールがあります。

@gabbybilka更新のおかげで、ユースケースに必要な重要な機能は、このスレッドで以前に共有した@hawkermのように、一度に複数のステータスメッセージを表示する機能です。 コントロールに複数のステータスメッセージの配置を処理させることはプラスになります。

その間、 @yaichenbaumにはツールキットのInAppNotificationコントロールがあります。

@hawkerm InAppNotificationについてはあまり調べていませんが、準備ができたら新しいコントロールに切り替えるのではなく、WinUIバージョンを待ちたいと思います。

こんにちは、みんな！
前回の更新から現在までの時間が足りなかったことをお詫びします。このコントロールの定義に懸命に取り組んできました😊
数週間前に@chenss3のプロトタイプがリポジトリにマージされるのを見たことがあるかもしれませんが、これが実現するのを見て本当に興奮しています！ この段階では、プロトタイピングとアプリケーションでの使用に関心のあるこのコントロールの消費者とつながることに関心があります。 開発しているアプリケーション、このコントロールを使用しているときのシナリオ、開始するための支援が必要な場合は、プロトタイプを使用したフィードバックに連絡して共有してください。

複数の通知の配置とスタックをサポートするこのコントロールのポップアップバージョンの実装の詳細を把握し始めたので、近い将来、インラインバージョンで作業を続けることにしました。 一部のシナリオでポップアップ機能が必要な場合のフィードバックをお待ちしており、今後もその方向に進んでいきます。 その間、以下のモックアップにより近いプロトタイプの次のバージョンを開発しています。

さらにいくつかの例を確認したい場合は、仕様を確認してください。

皆様、ありがとうございました。ご連絡をお待ちしております。

これはWinUI3で利用できるだけですか、それともWinUI 2プレリリースに入る予定ですか？

@kmgallahan WinUI 2プレリリース。プロトタイプとプレビューのバージョンについて、コミュニティと顧客からもう少しフィードバックを受け取りたいので、正確な出荷バージョンはまだわかりません。

早期のフィードバックを最大化するために、このようなプロトタイプをできるだけ簡単に試すことをお勧めします。 たぶん、免責事項を含むプレリリースビルドにそれらをプッシュするか、開発/ベータリリースを提供します。

プロトタイプを試すためにWinUIの開発ブランチを構築する必要があることは、特に（とにかくコードベースへの）貢献者ではなく主にWinUIコンシューマーである場合に、かなりの摩擦をもたらします。

同意しました。プロトタイプがソリッドステートになったら（表示されているモックアップに似ており、さまざまな入力オプションがサポートされています）、2.5プレビューにします。 その時に試してみることができますか/興味がありますか？

今すぐ試してみたいと思っています。ビルドにWinUIのような大規模なプロジェクトを追加するのではなく、NuGetから使用する方が好きです。

今のところ、プレビューになるものは何でも待ちます。

また会いましたね！ いくつかの更新：

• 仕様は引き続きレビューされ、繰り返されています。 このPRでお気軽にチェックしてコメントを残してください。 注目すべき変更は、ButtonBaseから継承する独自のコンテンツを取り込む汎用のActionButtonプロパティの追加です。

  • 私が指摘したい現在のモックアップの矛盾は、このActionButtonの場所です。 仕様では、アクションボタンは現在、閉じるボタンのすぐ左に右揃えで表示されていますが、実際の場所はメッセージのすぐ右にあります。 私の前のコメントと下に示されている画像は正しい場所です。 改善されたモックアップは、開発が進むにつれて更新され、仕様に追加され続けます😊

• @teaPは、WinUI 2.5プレリリースに向けて移行するにつれて、このコントロールのネイティブバージョンの実装を開始しました。 ありがとう！

以前と同様に、自分がこのコントロールの潜在的なユーザーであると思われる場合は、開発しているアプリケーションと、InfoBarを使用するシナリオについて自由にコメントしてください。 みんなありがとう！

また会いましたね！ 強調するために、@ teaPは、 InfoBarのプルリクエスト＃3325を最近開いたので、チェックアウトしたい場合は😊

なぜこれはInfoBarと呼ばれるのですか？ 情報は、含めることができる情報の1つの小さなクラスにすぎません。 また、エラーと警告に加えて、それらに基づくアクションもサポートします。 バーはまた、コントロールの「形状」を人為的に制約しています。 バー以外にも、いくつかのユースケースがあります。

私の意見では、NotificationViewやMessageViewなどの方が良い名前でしょう。

なぜこれはInfoBarと呼ばれるのですか？ 情報は、含めることができる情報の1つの小さなクラスにすぎません。 また、エラーと警告に加えて、それらに基づくアクションもサポートします。 バーはまた、コントロールの「形状」を人為的に制約しています。 バー以外にも、いくつかのユースケースがあります。

私の意見では、NotificationViewやMessageViewなどの方が良い名前でしょう。

もともとはStatusBannerとして提案されました
その後、 InformationBar/InfoBarに変更されました

このコントロールのFluentUIバージョンはMessageBarと呼ばれます

要約をありがとう。 名前はまだ私にはあまり意味がありません。 現在のコントロールの設計方法は通知です。 より一般化すると、ヘルプ/教育シナリオもサポートできるように、「メッセージ」にする必要があります。 さまざまな概念を一般化して、コントロールのより良い設計を次に示します。

1. 〜MessageView〜またはヒント：オプションのアクション、タイトル、グリフ、画像、およびボタンを使用して、ステータス、ヒント、または教育情報をユーザーに表示するためのコントロール。 これはどこにでも配置でき、ポップアップではありません。 また、さまざまなレイアウトをサポートします。

2. TeachingTip ：MessageViewをホストするフライアウト/ポップアップ。

   • ホストされたヒント

3. NotificationBarまたはStatusTip ：アプリケーションまたはビューの上部にある「バー」形式のアプリ全体の通知。

   • ホストされたヒント

4. ツールチップ：アクションや画像などをサポートするチップもホストできるようになります。

   • ホストされたヒント

私たちは本当に一般的な用語で考え、高レベルの概念を同じコントロールに組み合わせる必要があります。 それ以外の場合は、類似しているが異なるプロパティを持つ非常に特殊なコントロールを多数作成します。

一般的な「MessageView」コントロールの完璧な名前を考えました。これを「ヒント」と呼びます。 ToolTipもそれをホストできます。 それに応じて更新されました。

これは、いくつかの入力フィールドの上部にある通知バーの別の「実際の」例です。 現在のコントロールは、そのシナリオに役立ちます。

これは、いくつかの入力フィールドの上部にある通知バーの別の「実際の」例です。 現在のコントロールは、そのシナリオに役立ちます。

TextBoxesは、これの一部をカバーできる検証状態を取得しますが、これがさまざまなコントロールの表示方法です...

• ユーザーが積極的に識別したい単一の要素のツールチップ。
• 開発者がユーザーに気付かせたい単一の要素のTeachingTip （要素にアタッチされていない場合もあります）。
• 開発者が情報を提供したいアプリ/コンテンツ領域全体のInfoBar 。
• フライアウト/ダイアログは、開発者がユーザーに何かを読んだことを確認してから却下することを希望する場合に使用します。
• 開発者がユーザーに何よりも選択またはアクションを実行するように要求する場合のコンテンツダイアログ。

また、OSレベルの通知と通知センターがあるため、通知という言葉の使用は避けます。

また、OSレベルの通知と通知センターがあるため、通知という言葉の使用は避けます。

そうですね、開発者は違いを知っていると思いますが、それは確かに公正な点です。

また、多くの個別のコントロールを作成できることも事実です。 しかし、通知/ステータス/メッセージ/ヒント/教育に関しては、一緒に組み合わせることができるいくつかの高レベルの概念が確かにあります。 少なくとも、これらすべてからインターフェースを作成する必要があります。

Flyout / Contentダイアログは、ほとんどの場合、一般的なコンテンツコントロールであるため、別個の概念です。

さまざまなシナリオでホストする一般化された「メッセージビュー」タイプのコントロールの完璧な名前を考えました。これを「ヒント」と呼びます。 上記のコメントを適宜更新しました： https ：//github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

さまざまなシナリオでホストする一般化された「メッセージビュー」タイプのコントロールの完璧な名前を考えました。これを「ヒント」と呼びます。 上記のコメントを適宜更新しました： ＃913（コメント）

重要な警告やエラーメッセージをヒントに入れるのは気が進まないでしょう...

また、多くの個別のコントロールを作成できることも事実です。 しかし、通知/ステータス/メッセージ/ヒント/教育に関しては、一緒に組み合わせることができるいくつかの高レベルの概念が確かにあります。 少なくとも、これらすべてからインターフェースを作成する必要があります。

Flyout / Contentダイアログは、ほとんどの場合、一般的なコンテンツコントロールであるため、別個の概念です。

私はこのアイデアが本当に好きです。 アイコン、タイトル、メッセージ、アクションボタンのAPIには、これらの情報コントロール全体で一貫性のある共通点があると思います。 InfoBarを使用すると、この現在のバージョンで実装できるものかどうかはわかりませんが、この性質の次の制御のために実装できる可能性があります。

さまざまなシナリオでホストする一般化された「メッセージビュー」タイプのコントロールの完璧な名前を考えました。これを「ヒント」と呼びます。 上記のコメントを適宜更新しました： ＃913（コメント）

重要な警告やエラーメッセージをヒントに入れるのは気が進まないでしょう...

私もこれに同意します...さらに調査を行う必要があります。

さまざまなシナリオでホストする一般化された「メッセージビュー」タイプのコントロールの完璧な名前を考えました。これを「ヒント」と呼びます。 上記のコメントを適宜更新しました：＃913（コメント）

重要な警告やエラーメッセージをヒントに入れるのは気が進まないでしょう...

私もこれに同意します...さらに調査を行う必要があります。

既存のすべてのコントロールやアイデアにどれだけうまく適合するかを考えてください。その点では完璧です。 しかし、はい、それはエラー/警告の文脈では場違いに見えます。 人々はすぐにそれを理解すると思いますが、私はその論理について議論することはできません。

なぜこれはInfoBarと呼ばれるのですか？ 情報は、含めることができる情報の1つの小さなクラスにすぎません。 また、エラーと警告に加えて、それらに基づくアクションもサポートします。 バーはまた、コントロールの「形状」を人為的に制約しています。 バー以外にも、いくつかのユースケースがあります。

私の意見では、NotificationViewやMessageViewなどの方が良い名前でしょう。

InfoBarは必ずしもバーであるとは限らないというあなたの意見に同意しますが、名前に「bar」を含めることは、視覚的にも概念的にもアプリ全体のシナリオを対象としていることを意味すると思います。 「情報バー」の画像を検索すると、IEからの同様のエクスペリエンスの画像が見つかります（必ずしもIEと一致させようとしているわけではありません）。これは、期待される視覚的および機能的なレイアウトを示していると思います。 私はこれを「表示」とは見ていませんが、メッセージや通知に焦点を当てることは好きです。

@gabbybilkaはい、古いStatusBarや新しいAppBar ... CommandBar ...などと非常によく似ています。問題は、コントロールの使用法をかなり一般化して、任意の場所にヒントやメッセージを表示する必要があることです。 「表示」も100％に適合しませんが、一般的な名前に近いです。 本当に私の懸念は、根底にある概念を統一することです。そうすれば、複数のコントロールが同じことのバリエーションを実行することになりません。

2つの場所での複数のコメントで自分自身を混乱させるために編集されました。

私が他の問題の1つに投稿した反響する考え...

_コントロールのフローティングモードがV2で考慮されなくなったという事実に対応して_
行動や形式の変化により、代わりにTeachingTipに目を向けることは理解できますが、重大度、ステータスの色、およびTeaching Tip自体のデザインの欠如は、同じ種類のTeachingTipとは互換性がないことをお勧めします。 InformationBarコントロールが対応しているメッセージ。

フルスクリーンWinUIアプリ、狭い幅のウィンドウ、およびHololensやXboxなどの画面幅とUIレイアウトの違いは、ドッキングされたバーフォームファクターには適していません。

したがって、そのことを念頭に置いて、おそらくInformationBarをInformationCardコントロールとともにAppMessage APIにラップする必要があります。これにより、重大度、色、タイトル、メッセージ、アクションボタンなどの同じプロパティをXAMLまたはアクションボタンに配置できます。アプリのコード-およびそれらが画面に表示される方法は、フォームファクター/デバイスファミリーに合わせて変更されます。

アタッチされていないTeachingTipが代用する可能性はありますが、アプリステータスメッセージに適したカスタマイズはサポートされません。これは、このコントロールの背後にある本来の意図です。

では、実際には単なるメッセージである「ヒント」があるとしたらどうでしょうか。 グリフ、画像、メッセージテキスト、タイトルがあります。

次に、Tipから派生して、重大度、アクションなどを追加するAppMessageがあります。 その場合、TipはTeachingTipとToolTipで現在も使用できます。 また、私のシナリオでは、インラインの連続的なヒントにも役立ちます。

では、実際には単なるメッセージである「ヒント」があるとしたらどうでしょうか。 グリフ、画像、メッセージテキスト、タイトルがあります。

次に、Tipから派生して、重大度、アクションなどを追加するAppMessageがあります。 その場合、TipはTeachingTipとToolTipで現在も使用できます。 また、私のシナリオでは、インラインの連続的なヒントにも役立ちます。

しっぽのないTeachingTipはあなたの状況にぴったりのようです...

しっぽのないTeachingTipはあなたの状況にぴったりのようです...

TeachingTipでそれができるとは知りませんでした。 また、私のコントロールはTeachingTipよりもずっと長いので、これまでアップグレードを実際に調査したことはありませんでした。 いずれにせよ、あなたがそれを行うことができれば、それは私の側の見落としです。

編集：気にしないでください、尾がなくても、それはまだ何らかの方法で却下されるオーバーレイです。 私が説明している「ヒント」はすべてインラインであり、ユーザーが基本的に最初の要素を作成するまで持続します。 これは、ポップアップ、フライアウト、またはその他の非永続的なビューではなく、情報を表示する単なるコントロールです。

複数の場所で使用されるインターフェース/コントロールに分割するための多くの共通点があると私はまだ確信しています。 私たちが議論しているこれらのコントロールはすべて、違いよりもはるかに多くの類似点があります。 変化するのは、基礎となる情報が提示される場所/方法だけです。 これはすべて単純化するために熟しています。

しっぽのないTeachingTipはあなたの状況にぴったりのようです...

TeachingTipでそれができるとは知りませんでした。 また、私のコントロールはTeachingTipよりもずっと長いので、これまでアップグレードを実際に調査したことはありませんでした。 いずれにせよ、あなたがそれを行うことができれば、それは私の側の見落としです。

複数の場所で使用されるインターフェース/コントロールに分割するための多くの共通点があると私はまだ確信しています。 私たちが議論しているこれらのコントロールはすべて、違いよりもはるかに多くの類似点があります。 変化するのは、基礎となる情報が提示される場所/方法だけです。 これはすべて単純化するために熟しています。

分解すると、アイコンとテキストのみであり、「コンテキスト」は関連付けられていません。 しかし、それをAppMessageにラップするという私の提案には、私が推測するUIの別の形式としてNonAttachedTeachingTipsを含めることができます。

分解すると、アイコンとテキストのみであり、「コンテキスト」は関連付けられていません。 しかし、それをAppMessageにラップするという私の提案には、私が推測するUIの別の形式としてNonAttachedTeachingTipsを含めることができます。

申し訳ありませんが、上記の私の編集を参照してください。 ティーチングチップはまだインラインではなく、却下されるまで下部に浮かんでいます。 考慮すべき画像とタイトルもあります。

分解すると、アイコンとテキストのみであり、「コンテキスト」は関連付けられていません。 しかし、それをAppMessageにラップするという私の提案には、私が推測するUIの別の形式としてNonAttachedTeachingTipsを含めることができます。

申し訳ありませんが、上記の私の編集を参照してください。 ティーチングチップはまだインラインではなく、却下されるまで下部に浮かんでいます。

一番下にある必要はありません。

インラインは、その周りの他のコンテンツを置き換えるため、ヒントの珍しいユースケースである可能性があります。

V2がインライン/非フローティング表示モードのサポートを追加することを提案できます

@mdtaukのコメントにもう少しコンテキストを与えるために、仕様の「InfoBarV2の対象機能」セクションからフローティングモードを削除することに関する彼の質問に対する私の最初の回答を次に示します。
私から：

デザインの議論のためにここに飛び乗ってください。 V2の意図した機能が変更されていることに注意してください😉現在、いくつかの理由から、V2バージョンのInfoBarのフローティングモードを確約していません。 フローティングモードをInfoBarに含める必要があるのか​​、それともトーストのような通知をまったく別のコントロールにする必要があるのか​​をさらに詳しく調べたいと思います。 調査中に、フローティングモードの基本的な実装はTeaching Tipに非常に似ており、スタッキング、ポジショニング、オーバーレイの選択（WCT InAppNotificationのStackModeを参照）などのトーストのような通知シナリオ機能を完全に調査する必要があることがわかりました。 これにより、InfoBarの範囲と意図が、当初の焦点よりもはるかに広くなるように拡張されます。 注目すべきは、InfoBarにフローティング機能を追加することについての扉を完全に閉ざしたわけではありませんが、そうではないということです。

基本のAppMessageクラスに基づくInformationBarとInformationCardの提案については、私はこのアイデアが好きです。 「フォームファクター/デバイスファミリーに合わせて画面に表示される方法が変わる」とおっしゃっていましたが、これについてはさらに詳しく調べたいと思います。 カードUXに適したシナリオ（特に、一時的なメッセージ、ページ固有のエラーメッセージ、ドッキング可能なサーフェスのないアプリ）は、バーUXよりも優れていると思います。その逆も同様です。

私にとって、InfoBar / InfoCard / Teaching Tipを使用する「いつ」（視覚的および機能的なニーズに関連付けられている）と「なぜ」（エンドユーザーの認識と経験の一貫性に基づく）の両方に違いがあります。 一時的なメッセージは、InfoCardでサポートされるべきであり、InfoBarではサポートされるべきではないものとして私にとって明確なハイライトです。 永続的なオーバーレイコンテンツはアクセシビリティの観点からサポートするのが難しいため、ユーザーが却下できないメッセージはその逆の例です。

ただし、脇に追いやられないでください:)これらのさまざまなコントロールはすべて、ほとんどの場合、同じタイプの情報を、異なる領域/スタイルで表示しています。 これは一般化して統一する必要があります。 それを呼び出したい場合は、1つの一般的な「AppMessage」コントロールを統合できると思います。 次に、その「AppMessage」をさまざまな方法で表示するためのさまざまなコンテナを用意します。 これは、TeachingTIp、ToolTip、NotificationBar、カードなどの場所で表示できます。各コンテナーは、ユースケースに合わせてスタイルを変更できます。 ただし、基礎となるプロパティとタイプは統一されます。

@gabbybilkaの返信でコンテキストを誤解しようとしていませんでした😄

基本のAppMessageクラスに基づくInformationBarとInformationCardの提案については、私はこのアイデアが好きです。

これがネーミングの出番です。私は「AppMessage」が好きです（「Tip」はずっと計画だったように見えますが、素晴らしいでしょう）が、それを使用する場合は、「MessageBar」と「MessageCard」ホスティングである必要がありますそれ。

私にとって、InfoBar / InfoCard / Teaching Tipを使用する「いつ」（視覚的および機能的なニーズに関連付けられている）と「なぜ」（エンドユーザーの認識と経験の一貫性に基づく）の両方に違いがあります。

私はこれらのさまざまなユースケースとプレゼンテーションに間違いなく同意します。 しかし、彼らはまだ一般化および標準化できるメッセージを提示しています。 私たちは今、その概念に同意していると思います:)

カードメッセージ/ヒントの例

私が思う目的の1つは、受信トレイとファーストパーティのアプリ/ Windowsシェルを、カスタムソリューションから一貫した受信トレイコントロール/APIの使用に移行するように促すことです。

おそらく、UWPアプリでは、これらの概念のいくつかに取り組んでいることを追加する必要があります。 この議論に関連する簡略化されたバージョンは次のとおりです。

次のプロパティを持つ'Message'クラス（コントロールではなく、データ構造のみ）があります。

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

優先順位は基本的にあなたがすでに決定したものと同じです（それは今日かなり標準化されています）。 DisplayModeは、Notification、None、およびPopupをサポートします。 メッセージがバックエンドコードによって生成されると、フロントエンドに渡され、アプリの上部にある「バー」にクイック通知として表示されます。 または、より重大なメッセージのブロックポップアップとして。

さらに、メッセージを単独で受け取るが、グリフとタイトルを追加し、それを前に説明したインラインのコンテキスト「ヒント」として表示する「MessageView」コントロールがあります。

それがまさに私が提案することです。Appレイヤーで抽象化を行います。 どちらのビューにもアタッチできる単純なViewModelクラスがあります。 実行は簡単で、より柔軟です。 また、好みのロギングフレームワークを使用してロギングを実行したい場合、カスタムの優先順位を設定したい場合、独自のデータを追加したい場合があります。 ViewModelですべて簡単に実行できます。

あなたが言及したコントロールの目的は、各アプリにわずかに異なるUIと動作を持たせるのではなく、多くのアプリとOSのユースケースにわたって特定のシナリオを実行する統一された方法を提供することです。 ツールチップとInfoBar/MessageBarは、開発者とエンドユーザーの両方にとってよく知られている概念です。 どちらも情報を提供しますが、それらは非常に異なる目的で使用されます。 これらに共通の基本クラスまたは共通の概念を持たせることには、あまりメリットがありません。 グローバルアプリのインフォバーにすでに表示されているツールチップにメッセージを入れたいのはなぜですか（そしてこのツールチップをどこに添付しますか）？ これが多くの再利用につながるとは限りません。

一般的な概念がはるかに有用なIMOである他の領域があります。 Button、AppBarButton、MenuItemについて考えてみてください。 これらはすべてテキストとアイコンを表示し、すべてアクションをトリガーするために使用されます。 多くの場合、MenuItem（ContextMenu）とAppBar/CommandBarの両方で同じコマンドを提供します。 ここでは、コマンド、テキスト、アイコン、場合によっては長いメッセージ（ツールチップ）を配置できる一般的な概念が非常に役立ちます。 しかし、ToolTipとMessageBarに共通の概念がありますか？ 私は本当にこれの必要性を見ていません。 もちろん、UWPを最初から書き直すとしたら、共通の基本クラスを思いついたかもしれません。 しかし、私はそれが必要であるとか、過度に役立つとは思いません。

@lukasfあなたのポイントは理にかなっています。 それはアプリ自体で行うことができます。 ただし、非常によく似た概念がたくさんあり、ここで統一することで誰もが恩恵を受けることができます。

ツールチップは、メッセージとともにグリフとタイトルを付けることでメリットが得られるため、ディスカッションに投入されました。 概念的には、これらのコントロールはすべて何らかの形式のメッセージでもあります。表示される場所と方法のみが異なります。 大規模な標準化を行わなくても、MessageBarとMessageCardには多くの共有プロパティ/タイプが必要です。 MessageCardPriority浣腸と一緒にMessageBarPriorityを使用する必要はありません。 基本タイプでさえ将来にわたって利用できるようにするために、まだ考えを入れる必要があります。

これらすべてをTeachingTipの既存のアイデアと組み合わせるのは、私には論理的に思えます。 上記のすべてのコントロールとそのプロパティを並べて比較することで、どちらの方向に進むかが理にかなっていると確信しています。 時間があれば自分で比較してください。

Button / AppBarButton/etcに関するコメント。 私たちが増殖したくない考え方の完璧な例です。 Microsoftは、それらをまとまりのあるものにするための時間/労力を費やすことなく、いくつかの類似しているが異なるコントロールを作成する習慣を身に付けています。 この長期は、いくつかの理由から、あらゆる種類のフレームワークには適していません。

メッセージングコントロールの比較をまとめました。 ラフなので無料相談として差し上げます:)

これは、マイクロソフトの社内で作成されると予想される、一種の高レベルの比較および戦略ドキュメントです。 それが私自身が仕様/設計レビューを主導していた場合、私はこれらのタイプの分析を要求するでしょう、さもなければ誰も承認を得て去ることを期待することはできません。 次のことは絶対に重要です。

1. チームメンバー間の理解のギャップを埋める
2. 大規模なチームや組織で発生する「サイロ」を克服する
3. フレームワークの一貫した将来の方向性を確保して、将来の機能を優れた基盤の上に追加できるようにします（最も重要）

マイクロソフトは、WPFの後でどういうわけかこれらの全体像の原則を失い、この分野のリーダーシップによる「より高いレベルの」ビジョンはもはや存在しないようです。 とにかく、私は内部の議論に精通していないので、XAMLの原則の多くの経験と長い歴史を持っている何人かの個人と内部でもっと多くの計画が行われていることを願っています。

そうは言っても、以下のドキュメントを自由に分解してください。 最も重要なのは議論そのものです。

MessageControlComparison 20200929.xlsx

比較ドキュメントをありがとう、情報コントロールについてのあなたの考えを全体的に見るのはとてもクールです！ 私が引き続き議論したい2つの主要なトピックは次のとおりです。1。TeachingTipとInfoBarのAPI/プロパティ/機能が異なるのはなぜですか？ および2.比較ドキュメントで概説されているようにInfoCardがポップアップではなかった場合、InfoBarとInfoCardの違いは何でしょうか。

最初の質問では、赤いテキストのアイテムに対して行われた設計上の決定を強調し、もう少し明確にすることができます。

• TeachingTip字幕とInfoBarメッセージ：機能的には、はい、同じです。 これらは、これらのコントロールに太字ではないテキストを含む2番目のメッセージです。 指導のヒントでは、このメッセージは常にタイトルの下に表示され、字幕として名前を付けるのが理にかなっています。 InfoBarの場合、このメッセージはほとんどの場合、インラインでタイトルのすぐ右側に表示されますが、概念的にはサブタイトルのように名前を付けるのは意味がありません。
• TeachingTip HeroContentとInfoBarコンテンツ：Teaching TipにはHeroContentとContentの両方がありますが、InfoBarにはContentしかありません。 HeroContentプロパティは、教えるのに役立つこれらの大きな画像をサポートしているため、TeachingTipに固有のものです。 InfoBarは水平レイアウトに焦点を合わせているため、画像を明示的にサポートしていません。 両方のコントロールのContentプロパティは、追加のカスタムコンテンツ用であり、両方の残りのUI要素の下にあります。
• ヒントボタン戦略とInfoBarボタン戦略の違い：ここでの主な違いは、InfoBarが従来の「ボタン」以外のより多くの種類のボタンをサポートし、テキストを含めるために閉じるボタンのカスタマイズを推奨しないことです。
  
  
  
  • インフォバーの一般的なシナリオは、ハイパーリンクボタンを含めることです。 デフォルトのハイパーリンクボタンの前景色とさまざまな色の背景色との色のコントラストのため、InfoBarに含まれるハイパーリンクボタンに独自のカスタムスタイルを適用して、アクセス可能な状態を維持できるようにしたいと考えました。
  
  
  • 含まれているテキストと単一のアクションに焦点が当てられるように、デザインレビューの後でInfoBarに閉じるボタンのカスタマイズ（テキストに対して、必要に応じて軽量のスタイリングを行うためのCloseButtonStyleプロパティがまだあります）を含めないことにしました。 関連して、仕様で述べたように、ここで複数のアクションボタンをサポートするV2のActionContentAreaについて考えており、そこで再び閉じるボタンのカスタマイズを有効にすることを検討できます。
  
  
• InfoBar IsClosable＆IsIconVisible：Teaching TipにはIsClosableがありません。これは、ポップアップであり、非ブロッキング/緊急情報を表示するため、TeachingTipは常に閉じる必要があります。 また、InfoBarがさまざまな重大度レベルで行うデフォルトのスタイルでアイコンが表示されないため、IsIconVisibleもありません。 開発者が必要に応じて、提供されたアイコンを削除する方法を提供したかったのです。 IconSourceをnullに設定しようとしましたが、これは多くのファンキーなバグを引き起こし、IsIconVisibleプロパティを介して簡略化されました。

これらは意味がありますか？ 両方のコントロールには異なる目的があり、機能の違いはそれを反映していると思います。 これらの説明と設計の根拠がお役に立てば幸いです。

フォーマットの問題とタイプミスを編集します😊x2

これらのコントロールが独自のコンテキスト内で独自のことを行うことには正当な理由があるため、これらのコントロール間の調和を直接主張することはしません。

ただし、統合構造として機能するがフォームファクターに適応できるアプリ内メッセージングAPIを作成する場合は、コントロールを変更する必要はありません。

この種のAPIについて話し合い、回答するための質問があります。

• 開発者として、メッセージ呼び出しが画面に表示するコントロールのタイプをどのように指定できますか？
• コントロールタイプを指定しない場合、APIは指定されたプロパティを取得し、最も適切なものを「選択」しますか？
• 行動の選択を基礎となるコントロールにどのように渡しますか？
• プラットフォームの適合性に基づいて、どのフォームファクタがオーバーライドされますか？

そして、おそらくもっとたくさん私は笑について考えていません

Xboxをプラットフォームとして
画面サイズ/スケーリングと同様に、入力方法は大きく異なります。

全幅の情報バーは、画面の端でのオーバースキャンを考慮する必要があるため、これらのアプリには、情報カードの方が適している場合があります。

しかし、あなたは解雇をどのように扱いますか？

閉じるボタンの上にカーソルを移動する必要はありませんが、カードにコントローラーの入力を引き継がせますか？ これにより、モーダルになります。 しかし、コンテンツの上にオーバーレイされている場合、どのように選択してフォーカスを与えるのでしょうか。

それでは、それはインラインで表示され、コンテンツを押し下げますが、全幅ではありませんか？

さらに、Xboxには通知システムのような独自のトーストがあるので、このAPIはそれで動作するでしょうか？ それで動作しますか、それともシステムのみですか？

1. Teaching TipとInfoBarのAPI/プロパティ/機能が異なるべきではないのはなぜですか？

目標は常に同じものに共通のAPIを提供することです。 この全体的な議論は、一般的なユーザー向けメッセージに関するものであり、理解されるといくつかの類似点が現れました。 TeachingTipとMessageBarタイプのコントロールのユースケースが異なることは議論の余地がありません。 基本的に、1つはメッセージを提示し、もう1つはヒントも提示します。 私はここで全体的なデザインの選択に疑問を投げかけていません。 ただし、これらのコントロールとの違いよりもはるかに多くの類似点があります。 デザインだけを見てください。すべてにアイコン、タイトル、サブタイトル、コンテンツ、アクションボタン、閉じるボタンがあります（ただし、名前は異なり、APIの表面積も異なります）。 少なくとも名前と列挙型をここで標準化するのが良い考えである理由がわからない場合は、これ以上言うことはできません。 これは、優れたアーキテクチャの基本です。

ボタンの場合、両方のコントロールがアクションボタンと閉じるボタンをサポートしています。 しかし、あなたはこれを完全に異なる方法で行いました。 上記でいくつかの理由を説明しましたが、このような状況でボタンを使用するための「醜い」APIがあります。 これを今一般化して、将来に役立つ何かを持ってみませんか？ このようなボタンは、ContentDialog、TeachingTip、InfoBarなどのいくつかのコントロールに適用されます。 私たちは現在の制御だけを考えて設計を続けています-悪いアーキテクチャです！

メッセージまたはヒントのテキストの場合、1つはSubtitleと呼ばれ、他のMessage基本的に同じである可能性がありますが、異なるプロジェクトマネージャーがこれらのコントロールに取り組んでいる以外に異なる用語が使用されているのはなぜですか？

全体として、コントロールが同じように機能するのであれば、開発者にとっては役に立ちませんか？ はい、もちろん！ これは、これらすべての下に同じコントロールがあることを意味しますか？ 必ずしもそうとは限りませんが、同じプロパティ名、同じアクションボタンの概念、同じタイプを使用する必要があります。 それでも、すべてを結び付けるために使用されるメッセージ構造またはインターフェースを使用できることを望んでいます。 これらすべてのプロパティを手動で設定する代わりに、メッセージをメッセージバーに設定して表示するだけでよいのではないでしょうか。

比較ドキュメントで概説されているように、InfoCardがポップアップではなかった場合、InfoBarとInfoCardの違いは何でしょうか？

比較の最後の結論は、MessageBar / MessageCardは同じコントロールであり、スタイルのカスタマイズを通じてインラインヒントまたはヒントの例のユースケースもサポートする必要があるということです。

• MessageBar/MessageCardとTipを1つのコントロールに統合することができます。 唯一の懸念は、「メッセージ」と「ヒント」の概念的な違いです。
• 基礎となるコントロールは同じである必要がありますが、両方のケースをサポートするには、スタイルを高度にカスタマイズできる必要があります。 唯一の懸念は、「メッセージ」と「ヒント」の概念的な違いです。 デザインは非常に似ています。

編集：全体として、私の根本的な懸念は、私たちがどういうわけか建築的思考を後退させたことだと思います。 コントロールの設計は、Windowsフォームの時代であるかのように行われるようになりました。 新しいUWPコントロールは、WPFの概念に基づいている必要があります。 コントロールは高度に専門化されており、WPFに最初に触れた開発者を本当に「驚かせた」フレームワークにまたがる統合スレッドは見当たりません。 私の意見では、「全体像」の考え方に戻らなければなりません。

私は@roblooに100％同意します。同様のもののプロパティ名と列挙型名は、既存のコントロールと（可能な限り）整列させる必要があります。 同様のコントロールには、同様のAPIサーフェスが必要です。 MessageCardクラスを後で追加する場合（私が個人的に好むかもしれないMessageBarを拡張する代わりに）、少なくともMessageBarと非常によく似たAPIを備えている必要があります。

一般的な概念がはるかに有用なIMOである他の領域があります。 Button、AppBarButton、MenuItemについて考えてみてください。 これらはすべてテキストとアイコンを表示し、すべてアクションをトリガーするために使用されます。 多くの場合、MenuItem（ContextMenu）とAppBar/CommandBarの両方で同じコマンドを提供します。 ここでは、コマンド、テキスト、アイコン、場合によっては長いメッセージ（ツールチップ）を配置できる一般的な概念が非常に役立ちます。

@lukasf XamlUICommandクラスを知っていますか？ これにより、これらのプロパティを1つの場所にバンドルし、定義したXamlUICommandをこれらのコントロールのCommand APIに渡すだけで、Button / MenuItem/....に割り当てることができます。

@Felix-Devはいあなたは正しいです。 私はそれをほとんど忘れていました。 前回試したときにWinUIで利用できなかったため、また完全なソリューションではないため、使用していません。 AppBarとContextMenuには、単なるコマンドリンク以上のものがあります。 完全なソリューションを得るには、次のものが必要です。

• XamlUICommand
• XamlToggleUICommand
• XamlUICommandSubItem（サブメニュー/フライアウト）
• XamlUICommandSeparator

また、「Visible」プロパティおよび/またはプロパティ「HideIfDisabled」が欠落しています。

次に、MenuFlyoutとAppBar/CommandBarおよび同様のコントロールにItemsSourceが必要になります。 次に、最上位のコントロールは、各コマンド項目に対応するサブコントロールを作成します。

これらすべてが整った場合にのみ、アプリにコマンドのコレクションを1つ作成し、それらをMenuBar、ContextMenu、AppBar、NavigationViewにバインドできます。 しかし、今のように、カスタム定義されたクラスのリストを保持し、DataTemplateSelectorsやその他の厄介な回避策などを手動で実装して使用し、同じコマンド定義をさまざまな場所で機能させる必要があります。

XamlUICommandは良いスタートでしたが、完全な話ではありません。

ここでの応答が遅れたことをお詫びします。 @roblooは、数週間前の視点と比較表を共有していただきありがとうございます。 WinUIをより良くするためのすべての考えと考慮事項に本当に感謝しています！ 😊

InfoBarとプラットフォーム全体で、私は設計中に、定義されたUIパターンとして特定のシナリオ用に特別に設計されたコントロールの適切なバランスを見つけるよう努めていますが、まだ一般的でカスタマイズ可能であり、まだシナリオに拡張できないと考えています。まだ識別されています。 チームの新しい人として、WinUIコントロールがWPFの概念に戻る必要がある理由を聞きたいと思います。 同様の概念的なコントロールが同じ基本構造を持たない場合、あなたや他のUWP開発者はどのような日常的な問題に直面していますか？ この構造の作成にリソースを割り当てる必要がある理由をよりよく理解できるように、どのようなメリットがありますか？ 統合することでメリットが得られるWinUIの他のコントロールはありますか（@lukasfから上記のボタンの会話が表示されます）既存のコントロール/ブレインストーミングアプローチを変更できる領域があれば、新しい一般的な問題でもこの会話を続けることができると思います将来のコントロール。 ここでの入力については@SavoySchuler 。

InfoBarの場合、この会話からプレビューされるため、変更はまだ予測されていません。 特にアクションボタンとクローズボタンのAPIについて、満たされていない特定のニーズがある場合は、潜在的な変更を評価できるようにお知らせください。 共通のAppMessage基本クラスまたはインターフェイスがv2でInfoCardコントロールに関連付けられて実装されるか、または以前に起動された可変レイアウトの「自動」機能を有効にするための別個のDisplayModeとして実装されることが予想されます。 さらに、WinUIチームは、現時点ではTeaching TipとInfoBarをさらに調整することの価値をまだ認識していませんが、使用法を満たす必要がない場合は、ここで会話を続けてこれに対処できます。 InfoBarがプレビューに入り、アプリケーションに実装できるようになると、公式リリースの前に特定のシナリオや使用法のフィードバックを聞くことができます。

一般的な質問として、InfoBarの意図に一致するシナリオがあり、その機能またはビジュアルデザインの側面がニーズに合わない場合は、プレビューに入るときにお知らせください。 コメントと会話をありがとうございました！

InfoBarとプラットフォーム全体で、私は設計中に、定義されたUIパターンとして特定のシナリオ用に特別に設計されたコントロールの適切なバランスを見つけるよう努めていますが、まだ一般的でカスタマイズ可能であり、まだシナリオに拡張できないと考えています。まだ識別されています。 チームの新しい人として、WinUIコントロールがWPFの概念に戻る必要がある理由を聞きたいと思います。 同様の概念的なコントロールが同じ基本構造を持たない場合、あなたや他のUWP開発者はどのような日常的な問題に直面していますか？ この構造の作成にリソースを割り当てる必要がある理由をよりよく理解できるように、どのようなメリットがありますか？ 統合することでメリットが得られるWinUIの他のコントロールはありますか（@lukasfから上記のボタンの会話が表示されます）既存のコントロール/ブレインストーミングアプローチを変更できる領域があれば、新しい一般的な問題でもこの会話を続けることができると思います将来のコントロール。 ここでの入力については@SavoySchuler 。

構造を持つことのポイントは、プログラマーが高品質のコードを得るために、より少ないエラーでより速くコーディングできるようにすることです。

Microsoftの多くはサイロ化されたチームであるため、多くの場合、何かを行うには複数の方法がありますが、前述の手順を統一しないため、冗長性が生じ、すでに修正されているものを修正しようとします。

WPFが作成された後、Microsoftは「十分に良いマインドセット」に入りました。これは、Microsoft自身のチームからでもアプリの品質で直接表現されます。 マイクロソフト独自の受信トレイアプリが、コードの高品質で均一な一貫性とアプリの均一性で同じページにアクセスできない場合、サードパーティのパートナーがそのようなものを提供することをどのように期待しますか？

一般的でカスタマイズ可能なコードを提供すると、一般的なベースラインアプリになります。 ほとんどの開発者は、アプリを機能的で洗練されたものに見せるために余分な努力を払うつもりはありません。アプリを機能させるために十分なことをするだけです。 このレベルの「機能させるのに十分なことをする」は、エンドユーザーによって「半分評価する」と見なされます。

私の意見では、コントロールのポイントは、使用できる高品質のコードを用意することであり、必要に応じてカスタマイズすることができます。

開発者にオプションを提供することで、コントロールの使用方法についても、メッセージングと通知を管理する単一の方法にロックするのではなく、利点があります。

しかし、彼らが選択し、見た目も振る舞いも馴染みのある方法であり、Fluent Designに「属している」オプションを確実にすることには、一貫性の利点があります。

したがって、WinUIのコントロール自体が統一されたアプローチを提供しない場合は、WindowsToolkitがそれを管理するヘルパーAPIを作成する可能性があります。

そのリポジトリで提案することをお勧めします。WinUIコントロールを使用してアプリに表示できます。

みなさん、こんにちは。アップデートとして、InfoBarコントロールがプレビューされています🎉このコントロールの恩恵を受けるアプリケーションがある場合は、試してフィードバックを共有してください。
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
このコントロールのためにこれまでのすべての関与に感謝します！

情報バー/ボックス/カードの別の例を次に示します

編集：以下の問題はhttps://github.com/microsoft/microsoft-ui-xaml/issues/3581によってすでに修正されていることに気付きました。 以下の問題は無視してください。 コントロールを作ってくれてありがとう！ ナイチンゲールでは見栄えがします:)

@gabbybilkaナイチンゲールRESTクライアントアプリで情報バーを使用します。 それは私のシナリオの1つに最適です。 私の簡単なテストでは、情報バーのアイコンがライトテーマをサポートしていないように見えますか？ または、コントロールのXAML使用法で何か問題が発生している可能性があります。 ここにいくつかのスクリーンショットがあります

コントロールに「Opened」イベントを追加することを検討しますか？ 場合によっては、数秒後に情報バーを自動的に閉じることが適切です。 「Opened」イベントハンドラーは、タイマーを開始するための適切な場所です。

ダークテーマのサクセスカラーを変更する必要があると思います。 @YuliKl @anawishnoff @chigy @teaP
現在のダークテーマの色は＃393D1Bです。これは黄緑色で、ほとんどオリーブ色に見えます。 ライトテーマはよりクリアなグリーンを使用していますが、ほとんどミントのようなグリーンです。

_提案された変更の下で、現在の色を上にします_

＃1d3d1b

それは美的価値のためだけでなく、よりオリーブ色のバーが警告色とそれほど区別できないためでもあります

これがどのように見えるかです