@sapallie ，你能让设计模型公开吗？ 除非此时不共享它们。

目前正在做 XAML 开发，我很想看到这样的东西。 或者，类似一个不错的滚动消息控件。

从微软品牌的角度来看，标准化的错误横幅似乎可能会出错。 我担心最终用户会将每个应用程序错误与 Microsoft 品牌联系起来。 我刚刚阅读了提案，首先想到的是 memelords 在推特上谈论华丽的死亡旗帜。

@sapallie ，你能让设计模型公开吗？ 除非此时不共享它们。

抱歉@adrientetar ，我还不能分享它们。 这些设计目前只有微软。

@sapallie ，感谢您提出这个非凡的功能创意！ 我是 WinUI 的项目经理，我很高兴向团队推销这个！

我想写一点关于我们的流程的内容，以便您了解我们将如何从这里开始。 从现在开始，我将努力完善该提案的高级范围/要求以及开发的理由。 然后我会将它介绍给 WinUI 团队的其他成员，我们将考虑它是否与我们的路线图 (#717) 一致，以及我们是否认为我们可以相对较快地采取行动。 如果是这样，我将获准找出细节并开始编写规范，以便为开发人员准备好该功能。

以下是我已经知道的几件事，我需要对......

• 视觉行为

你的提议是边缘到横幅吗？ 还是像 Windows 通知一样的通知磁贴，但在应用程序窗口中，例如在中心、底部边缘或角落？

抱歉@adrientetar ，我还不能分享它们。 这些设计目前只有微软。

如果不能包含请求的公共视觉效果，我认为我无法获得该提案的批准，因为 repo _is_ 开源和封闭对话的视觉方面会纠缠我们社区的流程和体验. 基于对上述内容的回复，我很高兴尝试为该提案起草一个模型。 你更喜欢这个还是你有一个时间表来允许你公开你的设计？ 我喜欢你的模型，并渴望将它们包含在我们的头脑风暴中，以免我们不必要地把讨论引向与你的意图不同的方向。 请告诉我！ ：脸红：

横幅将使用户意识到阻止他们使用应用程序/功能的错误

横幅将因非严重错误而被关闭

我在阅读这些陈述时是否正确，这意味着您还需要为严重错误选择不可关闭的横幅？ 如果是这样，您能否告诉我更多关于您的特定应用场景，以便从拥有不可关闭的横幅的角度接收一个/继续？ 除非问题得到解决，否则用户是否会关闭应用程序？ 或者这是按钮会出现的地方，例如，将它们导航到“网络和 Internet 设置”页面？

再次感谢，我期待着完善这个想法！

每个人，请感到鼓舞，为这次对话贡献你的需求、设计和观点！ ：脸红：

我想说，有一些提案都要求类似的事情。 与其将其专门设置为错误横幅 - 为什么不直接从社区工具包中引入应用内通知。 可能会添加一个图标属性，使其显示错误图标或确认图标等。

@SavoySchuler – 很高兴收到您的来信。 我试图回答你所有的问题，但如果你还需要什么，请告诉我。

视觉行为：
理想情况下，横幅将类似于 Windows 通知磁贴，并且可以固定在应用程序窗口的顶部或底部。 它的固定位置取决于应用程序中的其他视觉元素以及焦点所在的位置。 这个决定应该由设计师做出。
我认为张贴的 GIF @mdtauk将是一个很好的起点。

解雇：
我认为深入挖掘我对关键错误和非关键错误的含义是有意义的：

• 严重错误= 由于系统范围的问题（例如 Internet 连接丢失）导致应用程序功能受损 - 这些应链接到用户可以解决问题的系统设置
• 非严重错误= 某些功能受损或单个功能不起作用，但用户仍然可以在应用程序中执行其他操作
• 引入横幅的纯粹信息迭代也很酷，它可以用来让用户知道应用程序更新或新功能可用。

而且我认为所有这些都应该被忽略（我也在提案描述中更新了这一点）

示例视觉效果
我对视觉效果做了一些更改，并且能够像这样分享它们：

这些示例是整个横幅基本上是一个大按钮的迭代。 用户可以关闭它或单击它以转到系统设置（严重错误）、打开包含有关功能修复的详细信息的网页（警告 1）、重新加载应用程序页面（警告 2）或去 Microsoft 商店更新应用程序（信息）。
可以扩展此概念以在横幅中添加多个按钮。

我真的很喜欢横幅的那些视觉效果。 我会将文本和图标向上移动 4 px，因此它们位于白色区域的中心，而不是白色和彩色条的中心。

同意。 发布的视觉效果看起来相当不错。

我真的很喜欢横幅的那些视觉效果。 我会将文本和图标向上移动 4 px，因此它们位于白色区域的中心，而不是白色和彩色条的中心。

我没有计算像素，但如果考虑到 X 高度上方的变音符号空间，它们看起来好像是居中的。

@sapallie您是否考虑过允许这些控件自动或以编程方式解除？

如果提示关于正在/下线，那么在再次上线时以编程方式删除这样的提示是有意义的。 （我见过应用程序不这样做，这可能会导致令人困惑的体验。）

同样，无限期地不显示非必要消息可以避免不必要的 UI 混乱，并且可以防止高级用户通过不强制他们手动关闭通知而在阅读消息后需要离开。

我了解围绕此类控件和这些行为可能存在额外的可访问性考虑，但我相信这些解除控件的方法是必不可少的。

我认为重要的是要指出这样的控件不适用于应用程序内的一般消息传递。 除非这确实是一个理想的用例。

是否应该允许应用一次显示多个横幅？
如果是这样，他们将如何安排？ 这是应用程序可以控制的吗？

这将满足那些要求在应用通知控件中使用 Android Toast 样式的人，它也可能对验证场景很有用，在表单中的空间非常宝贵的地方显示错误文本。

我也会称它为StatusTip或StatusNotification之类的东西，因此它不仅与负面用途相关联。

我假设设计会通过改变放置在窗口底部的纯色条的位置来适应？

它可能应该有一个超时属性，甚至可以在切换到确认错误消息之前显示待处理的消息，如进度环和一些文本，如“现在登录”。

我真的很喜欢横幅的那些视觉效果。 我会将文本和图标向上移动 4 px，因此它们位于白色区域的中心，而不是白色和彩色条的中心。

我没有计算像素，但如果考虑到 X 高度上方的变音符号空间，它们看起来好像是居中的。

我认为文本更有可能在框中垂直居中而不考虑彩色条

这是彩色条的位置如何随着控件的位置而改变

@mrlacey是的，当横幅不再相关时，程序化/自动关闭非常重要——我将它添加到提案描述中。

状态变化和错误：这就是横幅的用途。 不是一般的信息——我同意这一点。

而且我认为多个横幅应该可以工作。 他们应该只是堆叠。

@mdtauk我将其重命名为“状态横幅”——感谢您的建议。

对于加载状态——我认为这不应该发生在横幅中。 加载内容应显示在内容实际出现的应用程序中。

当涉及到更改彩色条的位置时——根据错误横幅在应用程序窗口中的放置位置具有灵活性会很棒。 👍

如果要构建此控件，问题 #622 和 #792 也可以涵盖。

@sapallie您关于严重错误情况的注释对于状态横幅将用户指向解决方案的建议指导很有趣。 我的直觉是，您可能还需要一个 API 来禁用，或者至少暂时关闭？

我了解围绕此类控件和这些行为可能存在额外的可访问性考虑，但我相信这些解除控件的方法是必不可少的。

@mrlacey ，很棒的标注！ 幸运的是，在考虑关于 TeachingTip 的定时自动关闭时，我已经完成了其中的很大一部分工作，虽然有必要与拥有可访问性设置的团队合作，但我不认为此功能会因为可访问性问题而被阻止。 +1 在您的所有其他点上！

是否可以添加链接到解决方案或设置快捷方式（如网络）的超链接按钮？

是否可以添加链接到解决方案或设置快捷方式（如网络）的超链接按钮？

我设想的潜文本包含指向应用内或设置应用程序的超链接（请参阅 TeachingTip 的 Xaml 控件的库代码）页面。 您是否正在考虑更标准化的@mdtauk？

@SavoySchuler内容属性而不是 MessageText？

您对严重错误情况的注释对于状态横幅将用户指向解决方案的建议指导很有趣。 我的直觉是，您可能还需要一个 API 来禁用，或者至少暂时关闭？

是的，我猜可能……添加它绝对没有坏处。 毕竟它增加了灵活性，并且对于某些用例可能非常有用。

@mdtauk - 是的，我当然是指内容属性！

@sapallie

您对严重错误情况的注释对于状态横幅将用户指向解决方案的建议指导很有趣。 我的直觉是，您可能还需要一个 API 来禁用，或者至少暂时关闭？

是的，我猜可能……添加它绝对没有坏处。 毕竟它增加了灵活性，并且对于某些用例可能非常有用。

一方面，您有一个覆盖 UI 的不可关闭的弹出窗口（这样做可能会导致其自己的基于场景的错误），另一方面，您有一个非持久性的应用程序警告/严重错误，这也使得我的蜘蛛侠感觉刺痛。

也许不是 UI + 提示样式的弹出窗口，而是 UI + 边缘到边缘的横幅（Office 套件使用此类横幅通知更新 - 见下文）在满足需求的同时满足需求在您的 UI 中提供持久空间？

@SavoySchuler如果控件宽度足够宽，控件上可能会有一种行为，它将标题和内容放在一行上。

如果控件从另一个控件的边缘滑出 - 而不仅仅是在窗口或面板中，我之前对不同定位布局的建议也将起作用。

也许不是 UI + 提示样式的弹出窗口，而是 UI + 边缘到边缘的横幅（Office 套件使用此类横幅通知更新 - 见下文）在满足需求的同时满足需求在您的 UI 中提供持久空间？

是的，这也有效。 👍

回想起来，Office 套件能够依赖其所有具有功能区的应用程序，因此同时具有内联和覆盖选项似乎是理想的。 @mdtauk我喜欢你的建议，它开始暗示我们如何看待出现/消失行为。

@all ，任何人都可以与我分享您设想使用此控件的真实应用程序中的特定场景吗？ 具体来说，我对视觉入口和提示解雇所需的用户交互的想法感兴趣？ 这里的要求是否涵盖了您需要从该控件中获得的核心行为？

@SavoySchuler考虑到入口和出口，它可以从边缘滑入，但如果开发人员选择，它也可以作为浮动叠加层动画。 在操作系统级别从屏幕的右边缘滑入 - 从应用程序窗口的右边缘，或从控件或 UI 元素的边缘滑出。

有一个关闭按钮用于关闭，但对于触摸显示器，从它出现的位置向相反方向滑动它的能力也可以工作。 为了确保一致性，这需要内置到控件中。

点击控件可能会触发消息文本指定的操作。
例外情况是显示操作的进度，该操作在出现错误超时或成功完成之前不会被关闭。

动画示例

进入、更新、退出 - YouTube 链接

制作动画 - YouTube 链接

教学提示存在并且是针对特定控件或 UI 元素的好方法，并且非常适合突出应用程序中的新功能。 从技术上讲，它可以用于与此 StatusBanner 相同的目的，因此需要对每一个的语义使用进行一些思考，并确定是什么让每一个都独一无二。

以下是我个人对状态横幅和教学提示之间的区别的看法

• 状态横幅_我相信_应该鼓励实际可操作的状态，因此应该在点击时调用单个操作。

  • 教学提示会将动作呈现为按钮或超链接，通常用于可以轻松忽略的信息。

• 当应用程序或操作系统条件发生变化时，这是应用程序所必需的，那么这应该会触发状态横幅的显示。

  • 教学提示不会提供关键信息，并且一旦被解雇就不会再次显示，除非添加新内容以被调用。

• 状态横幅应该在显示时保持不变，除非使用关闭按钮关闭，或者在触摸时滑动。 正在进行的进度方案完成或操作系统状态解决（网络已恢复）除外。

  • 教学提示可能包含超时功能，不会在应用程序运行时随机显示，主要显示在应用程序启动或导航到页面/屏幕时。

• 状态横幅应该以一致的方式在 OS Shell 中使用 - 可以有一组标准的本地化横幅，其中包含内容、图标、颜色作为枚举。

• 可能有一些操作系统逻辑将状态横幅附加到应用程序窗口。
  例如，当一个应用程序尝试访问网络但它不可用时，操作系统可以在应用程序窗口内而不是在屏幕空间中显示标准状态横幅，或者将其留给开发人员实施。

  • 教学提示将是特定于应用程序的，并且没有定义的标准内容，并且仅适用于开发人员。

@mdtauk ，视频制作很棒！ 🎉 它们在将这些想法变为现实方面非常有用。

持久性的需要是一个很好的观点，我认为关闭功能也可以通过指南来缓解，该指南建议在关键时使状态通知在通知窗格中持久可用，或者如果问题仍然存在，_可能_以非侵入性间隔重新显示它们。 这些不是明确的断言，只是在确保该解决方案在其场景解决方案中适当全面时需要考虑的要点。

需要将教学提示与此功能区分开来，我同意您的观点。 尽管可能有一些共享功能或代码的机会，但此控件将满足 TeachingTip 并非旨在解决的独特需求。

是否有任何利益相关者无法通过@mdtauk上面分享的内容来满足他们的需求？

在 OP 中模拟的状态横幅与在 Office 中看到的全宽通知（早期评论中的图像）或 Visual Studio（如下所示）之间似乎存在差异

两者之间的差异意味着我想知道它们应该是相同的控件还是单独的控件。

这是每个需要的属性的快速列表。 （例如名称，不固定但旨在推断含义）

状态横幅

• _图标_
• 消息文本
• 附加文本（第二行）
• 类型（严重、警告或信息）
• 颜色
• 地点
• 动画方向
• 点击事件/命令
• 暂停

全角通知

• _图标（可能）_
• 消息文本
• 链接样式（按钮或超链接）
• 链接（文本和点击事件/命令 - 多个）
• 暂停

两者都只存在粗体的属性。 _Icon_ 可能会造成混淆，因为每种类型都需要不同类型的图标（圆形或轮廓）。
还需要有一个属性来指示要使用的样式。

对我来说，这感觉就像单个控件有太多不同，将所有这些功能放在一起会令人困惑和复杂。
我认为这两个概念：

• 具有零个或多个可操作子元素的可关闭全宽横幅
• 用于指示状态变化并作为单个按钮操作的横幅

将作为单独的控件提供最大的价值和最少的混乱。

动画状态横幅如何支持一次显示多个通知？
还是现在超出范围？

• 状态横幅应该以一致的方式在 OS Shell 中使用 - 可以有一组标准的本地化横幅，其中包含内容、图标、颜色作为枚举。
• 可能有一些操作系统逻辑将状态横幅附加到应用程序窗口。
  例如，当一个应用程序尝试访问网络但它不可用时，操作系统可以在应用程序窗口内而不是在屏幕空间中显示标准状态横幅，或者将其留给开发人员实施。

这种级别的操作系统集成显示了超越单一控件和 WinUI 的雄心壮志。

“标准的本地化横幅”会是所有可用的，还是除了能够拥有完全可定制的东西之外？
如果默认提供一些，它们会是什么？
我担心只提供一组有限的选项会不必要地限制这种控制的潜力。

让操作系统在打开的应用程序中针对网络连接丢失等系统范围的场景显示横幅，这引起了我的许多担忧。

• 行动中心已经提供了一种提供系统范围通知的方法。
• 在打开多个窗口的情况下，看到每个窗口中显示的横幅似乎是不必要的干扰。
• 在应用程序中让系统显示通知（横幅）是我希望开发人员想要控制或禁用的东西。
• 如果应用程序只是偶尔需要网络连接，那么如果与用户当前正在做的事情无关，那么看到关于失去连接的提示可能会让用户感到不安或分心。
• 这会将应用程序与特定版本的操作系统联系起来，以获取更新或所需的行为。 操作系统功能的未来更改可能会以不良方式破坏或更改应用程序。
• 更新和错误修复仅适用于操作系统级别的发布计划。 WinUI 存在的部分原因是为了打破与操作系统和应用程序功能的耦合。

• 此处描述的此类控件的目标之一是使开发人员易于实现。 取消他们控制它的能力会给必须以自定义方式处理特定场景的应用程序带来问题。

刚刚从关于动画模型的 Twitter 帖子中发现了这个问题。 它似乎与我们使用工具包中的InAppNotification控件所做的许多工作重叠。 包括诸如如何处理多条消息之类的事情。

我们了解到，虽然这看起来像一个简单的控件，但它非常复杂。 如果有一个可以内置到 WinUI 中的整体解决方案来涵盖所有这些情况，那就太好了。 然后我们可以弃用工具包控件。

与@ryandemopoulos 协商，我想稍微重构一下这个初始对话，以便在解决方案（任何特定的错误UI 部分）之前关注问题（需要错误UI）。

为此，我的第一个目标是锁定错误 UI 的场景和要求（ @sapallie ，您的“关键：wifi 连接丢失”场景是一个完美的开始）。 从那里，我们可以共同决定解决方案是包含一个错误通知 UI 还是一组错误 UI 组件。 从中，我们将扩展@mrlacey对 API 相似性的分解（感谢您开始此操作），以决定派生方法是否有足够的共性与不同的控制是否有此对话的多个输出。 我不想超越自己，但@mrlacey对不同解决方案的论点_is_已经看起来很清晰，没关系。 我的重点是为这里的每个人创建正确的解决方案集。

因此，对于与此控件特别相关的任何人（@ sapallie 、@ adrientetar 、@ EverydayApps @Felix-Dev、@ mdtauk和 @mrlacey），您能否在此处向我提供以下信息或 dm @ [email protected] ：

• 应用标题
• 场景描述（错误、关键/非关键，以及您希望如何呈现它的描述）
• 将出现错误的应用程序屏幕的屏幕截图（如果有）

我已经更新了问题以反映这种以问题为中心的方法，并且我已经对迄今为止描述的需求、场景和解决方案可能性进行了分类。

@sapallie在保留您最初的工作时，我尽量保持礼貌。 版本历史可在问题顶部的“编辑者...”下拉菜单中查看。 如果我没有正确捕获任何内容，请告诉我。

我向 WinUI 团队提出了这个建议，我们相信这里定义的功能不仅可以提供错误消息，还可以提供整个应用程序范围内的长期状态消息。 这包括“更新可用”和“备份完成”类型的状态消息以及特定于错误的场景。

我已经更新了这个问题以反映这种更全面的方法。 我希望在接下来的几周内最终确定需求和场景，以便我们可以检查显示这些消息所需的 UI 输出部分。

我将在上面重新表述我的请求。 @ sapallie 、@ adrientetar 、@ EverydayApps、@Felix-Dev、@mdtauk 和 @mrlacey ，对于您希望在应用程序中显示的状态/错误消息，您能否在此处或[email protected]向我提供以下信息：

• 应用标题
• 场景描述（状态消息、关键/非关键以及您希望如何呈现的描述）
• 将出现错误的应用程序屏幕的屏幕截图（如果有）

值得注意的是，imo 应尽可能避免弹出对话框。 网络上到处都是弹出式提示，它们会打断流量以吸引您的注意。 例如，我认为空状态（ example ）应该是首选，例如，如果某些内容无法加载到控件中。

关于@mdtauk发布的视觉效果，我们真的需要从屏幕/应用程序的所有四个边缘显示弹出窗口吗？ WinUI 的重点应该是标准化这些项目的位置和外观，以便所有应用程序都使用相同的，在这方面，Android Snackbar是一个明显的参考。 Snackbar 需要注意的另一件事是，它不会以鲜红色或任何颜色显示错误，它具有清醒的外观，我认为这再次有益于不让用户过多地从他正在做的事情中分心。

例如，我们还需要关于何时使用此弹出窗口而不是对话框的指导，否则它只会创建碎片（不同的应用程序以不同的方式使用消息传递控件）。

Flyouts 有一个放置概念，这个控件可以做同样的事情。 从容器控件的内边缘出现，无论是页面还是选项卡内容等。

@adrientetar并非每个应用程序都是相同的，因此虽然此控件会有默认设置，但开发人员需要有一种方法来更改此位置，而无需重新模板或重新设计控件。

Office 使用功能区下方的空间。 Edge 使用屏幕底部。 只有 Windows 本身才能将其附加到外壳或屏幕边缘，并且可能有充分的理由阻止应用程序模仿系统级警报。

再加上任何开发人员都可以重新设计自己的警报控件，因此在这个阶段，它需要尽可能灵活，然后 Shell 团队将对控件使用的限制有一定的发言权。

Your Phone 团队拥有其中一种控件，因此也许您可以询问他们遇到了什么问题，并说服他们在完成并包含 WinUI 控件后转而使用它？

Dropbox 在他们的设计系统中也使用了 Snackbar （向下滚动，倒数第二行图像）。

最近发现了更多长期存在的应用程序范围状态消息的示例：

（团队中的“录制开始”消息）

（Dota 2 中的“尝试连接到游戏协调员”）

抱歉，这些很小——第一张照片是用超宽显示器从我的桌面上拍摄的。 :)

