对windows的标准对话框还可以加上时间限制的例子是一个对话框加上时间限制工具例子软件，“对话框”是让用户执行命令、向用户提问、向用户提供信息或进度反馈的辅助窗口。对话框由标题栏（用于标识对话框所来自的命令、特性或程序）、主标题说明（以解释用户在该对话框中的目标）、一些位于内容区域的控件（用于呈现选项）及提交按钮（以指出用户如何能够提交任务）组成。

对话框说明

在Windows操作系统中运行的软件应该遵照Windows UX规范。但目前主流的很多客户端软件并未完全遵照Windows UX规范，并且发展出了较多新的表现形式（也就意味着不符合Windows规范），也渐渐被人们所接受。尽管Windows UX规范并非评价对话框优劣的标准，但一些违反Windows UX规范的对话框的形式也势必会给交互体验上造成一定不良影响。以下将基于Windows UX规范针对客户端软件对话框进行解析。

1、标题

标题是用来表示对话框所来自的命令、特性或程序。通常以名词形式出现。命令形式以冠以“确认”“提示”的用法最为常见，其具有明确的任务导向，如图2，图3所示。特性主要是指类似于“设置”“属性”等作为标题。以程序名称作为标题形式，表示了对话框的出处，如图4所示。在标题形式中，并不提倡简单地使用“提示”作为标题。如图5所示。

（图2）

（图3）

（图4）

（图5）

2、主标题说明

主标题说明文本应使用显著的主标题说明来简要解释对话框需要做的事情。说明应当是明确的陈述句、祈使句式的指导，或是疑问句。文本应顶格左对齐，在有图标的情况下，以图标左对齐。如图6所示。主标题说明文本是陈述句的话，在末尾使用句号。如果说明文本是问句的话，则需要在末尾添加问号。对于进度对话框，应当使用动名词短语来简要地说明正在进行的操作，并以省略号结尾。例如：“正在打印图片…”。必要时，可以使用补充说明来提供额外的有助于理解或使用对话框的信息。补充说明用于详细解释主标题说明，而不是简单地换个说法（如图7所示）。如果主标题说明只会导致重复或者在上下文中显而易见的话，则不要硬是加上主标题说明。

顺带提一下，对于主标题说明中的人称问题，使用“您”为尊称，表达了软件作为工具的谦逊。也有人从平等的角度来将人称命为“你”亦可。

（图6）

（图7）

3、图标

对话框上的图标可分为两种，一种是程序、特性、对象图标。还有一种是标准图标。程序、特性、对象图标能帮助用户从视觉上认出程序的功能，或者是帮助用户识别问题中的对象，使用图标也能使功能具备自描述性。如下图8所示。

（图8）

标准图标有如下四种，错误图标、警告图标、信息图标和帮助图标，其说明和使用场景见图9。只有关键错误和警告才能使用错误图标和警告图标，用户需要一目了然地辨别信息的性质以及他们响应的后果，因此我们必须区分关键和非关键错误和警告。

关键错误和警告具有下列特征：（1）丢失重要的资料，如财务或其他数据。（2）无法访问系统或系统受损。（3）泄露隐私或失去机密信息的控制。（4）用户时间（大量时间，例如30 秒或是更多等）。（5）其后果不可预料。（6）需要立即采取正确措施，因为问题无法被轻易修复，而且很可能无法恢复。

对于错误图标和警告图标的区分使用主要界定点为错误是否已经发生，对发生的错误或问题使用错误图标，对在未来可能引发问题的情形使用警告图标。

（图9）

常见的图标错误使用有如下几种情况：

1）滥用错误图标和警告图标

对已经造成的错误应该使用错误图标。不严重的提示信息，应不使用警告图标。图10左右两图分别皆为警告图标错误使用。图11为错误图标使用错误。

（图10）

（图11）

2）滥用信息图标和帮助图标

信息图标并不在对话框中使用。帮助图标往往被作为疑问图标来用。对于用户来讲在对话框中将问号作为帮助图标来用并不常见，相反用问号来表示疑问却深得人心，也广受中国软件人的喜爱，包括微软的Office软件也这么使用。已经无法划清其对错的界限。

（图12）

3）非标准图标的使用

非标准图标的使用，这种情况下不能说它错。只能说是图标发展的一种多元化。大家都认可的图标所表达的含义，并且图标能很好的传达意思。这两点的具备已经足够说明这个图标的可存在性。如图13所示。

（图13）

4、提交按钮

常见的提交按钮的使用情况如下图14所示。

（图14）

规则并不一一罗列，选取关键的几条：

1），提交按钮向右对齐排成一行，置于对话框底部。应当以下列顺序呈现提交按钮：确定/[做某事]/是 、[不做某事]/否 、取消 、应用（如果有的话）、帮助（如果有的话）

2），对于主标题文本内容为“您确定要……吗”的句式的问题对话框，可使用“确定”“取消”组合，亦可以直接使用“是”“否”组合。但不要使用“确定”和“取消”来回答是否判断问题。除了上述情况外，“确定”“取消”组合时，“确定”的含义等同于“提交”，并且可更换为“提交”、“打开”等。如图15为错误例子。

（图15）

3）,不要为错误或警告信息使用“确定”按钮，应当改用“关闭”。如图16所示，出了问题一点也不 OK。应当改用“关闭”。

（图16）

同时若只是一些信息的呈现，也应该使用“关闭”，而不是“确定”。图17为Microsoft Office Word中的对话框，其使用了“确定”。然而特别是在中文语境中“确定”与“OK”的差异还是很大的，用“确定”表示“哦，我明白了”似乎也么有觉得不妥的地方。

（图17）

4），关于提交按钮焦点。由用户启动的对话框在显示时应当始终具有输入焦点。由程序启动的对话框则不应具有输入焦点，因为用户可能正在操作其他窗口，这种因对话框误导的操作可能会产生非预期的结果。同时将起始输入焦点赋予用户最有可能首先操作的控件。 这往往是（但并不总是）第一个交互控件。

5），在这里特别要提一下的是间接对话框的提交按钮。间接对话框是脱离上下文出现的，要么是某任务的间接结果，要么是系统或后台进程出现了问题而导致的。对于间接对话框来说，“取消”按钮存在歧义，因为它既可以表示取消该对话框，也可以表示取消整个任务。

如果用户需要将取消对话框和取消任务两个命令分开，应当提供取消按钮，将“取消对话框”的按钮标注为主标题说明的否定回答，将“取消整个任务”的按钮标注为“取消”，如图18例。在该图中，是用户点击关闭时出现的对话框，该对话框即为间接对话框，是一个与关闭没有直接联系的对话框。“不保存”的含义是关闭画图不保存。“取消”的含义是取消整个任务，即取消关闭。

如果用户只是需要取消对话框而非整个任务的话，应当使用明确针对主标题说明的否定回答按钮，并不需要“取消”。如图19例。该对话框是在安装程序时系统自动弹出的对话框，此时放置“取消”按钮的话其功能与“don’t run”重合。

这两者之间的差别关键点在于是否需要将取消对话框和取消任务两个命令分开。一个是用户自主触发的，一个是系统响应的。

（图18）

（图19）

在对话框的使用中，我们鼓励对话框窗体使用系统自带模式，其在各系统上的自适应性可减少界面UI定制所带来的复杂。

话说回来，不论遵循Windows UX规范也好，不遵循也罢，符合用户习惯并具有良好的交互体验才是判断对话框优劣的最佳标准。