最近的问题是什么时候模态对话真的有必要？.为什么模态对话框是邪恶的？是因为人们还是不读它们吗？因为它们经常实施得那么糟糕？别的什么？
到目前为止,大约一半的答案是解决确认对话的缺陷,而不是模态对话的缺陷.虽然绝大多数确认对话框都是模态的,但这并不意味着这两个术语是同义词.
一个MOD人对话是一个这使程序到一个特定的模式,并且不允许你做任何不符合该模式,而它是开放的.在最常见的实现中,这意味着您无法访问任何其他窗口.
这是邪恶的.
考虑一下地址簿应用程序.假设您在地址簿中有一个现有的人,并且您希望添加他们的室友.
如果"添加人"对话框是非模态的,则可以在旧记录和复制并粘贴数据的新记录之间来回切换.
如果"添加人员"对话框是模态的,则在添加对话框打开时,您无法对旧记录执行任何操作.在选择"添加"之前,您可以选择要复制的内容,但这只是一件事.其他一切都必须手动重新输入.
在极少数情况下,你会遇到一些真正必须在一个部分完成的事情,而不允许用户在完成之前偏离该任务.模态对话框适用于此类情况. 但这些情况非常罕见! 这基本上是这个问题引用的另一个线程的重点.
人们不会阅读它们,这是一件好事.您希望人们围绕您的UI形成习惯,但在弹出窗口中有一个重要的选择就是让用户点击确定.
它们会中断用户,阻止用户做其他事情.
如果您想从主窗口复制并粘贴某些内容,该怎么办？如果要在模式对话框中复制消息,该怎么办？如果你不在乎怎么办？
只需比较IE的查找对话框和Firefox
比较IE的"你想让我们为你记住这个密码吗？" 到Firefox
最好的UI是模态的.最糟糕的是.
模态UI - 无论是从对话框,工具栏按钮还是文本提示构建 - 只要每个模式符合用户转换到它的期望,这是唯一可取的.当程序意外地转换到某个模式时...或者该模式要求用户拥有他没有随时可用的信息......那么它将导致用户困难,要么迫使他恢复到以前的模式,要么猜测适当行动,可能产生不良后果.
非模态UI是一套完整的工具.有些与手头的工作有关,有些则不然.用户必须具备足够的技能来选择正确的工具,并以正确的方式应用它们.因此,非模态UI永远不会像良好的模态UI(当前任务的正确工具)那样最优,但它也可能永远不会像坏模式UI那样次优(错误的工具用于当前的任务猛烈闯入你粗心的手指).
对于非平凡的应用程序来说,设计一个好的模态UI可能是一个非常困难的任务,特别是对于旨在被各种各样的用户用于更广泛目的的通用程序.菜单系统和对话框试图弥合差距,允许在较大的非模态应用程序中使用特定于任务的小型模态部分.然而,两者都没有特别好的扩展,误用和过度使用使他们声名狼借,通常被视为懒惰程序员的第一个避难所.特别是对话框通常更多地用作强迫用户了解应用程序应该如何使用的程序员(或设计者)的想法,或者为用户提供困难的设计决策和棘手的错误处理,而不是用于他们的同名目标.通讯.
实际上,Web应用程序的兴起已经在许多论坛,新闻组和Q&A站点(例如此类站点)中出现了这种趋势,因为程序员习惯于编写超线性逻辑,在程序需要时提示用户输入,而不是在可供用户使用...被强制进入一个用户可以非线性导航的系统,并且很可能会将任何限制这种自由的企图视为一种被颠覆的古怪烦恼而不是必要的邪恶.这些可怜的程序员的悲惨哀嚎在"网络"周围回响,因为他们试图将这种粗略的模态行为强加于非模态系统,并在他们周围崩溃.对于我们这些长期遭受残酷"对话"困扰的人来说,这确实是一首可爱的曲调.
在您阅读我的答案之前,您必须仔细阅读以下完整的信息.所有进程,子进程,任务和线程将无限期暂停,等待您的回答.而且,一旦你完全理解了这个消息,并且可能同意一些合法的东西,以及所有这些的所有含义,那么只有这样才能继续.
在消费者风格的应用程序中,它们或多或少是无用的; 用户不会阅读它们,学会解雇它们,当它们阅读它们时,通常最终会感到困惑.我认为是/否/取消对话框是彻头彻尾的懒惰UI设计."按钮说出他们做什么"对话框略胜一筹,因为用户不必多读.
话虽如此:在数据关键型内联网/"企业"应用程序中,它们或多或少地需要确认破坏性操作或检查可能允许但不推荐的非标准工作流程.
因此,我不认为它们在概念上是"邪恶的",但往往是不良UI设计的结果.
它们是邪恶的,因为它们违反了用户应该能够指导软件操作的基本原则.模态对话框(通常是对话框的邪恶形式)将用户限制为仅一个操作.
一些答案似乎误解了它是任何要求例如用户确认的弹出窗口.这可以在不占用整个应用程序或计算机的情况下完成; 这是人们反对的这种行为.
在某些环境中,模态对话框仅在单个应用程序的上下文中约束用户(或者更少).真正糟糕的模态对话框会阻止用户在整个操作系统中执行任何其他操作(例如,Windows).
京公网安备 11010802040832号 | 京ICP备19059560号-6 