一些保管箱快餐栏的底部包含一个进度条。 这应该包括在这里吗？ 例如，对于上传、下载、更新、同步进度等内容，它可能是有意义的。 这不是必须具备的 imo，但也许可以或应该？

这些应该四舍五入吗？ 或者没有？

是的，我认为这里与教学提示的主要区别在于应用程序希望协调它们的消息传递空间，并且可能同时（或连续）显示多个错误/状态更新。

我认为理想情况下，这是开发人员在他们的应用程序中配置和放置的一个控件，然后也通过管道传递消息（我想它有某种类型来表示它是错误、状态、警告还是其他一些一般消息）。

在横幅和弹出式案例中，我都看到过可能有多个消息的应用程序。 有时他们会堆叠横幅，然后主导 UI 空间，因此如果此解决方案避免这种情况会很好（尽管没有什么可以阻止开发人员使用控件的多个实例来重新创建该行为）。

我很惊讶我们还没有调用 VS Code，因为它们在右下角有堆叠的弹出通知面板，上面也有额外的操作按钮（例如跳转到设置）。

VS 代码示例截图：

他们有不同类型的图标出现在左上角，可自定义的按钮操作，并且能够使用“齿轮”图标来配置有关每个扩展程序的通知的设置，在他们的情况下。

刚刚看到这张 Cortana 的截图...

