在vue项目中，经常会遇到需要刷新当前页面的需求。

因为vue-router判断如果路由没有变化，是不会刷新页面获取数据的。



方式1：go(0)和reload()

通过location.reload()或是this.$router.go(0)两种强制刷新方式，相当于按F5，会出现瞬间白屏，体验差，不推荐。



方式2：定义一个空白路由页面，路由跳转到该空白页后立马跳回当前页，实现路由刷新。

在router路由表中定义一个空白路由，



 // 强制刷新当前页所用的中间跳转页

   {

        path: '/redirect/:path*',

        component: () => import('@/views/redirect/index')

  }



写一个空白路由组件



//redirect/index

<script>

export default {

  created() {

    const { params, query } = this.$route

    const { path } = params

    this.$router.replace({ path: '/' + path, query })

  },

  render: function(h) {

    return h() // avoid warning message

  }

}

</script>





在需要刷新的页面使用



refresh() {

      // 刷新当前路由

      const { fullPath } = this.$route

      this.$router.replace({

        path: '/redirect' + fullPath

      })

    }



这种方式，基本上能够应付绝大多数情况，推荐使用。

但是，有时候，有一些极端情况下，这种刷新不起作用，而又不想用第一种那种毛子般的简单粗暴的方式的话，下面的方式可以选择使用。



方式3：provede/inject 方式

vue官方文档说了，这个依赖注入方式是给插件开发使用的，普通应用中不推荐使用。

但是，效果却很好。

app.vue修改



<template>

  <div id="app">

    <router-view v-if="isRouterAlive" />

  </div>

</template>

<script>

export default {

  name: 'App',

  provide() {

    return {

      reload: this.reload

    }

  },

  data() {

    return {

      isRouterAlive: true

    }

  },

  methods: {

    reload() {

      this.isRouterAlive = false

      this.$nextTick(function(){

        this.isRouterAlive = true

      })

    }

  }

}

</script>





使用的时候：

demo.vue



<template>

  <div class="container">

  xxx

  </div>

</template>



<script>

