网站内容更新系统( 网站信息传播机制的重要的通知机制，你了解吗？ )

　　网站内容更新系统(

网站信息传播机制的重要的通知机制，你了解吗？

)

　　

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

　　一、通知系统定义

　　通知系统，顾名思义，就是通知信息的传输和处理系统。目的是让用户获取他们需要获取和处理的消息和提醒。

　　这里的“需要获取”有两层含义： 1、用户交互触发的信息流（消息、评论或回复、私信等）2、网站希望用户理解他们关注的信息（系统公告等）

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

　　二、通知分类

　　不同的平台和产品由于业务需求不同，本身就有不同的类型。

　　大致可以分为以下几类：

　　

　　三、通知逻辑实现机制

　　通知逻辑简化如下：

　　

　　现在分别解释这些链接：

　　(一）合并通知

　　通知需要在推送之前聚合和合并。目的是提高消息传播和处理的效率；减少骚扰和噪音；并平衡服务器压力。

　　1） 整合周期：对固定时间内的所有消息进行汇总（24小时内/30天等）；无固定时间（只要不处理/读取，就会汇总）

　　当然，它们一般是组合使用的：合并24小时内未处理的消息

　　2） 同类别合并分类合并（例如将n条消息合并为1条消息）与同一发起者（例如张三发送给您的n条私信）在同一时间段内合并（比如24小时内一共收到n条评论）（二）通知分发

　　通知按照规则汇总后，系统会通过通知管道推送给用户，供用户处理。

　　1）分配方式

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

　　2）分发频率（时间）

　　分发时间主要根据消息的优先级来划分：

　　

　　3）分发管道

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

　　(三）用户处理

　　根据上面提到的分发方式，通知的处理在逻辑上可以分为两个层次：通知状态的处理和通知内容的处理。

　　1） 状态处理的狭义解释是它是否被读取（处理过）。

　　通常初始数量是系统推送的总未读数量。用户点击数字进入相关功能列表后，阅读动作完成，未读数字相应减少。

　　

　　有几种情况需要解决：

　　如果用户有大量未读信息（m=100），但第一页列表只能显示（n=10）），则未读数为mn=90；部分产品点击将等同于阅读，即无论列表是否打开，用户都会认为它已阅读。这种处理一般用于重要性较低的消息。点击阅读可以有效减少骚扰。一些更高的重要性级别 消息的处理状态可以定义为在用户执行相关操作后被处理，而不是被查看。例如，当用户发表评论、回复、点击忽略或点击时，用户会认为它已处理2）内容处理 狭义的，就是用户操作与否。

　　根据不同的消息类型和业务需求，操作可以分为：

　　加工：用户必须点击功能链接进行加工。例如：您的密码太简单，点击这里修改；回复：如果回复私信，回复评论；确认：对消息进行确认反馈，如部分系统提示可设置“我已经知道，不再提示”选项；忽略：用户忽略或什么都不做；删除：用户删除此消息。3） 消息处理后的状态需要统一。

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

　　(四）回收通知

　　回收主要是对用户已经处理过的消息进行操作。

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

　　注：具体交互需要考虑自身的业务特点和目标需求。某些业务可能需要强调，某些业务需要考虑骚扰，因此在没有特定上下文本身的情况下谈论交互是无耻的。

　　这里只针对一般社区网站，描述个人喜欢的交互方式。

　　1、新消息到达时提醒交互

　　当新消息到达时，您可以使用以下提醒

　　标题闪烁

　　

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

　　

　　泡泡+数字

　　

　　新闻浮动层

　　

　　弹出提示

　　

　　2、 通知处理

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

　　

　　采用这种方法时需要考虑：

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

　　

　　五、反骚扰（不好意思）

　　由于消息本身的业务性质，太多无用的通知势必会造成噪音和打扰用户。因此，合理设置消息的通知频率和渠道，防止早上体验和效率的损失。

　　1、提供通知频率和频道管理功能

　　如常用邮件退订管理、消息通知类型管理。

　　

　　脸书通知设置

　　

　　

　　2、添加屏蔽功能

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

　　

　　facebook应用消息管理

　　

　　新浪微博应用消息管理

　　3、结合权限系统1、功能隐私设置

　　使用隐私设置来定义特定的接收权限、范围等。

　　

　　微博私信设置

　　2、结合黑名单功能

　　使用黑名单阻止特定用户或关键词的特定通知。

　　六、用户拉回

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

　　

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

　　

　　七、总结

　　呃，如果你能看到这个，非常感谢。这个文章断断续续更新好几天就完成了，很多地方都不完整。我希望能原谅我。

　　本来想总结一套逻辑方法来处理这种业务，后来因为以下原因放弃了：

　　具体业务需要具体分析。现有资源和现状非常重要。这是设计的前提原则，比如优先级、统筹考虑、预留接口、数据统计等，最好不谈空间。

　　通过：阿狗小明

　　给作者一个奖励，鼓励他努力！

　　称赞

　　1人奖励