Office UI Fabric 的 MessageBar看起来很棒，IMO：

我注意到适用于 Windows 10 的 Samsung Notes 使用通知祝酒词来解释一个便条被丢弃，因为其中没有任何令人讨厌的东西

大家好！ 我是 WinUI 的项目经理，正在从@SavoySchuler 那里挑选这个提案。 在这个线程中已经有很多很棒的讨论和想法分享，感谢您的所有建议！

自从这里有一些活动以来已经有几个月了，我想和大家一起回顾一下，并重申我们目前所处的位置。

作为提案顶部我们当前范围的总结：

• 该通知将用于提醒用户与整个应用程序相关的基本信息
• 将支持自定义内容和样式
• 将能够被自动和以编程方式解雇
• 通知应该能够被用户关闭
• 应该支持可以根据应用程序指定的方式堆叠的多个通知
• 应响应应用程序大小调整和 UI 更改
• 该通知将不用于显示系统范围的通知

如果我遗漏了范围摘要中的任何内容，或者您​​不同意，请随时发表评论并告诉我。 在继续前进之前，我想确保我们都在同一个页面上😊

现在我们已经定义了范围，还有一些特定的场景和用户体验需要定义。 我希望定义这些体验将有助于指导控件的 UI 可供性。 你对你的场景有什么想法？
抄送：@ sapallie ，@ adrientetar ，@ EverydayApps @Felix-Dev，@ mdtauk ，@mrlacey

经验是：

• 通知如何离开视图
  
  
  
  • 用户手动关闭通知
  
  
  • 通知自动超时并自行关闭
  
  
  • 通知仅在用户做出与通知首先出现的原因相关的操作后才会消失
    
    
    
    
    
    • 即收到断网通知后，只有断网时通知才会消失
    
    
    
  
  
  • 其他？
  
  
