1? 总体原则
? 以用户为中心。设计由用户控制的界面，而不是界面控制用户。
? 清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，

且易于理解

? 拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，
来帮助用户能迅速学会软件的使用。

? 较快的响应速度。

? 简单且美观。

2?? 原则详述

2.1 用户控制

用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控

制。

操作上假设是用户–而不是计算机或软件–开始动作。用户扮演主动角色，而不是扮演

被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任

务。

提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面

的某些方面。Windows 为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属

性–例如颜色、字体或其他选项的用户设置。

采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用”非模式”辅助窗口。

“模式”是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当{zh0}使用一

个模式或该模式只是可替换的设计时–例如，用于在一个绘图程序中选定一个特定感觉–请

确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。

在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能

被改变，用户也应该可以最小化该窗口。

谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互

式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如

果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。

这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选

定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它

还包容潜在的用户错误，并且使用户易于还原。

2.2 清楚一致的设计

一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力

集中在任务上。这是因为他们不必花时间来尝试记住交互中的不同。通过提供一种稳定的感
———————– Page 5———————–

觉，一致使得界面熟悉而又可预测。一致在界面的所有方面都是很重要的，包括命令的名称、

信息的可视表示，操作行为，以及元素在屏幕和窗口内部的放置。

相同含义的词使用统一的术语。比如对于仓库中存放的物料，不可同时又称为物品、货

物、备品、产品和材料等等，而统一约定一个称谓，且此称谓是用户熟悉的和易于理解的。

使用一组一致的命令和界面来展示常见功能。例如，避免一个”复制”命令在一种情况下立刻

执行一个操作，但在另一种情况显示一个对话框要求用户键入目标然后才执行。应该使用同

样的命令来执行对用户来说相似的功能。

操作环境内的一致。保持Windows? 提供的交互操作和界面约定之间的高度一致，用户

将能很快熟悉软件的使用。

使用隐喻的一致性。如果一个特定的行为更多的是一个不同的事物的特征，而不是它的

隐喻的含义，那么用户可能在学习将行为和该事物相关联时遇到困难。例如，对于放在回收

站中的对象而言，焚烧炉和废纸箩代表不同的模型。

建立项目保留字。通过建立保留字来明确和统一术语和操作命令。

提供可视反馈。在后台运行长进程时（时间超过1～10 秒，视具体情况而定），必须提

供进度条等信息指示。

除非特别必要时，不要提供声音反馈。在有严重的问题发生时，可以使用声音来提示用

户，但是通常应该允许用户取消声音。

保持文字内容清楚。信息的表达要言简意赅，易于理解而又不罗嗦；避免使用冗长的文

字给用户反馈。

2.3 有良好的直觉特征

用熟悉的隐喻为用户的任务提供直接而直观的界面。通过允许用户利用他们的知识和经

验，隐喻使得预测和学习基于软件的表示的行为更加容易。

在使用隐喻时，不需要将基于计算机的实现局限在真实世界的对应物上范围之内。例如，

与其基于纸张的对应物不同，Windows 桌面上的文件夹可以被用来组织各种对象，例如打印

机、计算器、以及其他文件夹。同样，Windows 文件夹可以其真实世界对应物不可能的方式

被排序。在界面中使用隐喻的目的是提供一个认知的桥梁；隐喻并不以其自身为最终目的。

隐喻支持用户认知而不是记忆。用户记起与一个熟悉的事物相关联的意义要比他们记起一个

特定命令的名称要容易得多。

同常见软件保持一致性。出色的用户界面在程序中将实现同用户以前用过的其它成功软

件一致的动作。

2.4 较快的响应速度

保持界面能很快对用户操作作出反应。

提供快捷键。特别对于有大量录入项的界面，能让用户不使用鼠标即可完成快速数据录

入。在用户界面中加入一些功能，这些功能可以让熟练用户在不同的区域快速的输入数据。

这些功能包括重复功能、快捷键、带有有意义的图标的按钮等等，所有这些可以使速度快的

用户可以控制界面并加快数据的输入。

除非必要，不要重绘屏幕。
———————– Page 6———————–

2.5 简单且美观

简单。界面应该很简单（不是过分单纯化）、易于学习、并且易于使用。它还必须提供

对应用程序的所有功能的访问。在界面中，扩大功能和保持简单是相互矛盾的。一个有效的

设计应该平衡这些目标。支持简单性的一种方法是将信息的表示减少到进行充分交流所需的

最少信息。例如，避免命令名和消息的文字描述。不相关或冗长的句子扰乱了您的设计，使

得用户难以很容易地提取重要信息。另一个设计简单而有用的界面的方法是使用自然的映射

和语意。界面元素的排列和表示影响它们的意义和关联。简单还与熟悉相互关联。熟悉的事

物通常似乎更简单。尽可能尝试建立利用用户已有的知识和经历的联系。您可以使用渐进揭

示来帮助用户管理复杂的事物。”渐进揭示”涉及到仔细的信息组织，以便只在恰当的时候才

显示信息。通过隐藏向用户表达的信息，您减少了用户必须处理的信息数量。例如，您可以

使用菜单来显示操作或选择的列表，还可以使用对话框来显示一组选项。渐进揭示并不意味

