出自UXGuide.net

布局

Layout

目录 1 设计理念 1.1 视觉层次 1.2 阅读设计模型 1.3 为扫视进行设计 1.4 有效利用屏幕空间 1.5 控件尺寸 1.6 间距 1.7 可缩放窗口 1.8 焦点 1.9 流程 1.10 分组 1.11 对齐 1.12 水平对齐 1.12.1 左对齐 1.12.2 右对齐 1.12.3 居中对齐 1.13 垂直居中 1.13.1 元素顶端 1.13.2 文本基线 1.14 标签对齐 1.14.1 标签在控件上方左对齐 1.14.2 标签在控件左侧左对齐 1.14.3 标签在控件左侧左对齐，控件的左侧错开排列 1.14.4 标签在控件左侧右对齐 1.15 平衡 1.16 网格 1.17 视觉简洁 2 设计规范 2.1 屏幕分辨率及 DPI 2.2 窗口尺寸 2.3 控件尺寸 2.4 控件间距 2.5 位置 2.6 焦点 2.7 对齐 2.8 无障碍访问特性 3 推荐尺寸与间距

“布局”是指窗口或页面内各内容的尺寸、间距及位置。有效的布局对于帮助用户快速找到他们想要的东西至关重要，并可产生具有吸引力的视觉外观。有效的布局可以使有的设计用户立即就可以理解，而有的设计却使用户觉得困惑而不知所措。

注：与窗口管理相关的设计规范请参考各自相应的章节。特定控件的推荐尺寸与间距则请参考相应的设计规范章节。

设计理念

视觉层次

当窗口或页面的外观能够表明各个元素之间的关系和重要性时，即可认为是具有清晰的视觉层次。如果缺少视觉层次，用户就得靠他们自己来分辨它们之间的关系与重要性。

视觉层次是通过巧妙结合下列属性来实现的：

• 焦点。该布局指出用户首先要看的位置。
• 流。当目光顺畅自然地沿着清晰的路径在界面上移动时，看到的用户界面（UI）元素即是适合其使用的顺序排列的。
• 分组。在逻辑上相关的 UI 元素之间具有清晰的视觉关系。相关的项被组合在一起，不相关的项则被分开。
• 强调。根据 UI 元素的相对重要程度进行强调。
• 对齐。UI 元素并列排放，使其便于扫视并依次呈现。

另外，有效的布局还具有下列特性：

• 设备无关性。布局的呈现应当与字型、字体大小、分辨率（DPI）、显示器或显卡无关。
• 易于扫视。用户可以只扫一眼就找到他们要的内容。
• 高效性。那些尺寸较大的 UI 元素就应该这么大，而小的元素也能照样很好地使用。
• 尺寸可缩放性。如果有用的话，窗口尺寸可以缩放，而无论界面的尺寸多大或者多小，其内容的布局都能够保持有效。
• 平衡。内容匀称地分布在界面上。
• 视觉简洁性。这是说布局不要比它所应有的更复杂。用户不会觉得布局的外观复杂得让人头晕。
• 一致性。类似的窗口或页面应当使用类似的布局，这样用户总能熟悉自己所处的环境。

虽然尺寸、间距和位置等概念非常简单，但在布局中正确混合使用这些属性却不是一件容易的事情。

在 Microsoft® Windows® 中，布局是用对话框单位（DLU）这样的设备无关度量单位和相对像素来描述的。关于布局度量单位、测量及换算的更多信息，请参考布局度量单位。

阅读设计模型

用户是通过内容的外观和组织形式来选择要阅读的内容的。要创建有效的布局，你需要理解什么是用户经常阅读的以及为什么如此。

你可以在决定如何布局时参考阅读设计模型：

• 人们以从左向右、自上而下的顺序阅读的（在西方文化中）。
• 阅读分为两种模式：沉浸式阅读（immersive reading）和浏览（scanning）。沉浸式阅读的目的在于理解。

该图所示的是沉浸式阅读模式。

相反，浏览的目标则是定位。一般的浏览路径看起来像是：

该图所示的是浏览模式。

如果文本排列在页面的左侧，则用户会先浏览左侧。

• 使用软件时，用户不会沉浸于 UI 本身，而是沉浸于他们的工作中。因此，用户不会真正阅读界面上的文本——他们只会浏览。他们只会在确信必要的时候才会仔细阅读大量文本。
• 用户通常会跳过页面左侧或右侧的导航部分。用户能够认出它们在那里，但仅当他们想进行导航时才去看导航部分。
• 用户通常会跳过大块无格式的文本而完全不去阅读。

用户在浏览时通常会跳过大块文本及导航部分。

