网站内容更新系统(notice.jpg通知系统设计的原则可简单的归纳为)

　　网站内容更新系统(notice.jpg通知系统设计的原则可简单的归纳为)

　　写在前面：通知系统是网站信息传播机制的重要组成部分，够写一大章来解释了。本文仅梳理设计原则，后续相关内容会持续更新。这里的通知包括但不限于公告、提醒或消息（不同使用场景的功能定义不同）。关于各个客户端平台（ios、android、wp等）的通知机制，交互设计指南中有更详细的说明，可以自己参考。

　　一、通知系统定义

　　通知系统，顾名思义，就是通知信息的传输和处理系统。目的是让用户获取他们需要获取和处理的消息和提醒。这里的“需要获取”有两个含义：1、用户交互触发的信息流（留言、评论或回复、私信等）2、网站希望用户了解自己关心的信息（系统公告等）

　　通知.jpg

　　通知系统的设计原则可以简单概括为：1、最高的消息传播效率（获取、处理、信息传递、用户反馈等效率）2、避免骚扰（噪音、频繁提示）

　　二、通知分类

　　不同的平台和产品因业务需求不同而有不同的类型。

　　大致可以分为以下几类：

　　noticekind.png

　　三、Notification 逻辑实现机制

　　通知的逻辑简化如下：

　　shixianjizhi.png

　　现在单独解释这些链接：