export default {

  inject: ['reload], // 依赖注入

  name: 'Demo',

  computed: {

    message() {

      return '抱歉，您访问的页面地址有误或者该页面不存在...'

    }

  },

  methods: {

  handleReload() {

  this.reload() // 直接在需要刷新的方法中调用这个reload()

}

  }

}

</script>



<style lang="scss" scoped>

</style>



原理就是通过依赖注入的方式，在顶部app通过v-if的显示隐藏来强制切换显示，以此来让vue重新渲染整个页面，app中通过provide方式定义的reload方法，在它的后代组件中，无论嵌套多深，都能够触发调用这个方法。具体说明查看官方文档。

转自：站酷-呜呜吉良斯基

产品：这次需求很简单，对比上期只有字段和操作项的差异，把上次的稿子直接复制一下应该不用很多时间吧？

交互：上次你是不是做过高级筛选组合？我这期需求要用到，你把那部分稿子发给我用用吧。

研发：这个组件我在其他模块里看到过已有样式，这次为什么用不一样的？不然又要重复开发呀，能不能统一一下。

视觉：同一个按钮在不同的模块颜色不一样诶，这次要和哪个模块一致啊？

……

通过以上对话不难看出，最常出现在需求沟通与研发过程中，由于缺少统一的规范和标准化体系，导致实施环节各方沟通成本高，造成设计成果与实现有一定差距，影响用户体验；通用组件和业务组件混用，导致设计模式和代码复用率低。尤其是当业务发展到一定体量时，对于复杂产品的大量重复且类似的需求场景，如果没有一种的工具和规范来协同工作，将大大影响团队的生产及沟通效率。

问题

• 认知：产品、研发、设计师对于同一需求都有自己理解的解决方案，缺少统一规范的约束，难以达成共识。
• 效率：设计效率低，交互原型的维护成本及上下游团队的沟通成本高，易造成不专业的印象。
• 品质：认知和效率的局限性，最终导致实施落地的产品质量和用户体验难以得到保障。

解决

大家应该都知道乐高（LEGO）积木，它是一种可以互相嵌套组合的塑料积木，形状共有 1300 多种，每种形状都有 12 种不同的颜色，可以拼插出多种造型。其实组件库的工作方式就很像乐高，通过小元件的互相嵌套来产生多种组件或模块，多种组件模块结合生成页面结构。我们先来梳理一个概念，组件库是什么？

组件库是设计系统的一部分，是在我们常规界面设计过程中可以直接用来制作交互图例和搭建页面的组件集合，它可以作为单个组件独立存在，也可以通过多个组件组合而成的结构或模式来解决类似场景的设计问题。组件库是在约束条件下去构建解决方案的过程，所以组件的使用也需遵循一定的规范，按照一套标准化的体系复用于多个业务场景。

一个有效的组件库，可以帮助设计师和研发提高工作效率，提升设计专业度的同时让产品本身的体验更加一致、可学，品牌感更强，它所具备的基本特征一定是通用的、灵活的、复用的。

• 通用性：意味着足够基础和常见且不带业务属性，参与设计环节的每个人都应该知道这个组件的功能及目的，同时具备一定扩展性。
• 灵活性：要求元件的组合需灵活，可以在不同场景下通过互相组合来快速搭建交互框架原型图，并根据不同页面结构的演变来适应新的业务需求。
• 复用性：指的是适用于多个业务或产品，在设计过程和研发过程中都可以高频复用。

那么用组件库这种标准化体系来完成设计方案时，到底能带来怎样的价值？

组件库的价值

保证产品体验的一致性：对于一个含有多业务系统的大型复杂产品，每个独立的业务系统虽然在功能上有一定区别，但整体的用户体验需要满足基本的一致性。比如，当我使用同一个产品中的业务系统 A 和业务系统 B 时，我能通过类似的页面结构、组件及样式的一致性、操作反馈乃至提示文案结构的一致性，来感知到我使用的A、B业务系统隶属于同一个产品。

提升设计师的效率：在需求量巨大且需求来自不同的业务线时，需要逐一绘制页面及组件，造成大量重复劳动，并且在评审及需求沟通环节还可能存在不断地细节调优。所以对于设计师而言，组件的高频复用能大大提升设计效率，使设计师更多的将精力聚焦于理解和解决用户的实际问题。

提升产研团队的效率：通用场景及普通需求直接按规范进行设计和研发，减少上下游对同一页面及组件使用方式的不同理解而产生的多余沟通成本。

利于沉淀设计规范：组件本身的设计和使用方式就可以直接作为交互和视觉规范的一部分，按照统一的设计规范来确定需要使用的主题色、组件样式、组合方式及页面结构，可以快速搭建出一个或多个产品的交互框架。

构建「FishDesign」企业级UI组件库

那么如何构建一个企业级 UI 组件库？

我将用前段时间参与的「FishDesign企业级UI组件库」项目为例，通过在网易七鱼产品中的应用，来介绍一个企业级 UI 组件库的设计原则，内容构成包含哪些类型和元素，每种组件类型在分类和设计过程中是如何考量的。本文侧重讲述构建一个组件库所涵盖的内容，而不是某组件类别本身的设计方法。

顾名思义，「企业级」意味着 FishDesign 所服务的业务都是具备一定体量的，可能是服务一个包含了多个独立子业务系统的大型复杂产品，比如网易七鱼；也可能是同时服务多款产品，比如网易七鱼和网易定位等。

组件库是帮助设计者及前端工程师快速构建业务系统的工具，除了最重要的组件内容，还需要设计原则、配色方案及布局规范来指导具体业务产品的设计有效落地。

1. 设计原则

基于 FishDesign 目前主要是帮助搭建 B 端企业级产品，而 B 端业务的产品目的决定了它所才采取的设计模式，所以我们将用以下四点作为塑造组件库的设计原则：

• 简洁：如无必要，勿增实体，慎重筛选客户当前需要信息内容。
• 直接：提供用户操作后的直接反馈，保证用户的操作结果符合预期。
• 优雅：设计方案追求优雅，给使用者有质感的操作感受。
• 适应性：设计方案需提供可扩展能力及适应性，以适应不同模式的企业使用。

2. 颜色

产品会根据自身的产品目标和受众群体去选定产品的配色方案。前文提到，一个有效的组件库需满足通用性、灵活性、复用性，像配色方案就应该能被灵活自定义来应对多样化的诉求。以网易七鱼为例（下文均以网易七鱼为例），设置了 1 种主色，4 种辅助色和 6 种中性色来搭建一致的外观感受。

• 主色：选择蓝色系来传达智能服务、信任可靠、技术创新的品牌形象。
• 辅助色：除了品牌主色调蓝色，在辅助色中也存在一样的蓝色，那是因为蓝色是相对泛用性较广的色系，用于产品中的主操作按钮、文字按钮或 icon 等。红色唤起注意并昭示危险，所以一般用于谨慎操作及错误提示。黄色则常用于警示信息，提示用户操作可能带来的风险及后果。绿色能传递安全和健康的情绪感受，用于正向反馈提示或成功操作的引导。
• 中性色：一般采取黑灰色调来展示产品的文本信息、背景和边框色，用来表现层次结构。

3. 布局规范

为处理多业务中网页设计区域内的信息收纳问题，我们用规则的网格阵列来指导和规范版面布局以及信息分布，即栅格系统和页面布局。FishDesign 在 12 栅格系统的基础上，将整个设计区域按照 24 等分的原则进行划分，来增加页面的相似度，提升用户体验。

我们通过基本的配色及布局规范解决了产品风格及信息区块框架的设计，那组件库中重要的组件部分，是如何作用于产品搭建的？Brad Frost 提出的「原子化设计理论」可以帮助我们更好的理解，原子化设计的灵感来自于现实世界当中的分子结构，UI 中颗粒度最小的元素，即「原子」，组成了颗粒度较大的元件，即「分子」；而诸多分子又组成了更加复杂的组件与模块，即「有机体」。

组件库构建之初无法一应俱全，是需要后续不断的维护与迭代的。如何在最初海量组件中圈定适合的组件范围呢？最合适的切入点就是从身边的业务场景出发，从最基本、最简单、最小的元素入手。

4. 组件分类

我们根据当下已有的业务场景和对往后一段时期的业务发展方向进行规划，将组件库的组件类型分为通用组件和业务组件。一般业务组件库是不对外的（毕竟使用场景特殊也有限，放出来参考意义不大），所以在 FishDesign 官网只能看到通用组件部分。

• 通用组件：指适用范围广、复用频次高，可复用于多个业务且不包含业务逻辑。比如导航栏、按钮、toast、弹窗等。
• 业务组件：这类组件对比通用组件而言，最大的特点就是包含了较多业务属性，跟产品功能有较强的关联性，所以影响到适用范围可能仅限于 1~2 个业务系统或特殊场景，且复用频次不高。比如网易七鱼的在线和呼叫系统中的咨询分类组件。

一个大型复杂的业务产品通常有不止一位设计师或前端工程师参与设计，需要在多种处理方式中选择合适的设计模式来解决不同的场景问题，这要求根据组件属性的差异，需对通用组件做细分，那么如何确定通用组件中的子分类呢？

• 竞品学习与研究，穷举该部分产品类型中的组件类型。
• 遍历自己所负责产品内已有的业务场景，提取并整理业务场景中所用到的组件。
• 将整理好的两部分组件进行筛选去重，保留高频通用的部分。比如同样是下拉筛选组件，由于缺少统一规范和组件，可能导致的后果就是在同一产品不同业务系统的相同场景下，使用的组件从样式到交互方式都不一致。我们要做的就是对这部分在类似业务场景中使用了多种表达形式的组件做合并去重，然后通过设计组内审来圈定最后通用组件的范围。
• 基于组件的属性和使用场景，对圈定的组件范围进行归类。

由上述步骤，我们将通用组件继续细分为五个子类别：基础组件、导航、数据录入、数据展示、操作反馈。

• 基础组件：即按钮、图标等，相较于其他组件的使用场景更通用，或其他组件在实现时依赖了这些组件来实现的组件类别。
• 导航：即导航菜单、标签、面包屑等，可以帮助用户产品系统内快速找到所在页面层级或位置的组件类别。
• 数据录入：即输入框、选择器、表单等，支持用户将数据信息录入到系统的组件类别。
• 数据展示：即图表、表格、气泡卡片等，将录入到系统的数据信息多样化展示出来的组件类别。
• 操作反馈：即对话框、警告提示（Alert）、全局提示（Toast）等，在用户操作前后，使系统状态得以合理反馈的组件类别。

用组件库设计「网易七鱼」示例

以网易七鱼为例，看下有组件库参与搭建的设计示例，以下页面中所用组件均出自 FishDesign 组件库。

「导航组件」使用示例：

「表格组件」使用示例：

「弹窗组件」使用示例：

「步骤组件」使用示例：

总结

组件库最大的价值在于提升整个团队的产研效率，使设计质量得以保障的同时，提升产品整体的用户体验。

我们对构建企业级 UI 组件库的步骤及要素做个简单回顾：

• 首先，明确组件库所需解决的问题及存在的价值，这决定组件库的体量和服务范围是什么，以及构建的时机是否合适。
• 其次，通过竞品分析并结合身边最熟悉或深耕的业务入手，通过产品目的来选择设计模式，从最小元素开始逐步整理，包括产品配色方案和栅格系统等布局规范。
• 第三，需要对组件库的重要组成部分「组件」，进行圈定及合理分类。这里需要注意的是，组件范围的圈定，尤其在组件库搭建的初级阶段并不是越多越好，而是需要有效的覆盖那些经过规划的业务场景即可。
• 最后，组件库并不是构建完就结束了，是需要在后续项目中逐步维护与更新的长期积累过程。

任何组件库的构建都离不开一个优秀的团队在整个设计过程中的协同，十分感谢参与的设计师与前端工程师们。上文仅是个人参与过程中的一些经验总结，还不够全面，同时篇幅有限，关于组件的具体设计考量无法一次详尽，欢迎一起讨论组件库及标准化设计体系相关的更多内容。

文章来源：优设

说到渲染引擎就不得不提到延迟渲染，基本上一个引擎如果没有实现延迟渲染就不能说是一个好的渲染引擎，不过可惜的是three.js并没有实现延迟渲染（ps：呼吁作者赶紧实现mrt吧）。由于没有mrt和延迟渲染，本来不打算写后处理的，但是即使没有，我们也希望能实现一些炫酷的效果，那就在现在的基础上对three.js进行简单的改造来实现一套高性能的后处理渲染器吧。

要实现后处理我们首先要考虑需求，是否要兼顾移动端，是否要兼顾大屏（4k），是否要支持webgl1，是否要在各种显卡中都有一个还算不错的性能。目前我主要考虑的是：性能要好，可以兼顾大屏，不打算完美支持webgl1，尽量多使用webgl2的特性。后面所有的性能测试为都以N卡作为性能测试指标，先不管AMD卡（AMD抗锯齿的处理性能会高些的，但是动态处理性能会偏低，这里有很多细节问题）

好了，我们关心的是好的性能，尽量多使用webgl2的特性，尽量能兼顾大屏（这里主要是要注意显存问题），现在开始准备我们的渲染器吧

要完成一个后处理渲染器，我们首先要考虑抗锯齿，常用的有超采样技术和多重采样技术，具体可以看这个介绍 添加链接描述

three.js已经实现了SSAA，SMAA，TAA这三种超采样技术，效果都还不错，具体实现three.js都有例子，就不详细说明了。SSAA抗锯齿效果是最好的，但是性能最差，现实情况下根本无法使用。SMAA性能会好一些，2000个物体差不多掉15帧吧（SMAA比FXAA计算稍微复杂一些，SMAA研究的少，不知道能不能解决line的锯齿问题，如果知道的欢迎留言）。SMAA效果基本可以接受，但是2000个物体掉的帧率还是有点多，这个也不是我们首选的。TAA效果很好，如果场景里面很少动的东西，它是个不错的选择，如果有运动的物体或者动画等等，基本上抗锯齿就没效果了，理论上应该可以实现动态的TAA，但是用目前的技术很难实现。所以TAA先不考虑加入我们的后处理渲染器（真实使用场景下一般都有动画或者贴图流动效果，所以TAA无法使用）。

SMAA:效果不错，开销15帧左右（2000物体）

SSAA：效果最好，开销太大 （2000物体基本已经没有了帧率）





TAA：效果基本和SSAA差不多，但目前只有静止的时候才有效果



再来看看多重采样MSAA，这个特性必须使用webgl2，是webgl提供的方式，和浏览器自身的抗锯齿原理一样，效果不错，和正常渲染的结果没有区别，性能开销也不是太大，前提是我们不要使用stencilbuffer。而且three.js MSAA这块的释放有些小问题，详细可以在deallocateRenderTarget这个接口中进行修改。现在我们可以把MSAA作为主要的抗锯齿技术。MSAA虽然性能开销不大，但是唯一的不足是比较吃显存，如果是大屏，而且显卡不好的话还是容易崩，无法开启。因此我们还要继续选择一个开销小不吃显存的抗锯齿（当然也可以考虑SMAA，目前由于帧率开销较大（2000物体掉了15帧左右），我们不考虑加入SMAA）

MSAA：基本没有帧率开销，效果不错，但是耗费显存（2000物体）



最后的备选方案就是FXAA了，FXAA可以参考这个文章：添加链接描述讲的很详细，FXAA性能开销很小，但是效果很一般，特别是细线的锯齿没法解决，转动摄影机边缘的闪动效果也无法解决，而且还有一个问题是由于FXAA就是靠边缘模糊抗锯齿，所以必然导致画面会略有模糊。但是它最大的好处是开销很小而且不耗费显存，并且集成到后处理渲染器中最简单。但是当显存不足显卡太差的时候它还是个不错的选择。因此需要加入FXAA。

FXAA：效果一般，开销很小，无法解决线的锯齿问题，带来模糊（2000物体）

我们看了下各大引擎，基本每个引擎都实现了FXAA，还有很多引擎实现了FXAA3，FXAA3效果会好一些，但是依然无法解决线的问题。cesium的抗锯齿就是完全采用FXAA3，效果还可以接受，所以目前我们把cesium的fxaa3_11拿过来用，最终引擎选择使用MSAA加FXAA3_11的抗锯齿策略（当然SMAA和TAA也可以选择）。

HTML中如何引入图标



在头部引用在HTML中里面引用一个东西，。在头部引用<script defer src="https://use.fontawesome.com/releases/v5.0.8/js/all.js"&gt;&lt;/script&gt;

然后在网上搜索font awesome。可以进那个官方（外国网站比较卡)。以下为点进那个中文网–字体图标



