WordPress 探索 Feature Notifications 通知系统设计

WordPress 没有一个好的方式让人们了解自己网站上正在发生的事情。插件只能依赖会将页面内容向下推移的管理通知，因此支付失败、安全更新或团队成员的提问等重要事项，会淹没在提醒和促销信息之中。

Feature Notifications 正在构建一个共享解决方案（0.3.0 的状态和计划、每周更新）：为网站上发生的事情提供一个集中展示的位置，让真正的问题脱颖而出，并由人们控制自己接收的内容。在开展这项工作的同时，我还在探索它可能呈现的形式，并用一个真实插件进行测试：测试 WooCommerce 和 WooPayments 如今展示的每一条消息。

操作演示视频（7 分钟）、概念介绍 | 现场演示 | 目录及其背后的系统 | issue #655

这个想法

如今，每个插件都用自己的方式告诉人们各种信息：会将页面内容向下推移的管理通知、收件箱卡片、横幅和徽标。缺乏统一的机制来辨别什么重要，因此重要事项会淹没在其他信息之中。

这个想法是打造一个更好的位置，用来展示网站上发生的事情；它提供一套插件可以遵循的基础规则，作为回报，插件的通知可以显示在 WordPress 的各个位置，包括编辑器和网站前台：

• 一个铃铛，涵盖网站、其插件和 WordPress.com。
• 每条通知打开后，都会显示通知内容（订单、文章）、发送者，以及一个清晰的后续操作。
• 真正的问题会一直置顶，直到得到处理。其他所有内容都不会挡路。

设计灵感来自 Ollie Rozdarz 和 WordPress.com 通知团队打造的 WordPress.com 通知面板，并经过每天数百万人的使用测试和完善。

这是什么，以及不是什么

这是什么：一种触达用户的新方式。一个通知托盘，不仅像如今的通知那样只在特定管理页面可用，而是无处不在：每个管理界面、编辑器内部以及网站前台。使用它的插件能够以一致的方式传达消息，而不必依赖越来越大、将页面内容向下推移的通知。它还配有明确的设计方向和一套规则，因此无论通知由谁发出，其外观和行为都保持一致。

这不是什么：这不是一项破坏性变更。现有插件仍可继续使用，也不会移除任何 API 或钩子。管理通知（包括自定义通知）仍然有效。只是 WordPress 中的通知未来将不再以此形式呈现。它也尚未完成，也不会在 0.3.0 中全部交付。

更清晰的系统

这是原型的第二个版本。第一个版本展示了基本想法。早期反馈询问系统负责多少内容、留给各插件多少内容，因此第二个版本聚焦于规则（具体改变了什么）：

• 插件发送数据，而不是布局。它们从四种布局中选择一种并填写相应字段：Standard、Object（带有说明通知内容的卡片）、Conversation 和 Group。
• 五个彼此独立的维度，各自改变不同的属性。例如，一项争议属于支付（类型）、严重（严重程度）、运营（意图）和未读（阅读状态），发送者状态为“Needs response”，之后变为“Won”。这些值由核心管理，插件从中选择。
• 严重通知很少出现，而且醒目可见。它们会一直置顶，并将铃铛的计数标红，直到问题得到解决，而不只是被阅读。
• Alerts 标签页将严重通知和警告集中到一个地方，并显示数量，因此需要关注的事项始终一键可达。警告会留在那里，直到得到处理。
• 针对噪声的限制。 重复项会相互取代，许多相同项会合并为一个，提示和优惠也可以一次性全部关闭。

所有这些内容都列在目录中：System 包含尺寸、布局和规则，Styles 则展示每个部分，从徽章和行状态到铃铛本身。

这个版本还增加了人们提出的一些小需求。密度位于“外观”的 菜单中，可在舒适和紧凑之间切换：每行一行，因此繁忙的站点一次能看到两倍多的内容。也可以从通知的 ⋮ 菜单中将通知标记为未读。

待决问题

这些问题尚未确定，尤其欢迎大家提供反馈。

徽章：每种类型一个，还是设置几种类别？

