糟糕界面集锦—界面设计考虑要点
pixelcentric 著，雷立辉 译
颜色的使用
颜色选取和使用主要是针对于界面的图标来说的，其它地方几乎不会碰到这类问题。用户通常习惯于白底黑字（或相反，某些视力有障碍的人使用黑底白字），如果选用其它配色方案可能就会造成麻烦。
1. 考虑可读性
使用彩色用户界面元素时，要考虑紧接这个界面元素的相邻界面元素是什么。特别是要注意文本所在的背景底色。Apple就在Mac OS X 10.2版中的强制退出管理小程序中犯了这个错误。
这样设计的最初理由是为了表明名称显示为红色的应用程序在此时不能响应。理论上这似乎是一个很好的特征，因为它能很快让人找到出错的程序。但实际上由于被选择的项目背景是蓝色的（就不说用户可能会改变系统颜色设置了），这种蓝底红字实在是难以阅读。
另外一个问题与对比度相关的便是用户界面中的关键元素是否醒目。就以QuickTime4，5及6各自的电影播放控制按钮来说吧。灰色的，低对比度的QuickTime 4按钮对于有些人是非常难以辨认的－特别是眼睛没有年轻人亮行动没有年轻人快的那些中老年人来说－而这些在QuickTime 5，6中“Aqua”化的按钮则变得对比度更强从而好用多了。
2．考虑文化差异
许多文化中，红色都表示一种否定色彩的回答或命令，而绿色则表示一种积极色彩的回答或命令。即红代表“否”而绿代表“是”。如果忽略这点则可能造成问题。
这个糟糕的以是否回答的Windows风格的对话框竟然在Mac操作系统X中也出现了。其错误不仅仅在于它非动词性质的按钮而且更重要的是其使用的颜色也有问题。“否“用红叉表示，似乎表明了它是一个否定的，不应被选择的按钮－但实际上，当你一看提问便知选择“否”并不会使数据丢失而看起来似乎安全的绿色标志实际上是具有破坏性的选择。
使用颜色的失误正反两种情况都有：一些应用程序本来是安全的选择却做了危险的显示寓意。比如说一个提示性质的对话框使用红色符号来无谓地吓人；相反的，上面截图中的白色提示图标理应改为黄色的警告图标。我们一定要根据上下文使用正确的颜色设置。
硬性使用红－绿颜色对来表示这些与是/否选择无关的问题回答大体说来是有害的。比如说，一个计划程序用绿色表示人员是合适的而红色表示人员不太合适这样的方案绝对是有问题的，因为这种颜色的寓意与具体使用的情形关系并不是太明显。而在这种情况下，用一个亮色/有阴影的灰色配色方案会更好一些。因为灰色通常表示一种无效状态。
3．不要硬性规定颜色
你的程序如果使用自定义控件或自定义高亮颜色（比如文字的颜色），不要硬性规定这些元素的颜色。如果你规定了颜色，如果用户使用的可视化主题和窗口管理器所设定的缺省颜色不一样时，你程序就有可能完蛋：要么因为难看，要么因为不能阅读，要么因为既难看又不能阅读。不要硬性使用颜色而要使用系统提供的颜色设定。如Mac操作系统的字符颜色（accent colors）和控件颜色就是由显示管理器来设置的。
如果使用系统颜色不可行时（比如说你程序所运行的平台并没有这项功能），那么就应该将配色方案写成用户自定义的。如可以通过程序中的参数设定窗口中的颜色拣取器来让用户改变文本颜色。
总是要保证测试你的程序：使用不同的窗口管理主题来确保在不同的颜色配置条件之下你的程序都是易于使用的。
4．不要过度使用
就像界面中的声音一样，如果使用得当，颜色也是非常有效的。但是太多的颜色也会让你的界面主题分散而且华而不实。当一个界面中太多的元素都是以亮色显示时，这些颜色效果就会相互抵消从而造成每一个元素都不会突出，从而看起来个个都好像是沉闷的灰色元素一样。这一点对于图标的设计尤为重要：大片的，明亮的颜色区域会让图标的其它部分黯然无光。用颜色就要用得有意义。
声音的使用
如果使用得当，声音就像颜色一样会是一种具有潜力的强大的和高信息量的界面元素。但还是应该少而精地使用声音元素。
1．不要过度使用
声音或许会造成非常吵闹的效果，所以一定要在真正需要的地方使用它。在作为可视的提示或作为视力不佳的通用性访问特征时，声音使用最为有效。当然，在一个程序中的各种操作都有声音提示将会造成听觉过载甚至于困扰以及惹恼用户。所以要避免在相当短的时间内产生过多的声音信号，从而让用户将声音和一个错误消息或者操作完成相联系。
2．不要单独使用声音
相比需要用户干预的对话框来说，声音是一种过而不留痕的信号。所以不要将声音作为传递信息的唯一形式，因为用户有可能没有听到声音；用户可能会听力不佳；可能会在程序播放声音时不在现场；也可能就因为你过度使用声音嫌烦而直接关掉音响！
图标的使用
在一个图形界面环境中，图标是文档、目录等信息的载体而且用户主要通过图标来操作这些对象。请记住：对于大多数用户来说，图标并不是在文件系统中某个位置存放的文件的一个指针――用户认为图标本身即是文件。
注意：现在只有Mac操作系统图标设计指南。而对于Windows以及KDE窗口界面系统的图标设计指南将在以后发布。不过，现在这个指南的某些章节是与平台无关的。
1．桌面的革命
Mac操作系统X（Mac10）的发布带来了全新的桌面图标设计方案。Mac 7已经给大家提供了易于设定的256色图标；Mac8.5给我们提供了8位通道的真彩图标；但是Mac X的128x128大小的缩略图式图标则是一个更大的飞跃。
在某些方面，这个改变又是不太让人容易接受的。因为使用ResEdit软件来一个一个象素绘制图标的年代已经过去，而变成了使用诸如Illustrator或Photoshop这类的大型工具来绘制它们；有些人也可能说那些友好的，让人感到温暖的百分之百的手绘图标的年代已经逝去。但是另一方面，Aqua方案又使得图标变得水晶般透亮而且在大显示器上显示得足够大。谢谢苹果在Aqua人机界面设计方案上所做的努力。相比Mac7或Mac8/9所创建的图标，在软件中使用Aqua图标总的来说会与整个Mac10协调和一致。这最终达到视觉统一的效果。
相比昔日系统中的32x32象素图标的设计来说，创建一个Mac10图标会更难一些。首先图标的面积比以前大了很多，其次表现的细节也比以前要求更高，而且还要确保在低分辨率情况下（甚至到16x16大小条件下）依然显示良好。从而因这些要求使得图标设计更有难度。由于Aqua图标提供了从16x16到128x128范围之间的任意大小的图标，所以图标设计师不能只设计一款128x128，或16x16，或在这范围之内的一个尺寸的图标；图标设计师必须为这个范围内的任意一个大小的方形设计一个图标。为了设计出一款干净、醒目而且易懂的Mac X 的Aqua图标，我们将会在这篇文章里介绍设计师必须要了解的设计哲学和设计概念。
2．基础知识
图1 应用程序图标（左）和文档图标
任意Aqua图标的基础是形状，这是首当其冲的特征。而颜色及图案的差异则是紧随其后的。应用程序图标（图1左）通常是稍微反时针旋转的矩形图片。它们经常含有一些具有标志意义的元素（通常是一个工具，如一支笔或是一把刷子）使得用户知道这个程序大致是干什么的。应用程序图标应该具备一种传递当它们被打开时会发生特定事件的含义。而把产品标题作为图标则是一种不好的选择。
文档图标（图1右）通常与其相关的应用程序（host application）图标在色彩和图案保持类似，但是这些内容应该被一个右上卷边的纸状图案所包围。如果相关的应用程序包含一个工具或标志（如TextEdit的笔或预览用的放大镜），那么文档图标中就应该略去这个工具或标志，以免用户将这两类图标混淆。如果一个文档图标包含有一个徽标例如文件类型的标志符，那么这个徽标就应该完全包含在这个文档图标纸型图案中（如图1是一个好的例子而图3. A是一个不好的例子）。
图2A 一组设计良好的图标
图2B 设计较差的图标
工具条图标设计图案甚至应该更与原始形状接近。如果一行工具图标大体相似则会造成用户使用时混淆。这就是在浏览器工具条中做一个圆形停止浏览图标并且还有一个圆形的刷新箭头图标不好的原因了。就是这个原因，苹果在Mac10中重新设计了一组浏览器工具条图标，它们形状各自相异：计算机图标是矩形的；应用程序图标是三角形的；删除图标是圆形的等等。即是这些图标的颜色属于同一个颜色系列，它们仍然容易区别――相反，在Mac10中的浏览器Chimera中的工具条（图2. B）则缺乏与上述工具条相匹敌的设计。
3. 风格
图3A Mac9 风格，不要这样做
保持Aqua图标的统一风格也是非常重要的。Finder图标（finder icons）应该是具有真实照片感的，但不完全是。在任何情况下图标也不应该是一副照片的缩小版。而且，尽管Aqua图标是3D的，但也不完全是3D的，毕竟我们还要保留图标的基本形状通透（shine through）。Aqua图标中的3D效果应该以我们面对前方稍上的角度来渲染，就像观察者在看一个放置在他（她）前面桌子上的物体一样。
另一方面，工具条图标应该是较简单而且较平面的东西。设计工具条图标时应该较少使用阴影，3D效果。所有工具条图标都应该是正（面直对）视图（或如果可行的话，俯（首向下的）视图）。应用程序图标（如终端或网络工具）也应该是正视图。
值得注意的是Mac10的图标阴影风格也和以往的版本大不一样。与Mac9图标阴影是由光源以左上角度打过来不同的是，Mac10采用正上方光源（即垂直90度）产生的阴影。阴影应该在物体的下方而非侧面（如图3.A就是错误的阴影）。
图3B 无可救药。不要这样做
通常，模仿Aqua窗体控件和按钮等做一个类似风格的图标是错误的想法。不仅此种风格无可救药，而且由于这种样式的窗体控件充斥了系统的每个角落。使用与Aqua界面元素类似的图样也会让用户不能分清楚哪是图标哪是控件。
当我们使用得当的时候，这些珠宝般晶亮的控件会将这些图标衬托得华丽多彩而且过目不忘。不过，如果使用不当，你的图标将被迷失在早已存在的这些Aqua珠宝的汪洋大海之中。特别的，除非是要使用透明和光泽特性表达一种特殊的意义，否则这两个特性总会被排除在图标的设计之外（举例来说如图1. A中预览程序图标中的放大镜）。
4. 优雅的减少细节
图4A 细节逐渐消失
创建Mac10其中一个关键概念便是当创建文件浏览器中使用的图标要让这个图标随着它尺寸的变小让细节逐步消失。说着容易做着难，因为你不知道图标变小后是什么样子，也不知道某些细节在变小后是什么样子，因为图标缩小时某些细节就会被其它细节淹没。在这种情况下，图标总体的形状和颜色就被那些在128x128图标中的局部细节来的更为重要了。创建这种效果的时候，有时也把这个过程叫做“退化细节（receding detail）”，也需要很多尝试，但这最终还是值得的，因为这保证了你的图标在尺寸很小的时候依然可以“容颜依旧”。典型的举例来自程序TextEdit的图标，这个图标包含有一段文字。尽管少量细节丢失了，这个图标的文字块依然在48x48大小的图标中依然存在。不过，图标上页面上的横格细线看不见了。即使在16x16大小（图4. A 最右的图标）图标尺寸最小的情况下这个文字块还是有一个墨色的轮廓依然保留，而最基本的元素信纸及笔依然可以辨认。
5. 采用小图标资源隐藏技术（Take A Hint）
每一个Mac10 Finder图标重要的一点便是除了128x128资源之外还隐藏有一些其它尺寸的图标资源。隐藏图标尺寸有3种：16x16，32x32及48x48。如果图标资源里含有这三种大小的图标并且要显示这三种里某一种大小或近似大小的话，Finder将会使用最接近目标尺寸大小的图标来缩放至目标大小。这种技术加上优雅减少细节（Graceful Degradation）技术，是一种解决细致入微的128x128图标在更小尺寸下显示仍然光彩依旧的好方法。
文档窗口
所有的主流操作环境都是为了一个目的，也就是处理数据即文档。典型的文档窗口的显示方式及操作方式都与其它如状态窗口或警告窗口在内的窗口明显不同。下面的文字就说明了在设计文档处理的过程中要记住的事。
1. 不要使用多文档界面
多文档界面（MDI）的使用在Windows和一些Unix桌面管理系统中可以见到。由于本身就是有缺陷的窗口管理系统，为了解决这些缺陷反而导致了更多的窗口管理问题，所以让很多人吃尽了苦头。MDI其中一个致命缺点便是这个系统限制了窗口的显示区域。而且，MDI造成一个程序管理多个窗口的难题并且剥夺了用户同时在几个应用程序间操作的能力。Mac操作系统X就没有采用MDI，所以它就赋予了用户在程序窗口随意切换的能力，即使是几个不同程序的窗口。你可以在你的系统屏幕的底部开一个IE窗口，在其上再打开一个Word文件。而在这个窗口上面，你还可以打开另一个IE窗口等等。这样用户就可以不用切换到那个程序去看那个程序窗口的内容。这个特性在你将一个网页里的文字拖放到另一个文本文件中感觉尤为顺手。
另一个有趣的事儿便是微软自己的程序就对MDI的使用方式不一致。最新版本的Excel使用了MDI而最新版本的Word却不是这样。这让操作Excel没有操作Word顺手。IE6也没有使用MDI。看起来微软似乎有点在行进中开火的意思（fire and motion），一面规劝第三方使用MDI，而另一方面自己又在逐渐抛弃MDI。
2．提倡添加拖放支持
拖放操作是一种相对简单的手工操作，并且是执行如挪动文本或文件等各种命令的自然方式。添加文档间和程序间的拖放支持是重要的。Windows在这方面却做得不太好。我们本来想通过拖放一个项目来重新安排一下这个项目的位置没想到它却为我们创建了一个快捷方式；本来将这个文档中的文本通过拖放到另一个文档中去应该产生拷贝操作，没想到Windows却弄成剪切操作。当然，文档内的拖放文本的操作应该就是简单的挪动位置而不产生其它操作。
当拖放操作时鼠标按键松开时有一个明确提示是非常重要的。一个好的办法便是在鼠标箭头旁边显示一个状态图标，因为这时候用户正在看着鼠标箭头。同时，在拖放时显示一个虚化的图像也是一个好办法。
请不要对本来没有拖放意义的标准控件添加拖放支持，同时也要禁止用户将数据拖放至没有拖放意义的控件中去。
3．使用标准命令和控件
用户通常习惯于原来操作系统的工作方式，所以发明一个新控件或改变原来控件的工作方式的想法是错误的。不要重新发明*。如果你真的需要一个自定义控件来完成操作，请尽力将其操作方式和整个用户界面的操作方式保持一致。大体来说，你所设计的界面元素只可能是复杂的，很有可能这个操作是太复杂了。
4．避免多级子菜单
子菜单或许是唯一一种难以手工操作的界面元素了，所以在界面设计时如果可能的话一定要尽量避免使用它。多级子菜单是最有问题的，因为鼠标箭头稍一脱离菜单就会造成整个菜单全部消失，所以强迫用户重新在这些菜单中战战兢兢的挪动箭头去找那个隐藏很深的命令。
FirstClass软件（如上图）将非常常用的编辑命令做的如此之难用以致于他们不得不创建一个新的替代方法（如这个图片底端的工具条）（译者注：原图可能有失误）去做这件事。如果可能的话，避免使用子菜单，特别是像上图那些重要的命令更是不要把它们放进子菜单。如果是真的需要的话，也要让它们只有一级。
5．不要劫持计算机
任何一个应用程序相关的操作都不应该让应用程序阻止整个系统的运行；同样，一个文档相关的操作也不应该阻止整个应用程序的运行。这是Mac操作系统X发起的两个标准，这也应该被其它操作系统所遵守。用户不喜欢不停打断他操作的操作系统。诸如与文档相关的警告，信息窗口和保存命令都应该显示在那个文档窗口里面，而不是阻止整个应用程序以至整个系统。
举例来说，既然如一个文字处理系统或文本编辑工具的字数统计功能是与当前打开的这个文档有关，所以这个窗口显示的信息也就只与这个文档有关，所以用户就可以不用关闭它就可以在另外一个文档或程序继续工作。（译者注：目前Microsoft Office Word 2003还没有达到这个要求）
6．鼓励用户探索
不要让用户在使用你的程序时产生对某些命令或特征的使用恐惧心理。尽力提供多级的“撤消”和“重复”命令支持，并且让用户明确知道你对这个操作提供了支持（如果有工具条，将“撤消”和“恢复”放入工具条，并且把这两个命令放进编辑菜单里）。让你的程序能容忍用户的各种操作。
如果一个操作不可恢复，在执行这个命令前要提示用户。允许用户取消这个命令，就像上面这个截图例子一样。
对话框
对话框通常是用来请求用户输入或显示信息的。它们应该尽量少用――仅在这个对话框有充足理由存在的情况下使用。下面是几条关于对话框使用的指导性意见。
1．抛弃“是”“否”回答
经典对话框的缺点是使用“是”和“否”作为对话框按钮的内容。这会强迫用户必须仔细阅读对话框内的内容从而得知他（她）究竟同意还是不同意。请考虑以下的例子，它们分别来自于Windows和Mac操作系统X：
第一个例子不会让用户知道这个对话框是何用途。没有对话框里面文字的提示，用户不可能知道下一步该怎么办。相反，第二个例子用意则非常的明显以致于不需要解释文字用户也知道该怎么做。这两个例子都是来自于标准的系统保存对话框。Mac操作系统使用动词来作为按钮标题，所以它能明确提示用户这个按钮的用途，所以用户甚至不用阅读对话框提示就可以做出选择。
当这个对话框命令不能用动词来表示时，也不要用“是”“否”，而要用“确定（OK）”和“取消（Cancel）”并且让“OK”作为指令执行的动作按钮。如果这个命令或操作会造成数据丢失或破坏，则一定要把“取消（Cancel）作为缺省按钮。
2．要有实质信息，也不要信息过量
如果用户不能理解对话框里的内容，这就意味着是这个对话框设计者的失败。通常情况下，就像标准保存对话框或打开文件对话框那样，所有对话框都应该含有一个用来提问或警告的消息（图标），另外还含有一段附加的描述性文字来提供额外提示譬如“这个操作不可恢复”。你千万不要像下面这个对话框这样做：
这个问题对话框的标题与所提示的信息不符，更糟糕的是没有任何信息告诉用户究竟要“确信”什么（译者注：对话框显示“您确信吗？”的问题，而窗口标题却是“错误”）。
另一方面，不要信息提示过量。不告诉用户要做什么是错误的，而告诉了过多的信息也是错误的。长信息阅读费时不如短信息简明扼要，长信息会有更多的可能性让用户感到厌烦。
3．使用有意义的留空
如果你设计的对话框需要两个以上的按钮或者其它控件，请使用空白来传递特殊的意义，再以本小节1中的例子来说明：
第一个例子完全没有使用空白，按钮之间的距离都是一样的，尽管我们知道这三个按钮点下去造成的后果大不相同。有意思的是，这个会造成数据损失的按钮竟然相当不方便地放在中间。所以，这就造成一种被错误选择的可能性：如果你要点“是（Yes）”的右部，或者“取消（Cancel)”的左边，可手不小心一抖错过了几个象素就点到“否”按钮上了！数据因此而丢失。
而下面的这组按钮就有效的利用了空白。既然对话框中的提示是“您想在关闭文档前保存内容吗？”，所以这些按钮的动作结果和上面的一组一样：“取消”使关闭文档的命令取消；“保存”将保存文档并且关闭；因此“不要保存”按钮是唯一可以造成未保存数据丢失的按钮，所以它和其它两个按钮“取消”和“保存”（它们都不会未保存数据丢失）之间有一个很大的空白。这样的分布保证了让用户偶然错误选择“不要保存”的可能性非常小。
4．用户不是傻瓜
不要剥夺用户保护自己的权利。一些应用程序假设用户存在危险性而让用户在对话框中输入一个消息诸如“Yes”之类的东西才能向下执行从而来保证数据安全。这减慢了用户的操作速度并且让用户感觉这个程序不太好用。每个人都不喜欢别人把自己当作傻瓜。需要键盘输入的需求同样没有考虑这些对键盘操作不太灵便的需要，尽管他们对键盘不太适应可对于鼠标却可以操作。
隐喻
界面通常都需要使用一些隐喻来帮助用户理解和学习如何使用程序。或许最著名的应该是施乐公司帕罗阿尔托研究中心（Xerox PARC）开发的桌面隐喻――苹果使用自己的一些股票换取了在麦金塔什计算机上使用该隐喻的使用权。隐喻可以让用户更加简单地操作系统，但隐喻不当则会削弱程序的易用性。
1．足够真实
设计界面元素时要基于真实世界里的物体，不要使界面元素完全与真实物体无关。直到Mac操作系统8和9，苹果才从一个非常不恰当的隐喻中脱离出来：用户通过将磁盘图标和CD图标拖到垃圾回收站中来弹出磁盘和CD。对于偶然使用苹果系统的人来说很难知道这种方法，并且用户总以为把磁盘图标或CD图标拖到垃圾回收站中去会删去它们的数据。这个隐喻的使用是因为程序员的思维方法：删除文件在某种意义上是将东西扔掉而弹出磁盘则是完全不同。这种意义根本不明显。Mac操作系统后来的版本就将弹出命令变成弹出磁盘的首要命令。Mac操作系统X又前进了一大步：当拖动磁盘图标的时候，垃圾回收站的图标就会变成一个弹出图标。将磁盘拖到弹出磁盘图标上就十分的形象生动了。
2．也不要太真实
如果将一个界面设计得和真实世界完全一致也是不太可取的。应该采用真实世界里简便的使用方法而抛弃那些难用的东西。比如说，真的没有必要像真正的橡皮擦那样痛苦而缓慢的在文本编辑工具中“擦”去文本。相似的，也没有必要像倒垃圾桶那样来清空MaC或Windows里面的垃圾箱。
国际化
国际化的问题的要点不多,最重要的是你不能假设用户所在的国家，这包括他们使用的地址格式、度量衡、小数（十进制数字）分隔符（decimal separators）及甚至图标风格。
1．不要假设用户所处的地方
永远不要强迫用户使用美国使用的地址格式。许多国家并没有“州”的概念。如果强迫用户必须在州的域段里输入一些字符才能允许用户使用这个软件的话，这可能使你的用户放弃使用这个软件。如果你不能支持国际地址格式的话，那么最好提供一个传统的文本框来让用户输入地址。你的用户绝对足够聪明且知道他们自己的地址及其书写格式。
同样的原则使用于小数（十进制数字）分隔符、度量衡、货币符号等等。让这些值变成用户自定义的。当然，更好的办法应该是检测用户使用的操作系统的区域设置，让程序根据它来显示不同的表示方法。即使这样，这些输入值应该还是用户可设置的，因为一个芬兰人可能暂时呆在英国。
2．考虑文化差异
当你的软件要国际化时，请仔细考虑软件的界面元素可能因为文化的差异而被用户错误理解。文化差异范围非常广泛，涉及从不同颜色具有不同的含义到不同的手势在不同文化里表示的意义完全相反等诸如此类的问题。比如说，在西方世界点头表示同意而在某些亚洲国家点头则表示不同意。
在软件的本地化过程中，开发者总是除了对字符串进行翻译而不考虑其它要本地化的东西。比如让图像、动画等等都要顺应当地的风俗习惯。比如说，一个瑞士籍的信件读者可能不习惯使用一个美国风格的邮箱图标作为自己的邮箱图标。同时，一些符号或显示元素甚至被视为文化挑衅。一个典型的例子便是那些需要磁盘引导（disk first utilities）的软件，它们使用十字架符号。对于开发者来说，十字架表示修复和还原，但有些用户则认为这个是耶稣受难的表示（pro-Christian statement）。
3. 使用正确的语言名字
如果可能的话，使用它们本来语言里使用的名字而不是英文名称，无论这是让用户选择界面的语言还是其它你需要知道用户或顾客的母语的地方。这对于用户从语言列表中通过用自己母语表示的母语名字特别有意义。这不仅让用户更容易的发现自己的母语名字而且特别是在那些不是以拉丁字母排序的语言如日语和中文的列表中能加快选择速度。或许你还想在这些以母语表示各自的语言名字旁边还显示一列英语名字，比如说，苹果就在Mac操作系统X中的语言选择列表中使用标签来显示其对应的英语名字（如下图）。
二义性
在使用计算机的时候，用户会随时改变软件设置。所以软件的命令和文档不能有二义性表述。
总是使用肯定的语言表达方式
如上图所示，菜单项“Use Logging（写日志）”命令的结果可能有两种方案：一种使菜单项打勾，一种让菜单项改成否定的描述（如下图所示）。而对于程序实现者或者用户界面设计者来说，如果实践经验不足，则这两种方案似乎都是可行的。这样，采取哪一种方案就随当时的心情了。
而问题主要出在这儿：如果脱离上下文环境，命令“Don’t Use Logging（不要产生日志）”既可以认为是当前状态的表示，也可以认为是当这个命令被执行后产生的结果。所以这个菜单标题不能说明当前是否在写日志的状态。因而只有你执行了这个菜单之后你才有可能搞明白这个菜单究竟是什么意思。当然，这有可能导致不可预知的问题甚至造成破坏性的结果。
否定性质的标题是产生二义性的根本原因。这会让用户对你以及程序失去信任。所以一定要使用肯定性的命令和状态描述。不要说“不要产生日志”而要说“关闭日志功能”；不要说“不要使用小写字母”而要说“使用大写字母”。要让你的用户习惯于查看菜单项是否打勾。使用复选框控件而不要使用按钮按下去的状态来表示否定。