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

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

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

Notification Models — Schema

来源（source）：通知的来源属于应用程序的一部分。应用程序的架构可以有几个对信息进行分类的存储桶（bucket），这些存储桶将成为通知的来源。

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

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

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

锚点（anchor）： 锚点是应用程序的可视化组件，将通知显现在界面上。简单来说，这是一个用户可以看到通知角标的组件。注意，锚点不一定是通知的来源，而只是将通知显现出来的组件。一个锚点可以容纳多个来源或一个来源的通知。可以这样想，来源更多是在架构/信息层面，但是锚点是你可以看到通知角标的可视化组件。

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

1. 通知中心(Notification Center)

在这个模型，所有的通知都在一个被明确好的地方。通知中心可以是一个单独的界面或是一个弹窗，这取决于可利用的空间。在这种模型中，所有的通知，不管他们的来源，都被放在通知中心。然后，你可以从通知中心导航到通知来源。

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

Medium — Notification Center

这种模型更大的优点是灵活性。通知中心是一个可以容纳所有通知的地方，无论是来自现有来源的通知还是新的通知。

准则

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

如果有太多的通知来源，这种模型在有太多通知时就会看起来有点凌乱。如果有同类型的通知，你可以把他们分组，减少重复。例如“Sansa Stark以及其他三人请求添加为好友”。

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

何时使用通知中心

你的产品需要通知，但这些通知又无法被放到已有的导航选项中时。可能是因为这类通知与产品上的现有对象不一致，或者这类通知不是源自信息架构中任何已经定义的来源。

当通知来源多于应用程序主屏幕所能容纳的时候。

2. 固定来源通知(Source Anchored Notifications)

在此模型中，每个通知都固定到导航选项上，该导航选项也很有可能也是通知来源，没有为你的通知准备单独的中心。

可以参考一下WhatsApp：

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

WhatsApp — Source Anchored Notifications

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

准则

确保在主屏幕中每个通知都对应一个导航选项。随着应用程序复杂性的增加，通知来源的数量也可能会增加。在这种情况下，您可以选择通知中心模型，也可以考虑使用混合模型（这两种模型的结合）。我们会在下一部分讲解混合模型。