总的来说，模态界面会吸取大块岩石。另一方面，我想不出更好的方法来处理File Open ...或者Print ...，我认为这是因为

• 它们是偶发的，偶发的和短暂的动作，并且
• 它们本质上是原子的；我们或者完成所有打印选项的指定并进行浏览，或者取消整个显示。

让我们一起整理一下样式指南。建议任何使用对话框的情况下首选对话框的用例，以及为什么使用对话框的原因。对话框可以是非模式对话框吗？如果是这样，我们如何标记交易边界，因为"取消"不再具有明确的含义。例如，我们是否使用"应用"按钮？

解决方案

IMO，仅当我们必须处理对话框正在执行的操作或者在继续应用程序之前询问时，才应使用模态接口。在其他时间，如果我们使用的是对话框，则该对话框应为非模式对话框。

在执行非模式窗口时，我们可能要确保它们是唯一的：我们实际上并不需要两个相同的工具箱(例如在图形程序中)或者两个相同的首选项对话框(我在产品中看到过)，它们可以是充其量是令人困惑的。

另一方面，当"搜索/替换"对话框为非模态对话框时，我表示赞赏：我可以返回文档并取消上一次更改，跳过其他地方，等等。而不会丢失当前设置。

正如Stephen Wrighton的回答所指出的那样，模态对话框以某种方式告诉用户"停止其他所有操作并完成我们正在做的事情"，它有其用处。

如果需要安全，那么在用户登录窗口之前，我们不能(或者不应)使用应用程序的其余部分，除非我们已经登录。

我认为区别在于，如果显示对话框时用户在应用程序中可能有任何操作，那么它不应是模态的。这包括复制/粘贴操作。就个人而言，如果文件/打开和打印对话框也不是模态对话框，我会更喜欢它。我认为模态对话框是设计欠佳的标志，这是快速将代码发布出去的必要手段。

以我的经验，在UI中几乎没有什么应该是模态的。 Eclipse是最好的例子之一，并且可能是该站点的用户非常熟悉的例子。尽管它具有一些模式对话框，并且在这里我仅谈论核心IDE，但它们大致分为三类：文件操作，首选项对话框和参数对话框。

偏好对话虽然是传统的模态对话，但也不必是模态对话。我们所要做的只是看一下Mac OS首选项模型，该模型会立即进行配置更改，并且仅在更改可能对正在进行的工作造成破坏的情况下才引入模式行为。

简而言之，这就是我应该模态的一个很好的总结。此集合的例外情况应通过用法充分说明。

• 参数输入对话框(示例：重构向导。反示例：查找对话框)
• 文件操作
• 确认将立即产生破坏性作用的动作