为什么modal dialog是邪恶的？
回想最近的问题是什么时候模态对话是真正必要的？ 。 为什么modal dialog是邪恶的？ 是不是因为人们不读它们？ 因为他们经常执行得如此糟糕？ 别的东西？
到目前为止，大约一半的答案是解决确认对话框的缺陷，而不是模态对话框的缺陷。 尽pipe绝大多数确认对话是模态的，但这并不意味着这两个术语是同义的。
模拟对话框是一个将程序置于特定模式的对话框，它不允许您在打开时执行与该模式不对应的任何操作。 在最常见的实现中，这意味着你不能访问任何其他窗口。
这是邪恶的。
考虑一个地址簿应用程序。 假设你在地址簿中有一个现有的人，并且你想添加他们的室友。
- 如果“添加人员”对话框是非模态的，则可以在旧logging和新logging之间来回翻转，以复制和粘贴数据。
- 如果“添加人员”对话框是模态的，则在添加对话框打开时，您无法对旧logging执行任何操作。 select“添加”之前，您可以select要复制的内容，但只是一件事。 一切都必须手动重新input。
在极less数情况下，你遇到了一件真正必须要做的事情，而不会让用户在完成任务之前分歧。 modal dialog适用于这种情况。 但是这些情况非常罕见！ 这基本上是这个问题引用的另一个线程的点。
人们不读它们，这是一件好事。 你希望人们围绕你的用户界面形成习惯，但在popup窗口中有一个重要的select就是让用户点击OK。
他们中断用户，阻止用户做其他事情。
如果你想从主窗口复制粘贴东西呢？ 如果你想在modal dialog中复制信息呢？ 如果你不在乎怎么办
只需比较IE的查找对话框与Firefox
比较IE的“你想让我们为你记住这个密码吗？” 到Firefox
最好的用户界面是模式。 最糟糕的是
只要每种模式都符合用户转换的期望，模式UI（无论是从对话框，工具栏button还是文本提示构build而成）都是唯一需要的。 当程序意外地转换到模式中…或者模式要求用户拥有他不具备的信息时…那么这将导致用户吃苦，要么迫使他恢复到以前的模式，要么在适当的行动，可能会有不良后果。
非模态UI是一套完整的工具。 有些与手边的工作有关，有些则不是。 用户必须具有足够的技能来select正确的工具，并以正确的方式应用它们。 因此，非模态用户界面永远不会像优秀的模态用户界面（当前任务的正确工具已经存在）那样最优化，它也不会像坏模态用户界面那样次优（对于目前的任务砰砰入你粗心的手指）。
devise一个好的模态界面对于非平凡的应用来说是一个非常艰巨的任务，特别是对于那些旨在被广泛用户用于更广泛的目的的通用程序。 菜单系统和对话框试图缩小差距，允许在较大的非模态应用程序中使用特定于任务的小模态部分。 但是，这两者都没有什么特别好的地方，错误的使用和过度使用给他们留下了不好的名声，往往被认为是懒惰程序员的第一个避难所。 特别是对话框经常被用作强迫用户使用应用程序的程序员（或devise者）想法的手段，或者在用户面前进行困难的devise决策和棘手的error handling，而不是为了他们的同名目标通讯。
事实上，networking应用程序的兴起，在许多论坛，新闻组和网站等问答网站上引起了这样的倾向，因为程序员习惯于编写超线性逻辑，在程序需要时提示用户input，而不是在何时可用于用户…被迫进入用户可以非线性地导航的系统，并且可以认为任何限制这种自由的尝试都是一种被颠覆的古怪的烦恼，而不是一种必要的罪恶。 这些可怜的编码员的悲哀哀叹在“networking”周围回荡，因为他们试图迫使这种粗糙的模态行为进入一个非模态的系统，并将它们围绕在他们身上。 对于我们这些长期受到残酷对话困扰的人来说，这确实是一个可爱的曲调。
在阅读我的答案之前，您必须仔细阅读以下消息。 所有进程，subprocess，任务和线程将无限期地暂停，等待您的答案。 而且，一旦你完全理解了这个信息，并可能同意一些合法的东西，以及所有这一切的含意，那么只有这样你才能继续下去。
在消费者风格的应用程序中，它们或多或less是无用的; 用户不会阅读它们，学会解雇他们，而当他们阅读他们的时候，通常会被弄糊涂了。 我认为是/否/取消对话是完全懒惰的UIdevise。 “button说他们做什么”对话框稍微好一些，因为用户不必多读。
这就是说：在数据关键的内联网/“企业”应用程序中，它们或多或less地对确认破坏性行为或对可能允许但不被推荐的非标准工作stream进行完整性检查。
所以，我不认为他们在概念上是“邪恶的”，但往往是不好的UIdevise的结果。
他们是邪恶的，因为他们违反了用户应该能够指挥软件行动的基本原则。 modal dialog（通常是对话框的恶意forms）将用户限制为只有一个动作。
有些答案似乎错误地认为是要求用户确认的任何popup窗口。 这可以在不捆绑整个应用程序或计算机的情况下完成。 这是人们反对的这种行为。
在某些环境中，模态对话只能在单个应用程序的上下文中约束用户（或者更less）。 真正糟糕的模式对话框会阻止用户在整个操作系统（例如Windows）中执行其他任何操作。
我不喜欢它们的原因之一是因为它们是以连续的方式显示信息（一次一个信息）而不是平行的（所有你需要一次看到的信息），并行将允许用户select他们想要看看在哪里连续你几乎迫使他们select一个选项。
另外还有一个事实，就是他们打断了用户的控制权（例如，从你工作的对象那里偷取焦点），而我真的不喜欢这样做。 所以实际上，用户只需点击OK即可回到他们在做什么，并忽略对话框中的信息。
请注意，在某些情况下你仍然需要它们。
维基百科的文章有很好的总结投诉。
我不记得我第一次看到的是什么，但是更好的方式来进行模式对话通常是为了方便查找和使用“撤消”function。 Windows资源pipe理器实际上在删除文件时都执 它要求确认（modal dialog），然后，删除文件后立即编辑菜单有一个“撤消删除”选项。 只是一个简单的方式来访问回收站，当然，在这种情况下，微软真的可以刚刚取消对话框。
问题是，你经常可以在没有对话的情况下做一些思考，也许还有一些额外的代码，但是对于一个懒惰的，或者更为慷慨的，有时间限制的开发者来说，这是一个太简单的select。
这就是说，有时你真的想要一个对话。 考虑一下典型的“打印”对话框中的所有选项。 哪台打印机？ 所有页面，或只是几个？ 多less份？ 我不知道你会怎么做没有对话框…
Noboy读取它们，并打断程序stream程。 通常用作错误通知时，它们是程序故障的前兆。 当用户意识到发生了什么事情时，消息就消失了，他们只能尽可能地回想或发明消息。
我个人认为这完全取决于它是如何完成的。
尝试复制目标目录中每个文件都存在的10个文件，使用Windows资源pipe理器执行。
对于每个文件，单个modal dialog在这样的操作中确实是正确的答案。 我知道你有“对所有人是肯定的”，但是整个循环系统应该是不同的。 它应该已经把所有存在的文件收集到一个大列表中，并且询问一下“你想用这些文件做什么”，然后让我决定在列表中的每个文件下单击OK之前要做什么，然后恢复操作。
很多次对话框只是中断正常的工作stream程。
是的，人们不读对话框。 所以如果你必须使用对话框，那么一个黄金小窍门就是改写它。
而不是“你想删除数据库中的这一行？”，尝试措辞，以便你问（但这不是措辞正确）“你想不要删除数据库中的这一行吗？ 这样，如果他们只是打了“是”，这是一个用户的典型回应，他们最终什么也不做。
