消息通知是联接系统和用户的桥梁，但是对于不同系统来说，怎么设计消息组件，促使用户与系统的沟通呢？对于平台中的用户与用户之间的沟通，我们又该采用什么互动形式呢？让我们一上去看一看不同的消息组件有什么，希望能帮助我们作出更好地B端设计。
消息通知在我们设计的过程当中十分重要，由于它作为系统与用户之间沟通的桥梁，就能帮助我们提示用户：“目前的操作状态、系统的公告、用户之间的互动内容”，而不同的消息内容，我们须要使用不同的消息通知组件来进行反馈，例如用户与用户之间的互动应当采取哪些互动形式？那我们就来谈谈消息通知组件的具体使用。
一、消息通知的定义丨具体有什么组件是消息通知
我查阅了各大设计系统[1]，发觉它们对于消息通知的定义都称作“反馈”，即信息反馈给用户的方式。而在其反馈的组件当中，会包含有：全局提示（Message）、通知提醒框（Modal）、气泡确认框（Popcomfirm）、对话框（Modal）、抽屉（Drawer）、进度条（Progress）、结果页（Result）、加载中（Spin）、骨架屏（Skeleton）但因为组件太多，我们把系统当中用到最多的消息通知部份单独掏出来剖析，剩余部份则置于最后去做解析。
对于反馈的内容来说，系统当中会存在正面、负面、普通三种不同的反馈情绪，例如你的帐号早已过期，对于系统来说他都会提供一个负面的消息通知组件，因而我们会对消息通知的类型进行一个简单的分类：
其实你们一定要记住，关于正向和负向的类型如何打开qq消息提醒框，它并不是绝对的，只是大多数情况下它的情绪与这个相关。
[1]查阅的设计系统包含：Element、Arco、Ant、Lightning…
二、消息通知的设计丨关于消息通知到底有什么
为了让所有朋友才能快速直接的了解消息通知的设计方式，我们尝试去“测评”，将目前的所有消息通知组件，之后根据：「操作干扰度、反馈消息的强弱、出现位置」三个维度来对消息通知进行分类，因而得出消息通知设计当中，它们的差异到底在哪？
信息展示量：
信息展示量表示组件才能承载多少信息内容。由于不同的组件它们的使用环境本身并不相同，我们可以通过原子[2]的界定大致归纳为：图标、文本、链接、按钮、容器差异
操作干扰度：
操作干扰度主要是对用户当中操作会不会形成相应干扰，例如一个全局提示和一个对话框，它们对于用户的影响程度是完全不一样的，因而会使用干扰度进行判别。
其实操作干扰度这个维渡过于主观，我们又将其细分为：持续时间、是否阻断、信息来源三个方面持续时间：用于表示这个组件在页面当中到底须要逗留多久时间，这样就能帮助我们判定其干扰程度。是否阻断：页面当中是否会出现蒙层用于阻断用户注意力。这也是判定干扰程度的重要指标。信息来源：这条内容主要来自那里，分为系统、用户两种来源形式。
出现位置：
这个组件到底会在哪一个地方出现，主要考虑它们的呼出形式，以及对应呈现内容，才能帮助我们快速理解。
[2]原子设计理论：原理剖析丨聊一聊原子设计，对页面导致的影响
1.全局提示丨Message
全局提示在用户执行操作时，不会中断当前用户操作的前提下，通知提示一条简略的消息。它在整个B端系统当中使用的频度十分的高，例如：我们在填写一个表单之后，才会收到全局提示；更改完一个信息之后，会收到一个全局提示。
而它在使用过程当中会有以下几个特征：
信息展示量：
全局提示只会展示：图标、容器、提示文字，相对来说它展示的内容较少，是一个特别简单的组件类型。
在实际工作当中，由于它内容量少，更多提示用户的便是正确的操作，例如已添加成功、编辑成功、保存成功等正向情绪。
操作干扰度：
关于干扰程度，我们刚刚提到一共会有三个判别根据，为此我就从这三个方面来去判定具体提示的干扰程度。
出现位置：
全局提示由于其内容较少（图标+文字），因而好多时侯须要出现在较为醒目的位置。我们在使用全局提示的时侯，基本上就会出现在页面底部居中的位置，一般距离底部的距离为40-60px。这个位置大机率是底部导航与页面内容的交汇处，不会影响用户的使用。
注意事项：
关于注意事项，虽然就是我们在实际工作当中，还须要去考虑的一些小知识点，我们将其汇总到此：
（1）全局提示一共会有五种款式类型，分为是：手册提示（Info）、普通提示（Normal）、成功提示（Success）、警示提示（Warning）、失败提示（Error）。
这时侯，认真的朋友可能会问：“老师，你刚刚讲了全局提示不是抒发正面的结果吗？如何都会出现警告、失败等信息呢？虽然这个缘由主要是“失败也要分好多种，如同我们的失败一样/窃喜”比如：“在一些小的操作时，你确实不能提供对应的功能，就可以展示警告信息，如右图”
（2）全局提示“一般”不会存在关掉入口，由于它可以手动消失，不提供给用户关掉入口就会让他晓得，这个通知本身都会手动消失。所以好多情况下可以忽视关掉入口这个选择。
（3）关于它的逗留时间，我们可以在设计系统当中的API里进行自定义，一般3s–5s即可。在去做组件时，一定要去看组件的对应开发文档，了解这个组件到底支持什么自定义功能（拒绝被开发误导）
（4）全局提示在短时间内，可以提高多次，多次提示时，根据先后次序从上往下进行排列
2.警告提示丨Alert
警告提示常驻于页面中，用于表示持续性的提示信息。多用于危险、警告、紧急等负面情绪当中。在实际工作当中，由于它的特殊性，通常会用在系统、全局性的危险通知上。例如你的订阅时间已超时、账号团队正式解散等通知上。
信息展示量：
这儿警告提示会比全局提示展示的信息更多，它主要包含：图标、提示文字、辅助文字、按钮、关闭入口
操作干扰度：
警告提示的常用场景：多用于警告、危险等情况，须要提醒用户，导致她们的注意。诸如提示欠费、需要冲值
出现位置：
由于其须要常驻，所以一般在设计时侯，我们会将它置于模块与模块之间，进行展示。这样既不会影响到其他内容呈现，同时自己又能常驻。
注意事项：
3.通知提醒框丨Notification
通知提醒框在页面当中，主要是以互动的消息为主，全局展示通知提醒，将信息及时有效的传达给用户。在实际的工作当中，通知提醒框主要拿来提示互动等有价值的信息。
信息展示量：
这儿通知提示框主要包含：标题、辅助文字、按钮、关闭入口
操作干扰度：
出现位置：
在整个通知提醒框的使用过程中，由于它本身就是与用户之间的互动所形成的，而这些活动就好似在桌面端当中你收到的消息，我们会将其归纳到右上角的位置去做呈现。这样既不会太影响用户，同时也就能保证消息通知的及时性。
4.气泡确认框丨Popconfirm
气泡确认框是我们在工作当中使用频度相对较低的组件。它还能通过组件当中的卡片，完成与用户的快捷对话，并且因为在实际的场景当中，对话确认是须要强提示的方法，因而总觉得气泡确认框在它的使用上，有着些许矛盾。气泡卡片轻量、不易干扰用户，并且对话框要求阻断意味更强。
信息展示量：
首先我们从信息展示量来说，气泡确认框主要由触发器、气泡卡片、图标、文本、按钮操作，五部份组成。
在设计时须要愈发注意，气泡确认框本身不能否过分复杂，否则在一个气泡卡片当中，就变得愈发拥挤。假如信息过多，就考虑使用对话框来进行呈现与优化
操作干扰度
5.对话框丨Modal
对话框在整个系统当中特别重要，由于你会发觉在整个系统当中或多或少就会有它的身影，例如一个常见的数据录入表单，它的整体觉得和对话框较为类似；又或则是一个穿梭框，你会发觉也有异曲同工之处，因而我们先来看一下对话框到底是哪些？
对话框主要用于信息确认与信息录入，使用对话框会中断用户当前的任务流程，同时会对用户导致些许干扰，因而在使用的时侯，我们都须要特别慎重。
操作干扰度：
对话框的类型：
在整个对话框的展示当中，你会发觉它主要分为三部份，分别是Header标题位、Content内容部份、Footer顶部操作位，而在这三个部份所组成的内容当中。
其中因为它的用途不同，我们可以将其简单的分类为：确认对话框、消息提示对话框、功能业务对话框
确认对话框：展示对内容信息的二次确认，这样才能降低用户的误操作，增加操作风险。主要差异是内容部份以操作过程会出现的问题为主，来进行展示。其本质就是一个二次确认的过程，须要用户去作出判定，它要比气泡确认框更加重要，阻断性也更强。
消息提示对话框：展示对应的状态提示，例如当你删掉掉一个知识库之后，这些重要操作时，我可以通过消息提示对话框来将成功或则失败的消息展示给你，而且也就能让用户晓得问题到底出现在那里。其本质就是一个消息状态通知，只是更为重要。
功能业务对话框：将Content内容部份进行优化，用于展示更多复杂信息，例如各类复杂信息录入（输入框、单选、多选…）以及各类信息呈现，它还能通过功能业务对话框，去完成好多业务要求。
同时使用弹窗[3]的方式，才能帮助我们不脱离当前业务的前提下完成更多操作。其实在实际工作当中你会发觉，它还能承载的内容是十分多的，例如步骤条、Tab标签、各种选择录入，因而我觉得这种类型的对话框本质上就是一个容器，可以去承载好多内容。更多注意事项就是弹窗部份的内容，例如规格长度到底是多少、高度为多少，是否有蒙层等等。
三、几个组件的差别对比丨了解组件的差异
为了让朋友们就能快速了解这几个组件之间的差异，我们尝试把刚刚提及的那么多组件进行相应的对比，剖析一下其中差别点。
全局提示与警告提示
首先这两个组件在设计款式上是十分相像的，而且本身使用环境差别不大，因而很容易把这两个组件进行混淆。虽然我们可以从多个方面去进行对比分辨：
全局提示不建议使用关掉入口全局提示优先级更低，主要提示非紧急通知；警告提示则提示更多紧急须要用户立刻操作的通知全局提示会逗留3-5s后手动消失；警告提示则须要操作后消失气泡确认框与对话框之间的差异
这两个组件之间，同为用户二次确认的组件类型，但在实际的业务当中有着重要级之间的关系。
气泡确认框相对适宜阻断流程意味不强的情况，它更为轻量。对话框反之好多时侯气泡确认框会成为对话框的二次确认形式，这样才能防止出现弹窗套弹窗的难堪局面四、消息通知的优化丨了解不仅传统组件之外的通知形式
我们在去理解消息通知的时侯，常常不能否只去看待消息通知本身的组件方式，最终的目的一定是让用户才能更快速、直观的了解到他所关心的内容，因而在设计上，我们可以进行对应的优化。
声音提示
由于我们大多数B端产品都是采取网页端的方式进行内容呈现，因而常常会忽视通知提示当中的声音部份。其实我们在网页端，并且也就能通过播放声音+页签的信息通知（你有一个新消息，注意查看），让用户晓得他有重要信息须要处理，这样也能间接达到目的。
多端联动
大多数B端产品，就会碰到系统当中主要都是聚焦于桌面端，联通端的体验几乎为零。由于好多产品目前的联通端都是使用小程序解决，那通知就显得愈发困难，这时侯虽然可以尝试用一些通用形式打通设备限制。例如我们可以尝试发送陌陌订阅号推送系统通知，这样既才能保证用户日常的使用习惯，同时进行多设备间的联动。
再举一个反例如何打开qq消息提醒框，例如在月历模块，虽然就可以通过月历本身的CalDAV账户，来实现多设备间的月历联动，这样就才能保证桌面端不是一个孤岛~
通知分类
通知本身就是高触发的一个场景，就类似于手机的邮件一样，会存在大量的冗余信息。为此我们再去设计通知的时侯，考虑到不同的通知类型一定要采取不同的处理办法。
而想要在工作当中做好这件事，必须先将系统当中所有的通知信息进行整理，因而将其进行分类，分类规则大体遵守：用户之间互动＞用户系统互动＞系统系统互动。
因而作为B端设计师，组件之间的差别一定要注重上去。
五、结尾
消息通知如同是我们用户与系统、用户与用户之间的一个桥梁，而各类消息通知才能让我们用户晓得操作是否正确。也正是好多设计系统讲的原则：操作以后有反馈，你的反馈内容是哪些，都会直接决定我是否勇于去操作。
专栏画家
