何谓 对话框

　　" 对话框 " 是一种以文字与用户对话的用法者介面。其中，「警告对话框」（Alerts，以下简称警告框）一般用于公告用户发生了错误或警告，并询问下面的操作（赞同、不认可等等）。用警告框时需要十分注意，由于用户并不期望正在进行中的工作遭到打扰。
　　「确定 " 实行取消 “」和「取消 " 实行取消 “」

　　第一请看以下的图片：

　　对话框
　　这是一个警告框的例子，第一以说明文字询问用户是不是要中断现在的操作，接着给了「取消」和「好」两个作为行动的选项。看了这个例子之后有没感觉哪儿怪怪的？
　　文字内容意思
　　问句确定要取消编辑中的内容吗？确认是不是要抛弃编辑中的内容（两个选项）
　　赞同好抛弃编辑中的内容
　　不认可取消保留编辑中的内容
　　在这个语境中，系统向用户确认是不是赞同实行「取消编辑中的内容」。大多数赞同实行的用法者，或许会直觉地按下相同文字的「取消」按钮。可是如此的话并不会取消编辑。
　　由于这个取消按钮指的是「取消『取消编辑中的内容』」。也就是说，若想要如用户所想的抛弃编辑中的内容的话，需要选择另外一边的按钮。像是「取消实行取消 」这种具备双重否定意思的对话框，会让文字的意思变得复杂，应该要防止用。
　　那样大家试着改变按钮的用词来防止「取消实行取消」。
　　
　　如此应该就不会导致混乱了吧……？
　　但如此的修正方法并不好。只从「是」、「否」的文字，非常难想像按下按钮后的结果，用在对话框的按钮并不适合。
　　接着大家来尝试一下大伙肯定都看过的警告框。为了预防被大伙吐槽说明不够了解，大家加长说明文字，好似以下的图片：
　　
　　是！咦，等等，否？
　　由于这个警告框在最后说了「建议你事先储存」，想要这么做的用法者想来会直觉地按下「是」。然而，如果是选了「是」的话，就会实行原本询问的问题「取消编辑中的内容」，如此别说储存了，编辑中的内容反而会被删除，对用户来讲是最糟的状况。
　　设计简短、有逻辑且适合的文案
　　刚刚的例子可以说是因不适合的文案而导致的：「文字bug」。在 UI 设计的过程中，总是容易忽略文案的设计，如果是可以注意几个重点，「文字bug」是可以防止的。
　　大家再看一次刚开始的警告框：
　　
　　这个警告框的说明文字并不适合，并且选项的按钮用语也是不对的。
　　为何都不对呢？第一，在说明文字中直接用「取消」如此的字眼并不好，由于「取消」这个词常常用于表示否定意思的按钮上，应该防止用在问句中，以免导致混乱。另外，按钮的文字应该要能对应说明文字需要的动词。在前面的例子中用的「是」、「否」不是动词，用户非常难想像按下按钮后的结果是什么。为了理解意思所需的时间会比以直接以动词表示（比如「删除」、「抛弃」）的按钮还要久。
　　将「是」、「否」这种没逻辑性的文字用于按钮并不适合。具备否定意思的动作名字，请尽量地统一称作「取消」。在各作业系统中（iOS、macOS等），「取消」也是用来表示否定意思的统一用词。至于具备赞同意涵的按钮，如果是用「好」这个字在语境上读起来不会感觉奇怪的话，则可以放心用；需要更具体地传达意思的话，将「可以对应说明文字内容的动词」直接用于按钮的文字是最好的。
　　简洁地叙述说明文字
　　在说明文字中，尽可能不要频繁地用太过礼貌但不直接的句子。比如刚刚的例子中「确定要～吗？」的问句，从用情境来看，决定要抛弃编辑中的内容的是用户自己，因此大家可把说明文字再缩短成「要～吗？」的形式。
　　用户并非想要阅读文章，而是想要尽快地获得自己想要的内容，太旁敲侧击的说明只能让用户跟内容之间的距离变得更远。
　　看过上面这类讨论，大家可将这个警告框的说明文字中的「确定要取消编辑中的内容吗？」改写成「要抛弃编辑中的内容吗？」
　　
　　读者感觉怎么样呢？虽然跟刚开始的警告框比起来已变得最好懂了，但好像还有改变的空间。
　　考虑到破坏性操作
　　在警告框上的赞同操作「抛弃」同时也是破坏性操作，因此大家将它的按钮样式改成 Destructive Style（红色的文字）
　　这样一来就成为下图如此：
　　
　　由于「抛弃」除去是破坏性操作，在这个说明的语境中也具备赞同的意思，大家遵照 HIG（Human Interface Guideline）将它放在右侧，表示不认可的「取消」则放在左侧。 （在旧版的iOS HIG中，规定如果是具备破坏性操作的按钮，应该放在左侧，而取消则放在右侧，但在iOS 10中只规定将用户最大概选择的动作放在右侧。因此，像是在主画面删除App 时会出现的警告框，也像上图一样把取消放在左侧，并把套用了Destructive Style 的破坏性操作放在右侧。）
　　
　　看着非常像一回事了吧？不过其实还有一个大问题。
　　Action Sheet 的功能
　　上面的警告框看着好像非常完美了，但其实刚开始用警告框可能就是错误的。警告框是在用户不经意触发事件（错误等）时，用来询问用户的判断的一种 Modal View（模态视图）。考虑到这点后，这次的内容「抛弃编辑中的内容」并不符合这种情境。这个警告框是由于用户主动地按下关闭按钮才出现的，不可以说是「用户不经意触发的事件」。
　　在这里，Action Sheet 亮相了。 Action Sheet 也是一种对话框，它可以提供两种以上的操作选项，合适在用户主动操作的情境中用来询问是不是要删除内容。另外，即便合适用警告框的情境，如果是选项不少的话，也可以考虑改用 Action Sheet。
　　在 Action Sheet 中，肯定至少有一个同等于取消的按钮，因此选项包括了取消按钮后，一直有两个以上。用户随时都有中断马上实行的动作的权力。
　　
　　是否看着更像一回事了呢。
　　考虑 Action Sheet 的按钮配置
　　在刚刚完成的 Action Sheet 中，进一步询问用户是不是要储存内容好像也很好。因此大家需要增加一个按钮，如下面的表格，大家有两种增加的方法：
　　
　　经过以上的讨论，这次 Action Sheet 的设计，A才是正确答案。当然概念 App 本身的设计语言并且展示出独特的部分也非常重要，但第一更应该遵照系统平台的设计语言。
　　
　　考虑没选项时，警告框的按钮文字
　　
　　有些时候警告框只不过用来传达讯息，譬如在说明新功能的时候，会用到只有一个按钮的警告框。大家可想想在这种时候该怎么样设计按钮的文字。通常来讲，用「OK（好）」虽然没问题，但在不一样的语境中也大概需要改成其他文字。
　　另外，只有一个按钮的时候，将按钮设定为预设的样式（粗体字）会最好。
　　防止针对警告框本身的动作
　　
　　请防止在按钮上用「关闭」或「返回」等用来表示跳出警告框意思的文字。
　　读者可仔细想想「关闭」、「返回」所代表的语境，都是指涉「警告框」这个对象。用句子描述的话其实就是「关闭警告框」、「关闭警告框，并返回到之前的状况」的意思。但其实「关闭警告框」这件事是理所当然的，没必要特别提供一个「关闭警告框」的选项给用户去按。不管选项是代表赞同或不认可的按钮，只须按下就必然会关闭警告框，因此提供说明文字来讲明按下按钮后的结果是比较适合的。
　　假如想要在按钮上用「关闭」、「返回」等文字的话，请改用「OK（好）」就能了。大多数的状况下用「OK（好）」都不会有问题。
　　不要频繁地用对话框
　　对话框是在用户进行操作时强行介入的一种「模式」。在 App 中尽可能不要用警告框，也不要毫不考虑地用对话框。比如在 App 开启时跳出的「新消息」警告框，或者只不过告知用户操作的结果的警告框等，都要防止用。
　　结论
　　如果是需要在 App 中用对话框时，请注意以下要素来设计：
　　注意文字是不是简洁易懂并具一致性
　　防止用像是「取消的取消」如此的双重否定表现。尊重在作业系统中用的文字表现，并注意不要偏离。 「取消」是在系统中常常用于表示对于问句的否定，好似「保留字」普通的词，请勿在其他地方用它。
　　在按钮的文字上，推荐使用可以让用户预测到结果的动词。
　　想要在警告框中加入标题以外的补充文字时，请将文字写在 messageLabel（内文）中而不是 titleLabel（标题）。
　　遵守作业系统的规范
　　在 iOS 与 macOS 中，有「将表示赞同的动作放在右侧，表示不认可的动作放在左侧」的概念，请遵守这个资讯的排列规则。但注意在 Windows 或者旧版的 Android 中，这个规则刚好是反过来的。
　　在 iOS 中，也有「请在破坏性操作的按钮上用 Destructive Style（红色文字）」的规则，若用了会实行删除等操作的按钮，请考虑用 Destructive Style。
　　在用户主动选择行动时，用 Action Sheet 而不是警告框。
　　主角是用户与内容
　　不仅仅是对话框，所有些用户介面都不应该是主角。介面应该是连接用户与内容之间的桥梁，并且要尽可能维持透明，不干扰用户。
　　防止让用户意识到「关闭对话框」这个行为。在用户主动采取行动的同时，顺便也关闭警告框才是正确的，而不是让用户去关闭警告框。
　　不要频繁地用
　　防止什么讯息都用警告框表示。无论是跟 App 有关的新讯息，成功珍藏内容时的公告，开启 App 时的新功能介绍等等，在考虑用户的核心体验之后，再考虑是不是真的需要。
　　但在发生系统障碍、连线错误等没办法预期的紧急状况时，则可用警告框。

如没特殊注明，文章均为建站宝盒原创,转载请注明来自https://www.wcxywh.com/news/sheji/20250717/2478.html