点击右上角图标库





3随便点一个进去





4复制<i class="fa fa-address-book-o" aria-hidden="true"></i>

引入你的代码中<span><i class="fa fa-address-book-o" aria-hidden="true"></i>></span>



<div><i class="fa fa-address-book-o" aria-hidden="true"></i>></div>

1

在div或span里引用，可以实现块状元素和行内元素的功能，不用管i标签，改变图标大小用font-size，调上下高度line-height，左右位置text-align。

部分图标可以引用不了，大致样式

3.完美是最无情的禁锢

是什么

ES5提供的数组的方法。

reduce() 方法接收一个函数作为回调函数（accumulator），数组中的每个值（从左到右）开始缩减（其实就是从左往右开始对每个数执行回调函数），最终为一个值。



PS: 回调函数的返回结果类型和传入的初始值相同



语法以及参数

arr.reduce(  callback(accumulator, currentValue,index ,array ) ,initialValue )

1

initialValue 可选

如果有的话则作为，第一次调用 callback函数时的第一个参数的值。

如果没有提供初始值，callback则使用数组的第一个元素，作为第一次调用的初始值。

在没有初始值的空数组上调用 reduce 将报错。



accumulator

默认传入上一次调用回调函数的的返回值。

初始值： initialValue存在的话，则是initialValue 若没有则是数组的第一个元素



currentValue

数组中正在处理的元素。



index 可选

数组中正在处理的当前元素的索引。 如果提供了initialValue，则起始索引号为0，否则从索引1起始。



array可选

调用reduce()的数组



一个小小的例子

例1 无initialValue

var  arr = [1, 2, 3, 4, 5];

sum = arr.reduce(function(result, cur, index, arr) {

    console.log(result, cur, index,arr);

    return result+ cur;

})

console.log(sum) // 最后的结果是15



result cur index arr

第1次 1 2 1 [1, 2, 3, 4, 5]

第2次 3 3 2 [1, 2, 3, 4, 5]

第3次 6 4 3 [1, 2, 3, 4, 5]

第4次 10 5 4 [1, 2, 3, 4, 5]

例2 有initialValue 传入10

