JavaScript的提示，确认和警报被认为是“过时的” [关闭]

最近，我一直在为体育馆开发基于Web的管理系统。他们以前的应用程序是用Visual Basic开发的。对于新应用程序，所有前端脚本都使用jQuery，服务器正在运行PHP和MySQL ...您知道，这是典型的基于el-cheapo linux的堆栈。

无论如何，我想知道为什么如今JavaScript的提示，确认和警报消息对话框没有得到充分利用。有很多用于模态窗口和警报消息的jQuery插件，它们试图模仿该语言已经提供的功能，并且每个浏览器都必须正确支持。

对于复杂的表单和特殊需求，可以使用手工制作或基于插件的解决方案，但是如果您只需要索取单个值或确认删除记录，为什么要将这样的开销添加到Web应用程序中？此外，当您使用提示，确认和警报时，iOS和Android提供了适应性强的消息对话框。

1. UX：消息框大多是邪恶的

从UX的角度来看，警报框在所有情况下都是不好的。在桌面应用中。在网络应用中作为警报或嵌入式JavaScript消息。到处。

如果您想知道为什么，可以阅读AlanCooper¹的About Face 3。它很好地说明了这是如何打断工作流程并烦扰用户的，以及当前软件中存在的几乎每个警告框都是多么严重。在页542，“哭泣的对话框”狼！“中解释说，常规关闭警报框，因此它们的模型被完全破坏。本书的第543页列出了三个主要的设计原则：

• 做，不要问。
• 使所有动作都是可逆的。
• 提供无模式的反馈，以帮助用户避免错误。

然后，作者告诉我们如何通过正确的设计方法替换警报框。

提示消息略有不同。而且，它们仍然破坏了您应用程序的用户体验。如果希望用户输入内容，请考虑使用文本框或文本区域，并在需要时使用JavaScript装饰它。不要偷懒，在RIA和启用AJAX的应用程序时代提供丰富的界面；在所有情况下，如果禁用JavaScript，将不会显示提示。

在网页中，警报框和提示都非常令人讨厌。一些例子：

1. 一些论坛允许您通过无限提示输入列表项来创建列表。这意味着在创建列表时，您无法使用页面本身，包括复制粘贴。您也只有一个小领域。那长文本呢？粗体和斜体呢？

2. “如果您继续，该照片将最终从您的个人资料中删除。确定吗？” 。当然可以！否则，我会点击“从我的个人资料中删除照片”吗？为什么您的Web应用程序假设我是如此愚蠢？实际上，作为GMail的Google应用程序显示了正确的方法。您可以删除，删除，销毁所需的任何内容，执行此操作后，该应用程序将显示一个小的“撤消”链接。

3. “您想参加我们最大的调查吗？” 。好吧，实际上我是在那里访问您的网站的，但是由于您烦扰您的烦人的消息，我宁愿走到其他地方。

4. “为了保护受版权保护的照片，在此网站上禁用了右键单击”。好吧，实际上我在发送评论之前右键单击以更改拼写检查器的语言。当然，我会在不检查拼写的情况下发送它。

结论：从用户体验的角度来看，应用程序大多数时候会错误地使用消息框。

可是等等！许多低质量的网站通过用覆盖整个页面的半透明背景来烦人的JQuery消息来代替烦人的警报框。因此，缺点仍然存在。

嗯，还有另一个原因不在Web应用程序中使用消息框：

2.设计：警报框有自己的设计

您根本无法设计警报框。您无法更改其颜色，大小，字体。这使用户感到更加烦恼：您正在使用Web应用程序，并且工作流被一条消息打断了，该消息似乎无处不在，甚至与该应用程序的视觉外观都不匹配。不算按钮的语言也与OS /浏览器语言匹配，而不与Web应用程序语言匹配。

对于设计人员而言，JavaScript消息比警报框强大得多。

它们也更加广泛​​。您可以添加粗体和斜体，也可以选择自己的按钮（关于：“很抱歉，您输入的密码无效。[重置我的密码] [尝试另一个密码] [取消]”？）²。