• 用户将如何对通知做出反应
  
  
  
  • 立即采取与通知相关的措施
  
  
  • 将他们与通知相关的操作推迟到以后
  
  
  • 完全忽略和/或忽略通知
  
  
  • 其他？
  
  
• 通知何时出现
  
  
  
  • 在应用启动时
  
  
  • 以编程方式从应用程序状态
  
  
  • 用户进行操作后（即选择备份他们的文档）
  
  
  • 其他？
  
  
• 是否有可能同时出现多个通知以及原因

再次感谢您的所有想法，我期待着将这一点公之于众！

很高兴看到这个提议没有被遗忘@gabbybilka ，感谢您接受它！

如果可能的话，您可以联系那些使用包含此类通知 UI 的第一方应用程序的人员，以列出要求，以便他们从自定义解决方案迁移到 WinUI 本机控件。 他们的需求，再加上社区的需求，应该足以满足该控件的 V1 需求。

@chigy在与 Fluent Design 团队合作时，可以与她讨论最终设计规范。

如果要鼓励其他人使用一致的 WinUI 控件，Microsoft 应该以身作则。

• 小娜
• 凹槽音乐
• 影视
• 您的手机

这些是我想到的应用程序。

@gabbybilka我们还拥有Windows 社区工具包中的控件，很高兴随时与您讨论这个问题。 在这里为我们的用户提供升级路径并将其从 Toolkit 迁移到 WinUI 真是太好了。

我认为从您的初步摘要中涵盖了大部分内容，但也可以在具有可选的、可操作的按钮方面提出一些建议？ 或者那总是只是自定义内容？

工具包的后续操作以及工具包中的一些控件历史（已经有一段时间了）：

• 原始问题
• 第一次公关审查
• GitHub 历史- 不知道如何在一页上获取完整列表，所以向下滚动并继续点击“旧”

工具包中的样式仿照原始 Microsoft Edge 和 VS Code 通知样式（此后均已更新）。 但如图所示，它灵活且可重新模板化，适用于顶级状态栏 Office 式警告或一般弹出式通知。

再一次问好！ 作为对此的更新，我最近向团队重新提交了该提案，并收到了进一步定义此功能的通知。

对于前面概述的场景，我们希望继续创建一个当前名为InformationBar （简称 InfoBar）的控件，以表示长期存在的、应用程序范围内的基本状态消息。 最初的视觉设计思路受到 FluentUI 的MessageBar以及 Teams 如何显示他们的“Now Recording”和“Internet disconnected”消息的启发。
具体来说，包括图标、标题、灵活消息区域和关闭按钮作为容器中的主要、最小、可视组件，默认适合其所在内容区域的宽度。如前所述，信息栏将通过以下方式关闭当影响状态的应用程序功能得到解决时，用户或以编程方式，即恢复互联网连接，没有介绍/退出动画。

团队（正在录制）

办公（兼容模式）

团队（没有互联网）

随着 API 开始具体化，我将开始指导对规范的讨论。 在此期间，请随时继续分享您将使用 InfoBar 的场景以及您需要什么功能😊

在讨论的早些时候， @mrlacey和其他人提出了可能有两个单独的控件来覆盖所提到的场景。

我认为这两个概念：

• 具有零个或多个可操作子元素的可关闭全宽横幅
• 用于指示状态变化并作为单个按钮操作的横幅

将作为单独的控件提供最大的价值和最少的混乱。

我认识到 InfoBar 视觉样式和组件可能不适合以前共享的某些用例。 如果您的特定应用场景和功能需要不同的视觉风格，请随时在此线程中继续分享这些情况。

再次感谢大家！

控件的设计应与模板和样式很好地配合使用-因此可以对其进行模制以适应需求，而所有行为都是控件的属性。
动画或不动画。
显示关闭按钮或隐藏它。
位置。
是否显示图标。

等等

我认识到 InfoBar 视觉样式和组件可能不适合以前共享的某些用例。 如果您的特定应用场景和功能需要不同的视觉风格，请随时在此线程中继续分享这些情况。

再次感谢大家！

前进真是太好了。 显示出来的那些视觉风格给你留下了很多我不想使用该应用程序的期望。

@mdtauk发布的设计或上面的 Cortana 屏幕截图会更可取。 应用程序的设计需要向前发展，而不是被程序阻碍。

这会/是否也可以像在呈现/桌面共享时使用的那样充当可忽略的 CommandBar？ 例如

我知道它不支持覆盖所有内容，但就固定宽度并将其放入应用程序的覆盖层而言，我可以看到设计/功能的重叠在这个方向上是相似的。

@mdtauk

控件的设计应与模板和样式很好地配合使用-因此可以对其进行模制以适应需求，而所有行为都是控件的属性。
动画或不动画。
显示关闭按钮或隐藏它。
位置。
是否显示图标。

@shaheedmalik

前进真是太好了。 显示出来的那些视觉风格给你留下了很多我不想使用该应用程序的期望。

@mdtauk发布的设计或上面的 Cortana 屏幕截图会更可取。 应用程序的设计需要向前发展，而不是被程序阻碍。

感谢您的反馈！ 我同意控件应该足够灵活，以适应 Fluent Design 系统中的这种基本行为和可定制性。 我分享的视觉效果主要是对以前实现的示例的参考。
我们将继续尝试在使用过多功能重载单个控件之间取得平衡，同时确保其可定制且对各种长期存在的应用程序范围的状态消息场景足够有用。

这会/是否也可以像在呈现/桌面共享时使用的那样充当可忽略的 CommandBar？ 例如

@迈克尔霍克

我认为这是一个有趣的场景，尚未在线程中提出，并且可能会受到此控件的支持。 感谢您引起我们的注意！ 关于范围，这似乎是一个较低优先级的场景，但我同意设计/功能在覆盖优先级之外是相似的。

这个问题有更新吗？ 我们目前正在计划一个 UI 来显示 Files UWP 中文件操作的状态，我们倾向于的设计可以从这里提出的这种功能中受益。

嗨@yaichenbaum ，感谢您的入住！ 作为此提案的更新，我很高兴分享我们开始起草的规范文档。

作为迄今为止定义的总结，我们选择创建一个具有两种视觉模式的单一控件，“Bar”和“Toast”或“Card”。 我们目前的工作是定义“Bar”模式并对其进行原型设计。 这两种模式的组件是相同的，并且计划仅在视觉布局上有所不同。 由于会有多种视觉模式，我目前认为这个控件StatusBanner而不是 InformationBar 不限于单一的“Bar”样式，但是，请随时分享您的命名想法😊

StatusBanner 在布局中从左到右的主要组件是：

• 状态颜色
• 图标
• 标题
• 信息
• 操作按钮
• 关闭按钮

这些属性是可选的，通过“内容”属性自定义内容仍然是一个选项。

此外，我们计划定义开发人员可以设置的各种 BannerTypes，它们具有根据状态预设的图标和颜色组合。 这可以根据通知的重要性简化选择正确的图标或横幅颜色，并在应用程序之间提供一些一致性。 还支持自定义图标或横幅颜色。

“Bar”模式下的 StatusBanner 的纸质原型，没有操作按钮或自定义关闭按钮。

StatusBanner 栏布局的当前设计深受@mdtauk状态卡设计的启发，谢谢！

如果您想分享有关规范当前状态的反馈，请随时在此问题中发表评论。 我们接下来的步骤是巩固设计和代码片段（并扩展以涵盖更多用例）并定义堆叠和消息包装等功能。 谢谢大家！

@yaichenbaum同时有工具包的InAppNotification控件。

@gabbybilka感谢您的更新，我的用例需要的一个重要功能是能够一次显示多个状态消息，就像@hawkerm在此线程中之前分享的一样。 让控件处理多个状态消息的放置将是一个加号。

@yaichenbaum同时有工具包的InAppNotification控件。

@hawkerm我没有看太多InAppNotification但我宁愿等待 WinUI 版本，而不是在准备好时切换到新控件。

大家好！
很抱歉上次更新和现在之间没有时间，我们一直在努力定义这个控件😊
几周前你可能已经在 repo 中看到了@chenss3的原型合并，我们真的很高兴看到它变成现实！ 在这个阶段，我们有兴趣与任何有兴趣在他们的应用程序中制作原型和使用它的控件的消费者建立联系。 请联系并分享您正在开发的应用程序、使用此控件时的场景、是否需要任何帮助以开始使用，以及您对原型的反馈。