var  arr = [1, 2, 3, 4, 5];

sum = arr.reduce(function(result, cur, index, arr) {

    console.log(result, cur, index,arr);

    return result+ cur;

},10)

console.log(sum) // 最后的结果是25



result cur index arr

第1次 10 1 0 [1, 2, 3, 4, 5]

第2次 11 2 1 [1, 2, 3, 4, 5]

第3次 13 3 2 [1, 2, 3, 4, 5]

第4次 16 4 3 [1, 2, 3, 4, 5]

第5次 20 5 4 [1, 2, 3, 4, 5]

回调函数的返回值

上面的例子返回的都是一个整型数字，如果希望返回其他类型的数据呢？



这个就跟accumulator的初始值有关系了。

下面的例子我们传入的是一个object {sum: 0}



var items = [0,1,2,3,4];

var reducer = function add(sumT, item) {

  console.log(sumT)

  sumT.sum = sumT.sum + item;

  return sumT;

};

var total = items.reduce(reducer, {sum: 0});

console.log(total); // {sum:1130}



运行结果



 {sum: 0}

 {sum: 1}

 {sum: 3}

 {sum: 6}

 {sum: 10}



reduce()的应用

1. 数组扁平化
   
   递归+reduce
   
   
   
   let arr = [1, 2, '3js', [4, 5, [6], [7, 8, [9, 10, 11], null, 'abc'], {age: 12}, [13, 14]], '[]'];
   
   
   
   function flatten(arr) {
   
     if(Array.isArray(arr)) {
   
       return arr.reduce((prev, cur) => {
   
          // 如果遍历的当前项是数组，递归调用flatten
   
         return Array.isArray(cur) ? prev.concat(flatten(cur)) : prev.concat(cur)
   
       }, [])
   
     } else {
   
       throw new Error(' 当前参数不是数组')
   
     }
   
   }
   
   console.log(flatten(arr));
   
   
   
   PS:这里的throw new Error只是用来判断一开始的arr，这是因为在递归只传入数组。
   
   
   

本文作者结合实际案例，跟大家分享一下在RARRA模型下，如何做用户增长？

从AARRR到RARRA的运营思路转变

众所周知，AARRR经典的增长黑客体系，也称之为「海盗法则」，分别是获取、激活、留存、变现以及推荐。提出这个模型的 Dave McClure 认为，所有创新型、成长型的企业都应该按照这样的模型来做增长。

AARRR专注于获客（Acquisition），作为一个2007年提出的概念， AARRR模型可能已经不再适用互联网运营这个瞬息万变的场景。原因有二：

（1）获客成本增加

市场竞争激烈，用户获客成本已经不再便宜，一组数据显示：阿里线上获客的成本翻了 6 倍， 京东的获客成本翻了 1.5 倍，趣头条用户获取成本增加了 8 倍，百度的流量获取成本增长了 41%。在当前的情况下，以拉新获客为中心的增长模式意味着要比十年前这个模型提出时平均增加5倍以上的成本。

（2）流失率高

一组数据显示，现在平均每个App在安装后的情况：前3天内将流失掉77％的DAU。在30天内，它将流失90％的DAU。而到了90天，流失率跃升到95％以上。不管你是否心存怀疑，这就是目前众多创业公司所面对的现实窘境，它创造了Brian Balfour所说的“无意义成长之轮”。

因为以上两个原因，现在黑客增长的真正关键在于用户留存，而不是获客。所以我们需要一个更好的模型——就是RARRA模型。

AARRR与RARRA的区别

RARRA模型是托马斯·佩蒂特Thomas Petit和贾博·帕普Gabor Papp对于海盗指标-AARRR模型的优化，RARRA模型突出了用户留存的重要性。

简单的说，AARRR模型的核心在于获客，而在RARRA的模型下，专注用户的留存。

RARRA模型下，如何做用户增长？（成功案例分享）

分享一个我们前不久自己做的RARRA模型下用户增长的成功案例：

我们做的是一个在线教育平台，课程的分类包括：

• 以拉新为目的的新用户免费体验课（0元）；
• 以转化为目的的低价专题课（50元以内）；
• 以盈利为目的的短期班课（999元以内）和系统课（1000-4000元）。

这样的课程显然是以拉新-留存-转化个流程进行的设计，也是现在很多在线教育平台通用的课程模式设计，其实本质上和其他行业的平台也是类似。

在RARRA的模型下，数据驱动更重要。因为如果专注获客，可以在渠道选择等方面凭借经验和主观判断来选择，但是专注留存，就必须用数据分析找出每个留存环节的差异因素，进而制定最的方案大幅度提升留存率。在在线教育平台的运营中，因为从推广到课程设计、课程质量、售前售后服务等，包含大量影响营收的因素，因此数据分析方法也相对复杂。

数据分析的第一步，也是关键点在于：构建指标体系。

对于一个平台来说，一般的数据指标都非常多，但必须确定唯一关键指标（OMTM），也是大家常说的北极星指标，作为驱动的方向。

回归商业本质，一切商业模式的终极目标当然是收入，但是收入这个指标并非北极星指标，而是决定北极星指标的上级因素。如下图所示，平台收入=有效听课用户数*客单价。因为课程的客单价有大致的市场标准，不会做太多变动。因此经过分析，我们认为直播课程运营的北极星指标是——有效听课用户数，也就是购买了课程并且有效听课的用户数量。

那么接下来，就要对北极星指标进行分解。

从指标拆解来看：

• 有效听课用户中的新用户数=外部流量导入*转化率；
• 有效听课用户中的老用户数=老用户数*续报率。

在最后分解的四个指标中，除了老用户数是直接由新用户转化率决定的之外，流量、转化率、续报率三个指标都是可以通过运营来提升和改善的。

但是由于时间和资源的限制，对于三个指标，运营策略上肯定会有侧重点和先后顺序。

一开始，我们采用的是AARRR模型，把重点放在提升流量和新用户转化率上。通过广告投放、拉新红包等大量引流，并在课程设计上做了很多设计促进新用户转化率。最后流量和转化率都提升了，但问题是，用户停留在0元免费课和低价转化课上，而续报高价课的有效用户很少，这样看似产品新增用户很多，热热闹闹，但整体的营收还是上不去。

团队分析后认为，AARRR模型可能并不适合我们。既然续课率出了问题，应该尝试采用RARRA模型，把运营重点放在留存上。

于是，数据组开始探索留存的问题点出现在哪里。

我们拉出不同维度用户数据进行对比，最后发现新用户和老用户的续课率差值竟高达53%。

也就是说，新用户进行初步低价课转化后，在从低价课到达正价课的留存续课阶段，是流失最严重的一块。

找到了最痛的点，问题其实已经解决了一半。

接下来，通过各种数据因素分析，我们判断出了影响新用户续课率的几个重点因素，分别是：用户来源、课前服务、课程质量。并且对每一个因素继续分解深挖。（标红为续课率效果最好）