• 一切都等价时，用户首先从窗口的左上角看起，扫过整个页面，到右下角结束。他们通常会忽略左下角。

一切都等价时，用户会以 1、2、4、3 的顺序阅读这些数字。

• 但在交互式 UI 中，并非所有的一切都是等价的，因此不同的 UI 元素所受到的关注程度也是不同的。用户通常会首先看交互式控件——尤其是出现在窗口左上角和中间的控件——以及显著的文本。

用户关注于主要的交互式控件及显著的主标题说明，其他东西只有在他们需要的时候才会去看。

• 用户倾向于阅读交互式控件标签，尤其是那些看起来和完成手头任务相关的。相反，用户仅在他们认为需要的时候才有可能去阅读静态文本。
• 看上去不同的内容容易吸引注意力。粗体文本和大号文本能够从普通文本中突显出来。彩色的或者是位于彩色背景上的用户界面元素较为突出。有图标比没有图标更加突出。
• 除非确实需要，否则用户不会进行滚动。如果没有理由来滚动倒金字塔结构的内容，用户则不会。
• 一旦用户决定要做什么，他们会立即停止扫视文本转而做事。
• 由于用户会在他们认为结束的时候停止扫视，因此他们可能会忽略所有在完成点之后出现的东西。

用户会在他们认为结束的时候停止扫视。

当然，常规模式也存在例外。眼动仪实验指出，真实用户的行为很没有规律。此模式的目的在于帮助你做出好的决定，而不是精确地描述用户的行为。但既然你已经阅读了该列表，希望你也能辩别出许多你自己的阅读模式。

为扫视进行设计

用户并不阅读，他们只是扫视——因此你应当为视扫来设计用户界面。不要假设用户会像书写那样从左至右、从上到下地阅读文本，事实上他们会看那些吸引他们注意的 UI 元素。

要为扫视进行设计：

• 假设用户先是会快速地扫一眼整个窗口，然后大致会按下面的顺序来阅读 UI 文本：
  1. 中间的交互控件
  2. 提交按钮
  3. 其他地方的交互控件
  4. 主标题说明
  5. 补充解释
  6. 带有警告图标的文本
  7. 窗口标题
  8. 正文区域的其他静态文本
  9. 脚注
• 将用于触发任务的 UI 元素放在左上角或上方中间。
• 将用于完成任务的 UI 元素放在右下角。
• 尽可能将重要的文本放在交互性控件上，而非使用静态文本。
• 避免将重要信息放在左下角或是需要滚动很多的控件或页面底端。
• 不要展示大段文本。去除不必要的文本。使用倒金字塔的呈现方式。
• 如果想吸引用户的注意，确保其理由充分。

尽可能使用这个模式而不要进行改变，但有时你可能需要强调或弱化某些 UI 元素。

要强调主要的 UI 元素：

• 将主 UI 元素放在扫视路径上。
• 将任何触发任务的 UI 放在左上角或上方中间。
• 将提交按钮放在右下角。
• 将其他主要的 UI 放在中间。
• 使用控件来引起注意，比如命令按钮、命令链接和图标。
• 使用显著的文本，包括大字体和粗体。
• 将用户必须阅读的文本放在交互式控件上，或者附加图标，或者放在横幅上。
• 使用位于浅色背景上的深色文本。
• 在元素周围留有足够的空白。
• 不需要任何操作就应当可以看到你要强调的元素，比如指向或悬停。

该示例显示了强调主要 UI 元素的多种方式。

要弱化次要的 UI 元素：

• 将次要的 UI 元素放在扫视路径之外。
• 将任何用户并不经常需要看到的内容放在窗口左下角或底部。
• 使用不会吸引注意力的控件，比如用任务链接代替命令按钮。
• 使用正常或灰色的文本。
• 使用位于深色背景上的浅色文本。深灰或蓝色背景上的白色文本也可以。
• 在元素周围使用最小间距。
• 考虑使用渐进展开方式来隐藏次要的 UI 元素。

该示例显示了多种弱化次要 UI 元素的方式。

有效利用屏幕空间

要有效利用屏幕空间，需要对多种因素进行平衡：占用太多空间使窗口显得臃肿且浪费，以及基于费茨法则来说甚至会难以使用。

错误：

在这个示例中，窗口相对于其内容来说太大了。

另一方面，使用太少空间会使窗口显得狭小、不适、有压迫感，而且难以使用——如果需要滚动或其他操作才能使用的话。

错误：

在这个示例中，窗口相对于其内容来说太小了。