着对显示信息使用非传统的技术，例如需要一个修饰键作为访问基本功能的{wy}方法，或者

强迫用户通过一个更长的分级交互序列。这会使用户界面更加复杂和麻烦。

美观。可视设计是应用程序界面的重要部分。可视属性提供了非常好的印象，并传达特

定对象的交互行为的重要线索。同时，出现在屏幕上的每一个可视元素也是很重要的，它们

可能竞争用户的注意。提供清楚地促进用户对表达的信息的理解的连贯环境。图形或可视设

计器的技巧对于这一方面是无价的。

3 细节约定

3.1 界面风格

3.1.1 普通外观

使用一致性

一致的。

使用安排和流程

读，因此，应该将重要信息放在上面和左边。左上角最容易吸引起人们的注意力。

使用对齐

小数点对齐或右对齐。对于非数值文本，应该避免使用右对齐或居中对齐。不必对什么都使

用中间对齐，或者使它们保持对称形式。在右边或底部保留空白区域更适合习惯。

使用分组

关信息。将控件放在它所作用的对象旁。使用空格、分组框、线条和标签，或者其它分隔符

对用户界面控件进行分组。

使用强调????????????????????????????????????? /禁用、大小、颜色或者字体等，来将

注意力集中在需要首先看到的用户界面控件上。尽量以可视的方式指明用户接下来应该进行

的操作。

使用可视的提示

同的大小和间距来指出用户界面控件视是不同的。
———————– Page 7———————–

使用空格???????????????????? 个”透气室”，以使窗口布局更易于理解，并且查看起来更

舒服。空格的多少要适当，不要显得太分散。但是，要避免过多地使用空格。如果可能，尽

量使窗口小一些。

警惕空洞???????????????????? 或产品的名称及徽标。虽然在启动屏或”关于”框中出现公

司或产品名称及徽标是xx可以接受的，但其他窗口中的可用空间应该出现其他内容。如果

没有其他内容，那么应尽量使窗口小一些。

注意大小

GetGystemMetrics API 函数）或文本规格（使用GetTextMetrics 或GetTextExtentPoint32 API

函数）来确定用户界面控件的大小。任何显示文本的对象（如对话框或定义的文本文档）都

应该使用文本规格。

考虑使用资源或预定义的布局网格

窗口之间实现一致性。

注意：下页所示图的第二个对话框，与{dy}个不同，它有一个紧凑、从左到右、从上到

下的流程，并且，左对齐的标签很便于浏览；通过对齐编辑框并调整其大小，使它显得更有

组织，更加平衡。

3.1.2Windows 的可视提示

暗示与用户只需通过查看可视提示来确定对象的使用方式的能力有关。在Windows 中，

请保持使用下面的可视提示：

? 可以单击凸起的项目。

? 可以单击当鼠标从其上移过时突出显示的项目。

? 不能单击下凹的项目。

? 可以编辑具有白色背景和闪烁垂直条（光标）的项目。

? 不能编辑具有灰色背景的项目。

? 灰色项目是被禁用的。

? 可以拖动凸起的项目。

3.1.3 交互

尽量提供对所有功能的键盘访问

功能都应该只能通过键盘来访问。

尽量提供对所有功能的鼠标访问

只能通过鼠标来访问。

确保具有明显后果的操作要求用户进行明确的选择*??????????????????????????? 要xx明确他将要进行危

险性操作或破坏性操作。

对于使有耗时的操作都给出反馈*

表或其他的可视反馈。用户应该能够取消长时间的操作。如果可以取消未完成的操作，那么

将按钮标记为”取消”，否则将按钮标记为”停止”。

可视的指示模式*

通过更改光标或标题栏文本来做到这一点。

确保单击和双击的一致性*
———————– Page 8———————–

换句话说，双击（在列表框、组合框，或其他接受双击的控件中）的效果应该与选定控件中

的一个项目，然后按下Enter 键的效果一样。

鼠标右键仅用于快捷菜单*

不要使用鼠标中键*????????????????????????????????????????????? “控制面板”中的”鼠标”实用

程序自己分配中键的行为。

保持分配的快捷键的一致性????????????????????????? Ctr 键用于快捷键。习惯上不将At 键用于

组合键，业务At 键常常被用于访问键。尽量避免使用At 键和Ctr 键，因为这种组合会使快

捷键非常麻烦，而且也很不方便。

将快捷键作为补充方式*

更多的明显选择。

避免水平滚动条

来比较困难。解决的办法有：尽量使用垂直滚动条、加宽窗口、减小文本的宽度，或者使文

本自动换行等。当然，如果确实需要，还可以使用水平滚动条。

3.1.4 程序

只有主程序窗口才有标题栏图标、菜单栏、工具栏和状态栏*???????????????????????????? 为单击主窗口的任务

栏按钮也会xx二级窗口，所以二级窗口{jd1}不要显示在任务栏中。二级窗口不要因为使用

菜单栏、工具栏或状态栏而使其变得复杂。可以使用标题栏图标来明显区分主窗口和二级窗

口。另外，{jd1}不要使用默认的Windows? 图标(飘动的窗口图标)作为窗口图标。

简化默认配置

应用程序应该使用多文档界面（MDI ）或单文档（SDI）

