4、老土眼中的撤销重作原则

为了避免用户的误用和误击，系统应提供撤销和重做功能。

不知道其他人怎样，老土对“撤销重作原则”是又爱又恨的。先说“爱”，当然从用户的角度看，针对用户的误操作，为用户提供“撤销”和“重做”是非常贴心的。任何“贴心”的设计或多或少都可以提高用户满意度。然而谈到“恨”，老土不得不说，在很多场景中为了支持“撤销”和“重做”引入的开发工作量是巨大的，尤其是在应用设计的初期并没有考虑支持“撤销”和“重做”的时候更是如此。举例来说，如果一个操作涉及了一定次序的多个数据库表中条目的创建和修改，那么对这个操作的“撤销”和“重做”将会非常复杂，需要认真设计操作流程。在哪个环节进行“撤销”和“重做”，就需要将这个环节之前的“全部”数据库操作统统撤掉，从而保证“撤销”和“重做”不会导致有异常数据和垃圾数据出现。当然一种比较简单的做法是将这一系列的操作放在一个数据库事务中完成，但引入数据库事务操作对数据库的性能有不良影响，也需要非常慎重。

常见的“撤销重做”模式包括：

1、任意“撤销重做”：从想当然的角度，这种模式自然是“极好的”，但事实上，这种模式也是开发成本最高的。因为这里我们需要关注的是“撤销和重做”毕竟还是一个小概率操作（如果“撤销和重做”成了一个大概率操作，只能说明产品的交互设计出了问题）。为了这个小概率操作，引入不菲的开发量实在是不值得的。另一方面，随着操作“深度”的增加，任意“撤销和重做”的开发成本会越来越高，因此如果不得不支持任意“撤销和重做”，则在产品设计中非常有必要限制一下每个操作的“深度”。老土个人觉得“3步”已经是最大可以接受的深度了。

任意“撤销重做”

2、永远回到第一步：这种模式的最杰出的代表就是iPhone的Home键设计。当用户在操作iPhone的时候，不论遇到什么问题，只要按一下Home键就可以回到首屏。用户可以再次从这个首屏出发完成自己需要的操作。这个简单的特性，对非常多的初级用户绝对是福音，反正我老爸和老妈是非常喜欢的。而作为这种模式的一个变种就是“用户不得不完成一个系列的全部的操作，但是可以在完成这个系列操作之后，将这个系列的全部“成果”一次性干掉”。

永远回到第一步

3、仅撤销“上一步”：如果认为前两种方式过于极端，则可以考虑仅支持一步撤销。这种方式一方面提供了“撤销重作”的功能，另一方面有效的控制了相关的开发复杂度。

仅撤销“上一步”

综上，“撤销重作”可以有很多模式，但解决方案的最佳手段是“防止问题发生”，所以老土建议：

1、尽可能不要涉及多步连续操作（单步操作的“撤销重作”要简单的多）；
2、不得不多步连续操作，则要尽可能控制操作“深度”；|
3、多步连续操作的设计一定要非常慎重，代码逻辑要充分审阅，以保证不会引入异常数据和垃圾数据。

最后关于“撤销重做”再分享一个小的产品设计技巧。

锤子手机支持一项非常有趣的功能“取消短信发送”，操作方式如下：用户编辑短信，点击“发送”之后如果有特殊情况或者不想发送，可以立即点击短信界面右上角取消发送。

这个功能非常唬人，因为有电信网络技术背景的人都知道，短信技术本身是不支持“取消短信发送”功能的！那么锤子手机是如何实现的呢？其实也很简单，就是用户点击“发送”之后，短信并没有被立即发送，而是在3秒钟之后再发送。因此用户只能是在点击“发送”后3秒内可以取消发送，过了这3秒，也是不可能取消的！不过这3秒的缓冲已经算是对很多“误发”短信用户的福音了。

锤子手机的“取消短信发送”