韶关企业网站建设：真正的乐观用户界面

三个用户界面（UI）转到酒吧。第一个订购饮料，然后再喝几个。几个小时后，它要求账单，让酒吧喝醉了。第二个用户界面点一杯饮料，预先支付，订购另一杯饮料，支付等等，并在几个小时内让酒吧喝醉了。第三个UI在进入后立即退出酒吧 - 它知道酒吧如何工作并且足够有效而不会浪费时间。你听说过第三个吗？它被称为“乐观的用户界面”。

最近，在一系列致力于前端开发和用户体验的会议上讨论了心理性能优化，我惊讶地发现社区中乐观UI设计的主题很少。坦率地说，这个词本身甚至没有明确定义。在本文中，我们将找出它所基于的概念，我们将查看一些示例并回顾其心理背景。之后，我们将回顾有关如何保持对此UX技术的控制的关注点和要点。

韶关企业网站建设但在我们开始之前，要说实话，没有任何一件事可以被称为“乐观的UI”。相反，它是实现界面背后的心理模型。乐观的UI设计有其自己的历史和基本原理。

很久以前

很久以前 - 当“推特”这个词主要适用于鸟类时，苹果公司处于破产的边缘，人们仍然将传真号码放在他们的名片上 - 网络界面相当禁欲。而且他们中的绝大多数甚至都没有一丝乐观。例如，与按钮的交互可以遵循类似于以下的方案：

1. 用户单击一个按钮。

2. 该按钮被触发进入禁用状态。

3. 呼叫被发送到服务器。

4. 来自服务器的响应被发送回页面。

5. 重新加载页面以反映响应的状态。

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

• 用户必须等待。到目前为止，我们知道即使是服务器响应时间的最短延迟也会对用户对整个品牌的看法产生负面影响，而不仅仅是在这个特定页面上。

• 每次用户获得对其操作的响应时，都会以非常具有破坏性的方式呈现（加载新页面，而不是更新现有的页面），这会破坏用户任务的上下文并可能影响他们的思路。即使在这种情况下我们不一定谈论多任务处理，任何心理背景的转换都是令人不愉快的。因此，如果一个动作本身并不意味着切换上下文（在线支付是交换机自然的一个很好的例子），切换会在用户和系统之间建立一种不友好的对话基调。

好不好的日子

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

1. 用户单击一个按钮。

2. 按钮被触发进入禁用状态，按钮上显示某种微调器以指示系统正在工作。

3. 呼叫被发送到服务器。

4. 来自服务器的响应被发送回页面。

5. 根据响应状态更新按钮和页面的可视状态。

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

这种交互模式已经在数字媒体中广泛使用。但仍存在一个问题：用户仍需等待服务器的响应。是的，我们可以让我们的服务器响应更快，但无论我们如何努力加速基础设施，用户仍然需要等待。再次，用户不喜欢等待，温和地说。例如，研究表明，78％的消费者由于网站缓慢或不可靠而感到负面情绪。此外，根据 Harris Interactive对Tealeaf进行的一项调查显示，23％的用户承认诅咒他们的手机，11％的用户对他们尖叫，而且当遇到在线交易问题时，总共有4％的用户实际上扔了手机。延误是这些问题之一。

即使您在用户等待时显示某种进度指示器，除非您对该指示器非常有创意，否则现在这还不够。在大多数情况下，人们已经习惯了旋转器，表明系统运行缓慢。当用户除了等待服务器响应或完全关闭选项卡或应用程序之外没有其他选项时，旋转器现在更多地与纯粹被动等待相关联。那么，让我们想出一个改善这种互动的步骤; 让我们来看看这个乐观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设计时，我们谈论的是人机交互中的最佳响应时间。自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的推文很好地说明了这一点：

在网络上，这类活动的持续时间要短得多。让我们重温一下Robert B. Miller的作品。他引用的响应类型包括：

• 回应对所列信息的简单查询;

• 对图形复杂查询的回应;

• 回应“系统，你了解我吗？”

他将所有这些绑定到相同的2秒间隔，在该间隔内用户应获得相关类型的响应。如果不深入挖掘，我们应该注意到这个间隔也取决于一个人的工作记忆（指一个人可以在其头部保留一定量信息的时间跨度，更重要的是，能够操纵它）。对于我们来说，作为开发人员和用户体验专家，这意味着在与元素交互的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元素越简单，就越容易使其变得乐观。

• 将乐观模式应用于简单的类二进制元素，只需要成功或失败响应。例如，如果按钮点击假设服务器响应，例如“是”，“否”或“可能”（所有这些都可能代表不同程度的成功），那么在没有乐观模式的情况下这样的按钮会更好。

• 了解API的响应时间。这很关键。如果您知道特定请求的响应时间从未超过2秒，那么首先对您的API充满乐观可能是最好的。如前所述，乐观的UI最适合服务器响应时间少于2秒。超越这一点可能会导致意想不到的结果和许多沮丧的用户。考虑自己警告。

• 乐观的UI不仅仅是按钮点击。该方法可以应用于页面生命周期中的不同交互和事件，包括页面的加载。例如，骨架屏幕遵循相同的想法：您预测服务器将成功响应，以便填写占位符以尽快显示给用户。

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

韶关企业网站建设