虽然关键 UI 必须适合最小支持的屏幕分辨率，但不要认为有效利用屏幕空间就意味着窗口应该越小越好——事实上不是这样。高效的布局也顾及空白，并不是说把所有东西都塞到尽可能小的空间中去。现代显示器拥有足够的屏幕空间，应当尽可能有效地加以利用。因此，宁可占用过多屏幕空间，也不要使用太少。这么做可以使你的窗口感到更加轻便好用。

下列情况可以表明某布局确实有效地利用了屏幕空间：

• 不必调整窗口、面板及控件的尺寸即可使用。如果用户首先做的事就是调整窗口、面板及控件的尺寸的话，该尺寸则是错误的。
• 数据没有被截断。列表视图和树形视图中的大部分数据应当没有省略号，且其他控件中的数据不会被截断，除非数据特别的长。完成任务所必须阅读的数据则不应当被截断。
• 窗口和控件的尺寸恰当，没有不必要的滚动。仅有很少的水平滚动条，没有不必要的垂直滚动条。
• 控件基本使用其标准尺寸。尽可能减少控件不同尺寸的数量，比如，在某个界面上只使用一两种按钮宽度。
• 该用户界面平衡良好，没有大量未使用的屏幕空间。

选择恰好能够很好地适合其用途的窗口尺寸。（如果窗口是可缩放的，该条则应用于其默认尺寸。）被截断的数据或滚动条与大量可用屏幕空间的情况同时存在则是布局不当的明显标志。

控件尺寸

充分利用屏幕空间的第一步往往是决定各种 UI 元素的合适尺寸。参见控件尺寸表及各控件设计规范中的推荐尺寸部分。

费茨法则指出，目标越小，鼠标指向其所需的时间就越长。因此，对于那些使用 Windows Tablet 及触摸技术的计算机来说，这里所谓的“鼠标”事实上可能是手写笔或是用户的手指，因此你在为小控件确定尺寸的时候需要考虑其他输入设备。16x16 像素对于任何输入设备来说都是合适的最小控件尺寸。相反，15x9 像素的标准微调控件按钮对于手写笔来说则太小了一些。

间距

留出充足（但不过分）的间距会使布局看起来更加舒服并易于理解。有效的空间并不只是未被使用的空间——它扮演了非常重要的角色，使用户更容易进行扫视、且给你的设计增添了视觉吸引力。关于设计规范，参见间距表。

再次说明，对于使用 Windows Tablet 和触摸技术的计算机来说，“鼠标”事实上可能是手写笔或是用户的手指。当使用手写笔或手指作为定点设备时，定位会较为困难，以导致用户会点触到目标位置之外。当交互控件彼此靠得很近但并没有直接接触的话，用户可能会点击在控件之间的非交互区域。由于在非交互区域内点击不会产生任何结果或视觉反馈，用户往往无法确定哪里出了问题。如果小控件靠得过近，用户则需要非常精确地点触以避免误按其他对象。要解决这类问题，交互控件的目标区域要么彼此相接，要么之间留有至少 3 DLU（5 像素）。

具有良好间距的布局是指：

• 整体上来说，用户界面看起来舒适，没有束缚感。
• 间距均匀且平衡。
• 相关元素彼此靠近，无关元素则分开。
• 对于如何可以称为靠近是没有固定的值的，比如工具栏按钮。

可缩放窗口

可缩放窗口也是有效使用屏幕空间的一个因素。虽然这对于那些由固定内容组成的窗口来说没有什么帮助，但包含可缩放内容的窗口应当也是可缩放的。显然，用户缩放窗口的原因是可以利用额外的屏幕空间，因此窗口内容也应当相应地扩展，为需要的 UI 元素提供更多空间。可缩放窗口最适用于那些包含动态内容、文档、图像、列表及树的窗口。

在这个示例中，缩放窗口的同时会缩放列表视图控件。

这也意味着窗口可能被拉得太宽。例如，许多控制面板页在宽度超过 600 相对像素时会显得笨拙。在这种情况下，最好不要将内容区域缩放到超过最大宽度，或者是随着窗口的扩大而改变内容的原点位置。相反，应当保持宽度的最大值并固定左上角的原点位置。

当行宽不断增加时，文本会变得难以阅读。对于文本文档来说，考虑每行不超过 80 个字符以易于阅读。（字符包括字母、标点和空格。）

错误：

在这个示例中，文本太宽难以阅读。

最后，可缩放窗口在缩小时也需要有效使用屏幕空间，比如通过缩小可缩放的内容或是移除那些即使不存在也可以有效使用的 UI 元素。有时，窗口或其 UI 元素可能会太小而无法使用，则应指定最小尺寸或者有些元素应当完全移去。

在这个示例中，该面板具有最小尺寸。