当我们开始弄清楚这个控件的弹出版本的实现细节时，它支持定位和堆叠多个通知，我们决定在不久的将来继续开发一个内联版本。 我们听到您对某些场景需要弹出功能的反馈，并将继续朝着这个方向前进！ 与此同时，我们正在开发更类似于下面的模型的下一个原型版本。

如果您想查看更多示例，请查看规范：

谢谢大家，我期待着您的回音！

这只是在 WinUI 3 中可用，还是在 WinUI 2 预发行版中可用？

@kmgallahan WinUI 2 预发布，还不太确定确切的发布版本，因为我们希望从社区和客户那里收到更多关于原型和预览版本的反馈。

为了最大限度地获得早期反馈，我建议尽可能简单地尝试这样的原型。 也许将它们推送到带有免责声明的预发布版本中，或者提供开发/测试版本。

被要求构建 WinUI 的开发分支来尝试原型会产生很大的摩擦，特别是如果您主要是 WinUI 消费者而不是贡献者（无论如何都是代码库的贡献者）。

同意，一旦原型处于固态（看起来类似于显示的模型并支持不同的输入选项），我们希望将其置于 2.5 预览版中。 那时你能/有兴趣尝试一下吗？

我现在有兴趣尝试一下，我只是更喜欢从 NuGet 使用，而不是在我的构建中添加像 WinUI 这样的大型项目。

现在我会等待任何使它成为预览的东西。

再一次问好！ 一些更新：

• 该规范继续被审查和迭代。 请随时在此PR上查看并发表评论。 一个显着的变化是添加了一个通用的 ActionButton 属性，该属性将接收您自己的从 ButtonBase 继承的内容。

  • 我想指出的当前模型中的一个不一致之处是此 ActionButton 的位置。 在规范中，当前显示的操作按钮在关闭按钮的左侧右对齐，但实际位置将直接在消息的右侧。 我之前的评论和下面显示的图像是正确的位置。 随着开发的继续，改进的模型将继续更新并添加到规范中😊

• @teaP已着手实现此控件的本机版本，因为它向 WinUI 2.5预发行版移动。 谢谢！

和以前一样，如果您认为自己是此控件的潜在用户，请随意评论您正在开发的应用程序以及您将使用 InfoBar 的场景。 谢谢大家！

再一次问好！ 只是强调一下， @teaP最近为 InfoBar 打开了拉取请求 #3325，如果您想查看的话😊

为什么叫InfoBar？ 信息只是它可以包含的一小类信息。 它还支持错误和警告以及基于它们的操作。 Bar 也人为地约束了控件的“形状”。 除了酒吧之外，它还有其他几个用例。

在我看来，NotificationView 或 MessageView 等会是更好的名称。

为什么叫InfoBar？ 信息只是它可以包含的一小类信息。 它还支持错误和警告以及基于它们的操作。 Bar 也人为地约束了控件的“形状”。 除了酒吧之外，它还有其他几个用例。

在我看来，NotificationView 或 MessageView 等会是更好的名称。

它最初是作为StatusBanner提出的
然后改为InformationBar/InfoBar

这个控件的 FluentUI 版本叫做MessageBar

谢谢你的总结。 这个名字对我来说仍然没有多大意义。 当前控件的设计方式是作为通知。 更概括地说，它应该是一个“消息”，因此它也可以支持帮助/教学场景。 概括各种概念，这里有一个更好的控件设计：

1. ~ MessageView ~ 或Tip : 一个向用户显示状态、提示或教学信息的控件，带有可选的操作、标题、字形、图像和按钮。 这可以放置在任何地方，而不是弹出窗口。 它还将支持不同的布局。

2. 教学提示：托管 MessageView 的弹出/弹出窗口。

   • 托管提示

3. NotificationBar或StatusTip ：应用程序或视图顶部的“条形”格式的应用程序范围通知。

   • 托管提示

4. 工具提示：现在也可以托管提示，这将支持动作和图像等。

   • 托管提示

我们确实需要笼统地思考并将高级概念组合到相同的控件中。 否则，我们将创建许多具有相似但不同属性的非常专业的控件。

为通用的“MessageView”控件考虑一个完美的名称：称之为“提示”。 ToolTip 也可以托管它。 相应更新。

这是一些输入字段顶部的通知栏的另一个“真实”示例。 当前控件对于该场景很有用：

这是一些输入字段顶部的通知栏的另一个“真实”示例。 当前控件对于该场景很有用：

TextBoxes 将获得可能涵盖其中一些的验证状态，但这是我查看各种控件的方式......

• 用户主动想要识别的单个元素的工具提示；
• 开发人员希望用户注意的单个元素的教学提示（也可以不附加到元素上）；
• 开发人员想要传递一些信息的整个应用程序/内容区域的信息栏；
• 飞出/对话框，用于开发人员希望用户在关闭之前确认他们已阅读某些内容；
• 当开发人员要求用户做出选择或采取行动高于一切时的内容对话框；

我也会避免使用通知这个词，因为有操作系统级别通知和这些通知中心

我也会避免使用通知这个词，因为有操作系统级别通知和这些通知中心

好吧，我认为开发人员会知道其中的区别，但这当然是一个公平的观点。

我们可以制作许多单独的控件，这也是事实。 但肯定有一些关于通知/状态/消息/提示/教学的高级概念可以组合在一起。 我们至少应该从所有这些中创建一个接口。

Flyout 的/内容对话框是独立的概念，因为它们大部分是通用的内容控件。

我想了一个在各种场景中托管的通用“消息视图”类型控件的完美名称：称之为“提示”。 我已经相应地更新了我的评论： https ://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

我想了一个在各种场景中托管的通用“消息视图”类型控件的完美名称：称之为“提示”。 我已经相应地更新了我上面的评论： #913（评论）

在提示中放置重要的警告或错误消息我会感到不舒服...

我们可以制作许多单独的控件，这也是事实。 但肯定有一些关于通知/状态/消息/提示/教学的高级概念可以组合在一起。 我们至少应该从所有这些中创建一个接口。

Flyout 的/内容对话框是独立的概念，因为它们大部分是通用的内容控件。

我真的喜欢这个主意。 我认为图标、标题、消息、操作按钮 API 有一些共同点，这些 API 可以在这些信息控件中保持一致。 对于 InfoBar，我不确定它是否可以在当前版本中实现，但可能用于我们下一次控制这种性质。

我想了一个在各种场景中托管的通用“消息视图”类型控件的完美名称：称之为“提示”。 我已经相应地更新了我上面的评论： #913（评论）

在提示中放置重要的警告或错误消息我会感到不舒服...

我也同意这一点……还有更多的探索要做。

我想了一个在各种场景中托管的通用“消息视图”类型控件的完美名称：称之为“提示”。 我已经相应地更新了我的评论：#913（评论）

在提示中放置重要的警告或错误消息我会感到不舒服...

我也同意这一点……还有更多的探索要做。

想想它与所有现有控制和想法的匹配程度——在这方面它是完美的。 但是，是的，在错误/警告的背景下，它确实显得格格不入。 我认为人们会很快理解它，但我无法反驳这种逻辑。

为什么叫InfoBar？ 信息只是它可以包含的一小类信息。 它还支持错误和警告以及基于它们的操作。 Bar 也人为地约束了控件的“形状”。 除了酒吧之外，它还有其他几个用例。

在我看来，NotificationView 或 MessageView 等会是更好的名称。

我同意您的观点，即 InfoBar 可能并不总是一个栏，但我认为在名称中包含“栏”确实意味着它适用于视觉和概念上的应用程序范围的场景。 搜索“信息栏”的图像，您会发现来自 IE 的类似体验的图像（不是我们必须尝试匹配 IE），我认为它暗示了预期的视觉和功能布局。 我不认为这是一个“视图”，但我喜欢关注消息或通知。

@gabbybilka是的，它与旧的 StatusBar 或较新的 AppBar...CommandBar... 等非常相似。问题是控件的使用应该被广泛推广，以便在任意位置显示提示和消息。 “视图”也不适合 100%，但它更接近通用名称。 我真正关心的是统一基本概念，因此我们最终不会让多个控件对同一件事进行变体。

