乐观用户界面的真实谎言

三个用户界面 (UI) 转到一个 pub。 第一个点了一杯酒，然后又点了几杯。 几个小时后，它要了账单，然后醉醺醺地离开了酒吧。 第二个 UI 点了一杯饮料，预先付款，再点一杯饮料，付款等等，几个小时后，酒吧就喝醉了。 第三个用户界面在进入后立即退出已经喝醉的酒吧——它知道酒吧是如何工作的，并且足够高效，不会浪费时间。 你听说过这第三个吗？ 它被称为“乐观的 UI”。

最近，在一些专门针对前端开发和 UX 的会议上讨论了心理性能优化后，我惊讶地发现社区中很少讨论乐观 UI 设计的话题。 坦率地说，这个术语本身甚至没有很好的定义。 在本文中，我们将找出它所基于的概念，我们将看一些例子并回顾它的心理背景。 之后，我们将回顾有关如何保持对这种 UX 技术的控制的关注点和要点。

关于 SmashingMag 的进一步阅读：

• 用户是匿名的网页设计师
• 设计基于卡片的用户界面
• 对话界面：我们今天在哪里？
  

但在我们开始之前，说实话，没有任何东西可以称为“乐观的 UI”。 相反，它是接口实现背后的心理模型。 乐观的 UI 设计有它自己的历史和基本原理。

曾几何时

很久以前——当“tweet”这个词主要用于鸟类时，苹果公司濒临破产，人们还在名片上写传真——网络界面相当苦行。 他们中的绝大多数人甚至没有一丝乐观。 例如，与按钮的交互可能遵循类似于以下的场景：

1. 用户单击一个按钮。
2. 该按钮被触发为禁用状态。
3. 呼叫被发送到服务器。
4. 来自服务器的响应被发送回页面。
5. 重新加载页面以反映响应的状态。

这在 2016 年可能看起来效率很低； 然而，令人惊讶的是，许多网页和应用程序仍然使用相同的场景，并且仍然是许多产品交互过程的一部分。 原因是它是可预测的并且或多或少防错：用户知道该动作已经从服务器请求（按钮的禁用状态暗示了这一点），并且一旦服务器响应，更新的页面清楚地表明此客户端-服务器-客户端交互的结束。 这种交互的问题非常明显：

• 用户必须等待。 到目前为止，我们知道，即使服务器响应时间的最短延迟也会对用户对整个品牌的感知产生负面影响，而不仅仅是在这个特定页面上。
• 每次用户获得对其操作的响应时，它都会以极具破坏性的方式呈现（加载新页面，而不是更新现有页面），这会破坏用户任务的上下文并可能影响他们的思路。 尽管在这种情况下我们不一定要谈论多任务处理，但任何心理环境的转换都是不愉快的。 因此，如果一个动作本身并不意味着切换上下文（在线支付是一个很好的例子，说明切换是自然的），切换会在用户和系统之间建立一种不友好的对话基调。

美好的不那么老的日子

然后，所谓的 Web 2.0 到来并提供了与网页交互的新模式。 其中的核心是 XMLHttpRequest 和 AJAX。 这些新的交互模式由“微调器”补充：最简单形式的进度指示器，其唯一目的是向用户传达系统正忙于执行某些操作。 现在，我们不需要在收到服务器响应后重新加载页面； 我们可以只更新已经渲染的页面的一部分。 这使网络更加动态，同时为用户提供更流畅和更具吸引力的体验。 与按钮的典型交互现在看起来像这样：

1. 用户单击一个按钮。
2. 该按钮被触发为禁用状态，并且按钮上显示某种微调器以指示系统正在工作。
3. 向服务器发送呼叫。
4. 来自服务器的响应被发送回页面。
5. 按钮和页面的视觉状态会根据响应状态进行更新。

这种新的交互模型解决了旧交互方法的上述问题之一：页面的更新没有破坏性的动作，为用户保留上下文并让他们比以前更好地参与交互。

