探索不同通知模型的使用方式
媒体人，你们好！我们继续讲述APP功能细分系列的第五个细分功能 —应用程序的通知模型。现在来看，通知是一个复杂的功能。本文并未涵盖通知的所有细节，但我希望它可以在您为应用程序选择通知模型时提供一些清晰且正确的方向。
在我们开始讨论通知模型之前，让我们快速了解一下通知是什么以及它们包含什么。
通知是源自针对用户的应用信息。
以下是通知的一些重要组成部分。
来源：通知发起是应用程序的一部分。在应用程序的体系结构可以有多个存储区，进行信息分类，这些存储区将成为通知源。
信息：需要通过通知传达给用户的消息。例如“Daenerys Targaryen发给你的朋友请求”或“Lord Varys开始关注你”。
类型：通知主要有两种类型：信息和可操作。根据应用程序的不同，这两种类型都可以有其他子类型。
通知徽章：是用于指导用户通知的可视指示器。通知指示符可以像点一样简单，也可以对其进行计数，将显示未读通知的数量。
锚点：锚点是应用程序的可视组件，通知在界面上显示。简而言之，这是用户将看到的通知指示符/徽章的组件。请注意，锚点不一定是通知源，而只是通知表面所在的组件。锚可以容纳来自多个来源或仅一个来源的通知。想象一下，源代码更多地是在架构/信息级别上，但是锚点是可视组件，您可以在其中看到通知标记。
通知是应用程序与用户通信 ，并可能将用户带回应用程序的介质之一。因此，它们是应用程序中非常重要的一部分。让我向您介绍一些最常见的通知模型，以及何时使用一个通知模型。
1.通知中心
在这个模型中，只要有一个明确的地点，你所有的通知都会到达。通知中心可以是专用屏幕或弹出窗口，具体取决于可用的产品。在此模型中，所有通知不管其来源，都聚集到通知中心。然后，您可以从通知中心导航到通知来源。Medium使用此模型进行通知。徽章会显示在响铃图标上，该图标是所有通知的入口点。读取和未读通知是两种不同的视觉表现形式，目的是方便用户区分，这也是十分重要的。
该模型的最大优点是其灵活性。这是一个可以容纳每个通知的地方，无论是现有来源还是新内容。
使用方针：
必须考虑所有不同类型的通知，并且应遵循相同的设计架构。在设计模式时，将可伸缩性视为我们的主要目标非常重要。
如果您有太多的通知来源，那么当通知太多时，此模型可能会开始变得有点混乱。如果有类似类型的通知，您可以将它们组合在一起，这有助于减少重复。例如，“Sansa Stark和另外3人向您发送了朋友请求”。
确保通知中心易于发现和访问。
关于通知中心的使用：
您的产品无法锚定到任何现有导航选项的通知。这可能是因为通知与产品上的现有对象不一致，或者通知不是源自信息体系结构中任何已定义的源。
通知源可能比应用程序可以在屏幕上容纳的更多。
当你的时间很短。在您需要时间考虑所有可能的通知方案并找到每个方案的锚点之前，可能会出现需要发布功能的情况。在这种情况下，通知中心可能是您轻松的出路，因为它本质上非常灵活。
2.来源锚定通知
在这个模型中，每个通知都锚定到导航选项，该选项很可能也是通知的来源。您的所有通知都没有单一的中心。看看WhatApp可以获得更好的想法。在两个平台（Android和iOS）上，来自聊天或调用的通知都锚定到相应的导航菜单。该模型的优点在于它可以提供更多内容的可发现性。用户现在可以直接访问通知所传达的信息，而无需添加中间层。但是这种模型不像通知中心那样灵活或可扩展。
此模型在很大程度上取决于应用程序的信息架构。导航必须能够容纳所有不同类型的通知。与之前的模型一样，此处读取和未读取的通知在视觉上也是不同的。
使用方针：
确保每个通知都可以锚定到屏幕上的某个导航选项。随着应用程序复杂性的增加，通知源也可能会增加。在这种情况下，您可以选择通知中心，也可以考虑混合模型（即锚定模型和通知中心的组合）。我们将在下一节中介绍混合模型。
每个锚都应该有一个设计架构，用于它将容纳的内容。确保您的通知符合锚点的架构。为了理解这一点，让我们以WhatsApp为例。这里的锚点“聊天”有一个设计模式，用于定义聊天对象的外观。这意味着锚定到聊天的任何通知都必须遵循此架构。“呼叫”也是如此。
确保锚固件易于发现和可触及。避免使用嵌套锚点。
关于源锚定通知使用：
当所有可能的通知来源都可以在登陆屏幕上进行调整。
当您已经考虑了所有通知方案，并且可以使用现有设计模式来适应所有通知。这些通知遵循它们所锚定的源的模式非常重要。
3.混合模型
该模型是两种模型的组合（即锚定模型和通知中心的组合）。它是最常用的型号。Facebook，LinkedIn，Twitter和Instagram是一些使用它的常见应用程序。在这里，通知中心成为导航菜单中的选项之一，可以用作不符合登陆屏幕资格的源的锚。例如，Facebook将新朋友请求锚定到“朋友”选项卡，但是喜欢页面的邀请被锚定到通知中心。
该模型具有两种模型的优点，可以轻松适应大多数情况。虽然现在您可以将通知锚定到通知中心，但仍然必须仔细考虑所有方案并确定优先级，这可以通过源锚定通知进行调整。
就像源锚定模型一样，此模型也严重依赖于导航菜单，导航菜单现在还具有通知中心选项。
使用方针：
识别产品架构中最重要的信息并对其进行排名。对它们进行排名可以让您优先考虑哪些通知应该锚定到源，哪些通知应该放在通知中心。由于此模型取决于导航，因此通知的配置可根据可用的不动产进行更改。
确保主要锚点和通知中心可以作为登陆屏幕上导航的一部分轻松发现。
关于混合模型的使用：
您已经考虑过通知方案。您有一些通知可以锚定到各自的源，但仍有些其他通知无法锚定到架构中的任何现有源。
您在导航中已嵌套了源。例如，Facebook应用程序上的汉堡菜单图标是其它来源的通知锚点，例如群组，观察，记忆，已保存，市场等。
结论：
上面提到的所有模型在合适的情景下都是很有用的。选择应用程序的模型取决于信息体系结构和您想要迎合的通知类型。
—— 三米工作室 · 每周优质文章翻译 ——
原文链接：
https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96
