产品--什么时候有“确定”按钮又有“取消”按钮

一个并没有最终结论的话题，也使我们在行为设计上可以更进一步去思考，什么才是用户需要的。

先拿picasa为例，我们看到：

在最下面有“继续”（相同于“确定”）和“取消”按钮。

在相册里整理，编辑标题的时候，界面上只有一个确认的按钮：“完成

从中我们引发了思考，在新建相册，上传照片… 中有“确定”又有“取消”；在整理，编辑标题… 中只有“确定”而没有“取消”。是不是说有“确定”又有“取消”是当用户在进行某一个新建操作中，有发生不想继续的情形，而需要预留一个“取消”按钮提供 返回?而在作一些比较大的改动操作上，又因为担心误操作，而不设立“取消”按钮？而实际上，我在作一些较大的改动操作上，也会有改了一半发现不对，不改的 情况。那么，在不设立“取消”按钮的情况下，仅仅是因为担心用户的误操作带来的损失吗？当我需要返回上一个界面的时候，我找不到“取消”按钮，我通过其他 方式去返回到picasa的首页，也只能这样了，其实我想返回刚才相册的页面，也就是我希望这里会有一个“取消”，或者是给我一个路标，让我可以回去。

再看一下MSN Spaces的相册，同样在编辑照片的情况下，是没有“取消”按钮的。但是他的路标/左边的tab标签可以让我很方便地返回，进入到另外的相册，那么这个时候，没有“取消”按钮显然我不会感到迷惑。

我们回到主题，是不是在作一些简易操作上，我们有必要给于“确定”和“取消”；而在过于复杂的操作上，为了避免误点击，也避免了“取消”按钮？

我们也把一个身边的产品列出来，Qzone 空间的编辑器最大化：

（之前的错误设计是有“确定”又有“取消”，符合了技术模型。后来我们简单修改了这一个模型，把”取消”按钮去掉）

操作流程是这样的：

进入我的Qzone，日志，写日志，写了一会，发现太小了，插入的图片太大，操作起来好碍手，最大化编辑器。

虚拟的用户1：

进入我的Qzone；
日志；
写日志；
写了一会，发现太小了，插入的图片太大，操作起来好碍手，最大化编辑器；
天呐，这么大，算了，取消。
返回刚才的界面。

虚拟的用户2：

进入我的Qzone；
日志；
写日志；
写了一会，发现太小了，插入的图片太大，操作起来好碍手，最大化编辑器；
再写了一会，然后决定写完了，确定。
显然取消是取消了我刚才的所有写入操作。

我们细化过程，会发现存在更复杂的问题。

在这个界面中，又有“确定”又有“取消”按钮，显然就产生了矛盾。“取消”是返回刚才的最小化界面？还是说把我刚才最大化之后的操作全部取消？反而 我会认为这个“取消”是返回刚才的最小化界面，结果发现我的操作全部取消了。或者说我认为是取消我刚才所有，结果不是，只是返回了刚才的最小化界面。在这 样一个界面上，我们是否有必要给它“取消”功能呢？技术的模型让我们操作上需要进一步去思考，也经常因为不去思考而产生误操作。实际上，最小化编辑器，最 大化编辑器，这里我们只是给用户提供一个附加的功能，也是改善用户书写时候的障碍，我们并没有必要给他一个再额外复杂的功能，他还需要思考我刚才的某些操 作到底是确定了还是放弃了。其实我们仅仅只是需要一个按钮“最大化”，另外一个返回按钮“最小化”，他们之间的其他操作是没有必要去再让用户确认的。

“确定”和“取消”应该出在经常会需要使用的情况下，那么这种情况又是什么情况呢？或者说我们在大部分用户都并不会需要经常去撤销的时候，我们也同样考虑到他们或许会因为误操作，我们把“取消”隐藏了，放在一个不是很容易点到的地方?