这种交互模式在数字媒体中无处不在。 但是还有一个问题：用户仍然需要等待服务器的响应。 是的，我们可以让我们的服务器响应更快，但是无论我们如何努力加快基础设施的速度，用户仍然需要等待。 同样，用户不喜欢等待，委婉地说。 例如，研究表明，78% 的消费者会因网站运行缓慢或不可靠而产生负面情绪。 此外，根据 Harris Interactive 为 Tealeaf 进行的一项调查，23% 的用户承认在他们的手机上咒骂过，11% 的用户曾对他们大喊大叫，还有 4% 的用户在遇到在线交易问题时实际上扔掉了手机。 延误是这些问题之一。

即使您在用户等待时显示某种进度指示器，除非您对指示器非常有创意，否则现在这还不够。 在大多数情况下，人们已经习惯了使用微调器来指示系统运行缓慢。 Spinners 现在更多地与纯粹的被动等待相关联，当用户除了等待服务器的响应或完全关闭选项卡或应用程序之外别无选择。 所以，让我们想出一个改进这种交互的步骤； 让我们看看这个乐观 UI 的概念。

乐观的用户界面

如前所述，乐观的 UI 只不过是一种处理人机交互的方式。 为了理解它背后的主要思想，我们将坚持我们的“用户点击按钮”场景。 但是对于您可能希望乐观的几乎任何类型的交互，原理都是相同的。 根据牛津英语词典：

op-ti-mis-tic , adj. 对未来充满希望和信心。

让我们从“对未来充满信心”部分开始。

您怎么看：您的服务器多久会在某些用户操作上返回错误？ 例如，当用户单击按钮时，您的 API 是否经常失败？ 或者，当用户单击链接时，它可能会失败很多？ 坦白说，我不这么认为。 当然，这可能会根据 API、服务器负载、错误处理级别以及您作为前端开发人员或 UX 专家可能不愿意参与的其他因素而有所不同。但只要 API是稳定且可预测的，并且前端在 UI 中正确传达合法操作，那么响应用户发起的操作的错误数量将非常低。 我什至会说他们永远不应该超过 1% 到 3%。 这意味着在 97% 到 99% 的情况下，当用户单击网站上的按钮时，服务器的响应应该是成功的，没有错误。 这值得从一个更好的角度来看待：

想一想：如果我们对成功的反应有 97% 到 99% 的把握，我们就可以对这些反应的未来充满信心——嗯，至少比薛定谔的猫对未来更有信心。 我们可以写一个关于按钮交互的全新故事：

1. 用户单击一个按钮。
2. 按钮的视觉状态立即触发进入成功模式。

而已！ 至少从用户的角度来看，没有更多的东西——没有等待，没有盯着禁用的按钮，也没有另一个烦人的微调器。 交互是无缝的，系统不会粗暴地介入以提醒用户自己。

从开发者的角度来看，完整的周期是这样的：

1. 用户单击一个按钮。
2. 按钮的视觉状态立即触发进入成功模式。
3. 呼叫被发送到服务器。
4. 来自服务器的响应被发送回页面。
5. 在 97% 到 99% 的情况下，我们知道响应会成功，因此我们不需要打扰用户。
6. 只有在请求失败的情况下，系统才会说话。 暂时不要担心这一点——我们将在本文后面讨论这一点。

让我们看一些乐观交互的例子。 您可能熟悉 Facebook 和 Twitter 上的“点赞”按钮。 让我们来看看后者。

显然，它从单击按钮开始。 但是请注意当用户不再按下或悬停在按钮上时按钮的视觉状态。 它立即切换到成功状态！

让我们看看此时浏览器开发者工具的“网络”选项卡中发生了什么。

“网络”选项卡显示服务器请求已发送但仍在进行中。 “点赞”计数器的数量还没有增加，但随着颜色的变化，界面清楚地向用户传达了成功，甚至在服务器响应之前。