序的使用模式匹配。

默认情况下，应用程序应该保持为{zd0}化

用户的工作效率。

实用程序应该使用SDI 或对话框界面

对于实用程序，建议不要使用MDI 界面，因为管理这些窗口需要付出很多努力。

实用程序应该在小屏幕范围内运行

在小屏幕范围内运行。实用程序应该有灵活的窗口布局，以适应多种不同的大小。实用程序

很少以{zd0}化的形式运行。

使用实际文档的SDI 程序必须支持运行多个实例*

多个文档。

使用”退出”命令终止程序?????????????? “退出”终止程序；使用”关闭”移走主窗口和非模式对话

框；使用”取消”移走模式对话框。当关闭主窗口并不表示终止进程时，对于主窗口使用”关

闭”来代替使用”退出”。例如：关闭打印机状态窗口不会取消打印任务。

3.1.5 默认

保存和恢复用户选择????????????????????????????????????????????????? MDI? 程序应该能

够恢复文档窗口的大小和位置。对话框通常应该使用{zh1}输入的值作为默认值。

提供适当的默认值

成工作。提供最可能使用并给出设置实际使用方式的默认值。通常，{zh0}的默认值是用户最

后输入的值。
———————– Page 9———————–

考虑选择默认值时的安全性*

使用令用户感到莫名其妙的默认值。

3.1.6 窗体

对话框窗体大小尽量不要超过640*460，留20 给任务栏。并且高和宽（或W 宽和高）

的比应该大致保持为 3:4???????????? （或4 ：3 ）。一般应该将窗体的”Position” 属性定义为

“poDesktopCenter”，”WindowState”属性为”wsNorma”，某些主界面设置为”wsMaximized”。

“ShowHint”属性设为”True”。如果是模式对话框，则将”BorderStye”属性设置为”bsDiaog”。

窗体文件(*.dfm)保存为文本格式，以便在VSS? 中比较不同版本之间的差别。如果窗体大小

超过屏幕大小，则在Dephi 开发环境中打开时，大小会有改变，并且影响到运行时刻效果。

由于每个人的屏幕大小设置不一样，有些是1024*768，有些是800*600，因此在设计期间请

注意窗体大小，尽量不要超过800*600，以免出现上述问题。

3.1.7 布局和间距

窗体控件布局和间距尽量保持与Windows? 标准一致。控件与窗体的上、下、左、右边

距为7 象素。右下角xx令按钮之间的间距为6 象素，如果xx令按钮在右上角，之间的间

距则为4 象素。xx令按钮一般情况为75 ×21 象素，如果按钮的文本很长，应该适当加宽

按钮的宽度。如下图。其它详细资料请xx参照错误！书签自引用无效。和命令按钮。

控件的”TabOrder”属性值应该与控件排列顺序一致，即遵循从上到下、从左到右这样一

个流程。如果在PageContro??????? 的多个页面中存在类似的控件，应该尽量使得它们在各个页面

中出现的位置/大小比较一致，以免在页面间切换时产生闪烁感。

3.1.8 图标、图片

不同界面中的同一功能应该使用同样的图标和图片。图标、图片的色调、风格尽量保持

一致。图标、图片的隐喻应能确切表示功能的含义，如果不能，就直接使用文本，以免混淆

用户。如果功能是一个动作时，可能比较难找到确切表示该功能的图标，这时应该尽量采用

此动作相关的名词做图标。例如Windows? 中的”剪切”功能就是用一把剪刀来表示的。

3.1.9 提示信息（Hint）

工具栏按钮应该设置工具提示 “Hint”? 属性。Hint 能帮助用户更方便地理解和使用。详

细资料可以参照工具栏、工具提示。

如果使用了”TSpeedButton”控件，并且只有图标，同样应对它设置”Hint”属性。如果不

是特殊情况，应尽量避免使用”TSpeedButton”控件，而使用”TButton”控件代替。

3.1.10 标点符号

在标识控件用途的标签文本（abe ）和提示信息（Hint ）中，应使用半角符号。如果是
———————– Page 10———————–

指导性标签文本（如解释按钮功能的句子），则使用全角符号，并且句子应遵循中文标点符

号标准。如下图Microsoft 标准对话框例子。其他详细资料可参照静态文本。

3.1.11 对话框

对话框应该在所有视频模式下都能够正确显示???????????????????????? VGA 模式（640×480）下显示时，

对话框应该不超过640×460????????? （留20 像素给任务栏）。这将确保对话框能够显示在所有的视

频模式下。

确保模式对话框的模式*

柄，而不时提供NU 句柄。如果没有提供父窗口句柄，那么父窗口仍处于活动状态，因此该

对话框实际上并不是模式对话框。

不要使用可滚动的对话框*

这种对话框使用起来非常不方便，并且也时xx不必要的。应该重新设计这种对话框。

不要在作为二级窗口的对话框中使用菜单栏*

意，在用作主窗口的对话框（如”查找”实用工具）中，菜单栏时可以接受的。还要注意的是，

在所有对话框中，快捷菜单和菜单按钮都是可以接受的。

二级对话框不要使用菜单栏，但可以使用菜单按钮。

不要在作为二级窗口的对话框中使用标题栏图标*???????????????????????????????????? 别主窗口和二级

