最近碰到很多需要保存的场景，“什么时候保存”、“怎么保存”，总是要让我琢磨一番。
Web上的保存，其实就是提交表单，最早的形式基本都是一个“提交”按钮，表单里输入的内容就统统跑数据库去了。随着应用场景越来越复杂，原本很简单的一个交互模型衍生了许多变数，先看图：
第一张图是饭否的设置页面，第二张是wordpress后台设置页面。
先看问题：饭否这个“提交”动作不需要用户特意触发，只要“宽度”、“显示条数”改动，即算设置成功。这个出于节省用户操作的设计，由于没有任何反馈（包括宽度超出限定范围），刚开始用时，每次再改完后，我都要点一次预览查看是否成功。WP的提交则是最传统的形式，但是在多tab情况下，提交按钮的控制域是单tab还是多tab总是会让人迷惑，也可能在设计时被人忽略。
第一个问题关键在于完善反馈形式，成功、失败信息能及时在用户注视范围内显示，很容易就能避免用户对修改结果的疑惑。同时这个提示信息的时效性设计也需要我们关注，在多次修改的情况下，用户需要分辨出这个信息是不是这次修改成功的（比如加上成功时间，WP的动画提示……）。
第二个有关多tab的提交，一般的处理方法就是用视觉做区分，按钮在当前tab区域内的，提交的就是当前tab的内容；在tab外的，就是多tab内容一起提交。WordPress在视觉上这么处理，但用户在改完当前tab内容后，没点保存就切换到其他tab时，原来tab里的信息没有得到任何的处理。很显然，在这里容错性设计上的疏漏，给用户带来很大的伤害，如果能在切换时提示用户保存或者保留录入数据，避免用户出错。
归根到底，用户需要有效、友好的反馈信息，及时的知道自己操作会带来什么样的结果。适度提示，不干扰不迷惑！