• 在课程质量方面，三个细分数据指标综合可以衡量课程质量。
• 课前服务时间上，通过数据对比，我们发现课前两周进行服务的效果最好，续课率也最高。
• 用户来源上，短期班课的用户续课率远高于其他两个来源。

根据以上的数据分析，给出了运营策略指导为：

1. 教师和教研团队狠抓课程质量，改变以前主观评价模式。用出勤率、完课率和作业完成率三者综合考核教师KPI；
2. 助教团队的课程服务时间前置，从以前的课前一周和课后进行服务，改为课前两周开始进行用户服务；
3. 服务人群的重点转移到短期班课新用户上。

改进后的效果：

通过以上三个方向的运营策略调整，同样的团队，仅用了一个月的时间，就把新老用户续课率的差值从53%缩小到了9%！效果非常明显。同时平台整体收入也大幅增加，而运营成本却比以前大规模进行渠道投放大大节省了。

阶段性的成功，正是及时调整了用户增长模型，并采用系统的数据分析方法驱动用户增长。可以看出，数据驱动下，最终给出的运营策略非常简洁，但前面数据组背后付出的努力和精力是很难被看到的。这正是我们想要的结果，扎根稳且深入，但呈现的却是简洁明了的运营指令。

node系列之数据接口注册登陆接口的实现

1、使用express脚手架创建项目

2、了解项目的目录结构

3、准备数据库相关文件

4、编写注册接口

5、编写登陆接口

6、验证登陆实现

7、预告

1、使用express脚手架创建项目

// 安装脚手架，只需安装一次

npm i express-generator -g

// 创建express项目

express myapp --view=ejs

cd myapp

// 安装依赖

npm i 

// 安装需要使用的模块

// 数据库模块 用户唯一id模块 密码加密模块 token模块

npm i mongoose node-uuid bcryptjs jsonwebtoken -S



2、了解项目的目录结构

bin

www ------- 服务器启动

node_modules ------- 项目的依赖文件

public ------- 静态资源文件夹

images ------- 静态图片

javascripts ------- 静态的js文件

stylesheets ------- 静态的样式表文件

routes ------- 路由文件

index.js ------- 默认的路由

users.js ------- 用户相关的路由

views ------- 路由对应的页面

index.ejs ------- 默认的首页

error.ejs ------- 错误页面

app.js ------- 使用中间件，注册路由

package.json ------- 描述文件

3、准备数据库相关文件

大勋在node系列之数据库mongoose的封装中给大家介绍了如何封装mongoose，可以先行查看如何封装，封装的文件夹为sql，如果不想看的，可以直接通过网盘下载该文件夹



将该sql文件放置项目的跟目录下

• myapp
  
  - sql
  
  - collection
  
  users.js
  
  db.js
  
  index.js
  
  
  
  4、编写注册接口
  
  目标文件： myapp/routes/users.js
  
  
  
  实现思路：使用post提交数据的方式，先以手机号查询有没有该用户，如果有该用户，提示用户该账号已经注册过了；如果没有该用户，则可以完成注册，首先得将密码加密，加密完成后插入数据库
  
  
  
  代码实现：
  
  
  
  // 找到用户集合
  
  var User = require('./../sql/collection/users');
  
  // 找到数据库封装文件
  
  var sql = require('./../sql');
  
  // 状态码的封装
  
  var utils = require('./../utils')
  
  // 用户唯一标识的id
  
  var uuid = require('node-uuid');
  
  // 密码加密模块
  
  var bcrypt = require('bcryptjs');
  
  var salt = bcrypt.genSaltSync(10); // 加密级别
  
  
  
  // 实现注册接口 -- post提交方式
  
  router.post('/register', (req, res, next) => {
  
    // 1、先获取表单信息
  
    let { username, password, tel } = req.body;
  
    // 2、根据手机号查询 用户集合中是否有该用户，如果有，返回有该账户，如果没有注册继续
  
    sql.find(User, { tel }, { id: 0 }).then(data => {
  
      // 2.1 判断有没有该用户
  
      if (data.length === 0) {
  
        // 2.2 没有该用户----继续完成注册操作
  
        // 2.2.1 生成用户的id
  
        let userid = 'users' + uuid.v1();
  
        // 2.2.2 对密码加密
  
        password = bcrypt.hashSync(password, salt)
  
        // 2.2.3 插入数据库
  
        sql.insert(User, { userid, username, password, tel}).then(() => {
  
          res.send(utils.registersuccess)
  
        })
  
      } else {
  
        // 2.3 已有该用户
  
        res.send(utils.registered)
  
      }
  
    })
  
  })
  
  
  
  附 状态码封装模块 myapp/utils/index.js
  
  module.exports = {
  
    registered: {
  
      code: '10000',
  
      message: '该用户已注册，请直接登录' 
  
    },
  
    registersuccess: {
  
      code: '10101',
  
      message: '注册成功' 
  
    }
  
  }
  
  
  
  5、编写登陆接口
  
  目标文件 myapp/routes/users.js
  
  实现思路：根据手机号查询有没有该用户，如果没有，提示用户未注册，如果有该用户，使用bcryptjs模块验证密码的有效性，如果有效，生成token，返回给前端相应的token值。
  
  var jwt = require('jsonwebtoken');
  
  // 实现登陆功能
  
  router.post('/login', (req, res, next) => {
  
    // 1、获取表单信息
  
    let { tel, password } = req.body;
  
    // 2、依据手机号查询有没有该用户
  
    sql.find(User, { tel }, { _id: 0 }).then(data => {
  
      // 2.1 判断有么有该用户
  
      if (data.length === 0) {
  
        // 2.2 没有该用户
  
        res.send(utils.unregister)
  
      } else {
  
        // 2.3 有该用户，验证密码
  
        // 2.3.1 获取数据库中的密码
  
        let pwd = data[0].password;
  
        // 2.3.2 比较 输入的 密码和数据库中的密码
  
        var flag = bcrypt.compareSync(password, pwd) // 前为输入，后为数据库
  
        if (flag) {
  
          // 2.3.3 密码正确,生成token
  
          let userid = data[0].userid
  
          let username = data[0].username
  
          let token = jwt.sign({ userid, username }, 'daxunxun', {
  
            expiresIn: 606024// 授权时效24小时
  
          })
  
          res.send({
  
            code: '10010',
  
            message: '登陆成功',
  
            token: token
  
          })
  
        } else {
  
          // 2.3.4 密码错误
  
          res.send({
  
            code: '10100',
  
            message: '密码错误'
  
          })
  
        }
  
      }
  
    })
  
  })
  
  
  
  6、验证登陆实现
  
  目标文件： myapp/app.js
  
  实现思路：很多的数据请求都需要登陆之后才能获取到，在此统一封装验证登陆
  
  // 引入token模块
  
  var jwt = require('jsonwebtoken');
  
  // 全局的路由匹配
  
  app.use((req, res, next) => {
  
   // 排除登陆注册页面
  
    if (req.url !== '/users/login' && req.url !== '/users/register') {
  
    // 不同形式获取token值
  
      let token = req.headers.token || req.query.token || req.body.token;
  
      // 如果存在token ---- 验证
  
      if (token) {
  
        jwt.verify(token, 'daxunxun', function(err, decoded) {
  
          if (err) {
  
            res.send({ 
  
              code: '10119', 
  
              message: '没有找到token.' 
  
            });
  
          } else {
  
            req.decoded = decoded;  
  
            console.log('验证成功', decoded);
  
            next()
  
          }
  
        }) 
  
      } else { // 不存在 - 告诉用户---意味着未登录
  
        res.send({ 
  
          code: '10119', 
  
          message: '没有找到token.' 
  
        });
  
      }
  
    } else {
  
      next()
  
    }
  
  })
  
  
  
  
  