　　(一）注意合并

　　通知在推送前需要进行聚合合并，以提高消息传播和处理的效率；减少骚扰和噪音；并平衡服务器压力。 1）Consolidation cycle：固定时间内的所有消息汇总（24小时内/30天等）；没有固定时间（只要不处理/读取，就汇总）

　　当然，它们一般是合并的：合并24小时内未处理的消息2）classification合并和合并同一个类别（例如n条消息合并为1条）由同一个发起者合并（对于比如张三私信发给你的n条消息）在同一时间段内合并（比如24小时内收到n条评论）

　　(二）通知分发

　　通知按照规则汇总后，系统会通过通知管道推送给用户，供用户处理。 1）Distribution 方式 分发方式类似于feed系统，多采用Push方式，即在指定时间内主动推送给用户。某些特定类型需要用户请求 (Pull) 拉取未读消息。目前大部分通知会优先推送合并后未处理的通知总数，并提醒用户有新消息需要处理。用户点击号码，然后去服务器请求特定的消息内容。这样就综合考虑了成本、压力和经验。当然，一些极端情况需要优化：如果未读消息数超过1000条，前50条消息在用户请求时被推送或放入缓存。技术童鞋的方法有很多种，这里不再详述。 2）分发频率（时间） 分发时间主要根据消息的优先级划分：

　　fenfayx.png

　　3）Distribution channel 分发渠道是消息通知的具体推送渠道。按业务类型可分为：Web、App、短信、邮件等

　　(三）用户处理

　　按照上面提到的分发方式，通知的处理在逻辑上可以分为两个层次：通知状态的处理和通知内容的处理。 1）State 处理狭义理解为是否被读取（处理过）。通常初始数量是系统推送的总未读数量。用户点击数字进入相关功能列表后，阅读动作完成，未读数字相应减少。

　　noticezhuangtai.png

　　有几种情况需要解决： 如果用户有大量未读信息（m=100），但第一页列表只能显示（n=10），则未读数为mn=90；有些产品会将点击等同于已读，即用户无论是否打开列表都会认为已读。这种处理一般用于重要性较低的消息。阅读可以有效减少骚扰一些高层重要消息的处理状态可以定义为在用户进行相关操作后处理，而不是被查看。 、点击忽略或点击删除。

　　2）内容处理的狭义是用户是否操作。根据不同的消息类型和业务需求，操作可以分为： 处理：用户必须点击功能链接进行处理。例如：您的密码太简单，点击这里修改；回复：如果回复私信，回复评论；确认：对消息进行确认反馈，如部分系统提示，可设置“我已经知道，不再提示”选项；忽略：用户执行了忽略操作或不执行任何操作；删除：用户删除此消息。

　　3）消息处理后的状态需要统一。消息需要标记是否已处理，并在不同终端打开状态。例如，如果用户在客户端查看该消息，则该消息应在网站上自动标记为已读。

　　(四）notification 回收

　　回收主要是对用户已经处理过的消息进行操作。用户之间触发的消息通常需要存档。如评论/回复/留言/私信等，产品可以提供一个选项，询问用户是否在一定时间后自动清理。在某些产品中，还需要考虑功能的优先级。如果您取消好友关系或加入黑名单，双方的私信记录将被自动删除。系统触发的消息一般都会设置一定的恢复和删除时间。如系统提醒、通知、公告等，过期后会自动从产品中删除。物理上可以设置是否备份。已过期但未被用户处理的消息（用户长时间未登录但收到他人回复）可根据业务需要进行处理。例如，未读的私信/评论/回复将被永久保存。对于重要的未读消息，您可以尝试二次推送或使用其他方式（邮件、APP、短信等）通知您。

　　四、Notification 处理交互

　　注意：具体的交互需要考虑自身的业务特点和目标需求。某些业务可能需要强调，某些业务需要考虑骚扰，因此在没有特定上下文本身的情况下谈论交互是无耻的。这里只针对一般社区网站，描述个人喜欢的交互方式。 1、当新消息到达时提醒交互。当有新消息到达时，您可以使用以下提醒方法。标题闪烁

　　山东.png

　　有新消息到达时，声音提醒会自动触发声音

　　facebookn.png

　　气泡+数字

　　facebookqipa.png

　　新建新闻浮动层

　　weibonot.png

　　弹出提示

　　探创.png

　　2、Notification 处理目前消息大多采用当前触发器，实时处理类似于“所见即所得”的交互方式。

　　facebooktishi.png

　　使用该方法时需要考虑：消息通知位于全局导航中，可以保证在访问任何频道时都能及时收到新消息；消息在浮动层处理后，用户可以继续之前的操作而不会造成中断；由于导航区域有限，需要统一组织规划报文类型； （Facebook分为好友请求、私信和通知。）提供历史记录（更多和所有消息）的入口（二级页面）读取状态并处理消息提醒号码之间的关系

　　知乎notece.png

　　五、防骚扰（不好意思）

　　由于消息本身的业务性质，太多无用的通知必然会造成噪音和打扰用户。因此，合理设置消息的通知频率和渠道，防止早上体验和效率的损失。 1、提供了通知频率和渠道的管理功能，如常用邮件退订管理和消息通知类型管理。

　　facebookset.png

　　Facebook 通知设置

　　facebooknoticeste.png

　　2、增加屏蔽功能。消息屏蔽功能应属于业务中第一条的通知类型管理。当业务模块较多且之前的关联分散时，或通知第三方应用开​​放平台功能时，可以使用屏蔽功能。

　　facebookyingyong.png

　　Facebook 应用消息管理

　　weiboyingyong.png

　　新浪微博应用消息管理3、组合权限系统1、功能隐私设置使用隐私设置定义具体的接收权限、范围等

　　微博思信.png

　　微博私信设置2、结合黑名单功能使用黑名单屏蔽来自特定用户或关键词的特定通知。

　　六、用户撤回

　　当用户长时间不登录或不处理消息时，可以通过其他渠道推送通知，达到了拉回的目的。这应该与网站 的整体回调策略相结合。

　　万城拉会.png

　　示例：Facebook 好友请求确认以撤回电子邮件：

　　faceooklahui.png

　　七、Summary

　　呃，如果你能看到这个，非常感谢。这个文章断断续续的更新完成了好几天。很多地方不完整。我希望能原谅我。本来想总结一套逻辑方法来处理这种业务，后来放弃了。原因是：具体业务需要详细分析。现有资源和现状非常重要。这是设计的前提原则，例如优先级。空间层次、综合考虑、预留接口、数据统计等，最好不要说。

　　最后，如果你觉得这篇文章对你有用，请分享给更多人。 （请注明出处）