type
status
date
slug
summary
tags
category
icon
password
notion image

一、「心惊胆寒」的选择

与友相聚小酌，饭后约了代驾，在车边等候时，不慎误触「取消」，弹出一个界面问：是否取消？
节日期间，系统排队好久才「抢」到的代驾，我当然不要取消了！
但此时的界面，却宛如一道充满哲学智慧的两难选择题。
notion image
这个选择不仅关乎我们能否保住辛苦抢来的代驾，也关乎我们能否在寒冬顺利回家，更关乎我作为一个交互设计师的尊严……
通常来说，在交互设计逻辑中，二选一是最简单的，无非是 Yes or No。但此时的情况却很复杂：

推测 a

如果按「弹窗标题」与「选择的答案」关联来看：
标题：是否取消订单？
答案：取消 | 继续
结论：
  • 取消 = 取消（订单）
  • 继续 = 继续（订单）
但是经验告诉我，产品设计者的意思也可能是：

推测 b

如果按弹窗的一般原则来说，这个「继续」应该指「Yes」，而「取消」应该指「No」，而 Yes 和 No 的描述对象应该是指「是否取消订单？」。
结论：
  • 继续 = Yes，是的，取消（约司机）
  • 取消 = No，不要取消，继续（约司机）
你这样讲，好像也很有道理的样子呀？
等等！继续 = 取消？取消 = 不要取消？为什么感觉到哪里不太对？
来，我们一起再看看这个神奇的界面，你能肯定地说出哪个按钮才是「不要取消我的订单」吗
notion image
朋友们都笑了，说你想太多了！我们不能取消订单！小明果断出手，将「继续」点了下去。
界面显示：我们的订单被取消了。
取消了……
误操作在用户交互过程中是很常见的，如何将误操作的损失降低至最小，是我们应该思考的问题。长久以来其实我们常常会遇到这些「小问题」，不过一笑而过罢了。
但有时候，它不是一个小问题：
notion image
——————————在使用移动产品时，我们经常会遇到一个经典界面——对话框。优秀的对话框有助用户理解产品，并在关键节点帮助用户作出正确选择。而糟糕的对话框则会「帮倒忙」。
本文将重点谈谈我对「对话框」的观察，并告诉大家它将如何影响我们日常使用。