在网页和移动端界面中，内容和信息是否能够经过系统性、有效的整理和组织，对于内容的可用性和实用性，都是意义巨大的。而在呈现信息的时候，视觉间隔是组织信息的关键因素。它说起来并不难理解，但是在实际的运用当中，却是千变万化，今天我们来梳理一下流行的视觉间隔的方法。

什么是视觉间隔

视觉间隔是一种布局元素，它有助于将内容分隔成为清晰的分组、选项和部分。它可以让设计师更好地组织内容的视觉体验，处理信息的层级，也有助于用户理解内容，明白内容之间的关系。

视觉间隔和页面上的其他内容在一起，构成视觉层级，这是它最重要的作用。在视觉间隔的帮助之下，用户可以轻松地感知内容之间的关系，明白各个信息片段之间的关系是相似，并列，承袭，从属，还是其他。

视觉间隔的可用性也同样重要：在很多时候，有的视觉间隔元素看起来是可点击，可交互的，这在移动端界面上，是非常重要的。

视觉间隔的种类

谈到视觉间隔，我们可以从两方面来进行拆解分析：视觉间隔的外观和功能。按照视觉特征，视觉间隔有5种基本的类型：

• 线条
• 色彩
• 负空间
• 阴影/体积
• 图片

下面我们分别针对这5种类型进行说明。

线条

很长时间以来，在排版印刷领域，线条就一直是一种用来分隔内容的方法。线条的分隔功能是认可度最高的一种间隔方式，用户几乎不用思考，就能够理解和感知它，并且发挥作用。

另一方面，这种间隔方式也很容易显得过于简单，并且和应有的形态相去甚远。这也是为什么设计师在想尽办法去寻求别的视觉间隔形态。太多的线条间隔会让屏幕上的视觉干扰太多，并且带来不必要的视觉噪音。

所以，能够将线条间隔用得微妙、恰到好处、出神入化，是设计师功力的一个重要体现。

在这个网站产品页面中，使用深色的线条间隔来分割产品信息，用来组织和间隔信息内容。

在这个页面当中，线条分隔了不同的内容区块，让页面的结构更易于被扫读。

这个电商网站将不同级别的视觉内容进行了分离，借助简单的水平线将价格、CTA按钮以及承载相关信息的表单分隔到不同的区域。

负空间

负空间，也就是留白，也是最为常见的一种视觉分隔元素。留白绝不是对空间的浪费，和屏幕上其他的元素一样，它同样发挥着重要的作用，拱卫支撑着整个用户体验。负空间是最为流行的视觉分隔之一，尤其是在极简主义风格为主导的设计当中。负空间本身遵循着格式塔原理，尤其是其中「接近原理」和「相似原理」是负空间在设计中，发挥分隔作用的核心所在。合理地运用负空间，还能强化页面的呼吸感。

上面这款旅行规划 APP当中，使用留白将不同的条目分开，没有使用额外的具体视觉元素，仅仅只靠留白。

Health Blog 的列表的排版层次是基于负空间来实现的，看起来清晰又充满呼吸感。

色彩对比

高对比度的色彩，同样能够带来清晰的视觉间隔效果。在 UI 界面中高对比度的色彩有着极为明显视觉表现潜质，它们能够增强网站的信息和内容的表现力，分割区块，营造氛围。对比度是影响页面和屏幕可读性的关键因素之一。在具体的应用当中，不同的色彩会有效地分离不同的选项、条目和区域，这意味着它作为视觉分隔的作用非常强。这也是近年来分屏式设计如此流行的原因所在。

这是一套移动端菜单的概念设计，强烈的色彩对比让信息清晰可见。

即使是在这样的柔和的设计当中，色彩的对比度也发挥了相当的作用：一方面，强烈的色彩对比让CTA按钮和输入框之间有了明显的区分，另一方面，右侧的主视觉元素的背景也同样借由不同色彩的对比，做到了突出的效果。

在 GNO Blankets 这个网站当中，强烈的明暗对比将网站元素分隔成为精美而清晰的区块。

阴影和体积

阴影和体积也是一种非常常见的视觉间隔方式，通过营造在「高度」或者说高程上的视觉差异，从而达到分层的效果，而这种设计也是符合人类一直以来的认知习惯。这种方法有利于保持整个设计的平衡和易读性，另一方面，它又能保持足够的微妙和自然，不会那么引人瞩目从而让人觉得出戏或者受到干扰。

这个APP的目录页面所有元素都采用了白色的背景，而阴影让布局呈现出了纵深层次，让内容足以展现又不显突兀。

这款提供定制化花束服务的APP也采用了类似的阴影元素，让整体看起来清晰又通透。

图片

图片在 UI 界面当中，同样也是一种非常有效的视觉间隔，尤其是在包含大量文本内容的界面中。无论是博客、在线媒体网站还是其他类型的网站当中，图片的间隔作用都非常明显。无论是照片、插画、3D图形，它们作为图片都可以很好的平衡文本内容，提高内容的识别度和可读性，有效地划分层级，并且提高情感吸引力。

这个比特币网站的着陆页就使用了带有3D效果「了解更多」动态图片，图片和文本在内容和功能上都清晰地分隔开来。

在这个餐厅 APP 当中，图片作为划分内容的关键元素而存在。

按照功能划分

如果从功能的角度上来划分视觉间隔，可以根据它所处的层次来进行划分。

全出血间隔

使用线条作为全出血间隔是最为常见的，它会很跨整个屏幕布局来作为信息层级的划分。

这个画廊图库 APP 的艺术家目录当中，使用线条作为全出血间隔，来区分艺术家。

这个名为完美食谱的APP也使用了全出血间隔线来区分内容。

在这个财务APP当中，也使用了全出血间隔线来区分条目。

在这个电影APP的结帐页面当中，也使用了线条来作为全出血间隔。

嵌入式间隔

嵌入式间隔的功能是将相关性较高的内容分割开，并且它通常会和标题或者其他的特定元素保持对齐或者对应，它们通常是进行某个大区块内不同组件的分隔，或者将多个同类的元素分隔开。

这个网站当中，使用横向的短分隔线来区分表单中的参数条目。

中间分隔

这种分割线通常会置于布局的中间某处，同样是分隔相关的内容，但是通常它们在属性上不一定是一致的，但是层级近似。