3. JavaScript：应用程序流程停止

显示警报框时，JavaScript会停止执行，直到用户单击为止。在网站上，可能没问题。使用网络应用程序时，通常会遇到问题。

4.沙箱：不要强迫用户重新启动计算机

还记得那些显示无穷数量的消息框的肮脏网站吗？对于没有足够技术背景的用户来说，能够继续工作的唯一方法实际上是重新启动计算机。这给我们带来了一个问题：警报框不在网站或Web应用程序的范围内。您无权阻止用户访问浏览器的其他标签³。

相同的问题迫使浏览器以不同的方式解决它。例如，Firefox在选项卡上显示警报时允许访问其他选项卡。另一方面，Chrome浏览器可让您检查是否不想再从页面获取任何警报框，但仍会阻止访问其他选项卡。

尽管Firefox的方法非常有效，但可以批评Chrome的方法（因为它仍然会阻止每个选项卡），并引起问题：如果用户被您的应用发出的多个消息框所困扰并检查了情况，该怎么办？试图展示一些真正重要的东西？是的，用户将永远不会看到它。

事实仍然是这样，大多数用户都会被警报框烦扰，因此他们仍然不是很友好的用户，并且可能会在没有足够技术背景的情况下严重阻塞用户。内联，JavaScript消息可能会阻止页面，但不会阻止浏览器本身。由于Web应用程序模型是一种沙箱，因此您无法例如访问用户键盘或重新启动计算机或从硬盘读取文件，进入全屏或使用两个监视器，因此警报框及其阻止效果会严重破坏此功能。沙盒模型。

最后但并非最不重要的一点是，如果您的应用程序决定显示警报框时用户在另一个选项卡上，该怎么办？如果用户正在做重要的事情，并且不想立即与您的应用进行交互，该怎么办？

^{¹ 关于《交互设计要点》第3张，艾伦·库珀（Alan Cooper），罗伯特·瑞曼（Robert Reimann）和戴维·克罗宁（David Cronin），ISBN 978-0-470-08411-3；第25章：错误，警报和确认。}

^{²这只是一个例子。请不要在您的Web应用程序中执行此操作，因为这确实是一个糟糕的设计选择。}

^{³如果您想与桌面应用程序的世界进行比较，那么内联JavaScript消息就像是桌面应用程序的消息框。另一方面，浏览器中的警告框就像一个窗口，从无处显示，设置为最上方，在全屏不透明背景上，阻止您访问任何其他桌面应用程序。任何决定在我的计算机上执行一次的应用程序将立即被永久删除。}

底线：默认的提示，确认和警报对话框与您的浏览器样式匹配，而不与您的网站样式匹配。大多数UI用户都希望所有对话框都随其网站的UI一起流动。他们使用模式窗口来呈现消息并使用与网站UI相同的字体和颜色来收集数据，而不是使用MSIE或FF的默认灰色和蓝色。

如果您不需要其他地方的精美对话框，则只会增加开销。那时，将功能包含在浏览器中还是包含在所使用的框架中并没有多大区别，并且还可以使所有弹出窗口保持一致。

尽管您可以使用javascript来做很多事情，但是没有框架，但是我记得在框架可用之前用javascript进行开发的感觉，并且我不想再回到它了。

因为浏览器不能很好地处理它们。正如您可能已经注意到的那样，它们通常是模式对话框，不仅阻止用户移动和调整浏览器的大小，而且还阻止其他选项卡的访问，这很烦人。

对于诸如确认和更改之类的对话框，我仍然认为浏览器应该强制执行该行为，对于最新的Firefox浏览器，您可以看到它们已经解决了我上面提到的问题。它们在范围限于当前页面的页面警报中使用。

因此，我建议您覆盖警报行为，以便所有浏览器都可以更优雅地处理（至少是警报）。

一些总结的原因：

• 这是标准的API，开发人员可以弄清楚您要做什么。
• 它更加人性化，并且看起来更好。
• 平台支持，移动站点可能需要本机API。