窗口。

不要在任务栏上显示作为二级窗口的对话框*

xx二级窗口。

对话框中使用下页图所示的页面布局和间距。

对于相似的对话框，使用控件位置来强调其相似性。

如果意义相同的同一控件出现在一些相似的对话框中，那么它应该显示在相同的位置。

另一方面，应避免将可能会产生混淆的不同控件放在同一位置。

对非模式对话框{zh0}使用可停放的对话框

等效的，但其位置设置更为灵活。

策略地设置输入焦点????????????????????? 焦点设置在最可能首先使用的控件上。

在对话框标题文本中不要出现省略号?????????????????????????????? “打印选项…”命令结果而显示地

对话框的标题应该为”对于选项”。但是，表示命令正在执行过程中菜单对话框（如”连接到

Internet…”对话框）是一种例外情况。

为所有可处理访问键的控件分配访问键*

使访问程序更加方便。您可以直接在其标题中为诸如命令按钮、单选按钮、复选框等控件分

配访问键。通过提供静态文本标签或带有访问键、在Tab 顺序上先于控件的组框，您可以为

诸如编辑框、列表框、组合框等控件分配访问键。在其他情况下不要为组框分配访问键–这

会使人产生混淆。”确定”按钮没有访问键，因为在作为默认按钮时，它通过提Enter 键来选

定的。”取消”按钮也没有访问键，因为Esc 键预览xx模式对话框。如果可能，避免使用小

写的g、j 、p、q 或y 作访问键，也避免使用这些字母前后的字母作为访问键。下划线不能

与这些字母的下行字母分开。当然，访问键必须是{wy}的。

避免使用粗体文本?????????????????????????????? Windows 3.1 的对话框中，粗体文本用于

在旧式的视频硬件上绘制被禁用的文本（即抖动的灰色文本）。因为现在的视频硬件可以绘

制没有抖动的灰色文本，所以 Windows????????????? 为了使外观更加清洁，现在Windows???????????? 在对话框中

使用正常文本。粗体文本仅用于强调。对于大多数对话框不要粗体文本。

提供环境敏感的帮助
———————– Page 11———————–

过帮助按钮或F1 键访问），或者为个别控件提供控件特定的帮助（通过”这是什么？”按钮或

Shift＋F1? 键来访问），或者同时提供这两种帮助。

3.1.12 对话框的主要命令按钮

将xx令按钮与对话框主体分开*?????????????????????????????? “确定”、”取消”、”关闭”、”帮助”、

“停止”、”隐藏”，以及其他相关按钮的等命令按钮。这种分开使xx令按钮更易于查找和识

别。

认真选择对话框的方向

此，将xx令按钮靠底部或右边放置更容易被发现。您应该选择对话框的外观比例与屏幕的

外观比例（通常高与宽的比例为3：4）相似的方向。这将使对话框的外观看起来更加舒服，

并且更易于在屏幕上进行定位。如果按钮具有不同的大小，那么可以将它们放在对话框菜单

底部。当不能确定时，也可以将按钮放在底部，因为这种定位方式最为常见，也更易于阅读。

将排列在底部的xx令按钮右对齐

个xx令按钮时，您或许希望例外地将其居中放置。

右对齐xx令按钮

避免使用多行或多列的xx令按钮

有许多xx令按钮，那么注意，通常在右边排成一列与在底部排成一行相比可以放置更多的

按钮。另外，您可以考虑使用命令菜单。如果必须使用很多按钮，那么注意使用多行别使用

多列的效果好。

对模式对话框，通常提供”确定”和”取消”按钮*

识别前进（使用”确定”按钮）和后退（使用”取消”按钮）的方式。您可以使用更明确的按钮

代替”确定”按钮，但{jd1}不要在模式对话框中替换”取消”按钮，除非用”停止”来表明正在进

行的操作无法取消。

对于非模式对话框或或作为主窗口的对话框，提供”关闭”按钮而不提供”确定”和”取消”

按钮*将”确定”和”取消”按钮用于非模式对话框或作为主窗口的对话框可以使对话框看起来

像是模式对话框。而且，当用于非模式环境中时，”确定”和”取消”时没有什么意义的。使用

“关闭”按钮可以xx这种混淆。

通常将”确定”按钮排{dy}，”取消”其次，”帮助”{zh1}*?????????????????? “确定”或其等价按钮通常作为第

一个xx令按钮。”取消”按钮应该位于”确定”的右边或下面。将”确定”和”取消”按钮放在一

起。”帮助”按钮应该时{zh1}一个按钮。如果没有”确定”按钮，那么应该将”取消”按钮放在”

帮助”按钮的前面。这可以使xx令按钮更易于查找和识别。

确保”取消”按钮真正用于取消操作*

对话框xx相同。如果不是这样，那么应该用”停止”按钮来代替”取消”按钮。模式对话框中

的”取消”按钮应该与标题栏中的”关闭”按钮效果相同。而属性表是个例外，因为”取消”按钮

不会取消已经应用的更改。

3.1.13 属性表和属性页

让属性页独立工作

发现属性页之间的这种独立关系。在属性页的使用顺序方面应该没有限止。用户应该能够随

时查看任意的属性页。

