蜗牛派本期将为大家带来如何设计应用程序中的通知模型，现在，通知可能是一个复杂的功能。本文并未涵盖其所有详细信息，但我希望它足以为你提供一些清晰度和指导，为你的应用程序选择正确的通知模型。
在我们开始讨论通知模型之前，让我们简要介绍一下什么是通知以及它们由什么组成。通知是来自于针对用户的应用程序的信息片段。下面是通知的一些重要组成部分。
通知模型-模式
来源:这是应用程序中产生通知的部分。应用程序的体系结构可以有多个存储桶，用于对信息进行分类，这些存储桶将成为通知源。
信息:这是需要通过通知的方式传达给用户的消息。比如“小明向你发送好友请求”，或者“小莉开始关注你”。
类型:通知主要有两种类型:信息性的和可操作的。根据应用程序的上下文，这两种类型都可以有进一步的子类型。
通知徽章:这些是可视化指示器，将用户导向通知。通知指示器可以像点一样简单，也可以有一个计数来显示未读通知的数量。
锚:锚是app的可视组件，通知会出现在界面上。简单地说，用户将在这个组件上看到通知指示符/徽章。注意，锚不一定是通知源，而只是通知出现的组件。锚可以存放来自多个源的通知，也可以只存放一个源的通知。可以这样想，资源更多的是在架构/信息级别上，而锚点是可以看到通知标识的可视组件。
通知是应用程序与用户进行通信并可能将用户带回应用程序的媒介之一。因此，它们是应用程序中非常重要的一部分。让我介绍一些最流行的通知模型，以及如何使用其中一种。
1、通知中心
在这个模型中，有一个定义了所有通知的位置。通知中心可以是一个专用屏幕，也可以是一个弹出窗口，这取决于可用的尺寸。在此模型中，所有通知都锚定到通知中心，而不管它们的来源是什么。然后，你可以从通知中心导航到通知源。Medium使用这个模型来通知。一个徽章会出现在铃铛图标上，这是你所有通知的入口点。同样重要的是，已读通知和未读通知在视觉上有所不同，以便用户能够区分它们。
Medium-通知中心
这种模式最大的优点是它的灵活性。这是一个可以容纳每个通知的地方，无论是来自现有的源还是新的。
指导方针
- 所有不同类型的通知都必须经过深思熟虑，并遵循相同的设计模式。在设计模式时，务必将可伸缩性视为我们的主要目标。
- 如果你有太多的通知源，当有太多的通知时，这个模型可能会看起来有点混乱。如果有相似类型的通知，你可以把它们放在一起，这将有助于减少重复。比如，“小明和其他三个人向你发送了好友请求”。
- 确保通知中心易于发现和访问。
使用通知中心时
- 你的产品需要无法锚定到任何现有导航选项的通知。这可能是因为通知与产品上的现有对象不一致，或者通知不是来自信息体系结构中任何已定义的源。
- 可能的通知源比应用程序在着陆屏幕上所能容纳的要多。
- 当你时间不够的时候。可能会出现这样的情况:在没有时间考虑通知的所有可能场景并为每个通知找到锚之前，你需要发布一个特性。在这种情况下，通知中心可能是你的简单方法，因为它本质上非常灵活。
2、源锚定通知
在此模型中，每个通知都锚定到导航选项，该导航选项也很可能也是通知的来源。没有所有通知的单一中心/中心。看看WhatApp有一个更好的主意。在两个平台（Android和iOS）上，来自聊天或呼叫的通知都锚定在各自的导航菜单上。该模型的优点是可以导致更多的内容发现。用户现在可以直接到达通知所传达的信息，而无需添加中间层。但是此模型不像通知中心那样灵活或可扩展。
WhatsApp-源锚定通知
这种模式严重依赖于应用程序的信息架构。导航必须能够容纳所有不同类型的通知。与上一个模型一样，这里的已读通知和未读通知在视觉上有所不同也很重要。
指导方针
- 确保每个通知都可以锚定到着陆屏幕上的一个导航选项。随着应用程序的复杂性增加，通知源的数量也会增加。在这种情况下，你可以选择一个通知中心，或者你可以考虑一个混合模型(即锚定模型和通知中心的组合)。我们将在下一节中讨论混合模型。
- 每个锚都应该为它将要容纳的内容提供一个设计模式。确保通知符合锚的模式。让我们以WhatsApp为例来理解这一点。这里的锚点“chat”有一个设计模式，它定义了一个chat对象应该是什么样子。这意味着锚定到chat的任何通知都必须遵循此模式。“打电话”也是一样。
- 确保锚易于发现和访问。避免使用嵌套锚。
使用源锚定通知
- 当所有可能的通知源都可以容纳在着陆屏幕上时。
- 你已经考虑了通知的所有场景，并且所有通知都可以与现有的设计模式相适应。这些通知必须遵循它们锚定的源的模式，这一点很重要。
3、混合模型
这个模型是这两种模型的组合。它是最常用的模型。Facebook、LinkedIn、Twitter和Instagram是使用它的一些流行应用程序。在这里，通知中心成为导航菜单中的选项之一，可以作为不符合登陆屏幕条件的源的锚。例如，Facebook将新好友请求锚定在“好友”标签，而邀请喜欢页面锚定在通知中心。
Facebook -混合模式
该模型具有两种模型的优点，可以方便地适应大多数情况。尽管现在你已经能够将通知锚定到通知中心，但仍然有必要考虑源锚定通知能够适应的所有场景和优先级。
与源锚定模型一样，该模型也严重依赖于导航菜单，它现在也有通知中心作为选项。
指导方针
- 确定产品架构中最重要的信息桶并对其进行排序。对它们进行排序可以让你优先考虑哪些通知应该锚定到源，哪些应该进入通知中心。由于此模型依赖于导航，通知的配置可以根据可用的不动产进行更改。
- 确保主锚和通知中心作为导航的一部分很容易在着陆屏幕上被发现。
使用混合模型
- 你已经全面考虑了通知场景。有些通知可以锚定到它们各自的源，但其他一些通知不能锚定到体系结构中的任何现有源。
- 导航中嵌套了源代码。例如，Facebook应用程序上的汉堡菜单图标是来自它下面来源的通知的锚点，例如群组、观看、记忆、保存、市场等。
结论
上面提到的所有模型在正确的上下文中都是有用的。为你的应用选择哪种模式取决于信息架构和你想要迎合的通知类型。