为使自己在两个位置的多个评论感到困惑而进行了编辑。

与我在其他问题之一中发布的想法相呼应...

_针对 V2 不再考虑控件的浮动模式这一事实_
我可以理解行为和形式的变化会让你转向教学提示作为替代方案，但我会建议缺乏严重性、状态颜色和教学提示本身的设计 - 与同类型的教学提示不兼容InformationBar 控件正在处理的消息。

全屏 WinUI 应用程序、窄宽度窗口以及 Hololens 和 Xbox 等设备之间的屏幕宽度和 UI 布局差异 - 不适合停靠栏形式因素。

因此，考虑到这一点，也许应该将 InformationBar 与 InformationCard 控件一起包装到 AppMessage API 中 - 因此可以将 Severity、颜色、标题、消息、操作按钮等的相同属性放入 XAML 或放入应用程序的代码 - 以及它们在屏幕上的显示方式会发生变化以适应外形/设备系列。

一个未附加的教学提示可以代替，但它不支持那些适合应用程序状态消息的自定义 - 这是此控件背后的初衷。

那么，如果我们有一个实际上只是一条信息的“提示”呢？ 它有字形、图像、消息文本、标题。

然后从 Tip 派生出 AppMessage，它添加了严重性、操作和事物。 然后，提示仍然可以在教学提示和工具提示中使用，因为它们现在存在。 在我的场景中，它对于内联的连接提示也很有用。

那么，如果我们有一个实际上只是一条信息的“提示”呢？ 它有字形、图像、消息文本、标题。

然后从 Tip 派生出 AppMessage，它添加了严重性、操作和事物。 然后，提示仍然可以在教学提示和工具提示中使用，因为它们现在存在。 在我的场景中，它对于内联的连接提示也很有用。

没有尾巴的教学提示似乎非常适合您的情况......

没有尾巴的教学提示似乎非常适合您的情况......

不知道你可以用 TeachingTip 做到这一点。 此外，我的控制比 TeachingTip 存在的时间要长得多，所以直到现在才真正研究过升级它。 不管怎样，如果你能做到，那是我的疏忽。

编辑：没关系，即使没有尾巴，它仍然是一个以某种方式被忽略的覆盖层。 我正在描述的“提示”都是内联的，并且一直持续到用户基本上创建了第一个元素。 它只是一个显示信息的控件——而不是在弹出窗口、弹出窗口或其他非持久视图中。

我仍然相信有很多共性可以分解为多个地方使用的界面/控件。 我们正在讨论的所有这些控件的相似之处远多于差异。 只有基础信息的呈现位置/方式才会发生变化。 这一切都已经成熟了。

没有尾巴的教学提示似乎非常适合您的情况......

不知道你可以用 TeachingTip 做到这一点。 此外，我的控制比 TeachingTip 存在的时间要长得多，所以直到现在才真正研究过升级它。 不管怎样，如果你能做到，那是我的疏忽。

我仍然相信有很多共性可以分解为多个地方使用的界面/控件。 我们正在讨论的所有这些控件的相似之处远多于差异。 只有基础信息的呈现位置/方式才会发生变化。 这一切都已经成熟了。

当你分解它时，它只是一个图标和文本，并没有与之关联的“上下文”。 但我认为将其包装到AppMessage中的建议可能包括非附加教学提示作为另一种形式的 UI。

当你分解它时，它只是一个图标和文本，并没有与之关联的“上下文”。 但我认为将其包装到 AppMessage 中的建议可能包括非附加教学提示作为另一种形式的 UI。

抱歉，请参阅我上面的编辑。 教学提示仍然不是内联的，只是漂浮在底部直到被解雇。 还需要考虑图像和标题。

当你分解它时，它只是一个图标和文本，并没有与之关联的“上下文”。 但我认为将其包装到 AppMessage 中的建议可能包括非附加教学提示作为另一种形式的 UI。

抱歉，请参阅我上面的编辑。 教学提示仍然不是内联的，只是漂浮在底部直到被解雇。

不一定要在底部。

内联可能是一个不寻常的提示用例，因为它会取代它周围的其他内容。

您可以建议 V2 添加对内联/非浮动显示模式的支持

为了给@mdtauk的评论提供更多背景信息，这是我对他关于从规范中的“InfoBar V2 的预期功能”部分中删除浮动模式的问题的初步答复。
从我：

跳到这里参加设计讨论。 注意到 V2 预期功能发生了变化😉 现在我们没有承诺在 V2 版本中为 InfoBar 提供浮动模式，原因有几个。 我想进一步探讨浮动模式是否应该在 InfoBar 中，或者类似 toast 的通知是否应该完全是一个不同的控件。 在调查过程中，我们意识到浮动模式的基本实现与教学提示非常相似，并且可能需要完全探索类似 toast 的通知场景功能，如堆叠、定位和覆盖选择（参见 WCT InAppNotification 的StackMode ）。 这将扩大 InfoBar 的范围和意图，使其比最初的关注点更广泛。 需要注意的是，我们还没有完全关闭向 InfoBar 添加浮动功能的大门，但倾向于否。

对于基于基本 AppMessage 类的 InformationBar 和 InformationCard 提案，我喜欢这个想法。 您提到“它们在屏幕上呈现的方式会改变以适应外形/设备系列”，我想更深入地探索。 我认为有些场景比 bar UX 更适合卡片 UX（尤其是瞬态消息、特定于页面的错误消息和没有可停靠表面的应用程序），反之亦然。

对我来说，“何时”使用 InfoBar/InfoCard/Teaching Tip（与视觉和功能需求相关）以及“为什么”使用（基于最终用户感知和体验一致性）都存在差异。 瞬态消息对我来说是一个明显的亮点，因为它应该由 InfoCard 支持，而不是由 InfoBar 支持。 非用户可忽略的消息是一个相反的例子，因为从可访问性的角度来看，持久覆盖的内容很难支持。

不过不要走神 :) 所有这些不同的控件在大多数情况下都呈现相同类型的信息——只是在不同的区域/样式中。 这需要概括和统一。 如果你想这样称呼它，我认为我们可以围绕一个常见的“AppMessage”控件进行统一。 然后用不同的容器以不同的方式呈现“AppMessage”。 它可以在 TeachingTIp、ToolTip、NotificationBar、某个地方作为卡片等呈现。每个容器都可以修改样式以适应其用例。 不过，底层的属性和类型将是统一的。

我并没有试图用@gabbybilka的回复来误解任何上下文😄

对于基于基本 AppMessage 类的 InformationBar 和 InformationCard 提案，我喜欢这个想法。

这就是命名的用武之地。我确实喜欢“AppMessage”（“Tip”会很棒，因为它似乎一直是计划）但如果我们这样做，它应该是“MessageBar”和“MessageCard”托管它。

对我来说，“何时”使用 InfoBar/InfoCard/Teaching Tip（与视觉和功能需求相关）以及“为什么”使用（基于最终用户感知和体验一致性）都存在差异。

我绝对同意这些不同的用例和演示。 然而，他们仍然在呈现一个可以概括和标准化的信息。 我想我们现在都同意这个概念:)

卡片信息/提示示例

我认为的目标之一应该是鼓励收件箱和第一方应用程序/Windows Shell 从他们的自定义解决方案转向使用一致的收件箱控件/API

我可能应该补充一点，在 UWP 应用程序中，我处理的一些概念已经统一。 与此讨论相关的简化版本是：

有一个“消息”类（它不是控件，只是一个数据结构）具有以下属性：

        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 和行为。 ToolTips 和 InfoBar/MessageBar 对于开发人员和最终用户来说都是众所周知的概念。 尽管两者都提供信息，但它们用于非常不同的事情。 我看不出有一个共同的基类或共同的概念有什么好处。 为什么要将消息放入工具提示中，该消息已显示在全局应用程序 InfoBar 中（以及您将在何处附加此工具提示）？ 这不会导致大量重复使用。