在这个出售草药的电商网站的右侧，使用中间分隔线将文本和可交互的区域清晰地分隔开。

值得思考的问题

上面对于不同类型的视觉分隔方式都有描述，在此之外，还有两个问题需要注意：

• 保持微妙：视觉分隔不应该醒目、太过引人瞩目，它们不应该分散用户的注意力，它们应该支撑布局的同时，微妙而不那么抓人眼球。

• 中等频率：这和上一点是相辅相承的，过多的分隔线会变成视觉噪音，让用户浏览的时候感到疲倦。因此，应该仔细考虑使用频率，尽可能使用负空间，而不是线条。不要过度使用太多色彩，应该尽量保持整体的协调一致。

文章来源：站酷

我们通过门铃声儿得知门外有人来访，也能通过电话铃声得知正被人呼叫。短信通知也有着类似的作用，包括各类产品的消息推送。

但不同的是，消息推送的重要性随着「通知」被滥用而变得不那么重要了。它们变得不像门铃或电话铃声起到的作用性那么大，包括短信现在也大多是垃圾信息。

而且，通知越来越多地通过各种方式去触达用户。比如消息未读的红点提示，或者显示消息的数字统计，以及手机使用过程中的顶部提示与声音或震动的提醒，等等。

但我们还是无法抑制点击图标的冲动，这仅仅是因为它具有未读的计数或红点提示，即使我们已经知道当中的内容并不重要。

而我要说的是，当通知内容变得次要且被滥用之后，它仿佛成了一种违背设计原则的功能 —— 中断用户当前行为。因为它打破了用户与产品之间的层级关系，破局至产品之外来吸引用户的注意力，这是一个非常打扰的行为。如果我在看书，突然收到一条并不重要的消息，那我一定会非常反感。

所以，为了不被「红点」支配，以及不让通知所打扰，我会把手机里所有产品的消息推送都给关了。

但是，以上内容并不能说明通知的无用论。同样有许多用户还是沉迷于通知的使用上，它所控制的是用户对于某个产品的控制欲，担心错过某条消息，就好像我在豆瓣写了篇随笔，就想看别人给我点赞评论的消息，但我又不可能一直盯着，所以通知这时候就起到了一个很好的作用。

以至于对于优秀的产品人或设计师，包括运营来说，利用好通知，就能掌握用户心理，巧妙的将用户留在产品中。它们甚至有助于与打算放弃产品的用户建立联系并促进互动。

那么，我们应该如何更合理的设计通知呢？下面我们通过「通知的组成部分」以及「通知的使用类型与规则」来详细做一次拆解。

通知的组成部分

关于通知的简单定义：它是一种吸引用户注意的功能模式，让用户获悉新事件的信息动态。产品将其发送给用户并与用户产生交流。

因此从这个定义中我们可以知道，通知有两种形式，分别是被动只读型和操作反馈型。

被动只读型，是指该信息可读，但不可进行操作；操作反馈型，是指用户可对该通知进行操作，如某宝订单支付成功后的地址信息确认通知。

所以在梳理组件的时候也要注意掉这个差异。

1. 消息中心

这里的消息中心，是一个信息汇总中心，但并不一定是信息来源。意思是，信息来源可能是有很多用户在你的文章下面点赞了，而这个点赞行为被汇总到了消息中心，再用消息中心指引作者去到文章页面查看具体详情。

所以它是一个汇总表。但也有可能它就是信息来源点，比如一些系统通知，告知要升级，因为它没有其他功能可承载，所以只会在消息中心里出现。

或者类比 iOS 系统的通知中心，如果通知是 App 推送的，那么它会指引用户进入某个 App；如果通知是系统行为，如勿扰模式，「6:00 前来电和通知将会静音」这个通知，是只可在通知中心进行操作的。想要更改，就需要手动打开设置。

2. 通知指示符

它可以是点，也可以是计数器，只要表明目前消息中心有新的信息就可以。我个人一直觉得这就是让我们多数人养成强迫症的罪魁祸首。

3. 信息标题

它主要是指该信息来自于谁或属于什么子类型，比如用户互动点赞消息，评论消息，系统消息等等。用户可以通过标题来获悉该信息类型，再通过内容摘要来判断内容是否重要。

当然，这里的摘要如果过长，就需要省略处理，引导用户进入消息源或消息中心。

4. 推送时间

推送时间是一个看起来简单，实际上也好像不是很复杂的逻辑。只要说明该通知的发送时间即可，但是需要注意的是时间段问题。比如几分钟前，几小时前，几天前，这里的逻辑是按照时间推进规则持续增加来告知用户该消息的推送时间节点的。也就是过得越久，时间概念就越大。

5. 通知图标

上面讲到消息类型，我们也经常会在各类产品中发现不同通知的类型会汇总在各自的类型下。包括用户所接收到的信息，通常也会告知用户该信息属于什么类型。有时候，标题可能会更细，但是用户通过图标可以判断该信息属于什么类型，甚至都不需要仔细查看标题与内容。

但是，并不是所有产品的信息都可以通过图标来判断，有时候图标只是一个大方向，如果手机锁屏，相对于用户来说，这条通知只是告诉用户该信息是由什么产品推送，而并不能指向至该产品的什么类型的信息。所以在使用的过程中，同样需要根据业务的场景，谨慎地选择图标。

6. 阅读指示器

它就像是上面提到的红点，这里指的是进入 App 的消息中心之后，所显示的内容。

7. 操作行为

这里的操作行为分两种，分别是 App 外与 App 内，它们之间的操作逻辑是不同的。iOS 系统通知的清除操作，只是在系统的通知中心将该信息清除，进入具体 App 后，这条消息还是会存在。而在 App 内删除该条信息，则该信息才会真正消失。

所以从上面可以看到，通知推送，是有两大类别的，分别是 App 外与 App 内，它们之间的逻辑关系与展示形式会有所差异，需要根据具体情况进行设计分析。

8. 小结

对上面的内容进行总结，可以得到这样一幅画像：

大部分系统或产品的通知组成，都可以通过此图概括，唯一不同的是，它们会随着不同的业务而发生变化。

比如豆瓣的推送消息告知用户近期有新的电影上映，那么通知来源要么是电影模块的功能详情页，要么是通知中心的系统消息；而通知类型就是内容更新；详情则根据具体内容来组合排列；最后送达至用户。

而其中的差别就是，如果是通知中心推送的，用户点击之后则是进入通知中心列表。如果是具体功能推送的，那么用户点击进入的就是具体功能页面。如下图所示：

从这里可以看出，通知是有具体模式的。

一旦确定了通知的主要目标，以及想要解决的问题，包括它们如何对业务产生作用以及对用户形成吸引力，就可以确定通知的具体样式了。

在这一节里只要知道通知的组成部分与通知模式如何指引用户进入 App 即可。后面我来带大家理一遍逻辑，以及在设计通知时要注意哪些问题。

通知的使用方法