属性页的布局相互独立
———————– Page 12———————–

性页应该与{zd0}的属性页的布局的格式方式不同，因为将会产生额外的空间（见下图）。

属性页的布局保持独立，避免居中。

用属性表代替使用带选项卡的对话框

有一致性之外，没有什么明显的实用性优势。另外，对于实际显示对象属性的对话框使用属

性表，而对于其他用途，所有带选项卡的对话框。

对属性显示总采用属性表，即使仅有一个页*

属性而不是一般的对话框。属性表有一个”应用”按钮来帮助用户测试设置。

{jd1}不要使用两行以上的标签*

就太多了，可用级连属性设置或多个对话框代替。

总为属性提供”应用”按钮???????????????? 次，提供”应用”按钮帮助用户对设置进行测试。

对显示属性的属性表总是在其标题中写上”属性”一词和对象的名称*

属性表都是用来显示属性的。

总将命令按钮放在右边*

适用于单个页的命令按钮必须置于该标签页的里面。

3.1.14? 向导

对高级的、复杂的或不常用的任务使用向导

省去了用户许多麻烦的操作。当向导用于不常用的任务时，其效果{zh0}。对常用任务使用向

导则显得大而不当。

3.1.15 控件

尽量采用标准控件???????????????????????????? 6 个最早的控件和新的Win32 常用控件）。

采用非标准控件的程序与绝大多数Windows? 程序看起来不一致。只用xx合理时才使用自

定义控件。

定制标准控件时要小心

错的地方。

将无效控件置为不可用*

取消不必要滚动条

3.1.16 命令按钮

采用最小的宽度和标准的高度????????????????????????????????????? 50 个对话单位（75 个像素

点）的最小宽度、14? 个对话单位(21? 个像素点)的标准高度。尽量将不同大小的带文字命令

按钮的个数控制在两个以内。对父窗口拖动（owner-draw）按钮或无文字的按钮（如”…”），

其大小可以任意设置，原则是使命令按钮外观简朴一致。高度大于 14 个对话单位(21? 个像

素点)的按钮看起来不够专业。尽管不限制命令按钮的{zd0}宽度，但宽度超过200 个对话单

位的按钮使不妥当的。请参阅下图所示关于命令按钮的实例。

针对国际化适当加宽按钮???????????????? 50 个对话单位（75 个像素点）的宽度是适合英语文字

的最小宽度，但对需要针对其他语言进行本地化的程序来说，可能就太小了。对于需要翻译

为其他语言的程序，将命令按钮的最小宽度定为60 个对话单位可能更适合。
———————– Page 13———————–

将无效按钮置为不可用，以取消报错*

总采用省略号来表示需要更多信息*????????????????????????????? 表示执行命令时需要更多信息，而不

是简单的确认。省略号并不表示一定会出现对话框。

{jd1}不要指定双击行为*

行为。

命令按钮大小使用Window 标准75×21 象素。一般情况下，”确定”和”取消”按钮的属性

设置如下：

btnOk: TButton

Caption = ‘确定’

Defaut = True

ModaResut = mrOk

end

object btnCance: TButton

Cance = True

Caption = ‘取消’

ModaResut = mrCance

End

“确定”和”取消”按钮一般被映射为Enter 键和Esc 键，因此不应该对它们指定访问键，

除此以外的命令按钮都应该指定一个访问键。

3.1.17 复选框

用复选框开关选项，用单选按钮改变模式*

但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选框来表示是

否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，对横向和

纵向模式应该用一组单选按钮代替。

避免一组复选框中选项个数超过 8? 个??????????????????????????????????????????? 用的空间更

少，但复选框列表需要滚动时使用就稍稍麻烦了。尽管控件足够或保持与同一窗口中其他复

选框一致时，采用复选框时可取的，但大于8 个左右的复选框就未免太多了。

考虑将修改组的复选框置于应该分组框中

显。

宁可竖向对齐

对齐的一组复选框更易于浏览。

3.1.18 单选按钮

避免一组单选按钮中的选项个数超过8 个

更少，但要记住控件使用更麻烦些。尽管控件足够或保持与同一窗口中其他单选按钮一致时，

采用单选按钮是可取的，但多于8 个的单选按钮未免太多了。

避免使用单选按钮进行开/??????????? 关或是/??? 否选择

总将单选按钮置于一个分组框中*

使选择更为明确。

宁可竖向对齐
———————– Page 14———————–

对齐的一组单选按钮更易于浏览。

3.1.19 组合框

总给组合框提供一个标签*

使组合框的下拉列表最少有5 行长?????????????????? 5 行的列表就没有可用的滑块，不易于滚动。

请注意，如果组合框没有足够的列项来填满列表，那么将自动缩短列表的长度。

避免组合框的列项少于4

如果空间更为重要或为了保持与同一窗口中的其它组合框一致时，采用组合框则更为可取。

3.1.20 编辑框

总给编辑框提供一个标签*

签文字与编辑框文本垂直对齐。

避免有输入限制的编辑框

字的编辑。对于输入受限的情况，使用其他的控件，如组合框、列表、滑块和微调框。对于

日期和时间，使用日期和时间拾取控件。

用微调框和浏览按钮使编辑框可视