在其他领域，通用概念在 IMO 中会更有用。 想想 Button、AppBarButton、MenuItem。 所有这些显示文本和图标，都用于触发动作。 通常，您在 MenuItem (ContextMenu) 和 AppBar/CommandBar 中提供相同的命令。 在这里，一个通用概念将非常有用，您可以在其中放置命令、文本、图标，也可以是长消息（工具提示）。 但是对于 ToolTip 和 MessageBar 有一个共同的概念吗？ 我真的不认为有这个必要。 当然，如果我们从头开始重写 UWP，我们可能会想出一个通用的基类。 但我不认为这是必要的或过度有用的。

@lukasf你的观点是有道理的； 它可以在应用程序本身中完成。 但是，有很多非常相似的概念，每个人都可以从这里的统一中受益。

ToolTip 被纳入讨论，因为它可以使字形和标题与消息一起受益。 从概念上讲，所有这些控件也是某种形式的消息——只是它们的显示位置/方式不同。 即使我们不进行大规模标准化，MessageBar 和 MessageCard 仍然需要许多共享属性/类型。 我们不希望 MessageBarPriority 与 MessageCardPriority 敌人一起使用。 仍然需要考虑以确保即使是基本类型也是面向未来的。

将所有这些与教学提示中现有的想法结合起来对我来说似乎是合乎逻辑的。 我确信通过对所有提到的控件及其属性进行并排比较，哪个方向是有意义的。 如果我有时间自己做比较。

您对 Button/AppBarButton/等的评论。 是我们不想扩散的想法的完美例子。 微软正在养成制作几个相似但不同的控件的习惯，而无需花费时间/精力来使它们具有凝聚力。 由于多种原因，这种长期对任何类型的框架都不利。

我已经对消息传递控件进行了比较。 我会把它作为免费咨询赠送，因为它是如此粗糙:)

这是我希望在 Microsoft 内部创建的高级比较和策略文档。 如果是我自己领导规范/设计审查，我会要求进行这些类型的分析，否则没有人会期望得到批准离开。 绝对重要的是：

1. 弥合团队成员之间的理解差距
2. 克服大型团队和组织中出现的“孤岛”
3. 确保框架的未来方向一致，以便可以在良好的基础上添加未来的功能（最重要）

微软在 WPF 之后不知何故失去了这些大局原则，并且该领域的领导层似乎不再有任何“更高层次”的愿景。 无论如何，我不参与内部讨论，因此我希望在内部与一些具有丰富经验和 XAML 原则历史悠久的个人进行更多计划。

话虽如此，请随意撕开下面的文档。 最重要的是讨论本身。

MessageControlComparison 20200929.xlsx

感谢您提供比较文件，很高兴看到您对信息控件的整体看法！ 我想继续讨论的两个主要主题是 1. 为什么教学提示和信息栏不应该有不同的 API/属性/功能？ 和 2. 如果 InfoCard 不是比较文档中概述的 Popup，InfoBar 和 InfoCard 之间有什么区别？

对于第一个问题，我可以突出在红色文本项目上做出的设计决策，并提供更清晰的说明：

• 教学提示字幕与信息栏消息：功能上，是的，它们是相同的！ 它们是这些控件中带有非粗体文本的辅助消息。 在教学提示中，此消息将始终显示在标题下方，并且命名为副标题是有意义的。 对于 InfoBar，此消息通常是内联的并且直接位于 Title 的右侧，这在概念上不像 Subtitle 那样有意义。
• 教学提示英雄内容与信息栏内容：教学提示既有英雄内容又有内容，而信息栏只有内容。 HeroContent 属性是教学提示所独有的，因为它支持这些更大的图像来帮助教学。 InfoBar 不明确支持图像，因为它专注于水平布局。 两个控件的 Content 属性用于额外的自定义内容，并且位于两个控件的其余 UI 元素下方。
• 教学提示按钮策略与 InfoBar 按钮策略：这里的主要区别是 InfoBar 支持经典“按钮”之外的更多类型的按钮，并且不鼓励自定义关闭按钮以包含文本。
  
  
  
  • InfoBars 的一个常见场景是包含一个超链接按钮。 由于与默认超链接按钮前景色和我们各种颜色的背景颜色的颜色对比，我们希望确保我们可以将我们自己的自定义样式应用到包含在信息栏中的任何超链接按钮，以便它们保持可访问性。
  
  
  • 在我们的设计审查之后，我们决定不将关闭按钮自定义（对于文本，如果需要，仍然有一个 CloseButtonStyle 属性可以做一些轻量级的样式）到 InfoBar，以确保焦点保持在包含的文本和单个操作上。 相关地，就像规范中提到的那样，我们正在考虑 V2 中的 ActionContentArea 以支持多个操作按钮，并且可以研究在那里再次启用关闭按钮自定义。
  
  
• InfoBar IsClosable & IsIconVisible：教学提示没有 IsClosable 作为教学提示应该始终是可关闭的，因为它是一个弹出窗口并显示非阻塞/紧急信息。 它也没有 IsIconVisible，因为图标不会以其默认样式出现，InfoBar 通过不同的严重性级别执行此样式。 我们希望为开发人员提供一种方法，让他们可以根据需要删除提供的图标。 我们尝试将 IconSource 设置为 null ，这导致了很多时髦的错误，并通过 IsIconVisible 属性进行了简化。

这些有意义吗？ 我相信这两种控件都有不同的目的，功能上的差异反映了这一点。 我希望这些解释和设计原理对您有所帮助！

编辑格式问题和错字😊 x2

我不会直接提倡这些控制之间的协调，因为这些控制在自己的环境中做自己的事情是有道理的。

但是，创建一个作为统一结构但可以适应形式因素的 In App Messaging API 不需要对控件进行更改。

对于这种 API，有一些问题需要讨论和回答：

• 作为开发人员，您应该/如何指定消息调用在屏幕上显示的控件类型？
• 如果不指定控件类型，API 是否采用给定的属性并“选择”最合适的？
• 您将如何将行为选择传递给底层控制？
• 根据平台的适用性，哪些外形尺寸会被覆盖？

可能还有更多我没想到的，哈哈

以 Xbox 为平台
输入方法非常不同，屏幕尺寸/缩放比例也是如此。

全宽信息栏需要考虑屏幕边缘的过度扫描，因此对于这些应用程序，信息卡可能更合适。

但是你会如何处理解雇？

没有光标移到关闭按钮上，但您希望卡接管控制器输入吗？ 这使它成为模态的。 但是，如果它覆盖在内容之上，你如何选择它并赋予它焦点？

那么它是否显示为内联并将内容向下推送，但不是全宽？

另外，Xbox 有自己的类似 toast 的通知系统，那么这个 API 会/应该使用它吗？ 它可以与它一起使用，还是仅适用于系统？

1. 为什么教学提示和信息栏不应该有不同的 API/属性/功能？

目标应该始终是为相同的事物提供通用 API。 整个讨论一般都是关于面向用户的消息，一旦被理解，就会出现一些相似之处。 毫无疑问，TeachingTip 和 MessageBar 类型控件的用例不同。 从根本上说，一个是呈现消息，另一个也是一个提示。 我不是在质疑这里的整体设计选择。 但是，这些控件的相似之处远多于差异。 只看设计：它们都有图标、标题、副标题、内容、操作按钮和关闭按钮（但您对它们的命名不同，并且有不同的 API 表面积）。 如果您不明白为什么在这里至少标准化命名和枚举是一个好主意，那么我无话可说。 这只是良好架构的基础。

对于按钮，两个控件都支持操作按钮和关闭按钮。 但是您以完全不同的方式做到了这一点。 您在上面解释了一些原因，但现在我们有一个“丑陋”的 API 可以在这种情况下使用按钮。 为什么我们现在不概括这一点，以便我们对未来有好处？ 像这样的按钮适用于多个控件：ContentDialog、TeachingTip、InfoBar 以及谁知道接下来会发生什么。 我们一直在设计时只考虑当前的控制——糟糕的架构！

对于消息或提示的文本，一个称为Subtitle和另一个Message基本上它们可以相同，为什么除了不同的项目经理正在处理这些控件之外使用不同的术语？

总的来说，如果控件以相同的方式工作，对开发人员不是很有帮助吗？ 是的当然！ 这是否意味着所有这一切都会有相同的控制？ 不一定，但我们应该使用相同的属性名称、相同的操作按钮概念和相同的类型。 我仍然希望我们可以有一个消息结构或接口来将所有内容联系在一起。 将消息设置到 MessageBar 并显示它而不是手动设置所有这些属性不是很好吗？