对于有些程序来说，更好的方法是使用完全不同的呈现方式以使其内容在较小尺寸下仍保持可用。

在这个示例中，Windows Media Player® 在其窗口太小，无法使用其标准模式时，进行了改变。

焦点

当某种布局中存在一个明显会被最先看到的地方时即称为具有“焦点（focus）”。焦点非常重要，它告诉用户从何处开始扫视你的窗口或页面。如果没有清晰的焦点，用户的目光则会漫无目的地游荡。焦点应当位于那些用户需要快速找到并理解的重要内容处，且应当在视觉上予以强调。左上角是大多数窗口的自然焦点。

应当只存在一个焦点。在真实生活中，人眼一次只能聚焦在一件物体上，用户无法同时聚焦至多个位置。

要使某个 UI 元素成为焦点，可通过下列方式进行视觉加强：

• 置于界面上部的左侧或居中位置。
• 使用重要且易于理解的交互控件。
• 使用显著的文本，如主标题说明。
• 默认选中该控件并赋予输入焦点。
• 将控件置于不同的背景颜色上。

考虑一下 Windows 搜索。Windows 搜索的焦点应当在搜索框上，因为这是任务的起点。然而，为了与标准搜索框的位置保持一致，它被放在了右上角。虽然搜索框具有输入焦点，但是鉴于其在扫视路径上的位置，单单这样线索是不够的。

为了解决这个问题，窗口上方中部用一个显著的说明文字将用户引导至正确的位置。

可以接受：

在这个示例中，窗口上方中部的显著说明文字将用户引导至搜索框。

如果没有说明文字，该窗口将没有明显的焦点。

错误：

这个示例没有明显的焦点。用户不知道应当从何处开始。

如果你对某个 UI 元素进行了视觉加强，应当确保这种注意力是合适的。在之前那则错误的 Windows 搜索示示例中，高亮的 All 按钮位于左上角且是最为醒目的，然而它却并不是所期望的焦点。用户可能会停在这个按钮处，试图弄清应该怎么做。

错误：

失去了显著的说明作为焦点，高亮的 All 按钮意外地成了焦点。

流程

当用户能够顺着界面上清晰的路径而流畅自然地按合适的顺序找到他们想要的 UI 元素时，该布局即称为具有好的“流程（flow）”。一旦用户认出了焦点，他们就需要确定如何完成任务。UI 元素的位置传达了它们之间的关系，且应当反映出完成任务的步骤。通常来说，这意味着任务的各个步骤应当自然地从左至右、从上至下（在西方文化中）排列。

具有好的流程的布局应满足下列条件：

• UI 元素的位置反映出用户完成该任务需要的步骤。
• 触发任务的 UI 元素位于左上角或上方中部。
• 完成任务的 UI 元素位于右下角。
• 相关的 UI 元素相互靠近，无关的元素则分离。
• 必须步骤应在主流程中。
• 可选步骤应在主流程之外，可以使用合适的背景或渐进展开的方式进行弱化。
• 经常使用的元素比不常使用的元素出现在扫视路径上的位置更靠前。
• 用户始终知道下一步要做什么。任务流程中不存在出人意料的跳转或停止。

错误：

在这个示例中，用户不知道下一步该做什么。任务流程中存在出人意料的跳转和停止。

正确：

在这个示例中，UI 元素的呈现方式反映了完成任务所需的步骤。

分组

当那些在逻辑上相关的 UI 元素具有清晰地视觉联系时，该布局即可称为具有好的“分组（grouping）”。分组非常重要，因为这使得用户能够更加容易地理解并专注于一组相关而非单独的条目。分组可使布局显得更加简洁、易于理解。

你可以以下列方式进行分组（按分组程度由低到高排列）：

• 布局。你可以将相关的控件相互靠拢，并在无关的控件之间保留较大的间距。

在这个示例中，仅仅使用布局显示控件之间的关系。

• 分隔符。分隔符是用于划分控件分组的水平或垂直线条。分隔符提供了更加简洁的外观。不过，与分组框不同，它们在横跨整个界面时最为合适。

在这个示例中，带标签的分隔符用于显示控件之间的关系。

• 聚合器。聚合器是在强烈相关的控件间建立视觉联系的图形。

在这个示例中，边界聚合器用于强调控件之间的关系，使其看起来像是单个控件，而不是八个。

• 分组框。分组框是环绕在一组相关控件外的带标签的矩形框。

在这个示例中，分组框用于圈出并标注一组相关的控件。

• 背景。你可以使用背景来强调或弱化不同的内容。

在这个示例中，控制面板任务窗格用于对相关的任务和控制面板项进行分组。