从服务器接收到成功响应后，计数器会更新，但过渡比即时颜色更改要微妙得多。 这为用户提供了流畅、不间断的体验，无需任何感知等待。

另一个乐观互动的例子是在 Facebook 上看到的，它有自己的点赞按钮。 场景非常相似，只是 Facebook 会立即更新计数器以及按钮的成功颜色，而无需等待服务器的响应。

不过，这里要注意一件事。 如果我们查看服务器的响应时间，我们会发现它是1 秒多一点。 考虑到 RAIL 模型推荐100 毫秒作为简单交互的最佳响应时间，这通常会太长。 但是，由于这种交互的乐观性质，在这种情况下用户不会感觉到任何等待时间。 好的！ 这是心理表现优化的另一个例子。

但让我们面对现实吧：服务器返回错误的几率仍然是 1% 到 3%。 或者用户可能只是离线。 或者，更有可能的是，服务器返回技术上是成功的响应，但响应包含必须由客户端进一步处理的信息。 结果，用户不会得到失败指示，但我们也不能认为响应成功。 要了解如何处理此类情况，我们首先应该了解乐观 UI 为何以及如何在心理上发挥作用。

乐观 UI 背后的心理学

到目前为止，我还没有听到有人抱怨上述主要社交网络上的乐观互动。 所以，假设这些例子让我们相信乐观的 UI 是有效的。 但为什么它们为用户工作？ 他们工作仅仅是因为人们讨厌等待。 就是这样，伙计们！ 您可以跳到文章的下一部分。

但是，如果您仍在阅读，那么您可能有兴趣知道为什么会这样。 所以，让我们更深入地挖掘一下这种方法的心理基础。

一个乐观的 UI 有两个基本要素值得进行心理分析：

• 对用户动作的快速响应；
• 处理服务器、网络和其他地方的潜在故障。

快速响应用户操作

当我们谈论乐观的 UI 设计时，我们谈论的是人机交互中的最佳响应时间。 早在 1968 年就已经提出了这种类型的通信建议。当时，Robert B. Miller 发表了他的开创性文章“人机对话事务中的响应时间”(PDF)，其中他定义了多达 17 个用户可以从计算机获得的不同类型的响应。 其中一种类型米勒称之为“对控制激活的响应”——按下按键和视觉反馈之间的延迟。 即使早在 1968 年，它也不应该超过 0.1 到 0.2 秒。 是的，RAIL 模型并不是第一个推荐这个的——这个建议已经存在了大约 50 年。 不过，米勒指出，即使是这种短暂的反馈延迟，对于熟练的用户来说也可能太慢了。 这意味着，理想情况下，用户应该在100 毫秒内得到对其操作的确认。 这正在进入人体可以执行的最快的无意识动作之一——眨眼。 出于这个原因，100 毫秒的间隔通常被认为是瞬间的。 伦敦大学学院神经病学研究所的 Davina Bristow 说：“大多数人每分钟眨眼 15 次左右，眨眼平均持续 100 到 150 毫秒，这意味着我们每年至少要花 9 天时间眨眼。 ”

由于它的即时视觉响应（甚至在实际请求完成之前），乐观的 UI 是用于心理性能优化的早期完成技术的示例之一。 但是，人们喜欢在眨眼间做出反应的界面这一事实对我们大多数人来说并不令人惊讶，真的。 而且实现起来也不难。 即使在过去，我们也会在按钮被点击后立即禁用它们，这通常足以确认用户的输入。 但是界面元素中的禁用状态意味着被动等待：用户对此无能为力，也无法控制该过程。 这对用户来说是非常令人沮丧的。 这就是我们在乐观 UI 中完全跳过禁用状态的原因——我们传达积极的结果，而不是让用户等待。

处理潜在故障

让我们来看看乐观 UI 设计的第二个有趣的心理方面——潜在故障的处理。 一般来说，有大量关于如何以最佳方式处理 UI 错误的信息和文章。 然而，虽然我们将在本文后面看到如何处理故障，但在乐观 UI 中最重要的不是我们如何处理错误，而是何时处理。

