1.3. 细节约定
1.3.1. 界面风格
1.3.1.1. 普通外观
l 使用一致性一致的外观将使用户界面更易于理解和使用。用户界面控件看起来应该是一致的。
l 使用安排和流程在西方文化中（包括中国），人们习惯于从左到右，从上到下进行阅读，因此，应该将重要信息放在上面和左边。左上角最容易吸引起人们的注意力。
l 使用对齐通常，使用左对齐来使用户界面控件更易于浏览。对于数值文本，应该使用小数点对齐或右对齐。对于非数值文本，应该避免使用右对齐或居中对齐。不必对什么都使用中间对齐，或者使它们保持对称形式。在右边或底部保留空白区域更适合习惯。
l 使用分组将相关的用户界面控件分成组，以体现它们之间的关系。同时，还要显示相关信息。将控件放在它所作用的对象旁。使用空格、分组框、线条和标签，或者其它分隔符对用户界面控件进行分组。
l 使用强调使用焦点、位置、分组、层次、启用/禁用、大小、颜色或者字体等，来将注意力集中在需要首先看到的用户界面控件上。尽量以可视的方式指明用户接下来应该进行的操作。
l 使用可视的提示尽量使用近似的大小和间距来指出用户界面控件是相似的，而使用不同的大小和间距来指出用户界面控件视是不同的。
l 使用空格使用空格来创建一个"透气室"，以使窗口布局更易于理解，并且查看起来更舒服。空格的多少要适当，不要显得太分散。但是，要避免过多地使用空格。如果可能，尽量使窗口小一些。
l 警惕空洞不要到处粘贴公司或产品的名称及徽标。虽然在启动屏或"关于"框中出现公司或产品名称及徽标是完全可以接受的，但其他窗口中的可用空间应该出现其他内容。如果没有其他内容，那么应尽量使窗口小一些。
l 注意大小使用用户界面控件的分辨率具有独立性。使用系统规格（使用GetGystemMetrics API 函数）或文本规格（使用GetTextMetrics或GetTextExtentPoint32 API 函数）来确定用户界面控件的大小。任何显示文本的对象（如对话框或定义的文本文档）都应该使用文本规格。
l 考虑使用资源或预定义的布局网格资源模板或预定义的布局网格有助于您在不同的窗口之间实现一致性。
注意，下页所示图的第二个对话框，与第一个不同，它有一个紧凑、从左到右、从上到下的流程，并且，左对齐的标签很便于浏览；通过对齐编辑框并调整其大小，使它显得更有组织，更加平衡。
不合理的
平衡的对话框
1.3.1.2. Windows的可视提示
暗示与用户只需通过查看可视提示来确定对象的使用方式的能力有关。在Windows中，请保持使用下面的可视提示：
l 可以单击凸起的项目。
l 可以单击当鼠标从其上移过时突出显示的项目。
l 不能单击下凹的项目。
l 可以编辑具有白色背景和闪烁垂直条（光标）的项目。
l 不能编辑具有灰色背景的项目。
l 灰色项目是被禁用的。
l 可以拖动凸起的项目。
1.3.1.3. 交互
l 尽量提供对所有功能的键盘访问理想情况下，除了绘图这样的图形功能，其他所有的功能都应该只能通过键盘来访问。
l 尽量提供对所有功能的鼠标访问理想情况下，除了文本输入外，其他所有功能都应该只能通过鼠标来访问。
l 确保具有明显后果的操作要求用户进行明确的选择*用户需要完全明确他将要进行危险性操作或破坏性操作。
l 对于使有耗时的操作都给出反馈*在进行长时间的操作时，要确保有等待光标、进度表或其他的可视反馈。用户应该能够取消长时间的操作。如果可以取消未完成的操作，那么将按钮标记为"取消"，否则将按钮标记为"停止"。
l 可视的指示模式*向用户提供一种可视的反馈，以指出用户进入一种模式，通常可以通过更改光标或标题栏文本来做到这一点。
l 确保单击和双击的一致性*单击用于非按钮选定，而双击用于选定并执行默认操作。换句话说，双击（在列表框、组合框，或其他接受双击的控件中）的效果应该与选定控件中的一个项目，然后按下Enter键的效果一样。
l 鼠标右键仅用于快捷菜单*确保鼠标右键仅用于快捷菜单，而不要用于其他用途。
l 不要使用鼠标中键*如果用户的鼠标有中键，那么让用户使用"控制面板"中的"鼠标"实用程序自己分配中键的行为。
l 保持分配的快捷键的一致性组合功能键和Ctrl键用于快捷键。习惯上不将Alt键用于组合键，业务Alt键常常被用于访问键。尽量避免使用Alt键和Ctrl键，因为这种组合会使快捷键非常麻烦，而且也很不方便。
l 将快捷键作为补充方式*千万不要将快捷键作为访问命令的唯一方法。应该让用户有更多的明显选择。
l 避免水平滚动条与垂直滚动条不同，水平滚动条并不受欢迎，因为它会使项目阅读起来比较困难。解决的办法有：尽量使用垂直滚动条、加宽窗口、减小文本的宽度，或者使文本自动换行等。当然，如果确实需要，还可以使用水平滚动条。
1.3.1.4. 程序
l 只有主程序窗口才有标题栏图标、菜单栏、工具栏和状态栏*因为单击主窗口的任务栏按钮也会激活二级窗口，所以二级窗口绝对不要显示在任务栏中。二级窗口不要因为使用菜单栏、工具栏或状态栏而使其变得复杂。可以使用标题栏图标来明显区分主窗口和二级窗口。另外，绝对不要使用默认的Windows图标(飘动的窗口图标)作为窗口图标。
l 简化默认配置让用户按自己的速度来学习和使用程序。
l 应用程序应该使用多文档界面（MDI）或单文档（SDI）这些程序界面应该与应用程序的使用模式匹配。
l 默认情况下，应用程序应该保持为最大化当应用程序占用整个屏幕时，常常能够提高用户的工作效率。
l 实用程序应该使用SDI或对话框界面这些程序界面应该与实用程序的使用模式匹配。对于实用程序，建议不要使用MDI界面，因为管理这些窗口需要付出很多努力。
l 实用程序应该在小屏幕范围内运行实用程序常常与其他程序一起运行，因此它们需要在小屏幕范围内运行。实用程序应该有灵活的窗口布局，以适应多种不同的大小。实用程序很少以最大化的形式运行。
l 使用实际文档的SDI程序必须支持运行多个实例*运行多个实例使用户能够同时操作多个文档。
l 使用"退出"命令终止程序使用"退出"终止程序；使用"关闭"移走主窗口和非模式对话框；使用"取消"移走模式对话框。当关闭主窗口并不表示终止进程时，对于主窗口使用"关闭"来代替使用"退出"。例如：关闭打印机状态窗口不会取消打印任务。
1.3.1.5. 默认
l 保存和恢复用户选择程序应该能够能够恢复到其最后退出的状态。MDI程序应该能够恢复文档窗口的大小和位置。对话框通常应该使用最后输入的值作为默认值。
l 提供适当的默认值提供提供适当的默认值来减少用户不必要的操作，从而帮助用户完成工作。提供最可能使用并给出设置实际使用方式的默认值。通常，最好的默认值是用户最后输入的值。
l 考虑选择默认值时的安全性* 不应该将不可恢复或破坏性的操作设置为默认值。不要使用令用户感到莫名其妙的默认值。
1.3.1.6. 窗体
对话框窗体大小尽量不要超过640*460，留20给任务栏。并且高和宽（或W宽和高）的比应该大致保持为3:4（或4：3）。一般应该将窗体的"Position"属性定义为 "poDesktopCenter"，"WindowState"属性为"wsNormal"，某些主界面设置为"wsMaximized"。"ShowHint"属性设为"True"。如果是模式对话框，则将"BorderStyle"属性设置为"bsDialog"。
窗体文件(*.dfm)保存为文本格式，以便在VSS中比较不同版本之间的差别。如果窗体大小超过屏幕大小，则在Delphi开发环境中打开时，大小会有改变，并且影响到运行时刻效果。由于每个人的屏幕大小设置不一样，有些是1024*768，有些是800*600，因此在设计期间请注意窗体大小，尽量不要超过800*600，以免出现上述问题。
1.3.1.7. 布局和间距
窗体控件布局和间距尽量保持与Windows标准一致。控件与窗体的上、下、左、右边距为7象素。右下角主命令按钮之间的间距为6象素，如果主命令按钮在右上角，之间的间距则为4象素。主命令按钮一般情况为75×21象素，如果按钮的文本很长，应该适当加宽按钮的宽度。如下图。其它详细资料请完全参照错误！书签自引用无效。和命令按钮。
控件的"TabOrder"属性值应该与控件排列顺序一致，即遵循从上到下、从左到右这样一个流程。如果在PageControl的多个页面中存在类似的控件，应该尽量使得它们在各个页面中出现的位置/大小比较一致，以免在页面间切换时产生闪烁感。
1.3.1.8. 图标、图片
不同界面中的同一功能应该使用同样的图标和图片。图标、图片的色调、风格尽量保持一致。图标、图片的隐喻应能确切表示功能的含义，如果不能，就直接使用文本，以免混淆用户。如果功能是一个动作时，可能比较难找到确切表示该功能的图标，这时应该尽量采用此动作相关的名词做图标。例如Windows中的"剪切"功能就是用一把剪刀来表示的。
1.3.1.9. 提示信息（Hint）
工具栏按钮应该设置工具提示 "Hint" 属性。Hint能帮助用户更方便地理解和使用。详细资料可以参照工具栏、工具提示。
如果使用了"TSpeedButton"控件，并且只有图标，同样应对它设置"Hint"属性。如果不是特殊情况，应尽量避免使用"TSpeedButton"控件，而使用"TButton"控件代替。
1.3.1.10. 标点符号
在标识控件用途的标签文本（Label）和提示信息（Hint）中，应使用半角符号。如果是指导性标签文本（如解释按钮功能的句子），则使用全角符号，并且句子应遵循中文标点符号标准。如下图Microsoft标准对话框例子。其他详细资料可参照静态文本。
1.3.1.11. 对话框
l 对话框应该在所有视频模式下都能够正确显示当在VGA模式（640×480）下显示时，对话框应该不超过640×460（留20像素给任务栏）。这将确保对话框能够显示在所有的视频模式下。
l 确保模式对话框的模式*确保使用具有父窗口的模式对话框都提供正确的父窗口句柄，而不时提供NULL句柄。如果没有提供父窗口句柄，那么父窗口仍处于活动状态，因此该对话框实际上并不是模式对话框。
l 不要使用可滚动的对话框*也就是说，不要使用需要滚动条来进行完全查看的对话框。这种对话框使用起来非常不方便，并且也时完全不必要的。应该重新设计这种对话框。
l 不要在作为二级窗口的对话框中使用菜单栏*使用这种对话框需要付出很多努力。注意，在用作主窗口的对话框（如"查找"实用工具）中，菜单栏时可以接受的。还要注意的是，在所有对话框中，快捷菜单和菜单按钮都是可以接受的。
二级对话框不要使用菜单栏，但可以使用菜单按钮。
l 不要在作为二级窗口的对话框中使用标题栏图标*标题栏图标用于区别主窗口和二级窗口。
l 不要在任务栏上显示作为二级窗口的对话框*注意，单击主窗口的的任务栏图标也将激活二级窗口。
l 对话框中使用下页图所示的页面布局和间距。
l 对于相似的对话框，使用控件位置来强调其相似性。如果意义相同的同一控件出现在一些相似的对话框中，那么它应该显示在相同的位置。另一方面，应避免将可能会产生混淆的不同控件放在同一位置。
l 对非模式对话框最好使用可停放的对话框可停放对话框在功能上与非模式对话框是等效的，但其位置设置更为灵活。
l 策略地设置输入焦点将最初的输入焦点设置在最可能首先使用的控件上。
l 在对话框标题文本中不要出现省略号例如，作为选择"打印选项..."命令结果而显示地对话框的标题应该为"对于选项"。但是，表示命令正在执行过程中菜单对话框（如"连接到Internet..."对话框）是一种例外情况。
l 为所有可处理访问键的控件分配访问键*访问键可以使用户的手保持在键盘上，从而使访问程序更加方便。您可以直接在其标题中为诸如命令按钮、单选按钮、复选框等控件分配访问键。通过提供静态文本标签或带有访问键、在Tab顺序上先于控件的组框，您可以为诸如编辑框、列表框、组合框等控件分配访问键。在其他情况下不要为组框分配访问键--这会使人产生混淆。"确定"按钮没有访问键，因为在作为默认按钮时，它通过提Enter键来选定的。"取消"按钮也没有访问键，因为Esc键预览清除模式对话框。如果可能，避免使用小写的g、j、p、q或y作访问键，也避免使用这些字母前后的字母作为访问键。下划线不能与这些字母的下行字母分开。当然，访问键必须是唯一的。
l 避免使用粗体文本尽量少使用粗体文本。在Windows 3.1 的对话框中，粗体文本用于在旧式的视频硬件上绘制被禁用的文本（即抖动的灰色文本）。因为现在的视频硬件可以绘制没有抖动的灰色文本，所以Windows 为了使外观更加清洁，现在Windows 在对话框中使用正常文本。粗体文本仅用于强调。对于大多数对话框不要粗体文本。
l 提供环境敏感的帮助对于复杂的对话框，应该为整个对话框提供环境敏感的帮助（通过帮助按钮或F1键访问），或者为个别控件提供控件特定的帮助（通过"这是什么？"按钮或Shift＋F1 键来访问），或者同时提供这两种帮助。
1.3.1.12. 对话框的主要命令按钮
l 将主命令按钮与对话框主体分开*主命令按钮包括像"确定"、"取消"、"关闭"、"帮助"、"停止"、"隐藏"，以及其他相关按钮的等命令按钮。这种分开使主命令按钮更易于查找和识别。
l 认真选择对话框的方向在西方文化中，人们习惯于从左到右、从上到下进行阅读，因此，将主命令按钮靠底部或右边放置更容易被发现。您应该选择对话框的外观比例与屏幕的外观比例（通常高与宽的比例为3：4）相似的方向。这将使对话框的外观看起来更加舒服，并且更易于在屏幕上进行定位。如果按钮具有不同的大小，那么可以将它们放在对话框菜单底部。当不能确定时，也可以将按钮放在底部，因为这种定位方式最为常见，也更易于阅读。
l 将排列在底部的主命令按钮右对齐右对齐主命令按钮适合从左到右的阅读习惯。当只有一个主命令按钮时，您或许希望例外地将其居中放置。
右对齐主命令按钮
l 避免使用多行或多列的主命令按钮多行或多列的主命令按钮对用户是一个打击。如果有许多主命令按钮，那么注意，通常在右边排成一列与在底部排成一行相比可以放置更多的按钮。另外，您可以考虑使用命令菜单。如果必须使用很多按钮，那么注意使用多行别使用多列的效果好。
l 对模式对话框，通常提供"确定"和"取消"按钮*要使用对话框，用户需要能够方便地识别前进（使用"确定"按钮）和后退（使用"取消"按钮）的方式。您可以使用更明确的按钮代替"确定"按钮，但绝对不要在模式对话框中替换"取消"按钮，除非用"停止"来表明正在进行的操作无法取消。
l 对于非模式对话框或或作为主窗口的对话框，提供"关闭"按钮而不提供"确定"和"取消"按钮*将"确定"和"取消"按钮用于非模式对话框或作为主窗口的对话框可以使对话框看起来像是模式对话框。而且，当用于非模式环境中时，"确定"和"取消"时没有什么意义的。使用"关闭"按钮可以消除这种混淆。
l 通常将"确定"按钮排第一，"取消"其次，"帮助"最后*"确定"或其等价按钮通常作为第一个主命令按钮。"取消"按钮应该位于"确定"的右边或下面。将"确定"和"取消"按钮放在一起。"帮助"按钮应该时最后一个按钮。如果没有"确定"按钮，那么应该将"取消"按钮放在"帮助"按钮的前面。这可以使主命令按钮更易于查找和识别。
l 确保"取消"按钮真正用于取消操作*当取消时，程序的状态栏应该与之前显示的模式对话框完全相同。如果不是这样，那么应该用"停止"按钮来代替"取消"按钮。模式对话框中的"取消"按钮应该与标题栏中的"关闭"按钮效果相同。而属性表是个例外，因为"取消"按钮不会取消已经应用的更改。
1.3.1.13. 属性表和属性页
l 让属性页独立工作避免使一个属性页的行为或操作受其他属性页的限止。用户不可能发现属性页之间的这种独立关系。在属性页的使用顺序方面应该没有限止。用户应该能够随时查看任意的属性页。
l 属性页的布局相互独立一些属性页通常不会占用同样大小的空间。占用空间较小的属性页应该与最大的属性页的布局的格式方式不同，因为将会产生额外的空间（见下图）。
属性页的布局保持独立，避免居中。
l 用属性表代替使用带选项卡的对话框使用属性表而不使用带选项卡的对话框除了具有一致性之外，没有什么明显的实用性优势。另外，对于实际显示对象属性的对话框使用属性表，而对于其他用途，所有带选项卡的对话框。
l 对属性显示总采用属性表，即使仅有一个页*采用属性表能够明确告诉用户查看的使属性而不是一般的对话框。属性表有一个"应用"按钮来帮助用户测试设置。
l 绝对不要使用两行以上的标签*最好使用一行标签，但两行也是可接受的，两行以上就太多了，可用级连属性设置或多个对话框代替。
l 总为属性提供"应用"按钮再说一次，提供"应用"按钮帮助用户对设置进行测试。
l 对显示属性的属性表总是在其标题中写上"属性"一词和对象的名称*请注意，不是所有的属性表都是用来显示属性的。
l 总将命令按钮放在右边*适用于所有页的命令按钮必须置于标签页区域的外面，而仅适用于单个页的命令按钮必须置于该标签页的里面。
1.3.1.14. 向导
l 对高级的、复杂的或不常用的任务使用向导向导对非常高级或复杂的任务十分有用，省去了用户许多麻烦的操作。当向导用于不常用的任务时，其效果最好。对常用任务使用向导则显得大而不当。
1.3.1.15. 控件
l 尽量采用标准控件尽可能采用标准控件（6个最早的控件和新的Win32常用控件）。采用非标准控件的程序与绝大多数Windows程序看起来不一致。只用完全合理时才使用自定义控件。
l 定制标准控件时要小心改变标准控件的标准外观或行为时一定要小心，这是个常常出错的地方。
l 将无效控件置为不可用*将不适用于当前程序状态的控件置为不可用。
l 取消不必要滚动条尽量使控件的尺寸足够大，避免使用滚动条。
1.3.1.16. 命令按钮
l 采用最小的宽度和标准的高度带文字的命令按钮应该采用50个对话单位（75个像素点）的最小宽度、14个对话单位(21个像素点)的标准高度。尽量将不同大小的带文字命令按钮的个数控制在两个以内。对父窗口拖动（owner-draw）按钮或无文字的按钮（如"…"），其大小可以任意设置，原则是使命令按钮外观简朴一致。高度大于14个对话单位(21个像素点)的按钮看起来不够专业。尽管不限制命令按钮的最大宽度，但宽度超过200个对话单位的按钮使不妥当的。请参阅下图所示关于命令按钮的实例。
命令按钮大小示例
l 针对国际化适当加宽按钮尽管50个对话单位（75个像素点）的宽度是适合英语文字的最小宽度，但对需要针对其他语言进行本地化的程序来说，可能就太小了。对于需要翻译为其他语言的程序，将命令按钮的最小宽度定为60个对话单位可能更适合。
l 将无效按钮置为不可用，以取消报错*绝对不要使可用的按钮仅产生一条出错信息。
l 总采用省略号来表示需要更多信息*命令中的省略号表示执行命令时需要更多信息，而不是简单的确认。省略号并不表示一定会出现对话框。
l 绝对不要指定双击行为*用户意料不到命令按钮会响应双击，因此不可能发现这样的行为。
命令按钮大小使用Window标准75x21象素。一般情况下，"确定"和"取消"按钮的属性设置如下：
btnOk: TButton
Caption = '确定'
Default = True
ModalResult = mrOk
end
object btnCancel: TButton
Cancel = True
Caption = '取消'
ModalResult = mrCancel
End
"确定"和"取消"按钮一般被映射为Enter键和Esc键，因此不应该对它们指定访问键，除此以外的命令按钮都应该指定一个访问键。如下图：
主命令按钮在下
如果主命令按钮在右上角，应该布置为这样。
主命令按钮在上
如有其他不明，请参照命令按钮。
如果设计期间未指定"ModalResult"，注意一定要在按钮的"OnClick" 事件代码中为"ModalResult"赋值。
1.3.1.17. 复选框
l 用复选框开关选项，用单选按钮改变模式*用复选框进行选项的开关操作是很有效的，但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选框来表示是否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，对横向和纵向模式应该用一组单选按钮代替。
l 避免一组复选框中选项个数超过8个应该考虑用复选框列表代替，它占用的空间更少，但复选框列表需要滚动时使用就稍稍麻烦了。尽管控件足够或保持与同一窗口中其他复选框一致时，采用复选框时可取的，但大于8个左右的复选框就未免太多了。
l 考虑将修改组的复选框置于应该分组框中这样的分组使得复选框之间的关系更为明显。
l 宁可竖向对齐虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的，但竖向对齐的一组复选框更易于浏览。
1.3.1.18. 单选按钮
l 避免一组单选按钮中的选项个数超过8个考虑用列表或组合框代替，它们占用的空间更少，但要记住控件使用更麻烦些。尽管控件足够或保持与同一窗口中其他单选按钮一致时，采用单选按钮是可取的，但多于8个的单选按钮未免太多了。
l 避免使用单选按钮进行开 / 关或是 / 否选择用复选框代替。
l 总将单选按钮置于一个分组框中*由于单选按钮是一组相互排斥的选项，所以分组框使选择更为明确。
l 宁可竖向对齐虽然更合适的情况下采用横向对齐或直角对齐也是可以接受的，但竖向对齐的一组单选按钮更易于浏览。
1.3.1.19. 组合框
l 总给组合框提供一个标签*必须用标签来表明组合框的用途。
l 使组合框的下拉列表最少有5行长少于5行的列表就没有可用的滑块，不易于滚动。请注意，如果组合框没有足够的列项来填满列表，那么将自动缩短列表的长度。
l 避免组合框的列项少于4考虑用单选按钮代替，它们虽然多占空间，但更易于操作。如果空间更为重要或为了保持与同一窗口中的其它组合框一致时，采用组合框则更为可取。
1.3.1.20. 编辑框
l 总给编辑框提供一个标签*必须用标签来标明编辑框的用途。如果标签在左边，将标签文字与编辑框文本垂直对齐。
l 避免有输入限制的编辑框将编辑框用于用户对任何文本的输入或数字编辑框用于数字的编辑。对于输入受限的情况，使用其他的控件，如组合框、列表、滑块和微调框。对于日期和时间，使用日期和时间拾取控件。
l 用微调框和浏览按钮使编辑框可视微调框和浏览按钮是简单的可视机制，它们帮助用户在编辑框中进行有效的输入。避免让用户必须输入。仅对数字编采用带微调框的编辑框，对于文本，使用组合框代替。
l 按期望输入来设置编辑框的宽度编辑框的宽度是对期望输入的可视提示。例如，如果用户是输入地址，两个字符宽的State字段明显暗示用户输入两个字符的州名缩写。如果期望的输入没有特别的大小，就选择与其他编辑框或控件一致的宽度。
l 总采用数字编辑框用于数字输入*当用户在数字字段中输入非数字文本时，不应该有任何出错消息。
1.3.1.21. 滑块
l 总给滑块提供一个标签* 必须用标签来标明滑块的用途。而且，滑块还应该有标明高、低值意义和当前选择的标签--当然都不带冒号。
1.3.1.22. 静态文本
l 左对齐静态文本标签左对齐使得标签外观更有条理，且易于浏览。
l 宁可将静态文本标签置于相关控件的左边，而不是上面这样对齐使标签更易于被发现，且方便了标签和控件的浏览。很明显，长控件是例外情况，如列表视图、树形视图（Tree）和多行编辑框。
l 总在用于标识控件的静态文本标签后带上冒号*使用冒号明显表示为控件标签的文本。为控件提供附加信息的标签不应该有冒号，如用来解释滑块控件的标签。标签也可作为屏幕读出器的输入信息。
l 对非标签文本总用只读编辑框* 只读编辑框允许用户将文本复制到剪贴板上，并在文本比控件长时可进行滚动。
l 不要把静态文本置于凸起的边界上*在凸起边界上的静态文看起来像按钮，因而用户会试图单击它。
1.3.1.23. 列表框
l 总给列表框提供一个标签*必须用标签来标明列表框的用途。
l 使列表框至少5行长少于5行的列表没有滑块，不便于滚动。如果列表框没有滚动条，那么使用一个更短的列表框也是可以接受的。
l 对多个选择考虑采用复选框复选框列表可以突出其多个选择的能力。如果不能接受复选框列表，那么可以采用多选列表，并用静态文本表示选项个数，清楚指明可进行多项选择。
l 对多选列表考虑提供"全部选中"和"全部取消选中"命令由于希望全部选中或全部取消使常见的事情，所以这两个命令方便了用户进行多项选择。
1.3.1.24. 列表视图
l 总给列表视图提供一个标签*必须用标签来标明列表视图的用途。
l 使列表视图至少5行长少于5行的列表视图没有滑块，不便于滚动。如果列表视图没有滚动条，那么使用一个更短的列表视图也是可以接受的。
l 仅在列表可排序时采用可单击的表头*可单击的表头只应用于排序。首次单击时应按正序对列表进行排序，而第二次单击时按反序进行排列。
l 对列项大约超过30的列表视图总使其可进行排序*用户能够对列表进行排序方便了对信息的查找。
1.3.1.25. 滚动条
l 滚动条仅用于滚动*使用滑块或微调框来设置数值。
l 使滚动条足够长，保证有可用的滑块。没有滑块的滚动条不便于使用。
1.3.1.26. 分组框
l 利用分组框分组相关控件尽管分组框通常是用于单选按钮的分组，但也可用于任何控件的分组。避免使用只有一个控件的分组框，除非是为了保持与同一对话框中其他分组框一致。
l 考虑采用静态线或文本标签来代替分组框分组框多时要占去许多空间。如果空间紧张的话，一个替代分组控件的好办法是同时采用静态文本标签和静态线。
考虑采用静态文本标签和静态线代替分组框
l 不要在分组框标签的后面使用冒号*分组框标签的意思明白，使用冒号完全没有必要且让人糊涂。
1.3.1.27. 菜单
l 总用单个单词作为菜单标题*菜单栏上多个单词的菜单标题看起来像多个菜单标题。
l 不要在菜单栏的文本间留有空隙*不一至的菜单栏文本既无用，又难看。
l 避免占多行的菜单栏*尽管将父窗口缩小到足够窄时，任何菜单栏都要占用几行，当要避免正常使用时因菜单项都而占用几行的菜单栏。
l 保持菜单稳定*将无效菜单置为不可用，而不要删除它们。但是，对整个程序实例都无效的菜单，就应该删除。
l 合理安排菜单项的顺序将相关菜单项组合在一起。重要的命令应该位于菜单的顶部，而不重要的菜单则位于菜单的底部。
l 将无效菜单置为不可用来代替报错*菜单绝不应该有仅产生出错消息的可用命令。
l 分配访问键*访问键使用户可以手不离开键盘进行操作，并提供程序的可访问性。尽可能避免用小写字母g、j、p、q、y或单词中与它们靠近的字母来分配访问键，因为下划线与下一行的字母不好区分。当然，一个菜单中的访问键应该是唯一的。
l 总采用省略号来表示需要更多信息*命令中的省略号表示执行时需要更多的信息，而不是简单确认。省略号不表示一定有对话框出现。
l 使用标准菜单避免不提供"文件"、"编辑"和"帮助"菜单。由于这些是标准菜单，所以用户会期望它们出现。例如，期望在"文件"菜单中发现像"打印"和"退出"这样的命令，虽然这些命令可能与"文件"无关。同样，用户期望在"编辑"菜单中发现"剪切"、"复制"和"粘贴"命令，至少要在"帮助"菜单中发现"关于"命令。
l 统一放置"查找"和"选项"命令总将"查找"命令放在"编辑"菜单中，而有"工具"菜单时，总将"选项"置于其中，否则置于"查看"菜单中。
l 用复选标记来开关选项，用单选组来改变模式*用复选标记进行选项的开关操作是有效的，但如果用来将模式改变为另外一种状态就难免让人迷惑了。例如，可用一个复选标记来表示是否显示工具栏，但若用复选框来切换打印机的横向模式和纵向模式就会使人糊涂，对横向和纵向模式应该用一个单选组来代替。
l 不要使用多列的下拉菜单*多列增加了菜单不必要的复杂性。
l 不要使用"Bang"（爆炸的声音）菜单*Bang菜单是菜单栏上那些看起来像下拉菜单，但实际是选择后立即执行的命令，如"退出"！显然，用户希望菜单标题就只是菜单，而不是命令。
l 不要右对齐菜单标题*这样的菜单风格陈旧且不易于使用。
1.3.1.28. 上下文菜单
l 考虑将上下文菜单作为冗余使用上下文才菜单不应该是访问命令的唯一方式。通常上下文菜单中的命令应该在菜单栏中也提供，使用上下文菜单是为了提高访问效率。
l 避免在上下文菜单中包含快捷键应该将快捷键分配在菜单栏中，上下文菜单的快速访问是通过鼠标进行，而不是通过键盘。
1.3.1.29. 工具栏
l 保持工具栏稳定*将无效的工具栏按钮置为不可用，而不是将它删除。但是，应该考虑删除用户进入一种模式用不到的整个工具栏。
l 将无效命令置为不可用，而不是报错*工具栏绝不应该包含只出现错误消息的命令。
l 对实用程序采用大工具栏按钮好的使用程序工具栏常常与应用程序的按钮不同，其按钮更简朴，更大。实用程序工具栏应该只包含几个带有描述性文字和图形的显眼命令。
l 对应用程序采用可移动的、可定制的工具栏，而对实用程序采用固定的工具栏应用程序需要灵活的工具栏来支持其典型的使用方式。用户使用实用程序的时间一般不长，因而不需要定制工具栏。
l 提供显示或隐藏工具栏选项如果有多个工具栏，分别为它们提供显示或隐藏的选项。
l 总使用工具提示*工具提示帮助用户了解工具栏按钮的作用。
1.3.1.30. 工具提示
l 用工具栏的工具提示来提供信息，但要简短避免提示很明显的事情。考虑采用省略号来表示执行命令时需要更多信息。如果该命令已分配有快捷键，则显示该快捷键。
l 使工具提示文本成为高级用户的媒介工具提示用于简短的识别和提醒，而不是用来教学。
l 用工具提示显示有用信息不仅仅可在工具栏上使用工具提示，它的使用简单，能够向用户提供有用信息。但不可滥用--工具提示太多也就失去了其价值。不要对命令按钮会静态文本这样的控件使用工具提示。
l 不要自动消去包含许多文字的工具栏提示默认时，10秒种后工具提示将自动消去。如果工具提示的文字很多，10秒钟对用户来说就看不完了。
1.3.1.31. 文本
l 避免不必要的缩写词要么给文本更多的空间，要么改写文本使其占用更少的空间，缩写词使文本不易理解。
l 避免不必要的大写字母文本除非只去首字母构成的缩写词，否则不要用字母全为大写的单词，这样的单词看起来像在冲用户大喊大叫一样。
l 避免复杂的标号尽量采用简单的标点，如句号、逗号、问号，以及破折号。避免使用分号、感叹号、圆括号、括号，等等。
l 采用一致的大小写规则*对窗口标题、菜单、命令按钮、列标题属性页选项卡以及工具栏提示文字采用与书题一样的大小写规则，而对于标题、单选按钮、复选框、分组框和菜单项帮助中的文本采用与句子一致的大小写规则。（对于标题，除了不是标题开头和结尾的冠词和介词外，每个单词的第一个字母大小。对于句子，每个句子的第一个单词以及通常大写的单词--如专有名词的首字母大写。）
l 避免不好的背景将文本放在实地、颜色适中的背景上，确保在文本和背景之间存在良好的对比。
l 避免冒犯性语言避免激烈的词语，如fatal（致命的）、execute（执行）、kill（杀死、毁掉）、terminate（终止）、和abort（中止）。
1.3.1.32. 消息框
l 仔细选择消息框的类型采用带"确定"按钮的信息消息框向用户提供有关命令结果的信息。采用带"是"、"否"，以及可能"取消"按钮的警告消息框在继续进行前需要用户输入的情形下告诫用户。采用危急消息框通知用户进行工作前需要修改一个错误。
l 不要使用疑问消息框类型*不再推荐对消息框使用疑问标记符（MB_ICONQUESTION），因为它在Windows98后一致用来表示上下文修改帮助。
l 避免不必要的消息框不要用出错消息来报告正常行为，而应该用来报告不正常或不期望的结果。不要对很容易恢复的操作进行确认。
l 问用是/否回答的问题问用户问题时，采用"是"和"否"按钮代替"确定"和"取消"按钮，这样使问题易于理解。与对话框中不一样，"确定"和"取消"按钮很少同时用在消息框中。
l 确保消息框选项按钮与文本一致例如绝不要用"是"和"否"来作为非提问消息的响应。同样，不要使用多个效果相同的选项按钮。例如，除非有不同的操作结果，否则不要同时提供"否"和"取消"按钮。"否"按钮应该执行操作，而"取消"应该取消操作。
l 仔细选择默认按钮将最安全的或最常用的选项作为默认按钮。
l 避免无用的帮助除非提供真正有用的附加信息，否则不要提供"帮助"按钮。不要附加带无用帮助信息的没意义的消息框。
l 对危急错误考虑采用系统模式消息框采用系统模式消息框向用户提示严重的、可能造成破坏性的、急需注意的错误。系统消息框除了有WS_EX_TOPMOST样式外，与应用程序模式对话框完全一样。与在16位Windows中不一样的是，系统模式不影响用户与其他程序的交互。
1.3.1.33. 错误消息
l 避免错误号除非这个错误号对用户真正有用，否则不要给出错误号。
l 避免责怪用户避免在出错消息文字中出现单词you（你）或your（你的）。如果需要，当指用户操作时使用被动语气。采用与"错误发生了"等价的表达，比采用与"你捅漏子了"等价的表达要好得多。
l 避免敌对性语言避免在错误消息文字中使用词语bad（糟糕的、坏的）、caution（小心）、error（错误）、fatal（致命的）、illegal（非法）、invalid（无效）和warning（警告），而应该使用更具体的描述性词语。并且应该尽量解释到底是什么出了错。
l 在出错消息文字中使用平实的语句表达要简短、清楚、协调、具体。除非缩写词，否则不要使用全部大写的单词，那样的单词看起来像在冲用户大喊大叫一样。使用完整的句子和一般的现在或过去时态。避免缩写词。
l 避免在用户错误消息文字中装做有趣或高人一等用户并不觉得错误消息有趣，故装幽默并不能被广泛接受。
l 允许用户压制非危急的错误消息对经常出现的非危急错误，向用户提供一个压制该错误消息的选项。
1.3.1.34. 字体
字体统一使用以下设置：
Charset = GB2312_CHARSET
Name = '宋体'
Size = 9
Color = clWindowText
Style = []
字符集不要使用 ANSI_CHARSET 或 DEFAULT_CHARSET，否则可能导致不同的操作系统下字符集不一致。
l 尊重用户的字体选择*Windows允许用户为标题栏、菜单、消息框和工具提示选择字体。及时处理WM_SETTINGCHANGE消息以根据设置迅速而安全地改变字体。
l 避免让人分心地字体一般说来，应避免使用Arial、Tahoma和MS Sans Serif之外的字体。Verdana、TrebuchetMS和Century Gothic也适合于轻微差别的外观。即使文档中的截线字体很不错，但界面中的任何截线字体都被认为是让人分心的。除了提示用户输入或模拟打字机外，不要采用等宽字体。
l 避免使用粗体和斜体用粗体来吸引人的注意，用斜体表示着重，但要还少使用。
l 避免混合字体任何不包含文档的窗口最多包含两种不同的字体。
1.3.1.35. 颜色
l 使用系统颜色*尊重用户的颜色选择，避免使用固定颜色。不要强迫用户使用您选择的颜色。避免让人分心的文本颜色，通常是黑色之外任何颜色，对文本使用系统颜色COLOR_BTNTEXT或COLOR_WINDOWTEXT。在白色（COLOR_WINDOW）背景上使用黑色（COLOR_WINDOWTEXT）文字是完全正确的。及时处理WM_SYSCOLORCHANGE消息以根据设置迅速而完全地改变颜色。
l 根据内容而不是外观来选择系统颜色*不要将作为一个集合中的几种系统颜色混合匹配在一起。例如，不要将COLOR_BTNTEXT和COLOR_WINDOW混合在一起。
l 考虑对图形使用中间调色板在256色模式下使用中间色调色板避免了调色板的闪烁。
l 不要用颜色作为传递消息的唯一方式*不依赖于对颜色的区分可以增强程序对色盲用户的可访问性，并且使程序可运行在单色显示器上。
1.3.1.36. 三维效果
l 避免不必要的三维效果除非对控件分组，否则避免三维静态线和矩形框。宁可采用空白来分开组件，绝不在三维矩形框周围套其他的三维矩形框。避免使用三维文本。
三维效果过多
在界面中采用太多的三维效果是程序员常范的错误。毕竟，如果有些三维效果很酷，对吧？不完全如此。请看下面的对话框。一点也不酷。一旦三维控件流行起来，就好像能使用三维的都采用三维，而不管看起来是好是坏。即使采用三维边框，其目的也是为了让人理解。采用许多三维静态框架控件通常是个坏征兆，现代的趋时是倾向于更为简单的风格。
l 使用柔和的三维效果请注意Window98中更为细致的三维效果是如何比Window 3.1中的三维效果更有效更悦目的。尽管绝大多数现时世界的物体有加亮区，但很少有黑色实边框的。Windows98仅是通过在突起物体的右边和底部加上黑色边框以及在凹陷物体的上部和左边加黑色边框来达到三维效果。
去除多余的三维效果
最少三维效果
l 使用一致的三维效果*确保三维效果的光源位于屏幕的左上角。
1.3.1.37. 各种细节
l 不要发音和闪动没什么比发音和闪动的程序更烦人的了。但闪烁程序的任务栏窗口按钮通知用户未决消息例外。
l 避免不必要的视频效果至少一个使其为可选择的。理想情形是，默认时关闭这样的效果，用户有明确要求时才打开。
l 用缩放功能提高文档可访问性提供提供文档缩放功能，可提高显示文档的程序的可访问性和整体性能。
l 处理WM_DISPLAYCHANGE消息*改变显示分辨率后，程序应该能够正确显示和运行。
l 基于光盘的程序的应该支持自动播放当光盘插入驱动器后，"自动播放"应该显示一列选项，包括安装。程序安装以后，不应该运行"自动播放"。
l 支持用户采用日期和时间拾取控件进行日期输入，GetDateFormat和GetTimeFormat函数用于设置货币和数字的格式，LCMapString API用于排序。考虑采用RichEdit控件用于文本输入和输出。最后，利用WM_INPUTLANGCHANGE消息来处理输入语言的改变。
1.3.2. 统一术语
1.3.2.1. 术语的重要性
我们用名称来区别、描述和查找事物，使用名称来分解并理解不熟悉的事物。采用统一的术语有助于我们更好地理解和进行交流--简化并统一用户界面术语有助于用户理解和充分应用我们设计的界面。
使用不同的术语描述相同的事物是最让人迷惑的，而改变人人都已经熟悉的术语也是有害的。这两种情况都使得程序难以讨论、描述，以及归档。甚至使它难以编程。
1.3.2.2. 命名
下面是一些需要命名的、与界面有关的典型对象：
● 程序本身；
● 程序使用的文档类型；
● 用户利用程序执行的主要操作；
● 所有的窗口、对话框和属性表；
● 主程序窗口中的使用区域；
● 认为非标准的屏幕对象、命令、属性、交互、或者技术。
简而言之，用户可以看到或需要与其进行交互的、显示在菜单、工具栏、窗口、对话框、状态栏、联机帮助或文档中的任何内容都需要有一个名称。当然，您将会使用已存在的标准屏幕对象的名称。例如，您不需要命名常用的对话框，因为它们已经拥有名称。
1.3.2.3. 用用户的语言说话
使用软件面向的用户所熟悉的词语，除非您的软件是为了程序员设计的，否则应该避免使用计算机行话，而应用常用的单词代替。例如，对绝大多数用户来说，常用单词"separator"（分隔符）就比技术术语"delimiter"（定界符）要好得多。如果必须使用技术词汇，那么应采用那些用户可能知道的术语。
1.3.2.4. 要避免的术语
也有些术语是千万不要用在您的用户界面中的。尽管"execute"执行、"kill"（杀死）、"terminate"（结束）、"fatal"（致命的）和"abort"（中止）这样的术语在程序员文献中是完全可接受的，但完全应该避免出现在其他的文字中。