如果 InfoCard 不是比较文档中概述的 Popup，InfoBar 和 InfoCard 之间会有什么区别？

我对比较的最终结论是 MessageBar/MessageCard 应该是同一个控件，并且还通过样式自定义支持我的内联提示或提示示例的用例。

• 可以将 MessageBar/MessageCard 和 Tip 统一到一个控件中。 唯一需要关注的是“消息”和“提示”之间的概念差异。
• 应该是相同的底层控件，样式需要高度可定制以支持这两种情况。 唯一需要关注的是“消息”和“提示”之间的概念差异。 设计极为相似。

编辑：总的来说，我认为我最关心的是我们在架构思维上倒退了。 控件设计现在就像 Windows 窗体时代一样完成。 新的 UWP 控件应基于 WPF 概念。 控件变得高度专业化，我没有看到跨越框架的统一线程真正让第一次接触 WPF 的开发人员“惊叹”。 在我看来，我们必须回到“大局”的心态。

我 100% 同意@robloo的观点，即类似事物的属性名称和枚举名称应（尽可能）与现有控件保持一致。 类似的控件应该有类似的 API 界面。 如果稍后要添加 MessageCard 类（而不是扩展 MessageBar，我个人可能更喜欢），它至少应该具有与 MessageBar 非常相似的 API。

在其他领域，通用概念在 IMO 中会更有用。 想想 Button、AppBarButton、MenuItem。 所有这些显示文本和图标，都用于触发动作。 通常，您在 MenuItem (ContextMenu) 和 AppBar/CommandBar 中提供相同的命令。 在这里，一个通用概念将非常有用，您可以在其中放置命令、文本、图标，也可以是长消息（工具提示）。

@lukasf你知道XamlUICommand类吗？ 这允许您将这些属性捆绑在一个地方，然后将它们分配给您的 Button/MenuItem/.... 只需将您定义的 XamlUICommand 传递给这些控件的Command API。

@Felix-Dev 是的，你是对的。 我差点忘了这件事。 我没有使用它，因为我上次尝试它时它在 WinUI 中不可用，而且还因为它不是一个完整的解决方案。 AppBar 和 ContextMenu 不仅仅是命令链接。 对于完整的解决方案，我们需要：

• XamlUICommand
• XamlToggleUICommand
• XamlUICommandSubItem（子菜单/浮出控件）
• XamlUICommandSeparator

还缺少“可见”属性和/或“HideIfDisabled”属性。

然后我们需要 MenuFlyout 和 AppBar/CommandBar 上的 ItemsSource 和类似的控件。 然后顶层控件将为每个命令项创建相应的子控件。

只有当所有这些都到位时，我们才能在我们的应用程序中拥有一组命令，并将它们绑定到 MenuBar、ContextMenu、AppBar、NavigationView。 但就像现在一样，我需要保留一个自定义类的列表，手动实现和使用诸如 DataTemplateSelectors 和其他烦人的解决方法之类的东西，只是为了让相同的命令定义在不同的地方工作。

XamlUICommand 是一个好的开始，但它并不是一个完整的故事。

很抱歉我在这里延迟回复， @robloo感谢您在几周前分享您的观点和比较表。 我真的很感激所有让 WinUI 变得更好的想法和考虑！ 😊

在 InfoBar 和整个平台中，我的观点是，在设计时，我们正在努力找到适当的平衡，以便为特定场景专门设计的控件作为定义的 UI 模式 - 同时通用和可定制的足以扩展到我们没有的场景尚未确定。 作为团队的新人，我很想听听为什么 WinUI 控件应该回到 WPF 概念。 当类似的概念控件没有相同的底层结构时，您和其他 UWP 开发人员面临哪些日常问题？ 对您有什么好处，以便我们更好地理解为什么我们应该投入资源来创建这种结构？ WinUI 中是否还有其他控件可以从统一中受益（我从@lukasf 看到上面的按钮对话）我认为如果有一个领域我们可以修改现有控件/头脑风暴方法未来的控制。 @SavoySchuler在这里输入任何内容。

对于 InfoBar，我仍然没有预见到任何变化，因为它从这次对话中进入预览状态。 对于操作按钮和关闭按钮 API，特别是如果有未满足的特定需求，请告知我们，以便我们评估任何潜在的更改。 我可以预期一个通用的 AppMessage 基类或接口将通过与 InfoCard 控件关联的 v2 实现，或者作为单独的 DisplayMode 实现，以启用前面提到的变量布局“自动”功能@mdtauk 。 此外，WinUI 团队目前还没有看到进一步调整教学提示和信息栏的价值，但是如果有无法满足的使用需求，我们可以在此处继续讨论以解决此问题。 一旦 InfoBar 进入预览版并可以在应用程序中实现，任何特定场景或使用反馈都会在正式发布之前听到。

作为一般问题，如果您有与 InfoBar 的意图相匹配的场景，并且其功能或视觉设计的某些方面不满足您的需求，请在我们进行预览时告知我们。 再次感谢您的所有评论和对话！

在 InfoBar 和整个平台中，我的观点是，在设计时，我们正在努力找到适当的平衡，以便为特定场景专门设计的控件作为定义的 UI 模式 - 同时通用和可定制的足以扩展到我们没有的场景尚未确定。 作为团队的新人，我很想听听为什么 WinUI 控件应该回到 WPF 概念。 当类似的概念控件没有相同的底层结构时，您和其他 UWP 开发人员面临哪些日常问题？ 对您有什么好处，以便我们更好地理解为什么我们应该投入资源来创建这种结构？ WinUI 中是否还有其他控件可以从统一中受益（我从@lukasf 看到上面的按钮对话）我认为如果有一个领域我们可以修改现有控件/头脑风暴方法未来的控制。 @SavoySchuler在这里输入任何内容。

具有结构的意义在于，程序员可以更快地编写代码并减少错误，从而获得高质量的代码。

因为微软大部分都是孤立的团队，在许多情况下，有多种方法可以做某事，但没有统一所述程序，这会导致冗余并试图修复已经修复的问题。

WPF 创建后，微软进入了“它足够好的心态”，这直接体现在应用程序的质量上，甚至来自微软自己的团队。 如果 Microsoft 自己的收件箱应用程序无法在代码和应用程​​序的统一性方面以高质量的统一一致性出现在同一页面上，我们如何期望 3rd 方合作伙伴提供这样的服务？

提供通用但可定制的代码会产生通用的基线应用程序。 大多数开发人员不会付出额外的努力来让他们的应用程序看起来更实用和更精致，他们只会做足够的事情来让他们的应用程序正常运行。 最终用户将这种“做得足以使其发挥作用”的水平被认为是“半途而废”。

在我看来，控制的重点是拥有可以使用的高质量代码，并且可以根据需要对其进行自定义。

为开发人员提供关于他们如何使用控件的选项也有其积极意义，而不是将它们锁定在管理消息传递和通知的单一方式中。

但是确保他们选择的任何选项、外观和行为都以熟悉的方式，并且“属于”Fluent Design - 具有一致性的好处。

因此，如果 WinUI 中的控件本身不提供统一的方法，也许 Windows 工具包可以创建一个帮助程序 API 来管理它。

我建议你在那个 repo 中提出它，它可以使用 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我将在我的 Nightingale REST 客户端应用程序中使用信息栏。 它非常适合我的一个场景。 在我的快速测试中，信息栏中的图标似乎不支持浅色主题？ 或者也许我在控件的 XAML 使用中做错了什么。 这是一些屏幕截图

您会考虑向控件添加“打开”事件吗？ 在某些情况下，几秒钟后自动关闭信息栏是合适的。 “打开”事件处理程序将是启动计时器的正确位置。

我认为应该更改深色主题中的成功颜色。 @YuliKl @anawishnoff @chigy @teaP
当前的深色主题颜色是#393D1B - 看起来是黄绿色，几乎是橄榄色。 浅色主题使用更清晰的绿色，几乎像绿色一样薄荷。

_置顶当前颜色，低于建议的更改_

#1d3d1b

这不仅是为了审美价值，还因为更多的橄榄色条与警告颜色没有区别

这是它的外观