目前，每种通知类型在行内都有自己的小徽章：评论使用对话气泡，订单使用订单图标，统计数据使用柱状图。WordPress.com 采用的就是这种方式，浏览起来很快。但每当有插件带来新内容时，如预订或表单提交，列表就会增长。另一种方案是设置几个永不增长的通用徽章（消息、反应、活动、系统、里程碑、提示），具体内容则显示在圆形图标和标题中。随着更多插件加入，哪种方式效果更好？目录中对这两种方式进行了比较。

严重程度：三个等级够用吗？

严重程度决定哪些内容突出显示。严重问题固定在顶部，并将铃铛的计数变为红色；警告在“警报”标签页中等待查看；信息则包括其他所有内容。没有“成功”这一等级：好消息已经会显示在状态中，例如标记为“已赢得”的争议。Core 的文档建议使用警报、警告和信息，与此接近。三个等级够用吗？又由谁决定哪些通知可以被视为严重？

操作者及内容主题：可選附加信息，还是正式字段？

要显示是谁完成了某项操作（客户姓名和头像）以及具体内容（订单卡片），通知需要两项 Core 目前不会存储的数据。它们可以作为 actor 和 about 放入 Core 现有的 meta 列中，而无需更改数据库。但这会使它们保持为可选且定义较为宽松的内容。它们应该继续放在 meta 中，还是成为每个插件都按相同方式填写的正式字段？

跨渠道：每个事件应在哪里送达？

同一个事件可以通过多种方式触达用户：铃铛、后台菜单中的计数、电子邮件，或推送到手机。目前新订单会通过其中三种方式触达用户；如果 Orders 拥有自己的菜单项及计数，则可能达到四种。哪些事件应该通过哪些渠道送达，才能让每个事件只在正确的位置出现一次？这需要审查每个事件，而不只是铃铛。

未读：标签页，还是筛选器？

我会保留一个顶层的“未读”标签页，尽管它会将阅读状态与分类标签页混在一起，但这是人们最常想看的内容。作为对比，演示还提供了仅显示未读这一筛选器，可在任意标签页内使用，例如查看 Store 中的未读内容。要试用，请打开后台工具栏中的 Demo › Unread › 在齿轮菜单中，然后打开铃铛的 菜单 › 仅显示未读。

设置：如何扩展？

用户可以按渠道屏蔽通知，例如 WooCommerce › Orders，并用一个开关关闭每个插件的提示。当插件数量众多且每个插件都会发送多种类型时，该列表很快就会变得很长。应如何让设置保持易于管理？这一点尚未探讨。

无障碍：键盘操作对你来说好用吗？

键盘操作与 WordPress.com 面板一致：方向键可在列表中移动，Enter 会打开通知并将焦点移入其中，Esc 会返回同一行，再次按下 Esc 则关闭铃铛。下面是一段展示其实际效果的简短 GIF。它与屏幕阅读器和其他辅助技术配合得好吗？

接下来

• 收集反馈，反馈将在这里和 issue #655 中进行。
• 使用其他插件对系统进行压力测试。 WooCommerce 是首次深度测试。接下来，更多插件的通知也将通过同一目录处理，首先是 Jetpack，以观察它们的适配情况以及规则需要作出哪些调整。
• 0.3.0 中的第一步：设计核心首个 hub 能够展示的内容，使它已经朝这一方向发展。

这会何时推出？

不会很快推出，而这也没关系。会先推出 0.3.0，将其作为功能插件，随后再合并到核心中。插件只有在进入 WordPress 后才能采用通知，而迁移由每个插件按照自己的节奏自行完成。Jonathan 的每周进展更新也会遵循这一计划。我们有足够时间让反馈来塑造方案。

反馈

无论你是 WordPress 用户、正在开发会发送通知的插件，还是从事无障碍工作，都欢迎提供反馈。请在这篇文章或持续推进该项工作的 issue #655 下留言。你也可以在 Slack 上找到我们，频道为 #feature-notifications。

感谢 @jameskoster 提供早期反馈，@joen 提供指导，以及 @keoshi 此前对通知机制所作的探索。

#feature-notifications

+make.wordpress.org/design/