接下来举两个例子折腾一下:
案例1. 下载任务遇到了问题。
用户在开始下载一个任务的时候,会碰到几个特别的问题,技术角度上,当用户将下载请求提交给服务器后,从服务器反馈给用户的情况有以下几种:
初步来看,自然描述的情况下,客户端会显示以下几种提示:
单纯从表述角度看基本这样反馈基本是自然的,但是根据具体的场景来看,其中前两种反馈在客户端的表现都是下载进度停止,需要用户等待,而且用户也只能等待等待, 而后两种反馈在客户端的表现都是下载失败,需要用户重启任务或取消任务,除此之外什么也做不了,因为事件发生在服务器端。这种情况下如果不考虑这些提示,在用户看起来实际上只是遇到了同一种问题而已。 如果对用户来说所能看到的和所能做的都一样,并且虽然发生事件的原因不同但返回的结果基本类似,那么为什么还要给他那么多种反馈呢?于是我们把表现和处理一致的反馈进一步的归并为更为概略的情况:
这样一来,问题看起来变少了,世界也清净了。对于正常的用户来说,其实不需要去管后厨发生了什么大事件,只要知道鱼没有了就足够做下一步决定了,因为这是预期中可能出现的意外之一。 在这个例子中,原本的各种反馈都是自然的描述,都没有错,也没有什么问题,但是事实上它们有些多余,甚至有可能好心办坏事,说的太多反而容易让用户浮想联翩,产生额外的预期,引发不必要的不安全感和多余的思考。将多个表现和处理一致的反馈以相同的,常见于预期的方式呈现,可以减少用户所遇到的事件种类,减少思维负担。“多说多错”,这句话虽然比较灰色,不过这个例子里确是有些这样的味道。自然任务原则把已经是自然表述反馈进一步控制在用户的预期之内,避免节外生枝。
出处:Tencent CDC Blog
责任编辑:bluehearts
上一页 自然描述与自然任务 [1] 下一页 自然描述与自然任务 [3]
|