如何优雅地做系统错误提示?

这里是Z哥的个人公众号

每周五11:45 按时送达

当然了,也会时不时加个餐~

我的第「149」篇原创敬上

大家好,我是Z哥。

不管是日常的工作中还是生活中,我们每天会用到很多软件系统。

不知道你有没有过这样的感受,当你使用软件遇到异常的时候,有时候软件给出的错误提示让人摸不着头脑。唯一的办法就是复制到搜索引擎搜一下,看看有没有哪个不幸的人与我遇到一样的问题。

所以,一个好的错误提示特别重要。它不但能让使用者明白当前到底发生了什么,甚至还能引导如何解决异常。达到这个程度的话自然可以大大提高系统的使用效率,也能间接降低己方商务人员或者产品经理的培训成本。

因此,作为程序员群体的一份子,在这里我想呼吁大家认真对待错误提示,特别是那些不是给“人”看的错误提示……

作为软件的创造者,我们虽然无法避免出现异常、出现bug,但是我们可以做到避免无意义的错误提示产生。

首先,一些常见的容易让人摸不着头脑的错误提示要先避免。比如,

  • 提交失败。
  • 数据读取失败。
  • ……

这类错误提示看上去准确表达了当前遇到的问题,实际上啥也没说。你想象一下,当我点击一个提交按钮之后,页面没有跳转而且还弹个框出来,哪怕里面什么字都没写,我能也猜到这里估计出错了。

但是具体错在哪?作为用户该如何处理?一概不知。

另外,还有一种常见的情况是,错误提示含有太多的技术术语,使用者根本不明白啥意思,也不关心这些。比如,

  • 远程服务响应超时。
  • 事务执行失败,XX保存失败。
  • ……

其实这还算好的,有的甚至把技术框架中返回的expcetion信息直接作为错误提示出来。这对用户看起来就是一堆乱码,他只会找你说“系统乱码了,帮我解决一下……”。

如果上面的景象就在你日常工作中发生,也不用不好意思,我们都是这么过来的。Z哥我自己以前也同样没意识到这个问题,经过了这些年的工作之后,我认为,编写正确的错误提示可以按照以下的思路来。

/01 不要提示用户不关心的信息/

首先来个排除法。

我们作为程序员经常需要通过一些技术性的线索来排查问题,特别是expcetion信息。但用户并不关心它们,而且他们无法对此类消息进行任何处理。

所以,这些信息记录到日志里就好,页面上无需给出这种用户不关心的信息。

/02 清楚表达问题原因/

让用户清楚的知道问题的原因,是他能否自行解决问题的基础。

比如,前面提到的“提单失败”的例子,你告诉他由于缺少XX信息导致提交失败,那么使用者自然会去想办法把缺少的信息给补上。

我还记得我之前用某个邮箱的时候,有封邮件发不出去,它总是提示我“邮件发送失败。”我真是服了,到底啥原因发送失败,后来经过自己不断的测试才知道是某个附件太大了导致发送失败。

/03 给出引导建议/

这点在一些企业内部使用的系统,以及一些toB的项目中特别重要。因为大多数系统使用者都只负责自己工作相关的部分,对其他的模块并不了解。所以,哪怕你将问题的原因表达的很清楚,但是他还是不知道该如何解决,只能寻求产品经理或者开发人员的协助。

比如,电商平台的客服在后台替用户修改订单收货地址的时候,发现某个地区下没有可用快递可选。如果你没有给出引导,诸如“联系XX人员进行设置。”之类的内容,那么他们只能来找你解决,无其他路可走。

如果想做得更好一些,针对某些场景可以直接放出下一步操作的连接,这样用户可以直接到达需要他进行操作的页面。

/04 提示内容尽可能简短/

文字一多,大多数人都不会逐字逐句看的,甚至有些人会完全不看。

Z哥工作中遇到过无数次这种情况。不管是错误提示还是操作提示,不管你写的多么详细、清楚,只要文字超过2行或者有几十个字以上,很多人看都不看直接截个图发给你,问你该怎么办?

听说有个美国机构做过相关的研究:

如果句子中的单词数不超过8个,读者可以理解其中的100%。

如果句子包含43个单词或更长的单词,则读者的理解力将下降到不足10%。

虽然这个研究说的是英文,但是中文也是类似的道理。不过我没找到这个研究的具体出处,不知道真假,但是我觉得这个结论还是很符合常识的。

