GUI设计禁忌 之二 ——错误地使用了控件

本部分介绍的几种错误，控件选择是正确的，但是使用方式可能错了。

一、动态菜单项

大部分的应用程序都有一个菜单，很多教读者如何使用软件的教材，也都是从菜单开始的，用户自己也是通过查看软件的菜单来初步了解软件的。很多开发人员试图随着应用程序状态的变化对菜单项进行增删，让菜单只显示当前可以用的菜单项，从而减少菜单的大小和复杂性。这看起来似乎是在帮助用户，但实际上给用户造成了混淆。菜单项有时存在有时消失，用户会怀疑自己的软件出了问题，或者尝试找出菜单项变化的原因。

菜单中的菜单项应该是固定的，动态菜单项破坏了这个规律，不利于用户学习。如果想让用户在当前状态下只是用某些菜单项，可以把不需要的菜单项灰掉。至少这样用户不会因为菜单变长变短而感到恐慌。

有一种情况是某个软件能安装插件，一旦安装上新插件，菜单就需要增加一些项，卸载插件，菜单需要删除一些项。这也不应该成为使用动态菜单项的理由。正确的做法是为该插件在菜单栏增加/删除一个菜单，而不是在菜单上增加/删除几个菜单项。前者比后者更容易得到用户的认可。因为前者在用户的关注下发生，用户知道菜单的出现和消失，而后者却是用户看不到的。

二、过于严格的数据字段

为了确保用户输入的内容是有效的，应用程序(包括Web表单)都会对一些字段进行各种检查，比如长度，字符组成等。有时候检查过于严格，也是一种错误。程序员为了编程方便，约束用户的输入，比如某字段不能包含单引号或者另一个字段能输入的字符数不能超过16。这种要求是无理的。不能因为SQL中单引号是特殊字符，就不允许用户输入。

为用户提供稍微宽松的输入字段并不难：

使字段宽度和数据长度基本一致：字段的宽度足够容纳数据，但是也不要长出太多。这样用户不会无限制的填写内容。

对于一种数据所有常见的格式，都要尽量支持。这集中体现在日期和时间，以及小数的格式上。

不要以偏盖全。不要因为自己所在国家或者地区的邮政编码只有数字，就不允许软件接收字母出现在邮政编码中。

如果大小写字母对数据来说无关紧要的话，就不要区分大小写。

为字段提供有效格式示例，放在字段后面，或者上方，或者通过某种技术让它出现在空白的字段中。

不要因为技术原因对用户提出限制。技术问题应该自己解决，而不是交给用户解决。

三、没有默认值

默认值可以让用户减少鼠标操作和键盘操作，能避免用户因为不注意而漏填了必要信息。但是很多开发人员不知道这条规则，或者懒得去考虑用什么默认值。

有两种情况是可以不提供默认值的：

没有合理的默认值：比如在“省市县”三级联动下拉菜单中，为“省”设置一个默认值的确不太好选择，除非该应用仅限某一省的用户使用。

宗教、政治或者法律原因，不能选择其中一项作为默认值。

文本框应该有默认值，以减少用户操作次数，不过现在有Ajax技术，可以根据用户输入的前几个字符给用户提示，这样也是可以的。单选按钮也应该有默认值，否则用户会以为单选按钮哪一项都不被选中也是合理的，而且一旦选中了某一项，就不能再回到初始状态(所有项都不被选中)。同样是多选一，下拉菜单就可以不带默认值，而且用户不会觉得有什么不对。这是因为下拉菜单上“没有值”也是一个合理选项，表示什么也不选。并且下拉菜单的选项一般比单选按钮多，要选出一个默认值不太容易。不过如果可以的话，还是要为下拉菜单选出一个默认值，否则用户可能不太清楚这个下拉菜单的选项都是些什么内容。

四、不恰当的默认值

这比不设置默认值更危险。没有默认值，用户可能会得到一个错误提示，但是设置了错误的默认值，用户出了错却还不知情。所以，考虑默认值时，一定要慎重选择，最常见的含义，以往的填写统计，都可以作为参考。

五、反向复选框

在人的认知中，对于“选择”的理解，往往是正向的，即选择某一个选项，意味着希望一件正向的事情发生。比如：





上图是一款截图软件的设置界面。它对于复选框的所有使用都是正确合理的。比如第一项，勾选上表示捕捉光标，不勾选表示不捕捉光标。这种理解是非常符合人的认知习惯的。但是下面这个界面的红色框是反向的：





为什么要避免反向意义的复选框呢？因为这涉及到了双重否定。双重否定总是让人会迟疑一会。