我的github:codetoys,所有代码都将会位于ctfc库中。已经放入库中我会指出在库中的位置。
这些代码大部分以Linux为目标但部分代码是纯C++的,可以在任何平台上使用。
一个案例,症状:外部接口提供活跃数据,界面经常报错,特别是领导来视察的时候!
分析原因:为什么报错?因为数据已经失效,外部接口不再提供,点开数据查看细节时因为数据已经不存在而报错。
目录
这个案例里面存在诸多问题。
一、报错的方式
此案例里面使用前端业界很喜欢的刘海式提示,红色系统错误,几秒钟后自动消失。
这种报错方式怎么流行起来的?现在搞界面的全是美工、没有交互设计师吗?
如果一个信息只是闪一下就消失,那它是无关紧要的。报错信息是无关紧要的吗?
因为这个错误是用户主动操作产生的,那么就必须明确告知用户结果或原因,这里应该用一个弹窗,显示友好的信息(而不是系统错误):“数据已失效”。(注意,这只是针对错误提示,系统是一个整体,最终解决方案并非如此)
二、信息应该消失吗
在“信息列表-点击查看详情”这种界面下,列表里的信息的详情应不应该消失?
就算是提供动态数据的界面,界面上已经存在数据,从用户视角来看,一个条目存在,详情自然也存在(具体实现当然可能出问题,后面分析)。
界面设计有一个大忌:无故消失,让用户一头雾水,还以为出了大乱子。往大里说是会给用户造成巨大的心理创伤(其实这是真的,不过程序员懂心理学的更少)。
对应的界面原则是不可操作的按钮“灰掉而不是隐藏”。
所以在这里已经存在的条目的详情消失了是错误的(别说你有多少理由,消失了就是不对的)。
三、接口送过来的数据属于谁
这个外部接口确实是只提供活跃数据,所以你只显示活跃数据?
分析到这里我们发现问题似乎有点大,这不是一个改变查询参数就能解决的问题。整个界面和背后的数据库设计是以外部接口送过来的活跃数据为核心的,整个功能是依赖外部接口的,压根没考虑历史查询问题。
四、外部接口独立性
好的设计一定要对外部接口进行隔离,不要和外部接口捆死。首先的意义就是方便开发和测试,别在这里偷懒。
五、数据历史属于谁
好的设计一定要包含数据历史,一定不要在这里偷懒,开发、测试、查错、扯皮都靠这个。
(这里是结束)