聊完上面的内容之后，我相信大家对通知的组成与使用模式已经有了全新的认识，但也仅此而已，我们还是不知道一个优秀的通知功能应该从哪些方面去提升用户体验。这里面所包含的不止是表象，还有内在的规则逻辑。所以从这一节开始，我们仔细来梳理一遍。

从我们平时使用到的，以及上文提到的，可以大概先梳理出几类常见的通知类型。

1. 用户信息类通知

这种类型的通知有很多，比如微信消息发送，知乎私信，手机短信等等，它们主要由用户主动生成发送至其他用户被动接收，作用就是促进用户与用户之间的互动关系，以提升用户使用产品的频率与时长。

这种通知，可给予用户操作也可不给予操作，不操作就是读取，并回复；操作就是可对该用户的信息进行屏蔽、已读、删除等设置。

这是最常见的通知类型，在多数社交产品与有社交特性的产品里都能看到。

说明

之所以给予用户信息的操作行为，是因为用户信息可分为感兴趣的与不感兴趣的，它主要取决于人。不感兴趣的人，频繁的发送信息，会影响用户对产品的好感度，毕竟有很多用户消息并不是用户想要接收的，所以在社交产品里，用户可删除好友，或拉黑好友；在有社交属性的产品里，用户可拉黑账户，以达到不被骚扰的诉求。

如果没有到达删除好友的程度，也可对该好友的信息进行屏蔽，甚至对该好友信息做已读而实际上未读的处理；或者对重要信息做未读而实际上已读的处理。

当然，用户还能对群消息做更复杂的设置。这就是产品对这类通知的一种优化方式。

2. 系统推送类通知

我们经常会在手机上收到一种系统类通知，或者在 App 中也会收到类似的系统通知。大多是关于系统升级，密码更新等。

这类通知多数是用户被动接收，且对于系统与用户来说是较为重要的。当然也有不重要的，比如 App 更新说明的通知，告知用户新功能有什么变化，或系统更新了什么等等。

对于这类通知，用户大多无法进行设置，因为它们比较强制，没有可以商量的余地，类似于告知用户：我们有新的消息，比较重要，你来看看，即使你不打算更新或执行也来看下。

说明

系统类通知，通常来说较为被动，要么强制用户执行操作，要么就是提醒用户系统近期做了更新，或者是一些并不重要的信息提示，比如勿扰模式。

强制类系统通知不能频繁，否则会给用户造成控制欲反制的副作用。类似于本身用户使用产品需要对产品享有控制权，现在反而被产品控制了。这是不行的。

3. 通用推送类通知

这类通知就是第一节中提到的那些，比如点赞/评论，内容更新等等，这类通知如果是忠实用户，那么或许不会反感它的频率，当然还是需要适当。但如果是普通用户，那么造成的影响就是直接关闭该 App 的所有通知。

我们现在的很多人，之所以开始反感通知的主要原因，就是这类通知所造成的。内容不断更新，随着时间的推移，每天推送多条对于该用户来说无用的通知。包括只适合一些符合条件的用户参与的活动通知也推送给所有人，那么用户就会逐渐对这类产品的通知失去兴趣，造成无法弥补的损失。

即便像某团一样，经常弹出开启通知的弹框，也依然无法召唤回用户。这就是很典型的下场。

说明

通用型通知，如果是业务很复杂的产品，就必须建立通知推送的功能模块，给予用户进行选择接受哪类信息的权力。允许用户进行相应的设置，如活动类推送可拒绝接收。

在很多产品中都已经置入这样的推送模块设置，如下图。

这类内容就是针对于产品的具体业务进行细分。

比如兴趣精选，私信消息等做好类别划分。用户可对自己感兴趣的通知做选择性的推送接收。

另外就是，在相同账户的不同设备之间，推送应该同步推送与被处理。不能这边推送了，那边没推送，或者这边处理了，那边没被处理。

4. 智能推送类通知

不知道大家是否有印象，在使用如大众点评等产品时，只要你切换了城市，产品就会推送通知告知用户该城市有哪些值得游玩的景点与品尝的美食。

虽然这类通知还算不上多少智能，但至少在用户群体中是存在这类诉求的。而这类诉求有时候并不能主动感知，因为用户可能会想不起来通过哪类产品来查找附近美食。当这么一条通知出现的时候，正好解决了用户的问题，反而提升了用户对于产品的好感度。

现在很多产品的通知都逐渐智能化，不会像以前那样，三更半夜发来一条无关紧要的通知。而出现这类问题的主要原因还是在于产品、设计、运营，在这方面没有下过功夫，只将通知作为一种普通的工具来使用。导致用户开始排斥通知，将其强制关闭。之后，就很难再让用户开启了。同理心效应，当做这类功能的时候，可以回想一下自己是如何被其他产品打扰的。

随着大数据的发展，我相信未来的通知系统会更加全面，且能做到千人千面的模式，不过在此之前，各位产品设计师，还需要对通知下一番功夫才是。

5. 小结

我们还可以继续举例说明，但是基本大同小异，所以到这里为止，我再对上面的内容做一次总结，梳理出一个好的通知应该是如何设计的。

干扰最小化：通知本身具有强制性和干扰性。它的目的是把用户的注意力吸引到产品上来，所以要认真思考发送通知的内容、时间、频率；不要提醒用户当前屏幕上已经处于展示状态的内容；也不要推送与用户无关的系统信息。

跨设备：当用户读过了某条信息，这条信息应该不再做展示。同理，用户也应该能够在其它更适合接收消息的设备上找到已读信息。用户通知应该在所有设备上进行同步。

允许设置：允许用户在「设置」中禁止或调整通知的形式。如案例一，通过选择推送内容，来影响接收推送的频率。案例二，可选消息提醒的形式是红点+数字，或仅是红点。

时效性：良好的通知应尽可能实时推送。而不是等这件事情都过去很久了，才推送给用户知道。

支持汇总：把同类型的通知合并为一条，并显示信息未读数量。也可以考虑一键展开通知，显示信息详情。

可操作性：把通知和操作结合在一起，让用户不需要打开首页就能对特定通知进行常规操作。操作应该清晰明了，且仅在未重复默认操作时提供。同时操作应该是有意义、实时、和内容对应的，并且能让用户完成某个任务。如案例一，可以在不打开邮件的情况下，直接对通知进行管理、查看和清除。案例二中的操作针对的是未读邮件，可便捷地在通知板面进行回复、删除、标为已读或垃圾邮件。

总结

对本篇文章的拓展总结：

• 通知具有召唤属性，但是频率过多就会变成打扰，所以要注意通知的频率与内容重要性；
• 设计师或产品经理应该将通知的内容分类梳理出来，以便维护或新增必要需求可能需要用到的推送信息。
• 通知一般为两种类型，一类是推送只读型，一类是操作反馈型；设计师需根据不同类型的通知做好对应的设计，针对具体问题具体分析；
• 想要利用好「通知」，也需要对业务有详细的了解，再代入本文所列举的注意点，就可以设计出一个体验更佳的通知模式。
• 通知规则不会脱离本篇文章的范围，所以只要详细研读，必会有所收获。

文章来源：站酷