作者语:本文以element ui为例
何为消息提示类交互
按照交互原则之 “凡事皆有反馈”的原则,对界面的操作,会在操作前做询问,操作后做成功/失败的提示
本文会涉及到element ui的Message、MessageBox、Dialog、PopConfirm等组件
1 写库操作前需询问 - confirm
作者语:一键操作,意思为不需要繁杂的步骤,从界面展示到执行完毕,只需要点击一个按钮就可以调用操作
此处与toC端的一键三连等操作意思不同
在系统中做删除、禁用/启用、发布等一键操作的时候,需要提醒用户,避免误操作
并且写出相关的提示信息,如果操作之后 ,会有如何后果之类的
2 MessageBox or PopConfirm ?
两者均可以做 confirm操作,不同的是:
- PopConfirm直接出现在操作按钮的旁边(一般为上下方),便于就近点击确定/取消按钮
- MessageBox直接出现在界面的中央上方,距离当前操作按钮距离比较远
对此选择,Ant Design的建议是使用 PopConfirm,原因是不阻断用户心智
不过,我推荐的是 MessageBox,而且全系统统一,原因如下:
- MessageBox是直接使用this.$confirm调用的,而PopConfirm需要在模板代码中,将操作按钮包裹起来
- 这样如果是列表的话,PopConfirm会渲染很多次,个人之前遇到过,数据量大的时候,会影响界面性能
- 相比较开发体验而已,MessageBox这种调用,也更容易接受
- 相同的系统中,如果有这两种不同的提示,就会显得比较错乱,因为统一为一种最佳
3 操作成功之后的提示
操作成功通常会伴随着界面刷新、界面关闭等相关动作,而且操作成功的提示,也不会那么多需要用户获取的信息,所以通常是那种自消失的小弹窗(Message)提示
4 操作失败的提示
操作失败的提示逻辑稍微多一些,因为要提示给用户具体的失败信息
一般来说,失败信息由后端接口返回,便于拓展与管理
4.1 简单的操作失败提示
如果返回的提示信息不会太长,也可以使用 Message来展示
该类型消息提示,可以通过统一的接口拦截code判断展示
4.2 复杂的操作失败提示
如果是比较复杂的操作提示,比如需要明确告诉用户,失败的具体原因,可以供用户复制信息等,这样的话,自消失的message就不够用了。可以使用this.
a
l
e
r
t
来
做
简
单
的
操
作
提
示
,
这
个
提
示
信
息
也
是
由
后
端
返
回
,
按
行
展
示
。
这
种
alert 来做简单的操作提示,这个提示信息也是由后端返回,按行展示。 这种
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 总结
如上,个人总结了几点规范/原则
- 写库前必询问
- 写库后必反馈
- 提示前置