[译] 为 APP 设计通知提醒-优快云博客

本文探讨了三种应用程序通知模型：通知中心、锚点在消息源上的通知提醒及混合模型，并提供了选择合适模型的指导方针。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

原文地址：Designing notifications for apps: Explore different notification models and when to use which
原文作者：Shashank Sahay
译文出自：掘金翻译计划
本文永久链接：github.com/xitu/gold-m…
译者：Ryden Sun
校对者：pkuwwt sanfran1068

探索不同的通知提醒模型以及如何去选择

通知提醒模型

Medium 的读者们，我们又见面啦。这里是我们的功能分解系列文章的第五期：应用程序的通知提醒模型。当前，通知提醒算是一个处理起来比较复杂的功能。这篇文章不会覆盖其所有的痛点，但是我希望可以为你提供足够清晰的理解，并在选择合适的应用程序通知提醒模型时，为你指明一个方向。

在我们开始讨论通知提醒模型之前，我们简要的看一下通知提醒的介绍以及它是由什么组成的。通知提醒是由应用程序发送给用户的一系列消息提示。这里是一些其重要的组成部分。

通知提醒模型 — 图解

来源: 应用的这部分是通知提醒的起源。一个应用的架构可以有多个由信息分类组成的部分，并且这些部分是通知提醒的来源。

信息: 信息是一条需要通过通知提醒的方式传达给用户的消息。比如“嫦娥妹妹请求添加你为好友”或者“康熙开始关注你啦”。

类型: 通知提醒主要可分为两部分：通知型和可操作型。所有的类型都可根据其应用的内容有更深入的细分。

通知标记: 通知提醒提供可视化标示来引导用户查看通知。这些标示可以只是简单的点状符号，还可以加上未读消息的数目。

锚点: 锚点是应用程序界面上显示通知的可视化组件。简单来说，就是用户看到的通知标记所在的那个组件。简单来说，这个部分就是用户在哪里可以看到通知标记。注意，锚点不一定是通知的来源，只不过是显示通知的位置。一个锚点可以显示一个或多个来源的消息。换一句话说，消息来源是架构/信息层面的概念，而锚点只不过是实现层面让你可以看到通知标记的可视化组件。

通知提醒是应用程序用来和用户通讯的媒介，应用程序用通知提醒向用户发送信息，并且可能吸引用户重回应用。因此，它们是一个应用程序很重要的部分。让我来给你介绍一些最流行的通知提醒模型，并且合适去选择最合适的模型。

1. 通知中心

在这个模型里，会有一个明确的区域来落地所有的通知提醒。通知中心可以是一一整块专门的屏幕或者根据目前可用空间来弹出的界面。这个模型里，所有的通知提醒，不管其来源如何，都统一被放在通知中心。通过通知中心，你可以导航至不同通知提醒的源头。一个有通知标记的铜铃图标，就是所有通知提醒的入口。已读和未读通知提醒有一个可见的不同是很重要的，可以让用户来区别他们。

Medium — 通知中心

这个模型最大的优势在于它的灵活性。这个地方可以容纳所有的通知提醒，不管是已存在或是新的来源。

指导方针

所有不同类型的通知提醒都需要被考虑到，并且采用统一的设计形式。当设计此形式时，很重要的一点，是要将其可扩展性当做我们的首要目标。
如果你有太多不同来源的通知提醒，那这种模型可能会变得有一些杂乱。如果有相似的通知提醒类型，你应该将它们组合起来，以此来减少重复。举个例子，“王昭君和其他三个人请求添加您为好友”。
确保通知中心很容易被用户发现并访问到。

什么时候使用通知中心

你的产品有通知提醒的需求，而这些通知无法集成到任何已有的导航选项中。原因可能是通知与产品上已存在的对象不一致，或者通知并不源自于当前信息架构中定义的任何消息源。
可能还有更多的消息源头无法在应用程序的首页显示。
你的时间有限。可能还没来得及考虑清楚每一种可能的场景及相应的锚点，你就必须交付一个功能了。这种情况下，通知中心是你简单的解决方案，并且它天生就很灵活。

2. 锚点在消息源上的通知提醒

这个模型里，每一个通知提醒都固定于一个导航选项，最可能的选择是消息源。这里没有一个承载所有通知提醒的中心。看一看 WhatsApp 会有一个更清晰的认识。在两个平台（android 和 iOS）上，来源于聊天或者通话的通知的锚点都置于其相应的导航菜单上。这个模型的优势在于它能引导用户发现更多内容。通过这种方式，用户可以直接访问到通知所传递的消息内容，无需多一个中间层。但这个模型并不像通知中心那样灵活和可扩展。

WhatsApp — 锚点在消息源上的通知提醒

这个模型强烈依赖于应用程序的信息架构。导航必须容纳所有不同类型的通知。类似于前面的模型，已读和未读通知提醒有一个可见的不同是很重要的，可以让用户来区别他们。

指导方针

确保每个通知提醒的锚点都能对应到应用程序首页的某个导航选项上。随着你应用复杂度的增长，通知提醒的数目也会增加。这种情况下，你可以投向通知中心的怀抱，或者考虑一种混合模型（那就是锚点模型和通知中心的结合）。我们会在下一节讲到混合模型。
每一个锚点都应有一个对应其所含内容的设计形式。确保你的通知契合锚点的设计形式。为了理解这个，让我们看一下 WhatsApp 的例子。锚点“聊天”有一个设计形式，它定义了一个聊天对象看起来应该是什么样子。这意味着每一个锚点固定于聊天的通知提醒都应该服从这种设计形式。这同样被用来设计“通话”的通知提醒。
确保锚点易于发现和访问。避免使用嵌套锚点。

什么时候使用锚点在消息源上的通知提醒

当所有可能的消息通知来源都可以被首页容纳。
你已考虑到所有可能使用到通知提醒的场景，并且所有的通知提醒都可以适用于已存在的设计形式。很重要的一点是这些通知提醒应该遵守其锚点所在的消息源的设计形式。

3. 混合模型

这种模型是前面两种的结合。这种模型是最常被使用的。有很多比较火的应用是使用这种模式的，如 Facebook, LinkedIn, Twitter 和 Instagram。这些应用中，通知中心变成了导航菜单上的一个选项，它可以是不同来源的锚点，这些来源都不还不够资格在首页展示。比如，Facebook 把请求添加好友的通知锚点到“朋友”选项，但邀请点赞被锚点到了通知中心。

Facebook — 混合模型

这种模型有以上两种模型的优点，并且可以轻易地适用大多数情况。即使现在你有能力将消息提醒锚点到通知中心，但依旧有必要考虑所有的场景并且将它们排出优先级，找到那些可以适用锚点于来源的通知提醒。

就像锚点在消息源上的通知提醒模型，这个模型也严重依赖于导航菜单，而且还有一个通知中心的菜单选项。

指导方针

找出产品架构中最重要的那些信息，并对其优先级排序，这样你才可以决定哪些锚点应放在消息源，哪些应放在通知中心。因为此模型依赖于导航，通知提醒的配置可能会因可用空间的变化而改变。
确保首屏的导航中容易找到主要的锚点和通知中心

什么时候使用混合模型

你有考虑过所有通知提醒的使用场景。你有一些通知提醒的锚点可以放在消息源上，但是还有一些无法放在当前架构的任何消息源上
你的架构中存在嵌套的消息源。比如，Facebook 应用程序的汉堡式菜单图标是一个锚点，它对应于多个消息源，比如 Groups, Watch, Memories, Saved, Marketplace 等等。