前端UI交互 - 中后台系统 - 消息提示类交互

作者语：本文以element ui为例

何为消息提示类交互

按照交互原则之 “凡事皆有反馈”的原则，对界面的操作，会在操作前做询问，操作后做成功/失败的提示
本文会涉及到element ui的Message、MessageBox、Dialog、PopConfirm等组件

1 写库操作前需询问 - confirm

作者语：一键操作，意思为不需要繁杂的步骤，从界面展示到执行完毕，只需要点击一个按钮就可以调用操作
此处与toC端的一键三连等操作意思不同

在系统中做删除、禁用/启用、发布等一键操作的时候，需要提醒用户，避免误操作
并且写出相关的提示信息，如果操作之后 ，会有如何后果之类的

2 MessageBox or PopConfirm ？

两者均可以做 confirm操作，不同的是：

• PopConfirm直接出现在操作按钮的旁边（一般为上下方），便于就近点击确定/取消按钮
• MessageBox直接出现在界面的中央上方，距离当前操作按钮距离比较远
• 

对此选择，Ant Design的建议是使用 PopConfirm，原因是不阻断用户心智
不过，我推荐的是 MessageBox，而且全系统统一，原因如下：

1. MessageBox是直接使用this.$confirm调用的，而PopConfirm需要在模板代码中，将操作按钮包裹起来
2. 这样如果是列表的话，PopConfirm会渲染很多次，个人之前遇到过，数据量大的时候，会影响界面性能
3. 相比较开发体验而已，MessageBox这种调用，也更容易接受
4. 相同的系统中，如果有这两种不同的提示，就会显得比较错乱，因为统一为一种最佳

3 操作成功之后的提示

操作成功通常会伴随着界面刷新、界面关闭等相关动作，而且操作成功的提示，也不会那么多需要用户获取的信息，所以通常是那种自消失的小弹窗（Message）提示

4 操作失败的提示

操作失败的提示逻辑稍微多一些，因为要提示给用户具体的失败信息
一般来说，失败信息由后端接口返回，便于拓展与管理

4.1 简单的操作失败提示

如果返回的提示信息不会太长，也可以使用 Message来展示
该类型消息提示，可以通过统一的接口拦截code判断展示

4.2 复杂的操作失败提示

如果是比较复杂的操作提示，比如需要明确告诉用户，失败的具体原因，可以供用户复制信息等，这样的话，自消失的message就不够用了。可以使用this.$alert来做简单的操作提示，这个提示信息也是由后端返回，按行展示。这种$alert，默认的样式可能不够用，需要前端统一封装一下 class 样式

4.3 更复杂的操作失败提示

那种业务逻辑很复杂的操作失败提示，仅靠$alert弹窗已经不够了，需要普通的dialog来展示，里面内嵌表格之类的信息等

5 提示前置原则

有这么一个经典场景：你有一个table，单行内有删除按钮，但删除的时候后端有校验，有的数据会返回提示“不能删除”。
常规交互：
1、点击删除按钮 2、询问是否删除 3、后端返回不能删除，原因xxx
优化一下后的交互
1、点击删除按钮 2、先调用是否可以删除接口，能的话询问是否删除；不能的话，直接给出提示
优化后的交互，会提前阻断交互，避免了一些无效的操作询问。
同时也会带来一些新问题 ，就是这个事先询问的接口，返回时效要很高，要不然容易出现点击了按钮，前端没有任何交互反应的情况

6 重要操作的提示

6.1 在线考试的提交

这个时候，一次操作询问就有点不够了，需要操作人至少操作两次提交

6.2 在线文档、编辑器的离开

浏览器会做阻断提示，提醒当前界离开前的保存操作

7 不需要额外提示的场景

7.1 表单提交

一般的表单提交，都会有一些表单项，甚至有必填项的约束，这种交互就不属于“一键操作”的类型
除非那种影响流程比较大的表单提交（如公告发布、重要内容提交），一般不需要额外提示

7.2 纯前端的简单操作

比如有个table，前端点击一下“添加”按钮，会在table追加一条数据，数据内容也比较简单，没有调接口进行保存
这个时候，如果前端要删除该条数据的话，就无需调用询问操作

8 总结

如上，个人总结了几点规范/原则

1. 写库前必询问
2. 写库后必反馈
3. 提示前置