目录

  1. 对话框如何影响我们的使用？（您已读过）
  1. 影响对话框的 3 个因素
  1. 如何避免和利用「失误」
      2. (一段非正文的说明：这篇文章于2017年发表在科技媒体APPSO上，当时的结构中，此部分内容作为「引言」和「目录」，在文章的最开头。这次整理回自己的公众号时意识到在传播性的科普文章最前面加上「引言」和「目录」，是会影响阅读的感受的。因此，我将第1部分（即「心惊胆寒」的选择）作为故事化的开场，与这部分内容进行了顺序调换。这算是我「作文训练」中的一种思考和尝试。
——————————

二、发生了什么？对话框的几个小问题

本文中提到的这个「弹窗」，标准名称是「对话框」，是人机交互中的重要概念。在 Wiki 中的定义是：
notion image
……对话框是图形用户界面中一种特殊的视窗, 用来向用户显示信息以获得用户的响应，使计算机和用户之间构成了一个对话——以提供警告、通知、请求用户授权操作、或请求用户的输入等。
早期的 Windows 图形界面中，对话框一般长这个样子：
notion image
图：Windows 对话框 via UCDC 163

1. 文字描述的问题

选择性对话框通常是由一个肯定事件 一个否定事件（即与肯定的事件对立）共同组成，通过选择点击按钮来实现事件执行。
肯定事件不一定是积极的，也可能是消极的，或者破坏性的，比如删除、格式化等。以 Windows 为例，通常用「是」/「否」（Yes / No）来表示肯定和否定，如上图。
但有时候也用「确定」/「取消」（OK / Cancel）来表示，如下图。
notion image
如果一直就用「是」/「否」两选一，估计出错反而低一些，比如：
notion image
你确定删除这个文件吗？
是 | 否
你确定要退出？
确定 | 取消
你确定要移动这个文件吗？
是 | 否
看上去没有问题，对吗？
以上例子中：
  • 是 = 确定（肯定事件，继续当前动作）
  • 否 = 取消（否定事件，中止当前动作）
接下来这个对话框中，新的情况出现了：
notion image
原本「是」对应「否」，「确定」对应「取消」，现在却变成了三个同时出现，而且分别代表不同的意思：
  • 是 = 保存
  • 否 = 不保存
  • 取消 = 中止当前动作（等同于右上角的红叉）
这种由简单的「是」或「否」式的按钮文字表述，不能精确指向操作动作，需要用户在脑中理解翻译。于是，在图形界面的发展过程中逐渐出现了「用事件本身」来描述按钮。比如这样：
notion image
notion image
伴随着移动互联网的来临，人们要在小小的屏幕上完成一系列复杂操作，这对交互设计和产品体验提出了更高的要求，而上文中所用的「用事件本身」描述的原则被逐渐保留下来。
下图是移动界面中的一些对话框示范。
notion image
进而又变化出更多的形式（下图），但无论如何，都是以「描述得更精准」为目标。
notion image
但究竟如何才算「描述得更精准」呢？难道取决于设计人员或者开发人员的文字功底吗？
Google 的 Material Design 原则中有非常优秀的定义，这也是我近年看到最好的设计指导。
notion image
图源：Google Design
在这个官方的例子中，明确地定义了什么是「好的描述」：
The affirmative action text “Discard” clearly indicates the outcome of the decision.
notion image
合理的文字描述应该呈现的是选择所带来的结果（而不仅仅是描述选择本身）。
同时，文档中还对标题的提出了明确的要求：必须描述清楚这个行为，以及行为所带来的影响。
notion image
界面中的文字，绝不是修辞问题，而是事关信息传递是否正确的问题。
据以上的内容，我们可以定义出按钮文字的正确原则：「能描述行为本身，以及行为将带来的结果」。要避免 UI 界面的文字描述失误，最重要的是遵照正确的原则。

2. 按钮布局排序问题

你可能注意到了，Windows 的「肯定」行为在左，「否定」在右。
而 macOS 的布局排序似乎与此相反？
notion image
我没有找到 Windows 按钮布局排序的原因说明，也无法解释为是什么 Windows 的对话框的「肯定」行为是在左边。
但就江湖故事来推理的话，早年 Windows 大量抄袭了 macOS 的系统界面，但又不好意思全盘抄袭，于是来了个全盘大镜像，这也就是为什么它们的窗口关闭/最小化这些按钮一家在左上角，一家在右上角的原因……
而考虑到 macOS 的界面又来源于 Xerox，所以这事也没法细说……
notion image
图：Xerox 8100 的界面 via coolshell
为什么我要这样在意布局排序的问题？
这涉及到交互的一致性原则，我认为一致性是产品设计中最重要的原则之一：人的认知是有惯性的，在同一套系统里，相关属性应该保持一致，能大大降低用户的学习成本，减轻记忆负担。（相关属性包括但不限于颜色、尺寸、形状、位置、层级关系、形式等）
比如：家里所有的冷热水龙头，都应该保持左热右冷的方向一致原则，我们使用起来就会很方便。试想一下，家里所有的冷热水管都接反了——其实还好，稍适应一下就会习惯。
最糟糕的情况是，只有部分龙头的冷热水管被装反了——这将严重的破坏方向一致原则，使我们无法无法习惯操作所有的龙头。
同理，当我们使用 app 时，这种一致性会帮助我们快速反应。
notion image
图：iOS、Android 也继承 Unix 系的布局原则：肯定行为在右，否定行为在左。
在Material Design 中也对布局做了进一步规范：
notion image
Affirmative actions are placed on the right side and continue the process.
当然，移动系统的早期阶段，也经历了一段时间的混乱期 —— 不同的系统的按钮布局排序时而在左，时而在右。