要避免视觉混乱，能够达到效果的最轻量级的分组方式即是最好的选择。更多信息，参见分组框、选项卡、分隔符及背景。

无论使用何种分组方式，你都可以用缩进的方式在分组内部展示控件的关系。互相平行的控件应当垂直对齐，相互依赖的控件则应当缩进 12 DLU 或 18 像素。

有依赖关系的控件缩进了 12 DLU 或 18 像素，在设计上，这是复选框及单选按钮到其标签之间的距离。

分组良好的布局满足以下条件：

• 窗口或页面中最多包含 7 个分组。
• 每个分组的用途很明显。
• 各组控件之间的关系显而易见，尤其是控件间的依赖关系。
• 分组是对内容的简化，而不是使其更为复杂。

对齐

对齐是 UI 元素按照基准而排列的方式。对齐非常重要，因为这使内容更加易于扫视，并会降低用户所感受到的视觉复杂度。

当决定如何对齐时应当考虑下列目标：

• 易于水平扫视。用户能够水平阅读并依次找到相关的条目，没有任何不适当的间隙。
• 易于垂直扫视。用户可以扫视成列的相关条目并立即找到需要的内容，且只需最小的水平目光移动。
• 最小的视觉复杂度。如果某个布局在垂直方向上存在不必要的对齐网格线的话，用户会觉得它在视觉上较为复杂。

水平对齐

左对齐

由于从左至右的阅读顺序，使得左对齐适用于绝大部分内容。左对齐使得列数据易于垂直扫视。

右对齐

右对齐最适用于数值数据，尤其是成列的数值数据。右对齐也适用于提交按钮以及与窗口右边缘对齐的控件。

在这个示例中，高级搜索渐进展开控件是向右对齐的，因为它是对着窗口右边侧而放置的。

居中对齐

居中对齐最适用于那些左对齐和右对齐都不合适或显得不平衡的情况。

在这个示例中，媒体播放器控件是居中的，以保持外观平衡。

不要仅仅为了填充空间而将窗口内容居中。

错误：

在这个示例中，内容为了填充空间而错误地在可缩放窗口中居中。

垂直居中

元素顶端

由于自上而下的阅读顺序，使得顶端对齐适用于绝大部分内容。顶端对齐使得 UI 元素易于水平扫视。

文本基线

当控件与文本垂直对齐时，应当按照文本基线对齐以保持水平阅读流畅。

正确：

错误：

在正确的示例中，控件和其标签是按照各自的文本基线垂直对齐的。

对齐良好的布局应当满足下列条件：

• 水平和垂直方向都易于扫视。
• 简洁的视觉外观。

标签对齐

常规对齐规则适用于控件标签，但这也是值得特别注意的常见问题。标签对齐包含以下目的：

• 易于垂直扫视以找到相应控件。
• 易于水平扫视以将标签及其控件联系起来。
• 易于本地化，处理在不同语言中长度不同的标签。
• 适用于不同标签长度混合的情况。
• 避免截断文本的同时，尽可能有效利用可用空间。

总体目标在于当寻找用户可能需要的内容时减少必须的视线移动，但控件的特性以及用户需要的内容则取决于上下文环境。

以下是四种常见的标签摆放和对齐样式，以及各自的特点：

• 标签在控件上方左对齐
• 标签在控件左侧左对齐
• 标签在控件左侧左对齐，控件的左侧错开排列
• 标签在控件左侧右对齐

标签在控件上方左对齐

该样式最易于本地化，因为该布局不依赖于标签的长度，但这是在垂直方向最占空间的样式。

该样式在垂直方向最占空间但易于本地化。适用于标注绝大部分交互控件。

适用情形：

• 要标注的控件是可交互的（不仅仅是文本）。
• 该 UI 需要本地化。该样式通常有足够的空间来容纳双倍甚至三倍长度的标签。
• 该 UI 使用固定布局技术（比如 Win32）。
• 控件数量不超过 10 个。当控件数量更多时，扫视标签将变得困难。
• 垂直方向上有足够的空间放置标签。
• 布局需要是自由表单，而不仅仅是按列排列。

标签在控件左侧左对齐

该样式是纵向扫视时最为方便的，且当标签长度不一时也能够适用，但在将标签与控件关联起来方面较为困难。如果需要，该样式也可使用多行标签。

该样式很好用。不过，这里的两列看上去像是四列——数据看起来更加复杂。

适用情形：

• 用户需要纵向扫视以寻找特定的标签。
• 用户不太需要以从左至右、从上至下的方式阅读标签和控件。
• 水平方向上有足够的空间放置标签。
• 标签在长度上有巨大差别。
• 控件很多，比如在表单中。
• 列数较少。在视觉上，标签和控件像是两个独立的列。