人类自然地将他们的活动组织成团块，以完成主观定义的目的或子目的而终止。 有时我们将这些团块称为“思路”、“思路” (PDF) 或简称为“流程”。 心流状态的特点是享受高峰、精力充沛的专注和创造性的专注。 在流程中，用户完全沉浸在活动中。 Tammy Everts 的推文很好地说明了这一点：

在网络上，此类活动的持续时间要短得多。 让我们暂时回顾一下罗伯特·B·米勒的作品。 他引用的响应类型包括：

• 对所列信息的简单查询的回应；
• 以图形形式对复杂查询作出回应；
• 回应“系统，你懂我吗？”

他将所有这些都与用户应该获得相关类型响应的相同2 秒间隔联系起来。 无需深入挖掘，我们应该注意到这个时间间隔还取决于一个人的工作记忆（指的是一个人可以将一定数量的信息保留在脑海中的时间跨度，更重要的是，能够操纵它）。 对我们来说，作为开发人员和 UX 专家，这意味着在与元素交互的 2 秒内，用户将进入一个流程并专注于他们期望的响应。 如果服务器在此时间间隔内返回错误，则用户仍将与界面“对话”，可以这么说。 这类似于两个人之间的对话，你说了些什么，而另一个人略微不同意你的看法。 想象一下，如果对方花了很长时间点头表示同意（相当于我们在 UI 中指示成功状态）但最后对你说“不”。 尴尬，不是吗？ 因此，一个乐观的 UI 必须在流程的 2 秒内将失败传达给用户。

有了如何在乐观的 UI 中处理失败的心理，让我们最终了解那 1% 到 3% 的失败请求。

乐观 UI 设计的悲观一面

到目前为止，我听到的最常见的评论是，乐观的 UI 设计是一种黑色模式——欺骗，如果你愿意的话。 也就是说，通过使用它，我们在向用户谎报他们交互的结果。 从法律上讲，任何法院都可能支持这一点。 不过，我认为这项技术是一种预测或希望。 （还记得“乐观”的定义吗？在这里，我们为其中的“希望”部分留出了一些空间。）“说谎”和“预测”之间的区别在于你如何处理那 1% 到 3% 的失败请求。 让我们看看 Twitter 乐观的“点赞”按钮在离线时是如何表现的。

首先，与乐观的 UI 模式一致，按钮在被点击后立即切换到成功状态——再次，用户不再按下或悬停在按钮上，与用户在线时按钮的行为完全相同。

但是因为用户离线，所以请求失败。

因此，应尽快在用户流程中传达故障。 同样，2 秒通常是这种流程的持续时间。 Twitter 以最微妙的方式传达这一点，只需恢复按钮的状态即可。

这里有良心的读者可能会说，这种故障处理可以更进一步，通过实际通知用户请求无法发送或发生了错误。 这将使系统尽可能透明。 但是有一个问题——或者更确切地说，是一系列问题：

• 任何突然出现在屏幕上的通知都会切换用户的上下文，促使他们分析失败背后的原因，这个原因可能会出现在错误消息中。
• 与任何错误消息或通知一样，此消息或通知应通过提供可操作的信息来指导用户在这个新的上下文中。
• 该可操作信息将设置另一个背景。

好的，现在我们都同意这有点复杂了。 虽然这种错误处理对于网站上的大型表单来说是合理的，但对于像单击“赞”按钮这样简单的操作来说，这是过度的——无论是在所需的技术开发方面，还是在用户的工作记忆方面。

所以，是的，我们应该对乐观 UI 中的失败持开放态度，我们应该尽快传达它，这样我们的乐观就不会成为谎言。 但它应该与上下文成比例。 对于失败的点赞，将按钮巧妙地恢复到其原始状态就足够了——也就是说，除非用户喜欢他们重要的其他人的状态，在这种情况下，事情总是能更好地工作。

极度悲观

