文档介绍：自然描述与自然任务
这次我们来说一些很小的东西，相当小。不过先说一个故事：
这天晚上，你打算出去下一次馆子，就行动了，找到了一家新开的小店进去坐了下来，服务 员很殷勤的走了过来问你想吃点什么。
你问：“你们有什么好吃的么？”
时间之前的确不是这样的，这让交互设计师们都很郁闷。）这个就不多说了。 在此之外，某些情况下自然描述并不能完美的搞定某些场景和任务，自然描述一般来说是措 辞上的原则和技巧，针对任务场景和流程的优化原则我管它叫“自然任务”：
自然任务:在自然描述的基础上,根据斯亶和吟（按腿通 俗易懂、符合预期、不引起困惑的原则，筛选合适的自然 描述方案来优化和控制任务场景B
接下来举两个例子折腾一下：
。
用户在开始下载一个任务的时候，会碰到几个特别的问题，技术角度上，当用户将下载请求
提交给服务器后，从服务器反馈给用户的情况有以下几种：
却载服务器上的任务列表
链接任务于服务器端排队
,导玫下载失败
，导魏下载失庖
初步来看，自然描述的情况下，客户端会显示以下几种提示：
Z连接攀忙，正在等待排队.
，
链援下载浦源超时，下载灾败.
单纯从表述角度看基本这样反馈基本是自然的，但是根据具体的场景来看，其中前两种反馈 在客户端的表现都是下载进度停止，需要用户等待，而且用户也只能等待等待，而后两种反 馈在客户端的表现都是下载失败，需要用户重启任务或取消任务，除此之外什么也做不了， 因为事件发生在服务器端。这种情况下如果不考虑这些提示，在用户看起来实际上只是遇到 了同一种问题而已。
如果对用户来说所能看到的和所能做的都一样，并且虽然发生事件的原因不同但返回的结果 基本类似，那么为什么还要给他那么多种反馈呢？于是我们把表现和处理一致的反馈进一步 的归并为更为概略的情况：
任务正在排队,请稍等.
无法获取下载奏源,下载失败
这样一来，问题看起来变少了，世界也清净了。对于正常的用户来说，其实不需要去管后厨 发生了什么大事件，只要知道鱼没有了就足够做下一步决定了，因为这是预期中可能出现的 意外之一。
在这个例子中，原本的各种反馈都是自然的描述，都没有错，也没有什么问题，但是事实上 它们有些多余，甚至有可能好心办坏事，说的太多反而容易让用户浮想联翩，产生额外的预
期，引发不必要的不安全感和多余的思考。将多个表现和处理一致的反馈以相同的，常见于 预期的方式呈现，可以减少用户所遇到的事件种类，减少思维负担。“多说多错”，这句话 虽然比较灰色，不过这个例子里确是有些这样的味道。自然任务原则把已经是自然表述反馈 进一步控制在用户的预期之内，避免节外生枝。
。
有一个包含操作的提示气泡，由于它的重要性不能使用自动消失的方式，我们需要提供一个 “关闭按钮”，而由于任务特点，它被关闭之后便不能再出现。我们这时有三个候选方案:
文字连接“关闭”、文字连接“不再提示”、代表关闭的图标“X”。
这三个候选方案都像大自然一样自然，看似用哪一个都无所谓，可是我们纠结了很久之后， 选择了最啰嗦的方案一一文字连接“不再提示”。
［
这是重要的提示，但是我不能写出来。
修改设置不再提示