标签在控件左侧左对齐，控件的左侧错开排列

该样式使得在纵向扫视标签以及横时同时扫视标签和控件时较为方便，而且空间利用率很高，但纵向扫视控件较为困难。控件右侧对齐以充分利用空间。

该样式布局紧凑，易于阅读，但对控件的纵向扫视较为困难。

适用情形：

• 该 UI 使用可变布局技术（比如 Windows Presentation Foundation）。
• 用户需要纵向扫视以寻找特定标签。
• 用户需要以从左至右，从上至下的方式阅读标签和控件。
• 用户不太可能需要纵向扫视控件。
• 控件文本的长度差别很大，如果使用其他样式可能会被截断。
• 控件是只读的，比如只读文本框。对于其他控件，这种对齐方式看起来有些糟糕。不过，控件可以在单击时变为可编辑状态。
• 列数较多，但每列中的控件较少。

标签在控件左侧右对齐

该样式是最易于横向阅读并将标签与其控件联系在一起的，但是在纵向扫视标签时较为困难且当标签长度差距很大时不太适用。

该样式易于阅读以及纵向扫视，但扫视标签而较为困难。

适用情形：

• 用户需要以从左至右、从上至下的方式阅读标签和控件。
• 用户不太会纵向扫视以寻找特定标签，可能是因为：
  • 控件数量较少。
  • 标签被人们熟知。
  • 控件几乎都是自描述的，且极少出现空白内容（也许具有默认值以防止出现内容为空的控件）。
• 水平方向上有足够的空间放置标签。
• 标签的长度差别不大。
• 列数很多。在视觉上标签和控件像是单独的一列。

然而，在决定使用上述任一样式之前，还应当考虑下列两个因素：

• 最好使用能够在你的程序各处一致使用的样式。
• 在控件上方或者左侧的左对齐标签是最常见的样式，应当优先考虑。

平衡

当窗口或页面的内容在整个界面上分布均匀时，即可称其为“平衡”。如果界面实际的复杂度与看起来相一致的话，平衡的布局则不会倒向一边。

最常见的问题是窗口或页面的左侧包含太多内容。你可以通过下列方法来取得平衡：

• 在左侧比右侧留出更大的边距。
• 将用于完成任务的 UI 元素放在右侧。
• 将贯穿用于整个任务的 UI 元素居中放置。
• 加长可缩放或多行控件。
• 适当使用居中对齐。

这个平衡良好的向导页布局通过在左侧比右侧留有更多的边距来取得平衡。

如果上述方法无法取得平衡，考虑减少窗口或页面的宽度以更好地适应其内容。

对于可缩放界面来说，不要仅仅为了取得平衡而将内容居中。相反，应当将其固定在左上角，定义最大界面区域，并在可用空间内对内容进行平衡。

网格

网格是不可见的底层对齐系统。网格可以是对称的，但非对称网格也同样适用。当用于单个窗口或页面时，网格有助于在界面上组织内容。当重用时，网格可以在各个界面之间建立统一的布局。

网格线的数量会影响视觉复杂程度。网格线数量较少的布局比网格线数量较多的布局显得简单。

看起来复杂：

看起来简单：

不必要的网格线增加了视觉复杂度。

一个有效使用网格的布局应当满足下列情况：

• 具有相似内容或功能的窗口或页面具有相似的布局。
• 在各窗口或页面上重复出现的设计元素位于类似的位置。
• 没有不必要的垂直或水平对齐网格线。

视觉简洁

视觉简洁（visual simplicity）是指，在感觉上某种布局的复杂度不比它实际需要的更高。

视觉简洁的布局应当满足下列情况：

• 去除了不必要的窗口层次。
• 展示内容时使用最多不超过七个分组，且应当易于识别。
• 使用轻量级的分组方式，比如用布局或分隔符来代替分组框。
• 使用轻量级的控件，比如将链接代替命令按钮用于辅助命令，以及将下拉列表代替列表用于多个选项。
• 减少垂直和水平的对齐网格线数量。
• 减少控件不同尺寸的数量，例如，在界面上只使用一两种按钮宽度。
• 使用渐进展开的方式隐藏 UI 元素，直至需要时再显示。
• 使用充足的空间，以使窗口或页面不会让人感到拥挤。
• 适当调整窗口和控件的尺寸以消除不必要的屏幕滚动。
• 使用一种字体，以及少数不同的尺寸和文本颜色。

作为一条通用法则，如果某个布局元素可以被去掉而不影响 UI 的有效性，则应当将其去除。

设计规范

屏幕分辨率及 DPI