可能会出现另一个问题：如果用户在获得成功指示后但在服务器返回响应之前关闭浏览器选项卡会发生什么？ 最不愉快的情况是，如果用户在请求发送到服务器之前关闭了选项卡。 但除非用户非常灵活或有能力减慢时间，否则这几乎是不可能的。

如果一个乐观的 UI 被正确实现，并且交互只应用于那些等待服务器响应时间不超过 2 秒的元素，那么用户将不得不在 2 秒的窗口内关闭浏览器选项卡。 击键并不是特别困难。 然而，正如我们所见，在 97% 到 99% 的情况下，无论选项卡是否处于活动状态，请求都会成功（只是不会向客户端返回响应）。

因此，只有 1% 到 3% 出现服务器错误的人可能会出现此问题。 话又说回来，有多少人急于在 2 秒内关闭标签？ 除非他们在标签关闭速度比赛中，否则我认为这个数字不会很大。 但是，如果您认为这与您的特定项目相关并且可能会产生负面影响，那么请使用一些工具来分析用户行为； 如果这种情况的概率足够高，那么将乐观交互限制在非关键元素上。

我故意没有提到请求被人为延迟的情况； 这些通常不属于乐观 UI 设计的范畴。 此外，我们在悲观方面花费了足够多的时间，所以让我们总结一下实现一个好的乐观 UI 的一些要点。

经验法则

我真诚地希望这篇文章能帮助你理解乐观 UI 设计背后的一些主要概念。 也许您有兴趣在下一个项目中尝试这种方法。 如果是这样，在开始之前请记住以下几点：

• 到目前为止，我们讨论的所有内容的先决条件：确保您所依赖的 API 是稳定的并返回可预测的结果。 说够了。
• 在将请求发送到服务器之前，接口应该捕获潜在的错误和问题。 更好的是，完全消除任何可能导致 API 错误的东西。 UI 元素越简单，就越容易让它变得乐观。
• 将乐观模式应用于简单的类似二进制的元素，这些元素只需要成功或失败的响应。 例如，如果按钮单击假定服务器响应为“yes”、“no”或“maybe”（所有这些都可能在不同程度上代表成功），那么如果没有乐观模式，这样的按钮会更好。
• 了解 API 的响应时间。 这是至关重要的。 如果您知道特定请求的响应时间永远不会低于 2 秒，那么最好先对您的 API 保持乐观。 如前所述，乐观的 UI 最适合服务器响应时间小于 2 秒。 超出此范围可能会导致意想不到的结果和许多沮丧的用户。 认为自己受到警告。
• 一个乐观的 UI 不仅仅是按钮点击。 该方法可以应用于页面生命周期中的不同交互和事件，包括页面的加载。 例如，骨架屏幕遵循相同的想法：您预测服务器将成功响应，以便填写占位符以尽快显示给用户。

正如我们所见，乐观的 UI 设计在网络上并不是真正的新鲜事物，也不是一种特别先进的技术。 这只是另一种方法，另一种心智模型，可以帮助您管理产品的感知性能。 基于人机交互的心理方面，乐观的 UI 设计，当智能使用时，可以帮助您在 Web 上构建更好、更无缝的体验，而只需要很少的实现。 但是，为了使模式真正有效并防止我们的产品对用户撒谎，我们必须了解乐观 UI 设计的机制。

资源

• “人机对话事务中的响应时间”(PDF)，Robert B. Miller，秋季联合计算机会议，1968 年
• “引入 RAIL：以用户为中心的性能模型”，Paul Irish，Paul Lewis，Smashing Magazine，2015
• “移动网络压力：网络速度对情感参与和品牌认知的影响”，Tammy Everts，Radware 博客，2013 年
• 心流在人类发展和教育中的应用，Mihaly Csikszentmihalyi，2014
• “移动设计细节：避免使用微调器”，Luke Wroblewski，2013 年
• “为什么绩效很重要，第 2 部分：感知管理，” Denys Mishunov，Smashing Magazine，2015 年