户在编辑框中进行有效的输入。避免让用户必须输入。仅对数字编采用带微调框的编辑框，

对于文本，使用组合框代替。

按期望输入来设置编辑框的宽度

用户是输入地址，两个字符宽的State 字段明显暗示用户输入两个字符的州名缩写。如果期

望的输入没有特别的大小，就选择与其他编辑框或控件一致的宽度。

总采用数字编辑框用于数字输入*

任何出错消息。

3.1.21 滑块

总给滑块提供一个标签*

低值意义和当前选择的标签–当然都不带冒号。

3.1.22 静态文本

左对齐静态文本标签

宁可将静态文本标签置于相关控件的左边，而不是上面

现，且方便了标签和控件的浏览。很明显，长控件是例外情况，如列表视图、树形视图（Tree）

和多行编辑框。

总在用于标识控件的静态文本标签后带上冒号*

本。为控件提供附加信息的标签不应该有冒号，如用来解释滑块控件的标签。标签也可作为

屏幕读出器的输入信息。

对非标签文本总用只读编辑框*??????????????????????????????? 户将文本复制到剪贴板上，并在

文本比控件长时可进行滚动。
———————– Page 15———————–

不要把静态文本置于凸起的边界上*

会试图单击它。

3.1.23 列表框

总给列表框提供一个标签*

使列表框至少5 行长????????????? 5 行的列表没有滑块，不便于滚动。如果列表框没有滚动条，

那么使用一个更短的列表框也是可以接受的。

对多个选择考虑采用复选框

选框列表，那么可以采用多选列表，并用静态文本表示选项个数，清楚指明可进行多项选择。

对多选列表考虑提供”全部选中”和”全部取消选中”命令

常见的事情，所以这两个命令方便了用户进行多项选择。

3.1.24 列表视图

总给列表视图提供一个标签*

使列表视图至少5 行长?????????????? 5 行的列表视图没有滑块，不便于滚动。如果列表视图没

有滚动条，那么使用一个更短的列表视图也是可以接受的。

仅在列表可排序时采用可单击的表头*

正序对列表进行排序，而第二次单击时按反序进行排列。

对列项大约超过 30??????? 的列表视图总使其可进行排序*

对信息的查找。

3.1.25 滚动条

滚动条仅用于滚动*

使滚动条足够长，保证有可用的滑块。

3.1.26 分组框

利用分组框分组相关控件

件的分组。避免使用只有一个控件的分组框，除非是为了保持与同一对话框中其他分组框一

致。

考虑采用静态线或文本标签来代替分组框

的话，一个替代分组控件的好办法是同时采用静态文本标签和静态线。

考虑采用静态文本标签和静态线代替分组框

不要在分组框标签的后面使用冒号*

且让人糊涂。
———————– Page 16———————–

3.1.27 菜单

总用单个单词作为菜单标题*

不要在菜单栏的文本间留有空隙*

避免占多行的菜单栏*

要避免正常使用时因菜单项都而占用几行的菜单栏。

保持菜单稳定*???????????????????????????????????????????? 但是，对整个程序实例都

无效的菜单，就应该删除。

合理安排菜单项的顺序

而不重要的菜单则位于菜单的底部。

将无效菜单置为不可用来代替报错*

分配访问键*

可能避免用小写字母g、j 、p、q、y 或单词中与它们靠近的字母来分配访问键，因为下划线

与下一行的字母不好区分。当然，一个菜单中的访问键应该是{wy}的。

总采用省略号来表示需要更多信息*??????????????????????????? 号表示执行时需要更多的信息，而

不是简单确认。省略号不表示一定有对话框出现。

使用标准菜单???????????????? “文件”、”编辑”和”帮助”菜单。由于这些是标准菜单，所以

用户会期望它们出现。例如，期望在”文件”菜单中发现像”打印”和”退出”这样的命令，虽然

这些命令可能与”文件”无关。同样，用户期望在”编辑”菜单中发现”剪切”、”复制”和”粘贴”

命令，至少要在”帮助”菜单中发现”关于”命令。

统一放置”查找”和”选项”命令?????????????? “查找”命令放在”编辑”菜单中，而有”工具”菜单时，

总将”选项”置于其中，否则置于”查看”菜单中。

用复选标记来开关选项，用单选组来改变模式*

效的，但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选标记

来表示是否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，

对横向和纵向模式应该用一个单选组来代替。

不要使用多列的下拉菜单*

不要使用”Bang”? （爆炸的声音）菜单*??????????? Bang 菜单是菜单栏上那些看起来像下拉菜单，

但实际是选择后立即执行的命令，如”退出” ！显然，用户希望菜单标题就只是菜单，而不是

命令。

不要右对齐菜单标题*

3.1.28 上下文菜单

考虑将上下文菜单作为冗余使用

下文菜单中的命令应该在菜单栏中也提供，使用上下文菜单是为了提高访问效率。

避免在上下文菜单中包含快捷键

问是通过鼠标进行，而不是通过键盘。

3.1.29 工具栏

保持工具栏稳定*??????????????????????????????????????????? 将它删除。但是，应该考
———————– Page 17———————–

虑删除用户进入一种模式用不到的整个工具栏。

将无效命令置为不可用，而不是报错*