• 支持 800x600 像素的最小 Windows 屏幕分辨率。对于那些必须可以工作在安全模式下或用于 Ultra-mobile PC（UMPC）及 Windows Media Center PC 的关键用户界面，应当支持 640 x 480 像素的屏幕分辨率。确保在垂直方向上为任务栏预留了 30 个像素的空间，以便在任务栏的情况下显示窗口。
• 要支持这些环境，即使当前屏幕分辨率低于你程序最小支持的分辨率，也仍然应当显示部分用户界面。该用户界面的功能可能受到限制。
• 为 1024x768 像素的屏幕分辨率优化可调整大小的窗口布局。自动调整窗口尺寸以适应较低的屏幕分辨率。
• 确保在 96 dpi 和 120 dpi 模式下测试你的窗口。检查布局问题、控件和窗口裁剪、以及图标和位图拉伸情况。
• 对于用于移动使用的程序，应为 120 dpi 进行优化。目前 Mobile PC 上普遍采用高 dpi 屏幕。

窗口尺寸

• 选择适合其内容的默认窗口尺寸。不要怕使用较大的初始窗口尺寸，只要你能够有效地利用空间即可。
• 使用平衡的长宽比。最好是 3:5 到 5:3 之间，尽管消息对话框可以使用 1:3 的长宽比（比如错误信息和警告等）。
• 尽可能使用可缩放窗口以避免出现滚动条或数据截断。可缩放窗口最适合于包含动态内容和列表的情况。
• 对于文本文档，考虑每行最多不超过 65 个字符以使文本易于阅读。（字符包括字母、标点和空格。）
• 对于固定大小的窗口：
  • 必须完全可见，且其尺寸应当适合其工作区。
• 对于可缩放窗口：
  • 可以为较高的分辨率进行优化，但在显示时应当根据需要按照实际屏幕分辨率进行调整。
  • 当窗口逐渐增大时应当也逐渐显示更多的信息。确保窗口中至少有一部分或一个控件具有可缩放的内容。
  • 在缩放窗口时，内容左上角原点的位置应保持不变。不要在窗口尺寸改变时通过移动原点来保持内容的平衡。
  • 如果内容可以被拉得很宽的话，应当设置最大内容尺寸。如果内容太宽而显得笨拙，则不要将内容区域缩放到超过最大宽度，或者随着窗口放大而改变内容的原点位置。相反，应当保持最大宽度以及固定的左上角位置。
  • 如果当窗口小于特定尺寸后内容不再可用，则应当设置最小窗口尺寸。对于可缩放控件，应当根据其最小的可用尺寸设计最小可缩放元素尺寸，例如列表视图中的最小可用列宽。可选的用户界面元素应当完全移去。
  • 考虑更改呈现方式以保存内容可以用于更小的尺寸。

在这个示例中，Windows Media Player® 在因窗口太小而标准形式不再适用时，改变了它的形式。

控件尺寸

• 所有可交互控件应当至少有 16x16 像素大。这样可以适用于所有输入设备，包括 Windows Tablet and Touch Technology。
• 调整控件尺寸以避免数据被截断。不要截断那些为了完成任务必须阅读的数据。调整列表视图的列宽以避免数据被截断。
• 调整控件尺寸以消除不必要的屏幕滚动。如果将控件稍稍调大即能消除滚动条的话，则应当这么做。应当仅有个别的垂直滚动条，没有不必要的水平滚动条。

在这个示例中，下拉列表的尺寸进行了调整以消除滚动条。

• 减少单个界面上的控件尺寸数量。尽可能使用标准推荐控件尺寸，使用少数尺寸统一较大或较小的控件。尽量为所有的列表框和树形视图使用相同的宽度，命令按钮和下拉列表不要使用超过三种宽度。不过，文本框和组合框的宽度应当暗示其输入内容的最大长度或预期长度。

在这个示例中，统一使用了一种列表框和命令按钮尺寸。

• 应当额外空出 30% 的长度（对于较短的文本来说，最多 200%）用于需要被本地化的任何文本（但不包括数字）。此条准则基于采用英文文本进行布局设计的假设。还需注意的是，此条准则所指的是被本地化的文本，而不是数字。
• 将静态文本控件、复选框及单选按钮扩展至贴合该布局的最大宽度。这将避免截断长度未知的以及本地化的文本。

错误：

在这个示例中，对控件文本进行了不必要的截断。

控件间距

• 如果控件之间并不直接相连的话，应当留出至少 3 DLU（5 个像素）的间距。否则，用户可能会点击在控件之间的非交互区域。由于在非交互区域内点击不会产生任何结果或视觉反馈，用户往往无法确定哪里出了问题。

位置

