通知是一项处理起来比较复杂的功能。本文不会涉及所有的细节，但是希望所提供的信息能够为你的应用程序选择正确的通知模式提供清晰的指引。
在开始讨论通知模式之前，先来快速熟悉一下什么是通知以及它是由什么构成的。通知是针对来源于针对用户的应用程序的信息。以下列出通知的一些重要组成部分。
通知模型架构
来源：这是通知在应用程序中的起源地。应用程序的体系结构可以有几个对信息进行分类的buckets，这些buckets将成为通知的来源。
信息：这是通过通知传达给用户的消息。例如「xxx向您发送了一个好友请求」或“「xxx开始关注您」。
类型：通知主要分为两个类型：信息通知和可操作通知。根据应用程序的使用情境不同，这两种模式还都会有进一步的细分类型。
通知提示：这是将用户引导至通知的视觉提示。通知提示符可以简单的使用一个小圆点，也可以在圆点上标记上数值，以提示未读通知的数量。
锚点：锚点是通知在应用程序上呈现出来的可视组件。简而言之，是用户可以看到通知提示符的组件。请注意，锚点不一定是通知的来源，而只表示通知所在位置的组件。锚点可以容纳来自多个或单个来源的通知。你也可以这样理解，来源更多的是指架构/信息层面，锚点是你可以看到通知标识的可视组件。
通知是应用程序与用户进行通信并将其带回应用程序的媒介之一。因此，它们是应用程序中非常重要的一部分。接下来将介绍一些目前最受欢迎的通知模型及其使用时机。
1. 通知中心
在此模型中，所有通知都放置在既定的位置。通知中心可以是一个专用屏幕，也可以是弹出窗口。并且，所有通知均锚定在通知中心，无论其来源是哪儿。你可以从通知中心导航到通知源。如下图所示，Medium应用程序使用了此通知模型。响铃图标上会显示一个badge徽标，这是所有通知的入口。同样重要的是，已读和未读通知在视觉上要有所不同，以便用户能够区分它们。
Medium 的通知中心
此模型的最大优点就是灵活性。它是一个可以容纳所有通知的地方，无论是来自现有源的通知还是新的通知。
使用方法
- 必须仔细考虑所有不同类型的通知，并应遵循相同的设计架构。设计架构时，将可伸缩性视为主要目标很重要。
- 如果有太多的通知来源，那么当通知太多时此模型可能会显得有些混乱。如果存在类似的通知类型，可以将它们分成一组，这将有助于减少重复。例如，「xxx和其他3个人向您发送了一个好友请求」。
- 确保通知中心易于被发现和访问。
使用时机
- 你的产品需要具有无法锚定到任何现有导航选项的通知。这可能是因为通知与产品上的现有对象不一致，或者通知不是源自信息体系结构中任何已定义的源。
- 通知来源可能比应用程序在着陆屏幕上所能容纳的来源更多。
- 时间紧迫时。在某些情况下，你需要先发布功能，然后再考虑所有可能的通知场景并为每个场景找到锚点。在这种情况下，通知中心可能是一条轻松的出路，因为它非常灵活。
2. 源锚定通知
在此模型中，每个通知都锚定到导航选项，该选项可能就是通知源。并且，该模型没有单个中心用于所有通知。如下图所示，以WhatApp为例。在 Android 和 iOS 双平台上，来自「聊天 Chats」或「呼叫 Calls」的通知都锚定到相应的导航菜单上。该模型的优点是可以带来更多可被发现的内容。用户可以直接到达通知所传达的信息处，而省去添加中间层的麻烦。但是，此模型不像通知中心那样具有灵活性和可扩展性。
WhatsApp 的源锚定通知模型
该模型在很大程度上取决于应用程序的信息架构。导航必须能够容纳所有不同类型的通知。与前一个模型一样，此处还必须对已读和未读通知进行视觉上的区分。
使用方法
- 确保每个通知都可以锚定到着落屏幕的导航选项上。随着应用程序复杂性的增加，通知源的数量也可能会增加。在这种情况下，你可以选择一个通知中心，也可以考虑使用混合模型（即锚定模型和通知中心的组合）。下一节中将会介绍混合模型。
- 每个锚点应为其所包含的内容提供设计架构。确保通知符合锚点架构。为了理解这一点，还是以WhatsApp为例。这里的锚点「聊天 Chats」具有定义聊天对象的外观设计架构。这意味着任何锚定到聊天的通知都必须遵循此架构。「呼叫 Calls」也是如此。
- 确保锚点易于被发现和访问。避免使用嵌套锚点。
使用时机
- 当所有可能的通知源都可以容纳在着陆屏幕上时。
- 你已经考虑过所有的通知场景，并且所有通知都可以使用现有的设计架构来容纳。记住，这些通知必须遵循其锚定源的架构，这一点很重要。
3. 混合模式
该模型是以上两个模型的组合，也是最常用的模型。Facebook、LinkedIn、Twitter和Instagram这些热门应用程序都是使用的这一模式。在这种模式下，通知中心成为导航菜单中的选项之一，可用作不符合着陆屏幕条件的通知源的锚点。例如，Facebook将新朋友请求锚定到「朋友 Friends」选项卡上，但是将喜欢页面的邀请锚定到通知中心。
Facebook 的混合模式
该模型具有两种模型的优点，并且可以轻松适应大多数情况。尽管现在你可以将通知锚定到通知中心，但是仍然必须仔细考虑所有方案并确定源锚定通知可以容纳的场景的优先级。
就像源锚定模型一样，此模型也严重依赖于导航菜单，并且该菜单现在还具有通知中心的选项。
使用方法
- 确定产品架构中最重要的 buckets 并将其分类。对 buckets 进行排名以便能够优先确定应将哪些通知锚定到源，哪些放在通知中心。由于此模型取决于导航，因此通知的配置会根据可用空间进行更改。
- 确保在着陆屏幕上可以轻松发现主要锚点和通知中心。
使用时机
- 你已经考虑了通知场景。有一些通知可以锚定到它们各自的源，但是其它一些通知则不能锚定到体系结构中的任何现有源。
- 导航中已经嵌套了源。例如，Facebook应用程序上的汉堡包菜单图标可锚定来自其内部源的通知，例如小组、视频、回忆、收藏夹等。
总结
上面提到的所有模型在正确的情境中都是有用的。为你的应用选择哪种模型取决于信息体系结构和想要满足的通知类型。
英文原文：https://uxmag.com/articles/designing-notifications-for-apps
原文作者：Shashank Sahay
编译作者：@设计吐司
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
网友评论