对实用程序采用大工具栏按钮

钮更简朴，更大。实用程序工具栏应该只包含几个带有描述性文字和图形的显眼命令。

对应用程序采用可移动的、可定制的工具栏，而对实用程序采用固定的工具栏

序需要灵活的工具栏来支持其典型的使用方式。用户使用实用程序的时间一般不长，因而不

需要定制工具栏。

提供显示或隐藏工具栏选项

总使用工具提示*????????? 具提示帮助用户了解工具栏按钮的作用。

3.1.30 工具提示

用工具栏的工具提示来提供信息，但要简短

来表示执行命令时需要更多信息。如果该命令已分配有快捷键，则显示该快捷键。

使工具提示文本成为高级用户的媒介

学。

用工具提示显示有用信息

用户提供有用信息。但不可滥用–工具提示太多也就失去了其价值。不要对命令按钮会静态

文本这样的控件使用工具提示。

不要自动消去包含许多文字的工具栏提示?????????????????????????? 10? 秒种后工具提示将自动消去。

如果工具提示的文字很多，10 秒钟对用户来说就看不完了。

3.1.31 文本

避免不必要的缩写词

写词使文本不易理解。

避免不必要的大写字母文本

的单词，这样的单词看起来像在冲用户大喊大叫一样。

避免复杂的标号

分号、感叹号、圆括号、括号，等等。

采用一致的大小写规则*???????????????????????? 单、命令按钮、列标题属性页选项卡以及工

具栏提示文字采用与书题一样的大小写规则，而对于标题、单选按钮、复选框、分组框和菜

单项帮助中的文本采用与句子一致的大小写规则。（对于标题，除了不是标题开头和结尾的

冠词和介词外，每个单词的{dy}个字母大小。对于句子，每个句子的{dy}个单词以及通常大

写的单词–如专有名词的首字母大写。）

避免不好的背景??????????????????????? 颜色适中的背景上，确保在文本和背景之间存在良

好的对比。

避免冒犯性语言????????????????????????? fata? （致命的）、execute? （执行）、ki?? （杀死、毁

掉）、terminate （终止）、和abort??? （中止）。
———————– Page 18———————–

3.1.32 消息框

仔细选择消息框的类型???????????????? “确定”按钮的信息消息框向用户提供有关命令结果的

信息。采用带”是”、”否”，以及可能”取消”按钮的警告消息框在继续进行前需要用户输入的

情形下告诫用户。采用危急消息框通知用户进行工作前需要修改一个错误。

不要使用疑问消息框类型*

（MB_ICONQUESTION ），因为它在Windows98 后一致用来表示上下文修改帮助。

避免不必要的消息框??????????????????????????????????????????? 用来报告不正常或不期

望的结果。不要对很容易恢复的操作进行确认。

问用是/否回答的问题?????????????????????????? “是”和”否”按钮代替”确定”和”取消”按钮，

这样使问题易于理解。与对话框中不一样，”确定”和”取消”按钮很少同时用在消息框中。

确保消息框选项按钮与文本一致????????????????????????? “是”和”否”来作为非提问消息的响应。

同样，不要使用多个效果相同的选项按钮。例如，除非有不同的操作结果，否则不要同时提

供”否”和”取消”按钮。”否”按钮应该执行操作，而”取消”应该取消操作。

仔细选择默认按钮??????????????????????????? 选项作为默认按钮。

避免无用的帮助?????????????????????????????????????????????? “帮助”按钮。不要附加

带无用帮助信息的没意义的消息框。

对危急错误考虑采用系统模式消息框

成破坏性的、急需注意的错误。系统消息框除了有WS_EX_TOPMOST 样式外，与应用程序

模式对话框xx一样。与在16 位Windows 中不一样的是，系统模式不影响用户与其他程序

的交互。

3.1.33 错误消息

避免错误号

避免责怪用户???????????????? 消息文字中出现单词you???????? （你）或your? （你的）。如果需要，

当指用户操作时使用被动语气。采用与”错误发生了”等价的表达，比采用与”你捅漏子了”等

价的表达要好得多。

避免敌对性语言??????????????????????????????????? bad （糟糕的、坏的）、caution????? （小

心）、error （错误）、fata? （致命的）、iega???? （非法）、invaid? （无效）和warning???? （警告），而应

该使用更具体的描述性词语。并且应该尽量解释到底是什么出了错。

在出错消息文字中使用平实的语句

则不要使用全部大写的单词，那样的单词看起来像在冲用户大喊大叫一样。使用完整的句子

和一般的现在或过去时态。避免缩写词。

避免在用户错误消息文字中装做有趣或高人一等

默并不能被广泛接受。

允许用户压制非危急的错误消息

误消息的选项。

3.1.34 字体

字体统一使用以下设置：
———————– Page 19———————–

Charset = GB2312_CHARSET

Name = ‘宋体’

Size = 9

Coor = cWindowText

Stye = []

字符集不要使用 ANSI_CHARSET????????? 或DEFAUT_CHARSET，否则可能导致不同的操作

系统下字符集不一致。

尊重用户的字体选择*?????????? Windows 允许用户为标题栏、菜单、消息框和工具提示选择字

体。及时处理WM_SETTINGCHANGE 消息以根据设置迅速而安全地改变字体。