• 将 UI 元素在界面中按从左自右、从上自下的顺序（在西方文化中）自然地排列。UI 元素的位置将反映它们之间的关系，以及完成任务所需的步骤。
• 将用于触发任务的 UI 元素放在左上角或上方中间。对于用户应当先看的 UI 元素，应当给予最强的视觉强调。
• 将用于完成任务的 UI 元素放在右下角。
• 将相关的 UI 元素放在一起，将无关的元素分开。
• 将必须步骤放在主流程中。
• 将可选步骤放在主流程之外，可以使用合适的背景或渐进展开的方式进行弱化。
• 经常使用的元素比不常使用的元素出现在扫视路径上的位置更靠前。

焦点

• 将用户需要首先看到的一个 UI 元素设为焦点。焦点应当位于那些用户需要快速找到并理解的重要内容处。
• 将焦点放在左上角或上部居中。
• 给予焦点最强的视觉强调，比如显著的文本、默认选中以及初始输入焦点等等。

对齐

• 通常来说，使用左对齐。
• 数值数据应使用右对齐，尤其是成列的数值数据。
• 提交按钮应使用右对齐，以及与窗口右边框靠齐的控件。
• 当左对齐和右对齐都不合适或显得不平衡时，可使用居中对齐。
• 当控件与文本垂直对齐时，应当按照文本基线对齐以保持水平阅读流畅。
• 关于标签对齐，参考设计理念中的标签对齐部分。

无障碍访问特性

• 不要将布局用作传达关于某 UI 上的重要信息的唯一手段。具有视觉障碍的用户可能无法理解这种方式的呈现。例如，确保控件标签表达了它与其他项的关系。
• 不要通过在控件标签中嵌入附属控件来创建句子或短语。这种关联纯粹基于布局，而且不利于键盘导航和无障碍访问辅助技术。而且，这种做法无法进行本地化，因为不同语言中句子的结构会发生变化。

错误：

在这个示例中，文本框错误地放置在复选框的标签中。

• 使分组能够被无障碍访问。无障碍访问辅助程序能够自动处理那些由窗口面板、分组框、分隔符、文本标签和聚合器定义的分组。但仅由布局和背景来定义的分组则不行，必须通过编程方式来对无障碍访问进行定义。

更多设计规范，参见<a href="../../interaction/accessibility.aspx">无障碍访问（辅助特性）</a>。

推荐尺寸与间距

控件尺寸

下表列出了对于常见 UI 元素（在 96 DPI 下 9 pt 的 Segoe UI 字体）的推荐尺寸（宽 x 高，如果只有一个值则为高）。对于要进行本地化的文本（不包括数字），其宽度应当在基于英语中最长项的宽度之上再加 30% 以用于本地化（对于较短的文本来说，最多 200%）。

	控件	对话框单位	相对像素
	复选框	10	17
	组合框	最长项的宽度 + 30% x 14	最长项的宽度 + 30% x 23
	命令按钮	50 x 14	75 x 23
	命令链接	25（单行）或 35（两行）	41（单行）或 58（两行）
	下拉列表	最长有效数据宽度 + 30% x 14	最长项的宽度 + 30% x 23
	列表框	最长项的宽度 + 30% x 取项目条数整数（最少 3 项）
	列表视图	避免截断数据的各列总宽 x 取项目条数整数
	进度条	107 或 237 x 9	160 或 355 x 15
	单选按钮	10	17
	滑块	15	24
	文本（静态）	8	13
	文本框	最长或预期输入值的宽度 + 30% x 14（单行）+ 每增加一行加 10	最长或预期输入值的宽度 + 30% x 23（单行）+ 每增加一行加 16
	树形视图	最长项宽度 + 30% x 取项目条数整数（最少 5 项）

间距

下表列出了常见 UI 元素（在 96 DPI 下 9 pt 的 Segoe UI 字体）之间的推荐间距。

	元素	对话框单位	相对像素
	对话框边距	各边为 7	各边为 11
	文本标签与相应控件（例如，文本框及列表框）之间	3	5
	相关控件之间	4	7
	无关控件之间	7	11
	分组框内的第一个控件	距分组框顶端 11；与分组框标题垂直对齐	距分组框顶端 16；与分组框标题垂直对齐
	分组框内的控件之间	4	7
	水平或垂直排列的按钮之间	4	7
	分组框内的最后一个控件	距分组框底部 7	距分组框底部 11
	距分组框的左边	6	9
	控件旁边的文本标签	距离控件顶端 3	距离控件顶端 5
	文本段落之间	7	11
	交互控件最小间距	3 或无间距	5 或无间距
	非交互控件与任意控件的最小间距	2	3