以上这4点说起来简单,也很好理解,没什么新奇的。但是真正做的时候很多人就把它们抛之脑后了。

当然,比给出合理的错误提示更好的是,避免出现错误。所以你还可以更进一步,提前规避掉一些错误。

比如,

  • 为了避免日期选择超过有效范围,可以对有效范围外的日期设置为禁用状态。
  • 为了避免在信用卡卡号之类的文本框内输入数字以外的字符,做一下输入限制。
  • 为了避免在弱网络下页面无法正常加载而提示错误,可以做缓存,提前预存一些数据在本地。
  • ……

好了,总结一下。

这篇呢Z哥和你分享了我对软件系统抛出的错误提示的看法。我认为好的错误提示需要符合以下4点。

  1. 不要提示用户不关心的信息
  2. 清楚表达问题原因
  3. 给出引导建议
  4. 提示内容尽可能简短

如果可以的话,还可以通过做一些前置的限制约束来提前规避掉一些可能发生的异常。

希望对你有所帮助。

推荐阅读:

作者:Zachary

出处:https://zacharyfan.com/archives/1250.html

如果你喜欢这篇文章,可以点一下右下角的「爱心」,支持我的创作~

▶ 关于作者:张帆(Zachary,个人微信号:Zachary-ZF)。坚持用心打磨每一篇高质量原创。本文首发于公众号:「跨界架构师」(ID:Zachary_ZF)。

如果你是初级程序员,想提升但不知道如何下手。又或者做程序员多年,陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」,回复「技术」,送你一份我长期收集和整理的思维导图。

如果你是运营,面对不断变化的市场束手无策。又或者想了解主流的运营策略,以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」,回复「运营」,送你一份我长期收集和整理的思维导图。

定期发表原创内容:架构设计丨分布式系统丨产品丨运营丨一些深度思考。

85 声望
31 粉丝
0 条评论
推荐阅读
Spring事务传播行为详解
Spring在TransactionDefinition接口中规定了7种类型的事务传播行为。事务传播行为是Spring框架独有的事务增强特性,他不属于的事务实际提供方数据库行为。这是Spring为我们提供的强大的工具箱,使用事务传播行可...

JerryTse238阅读 121.1k评论 94

刨根问底 Redis, 面试过程真好使
充满寒气的互联网如何在面试中脱颖而出,平时积累很重要,八股文更不能少!下面带来的这篇 Redis 问答希望能够在你的 offer 上增添一把🔥。

菜农曰17阅读 973

封面图
开源问答社区软件 Answer 1.0 正式版发布!
这是继 10 月 Alpha 版本发布后的首个正式版本。你可以使用 Answer 高效地搭建一个问答知识社区,并用于产品技术问答、客户支持、用户交流等场景。

AnswerDev7阅读 2.4k评论 1

封面图
PHP转Go实践:xjson解析神器「开源工具集」
我和劲仔都是PHP转Go,身边越来越多做PHP的朋友也逐渐在用Go进行重构,重构过程中,会发现php的json解析操作(系列化与反序列化)是真的香,弱类型语言的各种隐式类型转换,很大程度的减低了程序的复杂度。

王中阳Go10阅读 2k评论 3

封面图
万字详解,吃透 MongoDB!
MongoDB 是一个基于 分布式文件存储 的开源 NoSQL 数据库系统,由 C++ 编写的。MongoDB 提供了 面向文档 的存储方式,操作起来比较简单和容易,支持“无模式”的数据建模,可以存储比较复杂的数据类型,是一款非常...

JavaGuide5阅读 847

封面图
2022风云变幻的一年,我开始思考生活的意义
2022 年对所有人来说,是束缚的一年、也是艰难的一年。这一年疫情起起伏伏,商场歇业,饭店关门,在工作之余吃一碗热乎的刀削面也成了奢侈。对一个北漂来说,“回家”和“进京”从未如此艰难。假期好不容易回趟家,结...

杨成功9阅读 1.4k评论 1

封面图
技术社区的朋友们,让我们在 2050 团聚吧!
提到 2050 你会想到什么? ——第一批 00 后步入 50 岁,刚刚出生的孩子们成为这个世界的中流砥柱;如科幻般的世界:上天下地、无尽探索、发达的医疗、先进的交通;

SegmentFault思否5阅读 12.9k评论 1

85 声望
31 粉丝
宣传栏