避免让人分心地字体????????????????????????????? Aria、Tahoma 和MS Sans Serif 之外的字

体。Verdana、TrebuchetMS 和Century Gothic 也适合于轻微差别的外观。即使文档中的截线

字体很不错，但界面中的任何截线字体都被认为是让人分心的。除了提示用户输入或模拟打

字机外，不要采用等宽字体。

避免使用粗体和斜体

避免混合字体

3.1.35 颜色

使用系统颜色*

的颜色。避免让人分心的文本颜色，通常是黑色之外任何颜色，对文本使用系统颜色

COOR_BTNTEXT? 或COOR_WINDOWTEXT 。在白色（COOR_WINDOW）背景上使用黑

色（COOR_WINDOWTEXT ）文字是xx正确的。及时处理WM_SYSCOORCHANGE 消息

以根据设置迅速而xx地改变颜色。

根据内容而不是外观来选择系统颜色*

配在一起。例如，不要将COOR_BTNTEXT 和COOR_WINDOW 混合在一起。

考虑对图形使用中间调色板??????????????? 256 色模式下使用中间色调色板避免了调色板的闪烁。

不要用颜色作为传递消息的{wy}方式*

户的可访问性，并且使程序可运行在单色显示器上。

3.1.36 三维效果

避免不必要的三维效果??????????????????????????????? 免三维静态线和矩形框。宁可采用空

白来分开组件，绝不在三维矩形框周围套其他的三维矩形框。避免使用三维文本。

三维效果过多

在界面中采用太多的三维效果是程序员常范的错误。毕竟，如果有些三维效果很酷，对

吧？不xx如此。请看下面的对话框。一点也不酷。一旦三维控件流行起来，就好像能使用

三维的都采用三维，而不管看起来是好是坏。即使采用三维边框，其目的也是为了让人理解。

采用许多三维静态框架控件通常是个坏征兆，现代的趋时是倾向于更为简单的风格。

使用柔和的三维效果???????????????? Window98? 中更为细致的三维效果是如何比Window?? 3.1

中的三维效果更有效更悦目的。尽管绝大多数现时世界的物体有加亮区，但很少有黑色实边

框的。Windows98 仅是通过在突起物体的右边和底部加上黑色边框以及在凹陷物体的上部和

左边加黑色边框来达到三维效果。

去除多余的三维效果
———————– Page 20———————–

最少三维效果

使用一致的三维效果*

3.1.37 各种细节

不要发音和闪动???????????????????????????????????????????????????? 的任务栏窗口按

钮通知用户未决消息例外。

避免不必要的视频效果

果，用户有明确要求时才打开。

用缩放功能提高文档可访问性

问性和整体性能。

处理WM_DISPAYCHANGE??????? 消息*

行。

基于光盘的程序的应该支持自动播放??????????????????????????????????? ” 自动播放”应该显示一列

选项，包括安装。程序安装以后，不应该运行” 自动播放”。

支持用户?????????? 期和时间拾取控件进行日期输入，GetDateFormat? 和GetTimeFormat

函数用于设置货币和数字的格式，CMapString API 用于排序。考虑采用RichEdit 控件用于文

本输入和输出。{zh1}，利用WM_INPUTANGCHANGE 消息来处理输入语言的改变。

3.2 统一术语

3.2.1 术语的重要性

我们用名称来区别、描述和查找事物，使用名称来分解并理解不熟悉的事物。采用统一

的术语有助于我们更好地理解和进行交流–简化并统一用户界面术语有助于用户理解和充

分应用我们设计的界面。

使用不同的术语描述相同的事物是最让人迷惑的，而改变人人都已经熟悉的术语也是有

害的。这两种情况都使得程序难以讨论、描述，以及归档。甚至使它难以编程。

3.2.2 命名

下面是一些需要命名的、与界面有关的典型对象：

? 程序本身；

? 程序使用的文档类型；

? 用户利用程序执行的主要操作；

? 所有的窗口、对话框和属性表；

? 主程序窗口中的使用区域；

? 认为非标准的屏幕对象、命令、属性、交互、或者技术。

简而言之，用户可以看到或需要与其进行交互的、显示在菜单、工具栏、窗口、对话框、

状态栏、联机帮助或文档中的任何内容都需要有一个名称。当然，您将会使用已存在的标准

屏幕对象的名称。例如，您不需要命名常用的对话框，因为它们已经拥有名称。
———————– Page 21———————–

3.2.3 用用户的语言说话

使用软件面向的用户所熟悉的词语，除非您的软件是为了程序员设计的，否则应该避免

使用计算机行话，而应用常用的单词代替。例如，对绝大多数用户来说，常用单词”separator”

（分隔符）就比技术术语”deimiter”? （定界符）要好得多。如果必须使用技术词汇，那么应

采用那些用户可能知道的术语。

3.2.4 要避免的术语

也有些术语是千万不要用在您的用户界面中的。尽管”execute”执行、”ki”????????????????????????? （杀死）、

“terminate”? （结束）、”fata”? （致命的）和”abort”? （中止）这样的术语在程序员文献中是xx

可接受的，但xx应该避免出现在其他的文字中。

来源：

你可能还会喜欢以下内容