为App设计通知：探索不同通知模型以及使用场景

通知可能是一个复杂的要素。这篇文章没有涵盖关于通知的所有细节，但我希望这篇文章可以为你提供足够清晰的指导，以便为你的App选取正确的通知模型。

在我们开始讨论通知模型之前，让我们简明扼要的说一下什么是通知以及他们是由什么组成的。通知是源自针对用户的应用程序的信息。以下是通知的一些重要组成部分：

Notification Models — Schema

信息（information）：通过通知传达给用户的信息。例如“Daenerys Targaryen请求添加为好友”，“Lords Varys 关注了你”。

类型（type）：通知主要分为俩个类型:信息型（informational）和可操作型（actionable）。这两个类型可以有其他的子类型，这取决于应用程序的背景。

通知角标（notification badge）：这是可以将用户引导到通知的可视化指示物，可视化指示物可以是点，也可以是未读信息的数量。

通知是应用程序与用户交流并可能将其带回应用程序的媒介之一。因此，通知是应用程序的重要组成部分。接下来让我来介绍一些最流行的通知模型，以及什么时候应该使用其中的一种。

1. 通知中心(Notification Center)

Medium用的就是这种通知模型。一个带角标的铃状图标是所有通知的入口。已读和未读通知在视觉上有所不同以便用户能够区分它们，同样是很重要的。

Medium — Notification Center

必须全面考虑所有不同类型的通知，并且应该遵循相同的设计模式。在设计模式时，将可拓展性视为我们的主要目标是极为重要的。

确保通知中心的可发现性以及易使用性。

可以参考一下WhatsApp：

在Android和iOS两个平台，聊天和通话的通知被放置在各自的导航菜单。这个模型的优点是可以使更多的内容被发现，用户可直接到达通知所传达的信息，无需添加中间环节的麻烦。但是这个模型不像通知中心那样灵活，以及具备可拓展性。

WhatsApp — Source Anchored Notifications

这个模型重度依赖于应用程序的信息架构。导航必须可以容纳不同类型的通知。并且像前一个模型一样，已读和未读通知在视觉上有所不同是很重要的。

每个锚点都应有一个它所容纳的内容的设计模式。确保你的通知符合锚点的设计模式。为了理解这条，我们可以以WhatsApp为例。这里的“聊天”锚点有一个设计模式，用于定义 “聊天”这一对象是什么样的。这就意味着任何被放置在“聊天”得通知都应遵循这一模式。“通话”同理。

确保锚点的可发现性以及易使用性。避免使用嵌套的锚点。

Facebook — Mixed Model

确定产品架构中最重要的信息并将其分类。分类可以使你优先处理哪些通知应该被放到锚点，哪些应该放进通知中心。由于此模型取决于导航，因此通知的布局可以根据可利用的空间进行调整。

确保主要的锚点和通知中心可以被轻松的发现。

上面提及的所有模型在特定的情况下都是很有用的。决定将哪种模型运用到你的app上取决于信息架构和你想满足的通知类型。

题图来自Unsplash，基于CC0协议

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！