我真诚地希望，这篇文章能帮助你理解乐观派UI设计背后的核心观念。
想象3个用户界面（UI）一起去了酒吧。第1个点了一杯酒，然后又再点了几杯。几小时后，它买了单，醉醺醺的走了。第2个界面点了一杯酒，直接把钱付了，然后又点了一杯酒，又马上买了单，几小时后也醉醺醺的离开了酒吧。第3个界面刚走进酒吧，马上就已经醉醺醺的离开了——它知道酒吧是干什么的，它非常讲求效率，一点时间也不浪费。你听说过这第3种界面吗？它就叫做“乐观派UI”。
乐观派UI设计并非乐观地看待页面——至少不仅限于此。（查看大图）
我最近参加了许多关于前端开发和用户体验的会议，讨论了心理表现最佳化，我很惊讶，乐观派UI设计是业界一个如此微不足道的话题。坦白说，这个术语本身都没有清晰的定义。本文中，我们来探讨它的基本概念，寻找一些案例，并回顾它的心理学背景。然后，我们讨论掌握这项用户体验技巧的关键。
开始之前，我得说，没有任何一个单独的界面能被称作“乐观派UI”。其实它是界面实现背后的心智模型。乐观派UI设计有它自己的历史和逻辑。
很久以前
很久以前——那时候“tweet”一词还只有鸟鸣的意思、苹果公司濒临破产、人们还会把传真号码印在名片上——网页界面相当单调。其中绝大多数没有一丝一毫的乐观意味。比如一个按钮的交互，可以遵循下面类似剧本来进行：
用户点击一个按钮。
按触发进入禁用状态。
一条请求发送到服务器。
服务器返回信息到页面。
页面刷新，反映出返回的状态。
那个年代，界面与乐观派扯不上什么关系。（查看大图）
站在2016年回顾这些，我们会觉得效率低下；但是相当惊人的是，同样的剧本仍然在许多网页和应用中上演，它仍然是许多产品的交互流程。原因在于它可以预测，而且或多或少总会出点错误：用户知道这项操作已经请求了服务器（禁用状态的按钮表明了这一点），当服务器有响应，更新后的页面清晰表明这种客户端——服务器——客户端的交互结果。这种交互方式的问题很明显：
用户必须等待。如今我们都知道，即使是最短的服务器响应延迟，也会对整个品牌，而非这个单独页面产生负面的用户感知。
每一次用户的操作得到响应，都会以一种相当破坏性方式呈现（整页刷新，而不是更新现有部分），会打断用户的任务流程，可能影响他们的思维轨迹。 我们甚至还没说到多任务，心理环境的任何变化都令人不愉快。那么，如果某个操作本意不是改变环境（在线支付就是个需要改变环境的好例子），那么这种改变会在用户与系统的交流中创造不友善的氛围。
不久以前
然后，所谓Web 2.0出现了，提供了新的页面交互模式。它的核心是XMLHttpRequest和AJAX。一种最简单的进度条形式：“菊花”，补足了这些新交互模式，它的基本目的就是告诉用户，系统正忙着处理事情。现在，服务器返回信息后，我们不必刷新页面了；我们只需要对已经渲染的页面进行局部更新。这使得网站更加动态化，为用户创造了更加顺畅和亲切的体验。一个按钮的典型交互如今是这样的：
用户点击按钮。
按钮触发变为禁用状态，按钮上显示出某种菊花图形，表明系统正在运转。
请求发送到服务器。
服务器返回信息到页面。
根据返回的状态更新按钮和页面的视觉状态。
这种新的交互模型解决了旧交互方式存在的一个问题：页面的刷新不会导致破坏性操作，保持用户所处环境不变。相比之前，这种交互亲切多了。
XMLHttpRequest和菊花解决了旧交互方式的一个问题：服务器响应会导致破坏性的刷新，改变整个环境。(查看大图)
这种交互模式已经广泛应用于数字媒介。但还有一个问题：用户仍然需要等待服务器反馈。当然，我们有办法加快服务器响应速度，但无论我们如何努力优化基础设备，用户仍然要等待。比如，研究表明78%的用户对于缓慢或不稳定的网站产生负面情绪。更有甚者，Harris Interactive为Tealeaf做的一份调查显示，23%的用户承认咒骂过自己的手机，11%冲自己手机大喊过，而且4%的用户在网络出问题时扔过手机。延迟就属于这类问题之一。
大约78%的用户面对缓慢或不稳定的网站时，会产生负面情绪。（查看大图）
即使在用户等待时展示某种进度条，如今也于事无补，除非进度条非常有创意。多数情况下，人们已经习惯性把菊花进度条当作系统缓慢的表现。菊花如今已经是一种纯粹的被动等待，用户毫无选择，要么等待服务器响应，要么关闭标签页或整个应用。那么，我们再进一步，改善这种交互；我们来看看乐观派UI的概念。
乐观派UI
正如前文所说，乐观派UI仅仅是处理人机交互的一种方式。要理解它背后的核心观念，我们还是要回到“用户点击按钮”这个场景。不过它的原则用在任何乐观派交互上都一样。牛津英文词典的解释如下：
乐观主义，形容词，对于未来充满希望和信心。
我们从“对未来充满信心”这部分说起。
想一想：用户操作引发服务器错误的频率高么？比如说，用户点击按钮时，你的API经常出错吗？或者用户点击某个链接时经常会出错？说实话我觉得不会。当然，API、服务器载荷、错误处理等级不同，表现也不一样。还有一些其他因素，作为前端开发或者用户体验专家，你可能不会考虑。但只要API稳定可靠，前端以适当方式反馈正确的UI操作，那么由用户触发导致的问题会特别少。以目前状况来看，我敢说不会超过1%到3%。这就意味着97%到99%的状况下，用户点击网站的某个按钮，服务器的响应应该是成功的，没有错误。应该从一个更好的角度来看待这个问题。
乐观派UI基于一个假设，用户点击按钮，服务器在97%到99%以上的状况下返回成功。（查看大图）
仔细想一想：如果97%到99%以上肯定是成功的响应，我们对于反馈就有充足信心——嗯，至少比薛定谔的猫有信心多了。我们就可以写出一个全新的按钮交互剧本：
用户点击按钮。
按钮的视觉状态立刻变为成功。
就是这样！至少从用户的角度来看，仅此而已——不用等待，不用盯着禁用状态的按钮，也没有烦人的菊花转。交互流畅无缝，系统不会粗暴地现身，提醒用户注意它的存在。
乐观派UI交互里根本没有禁用状态按钮和菊花。（查看大图）
从开发者的角度来看，完整的流程是这样的：
用户点击按钮。
按钮的视觉状态立刻变为成功。
请求发送到服务器。
服务器响应发回页面。
在97%到99%的状况下，我们知道响应会成功，所以不用再给用户添麻烦。
系统只会在请求错误的情况下现身。暂时不用担心这块——我们会在后文中讲到。
我们来看一些乐观派交互的案例。你可能很熟悉“点赞”按钮，Facebook和Twitter上就有。我们来看看Twitter的。
很明显，从点击按钮开始。但是请注意用户松开并移开鼠标时按钮的状态。它立刻变成了成功状态！
点了赞之后，Twitter立刻把它更新为成功状态。
此时，我们用浏览器开发人员工具，看看里面的“网络”标签栏发生了什么。
按钮的视觉状态改变，独立于服务器请求存在，此时服务器请求正在进行中。（查看大图）
“网络”标签表明，服务器请求已经发送，但正在处理中。“赞”计数器还没有增加，但由于颜色变了，界面上已经清晰表明了点赞成功，甚至服务器都还没有给出反馈。
服务器返回成功的响应后，计数器增加，但这个变化比色彩改变微弱得多。这就给用户提供了一种流畅连贯的体验，感觉不到任何等待。
尽管赞按钮在视觉上已经变为成功状态，计数器只在服务器响应确认成功后才变化。
在Facebook可以看到另一个乐观派交互的例子，也是点赞按钮。场景非常相似，不过Facebook是连着计数器一起直接变为了成功状态，完全没有等待服务器响应。
Facebook用了和Twitter一样乐观派交互，但它连着计数器一起更新了视觉状态。
但有一点要注意。如果我们观察服务器响应时间，会发现它大约在1秒多。考虑到RAIL模型建议采用100毫秒作为简单交互的最佳响应时间，相比之下1秒显得太长了。但是，用户感知不到任何等待，因为这种交互天然的乐观属性。非常棒！这是心理表现最佳化的又一个例子。
但我们要面对现实：仍然有1%-3%的可能服务器会返回错误。或者有可能用户断线了。又或者一种更有可能的情况，服务器在技术上返回了成功状态响应，但是这个响应仍然需要客户端进一步处理。因此，用户看到的不是失败提示，但我们也不能认为响应是成功状态。要了解如何处理这种状况，我们首先要了解乐观派UI在心理学上为何能起作用。
乐观派UI背后的心理学
目前为止，我还没有听谁抱怨过主流社交媒体上的乐观派交互，就是我们之前提到的那种。那么，我们可以说这些例子已经证明，乐观派UI是有用的。但为什么它们有用？这仅仅是因为人们讨厌等待。仅此而已啊，亲！你可以直接跳到下个章节了。
不过如果你继续往下读，说明你对深层原因感兴趣。那么，我们稍微深入一点，了解这种方式的心理学基础。
大脑研究帮助我们理解乐观派UI起作用的心理学成因。（查看大图）
乐观派UI有两个值得心理学分析的要素：
用户行为的快速响应；
服务器对于潜在错误的处理，无论是网络还是其他方面。
用户行为的快速响应
我们谈论乐观派UI设计时，我们谈的其实是人机交互中的最佳响应时间。早在1968年，这类交互就有了相关建议。当时，Robert B. Miller发表了他的开创性研究“人机对话的响应时间”（PDF），他在其中定义了不同类型的响应，用户可能从计算机得到的反馈多达17种。Miller将其中一种称为“控件操作响应”——按下按钮到得到视觉反馈的时间。甚至早在1968年，就规定了它不应该超过0.1-0.2秒。是的，这并不是RAIL模式首创——这个建议大约已经存在了50年。但是，Miller注明了，对于熟练的用户而言，这么短的延迟都可能太慢了。这就意味着，理想情况下，用户应当在100毫秒内获得操作的反馈。这就接近人体最快的潜意识动作——眨眼。因此，100毫秒的间隔给人感觉通常就是瞬间。“多数人每分钟眨眼大约15次，一次眨眼平均持续100到150毫秒”，伦敦城市学院神经学创立者Davina Bristow说，他还补充说：“这意味着我们每年有9天花在眨眼睛上。”
正由于瞬间的视觉响应（甚至在实际请求完成之前），乐观派UI在心理表现最佳化中，是一种已经完善的技巧。但事实上，那些人们喜爱的能在眨眼间响应的界面，对我们而言应该不算惊喜，真不算。而且这也不难做到。即使在很早以前，我们在用户点击按钮后，会将它变为禁用状态，这通常就足以表明用户的输入了。只不过，界面中的禁用状态意味着被动等待：用户什么也做不了，无法掌控整个过程。这对用户而言很令人扫兴。这就是为什么我们在乐观派UI中直接跳过了禁用状态——我们不让用户等待，直接给他积极的反馈。
处理潜在错误
现在我们进入乐观派UI设计中的第二个有趣的心理学问题——处理潜在错误。一般来说，有大量信息和文章讲述如何以最恰当的方式处理UI错误。但是，本文中讨论的错误处理，在乐观派UI中，最重要的不是如何处理错误，而是什么时候处理。
人们天生会把行为聚类处理，以主观定义的目标或者小目标达成为结束。有时候我们把这些聚类称作“思维轨迹”、“思维涌动” (PDF)，或者就简单称作“心流”。心流状态的特征包括乐趣达到巅峰、精力集中、创造力爆发。在心流状态中，用户完全被这项活动吸引。Tammy Everts的一条推特准确描绘了这点：
【图注：我喜欢心流状态的一切，除了一点，我会连续几个小时忘记眨眼。我的眼睛现在是这样的。】
有时候，辨认出一个人是否处于心流状态非常简单。（查看大图）
在网络中，这些活动聚类的持续时间短得多。我们回顾一下Robert B. Miller的作品。他指出，响应类型包括：
粗略浏览列表信息的响应；
仔细浏览图表信息的响应；
“系统，你明白我要什么吗？”的响应。
他把这几类都归为2秒延迟的类型，用户会获得相应类型的响应。如果不继续深究，我们应该注意，这些延迟也取决于一个人的记忆运转（这是指一个人记住一定量信息所需的时间，更重要的是，不仅记住，还要能运用）。我们作为开发者和用户体验专家，这意味着在操作了某个元素的2秒内，用户会短暂进入心流状态，专注于他们期待的响应。如果服务器在这个时间内返回错误状态，用户仍然处于与界面的“对话”中，这是个比喻。类似于两个人对话，比如你说了一句话，对方委婉地反驳你。想像一下，如果对方花了很长时间点头表示同意（等同于我们UI中的成功状态），但然后最终对你说“不”。这多尴尬啊？所以，乐观派UI必须在心流状态的2秒内传达出错误信息。
乐观派UI必须清楚表达错误状态给用户。最重要的是，它要在用户进入心流状态的2秒内发生。（查看大图）
现在我们掌握了这项心理原则，用来处理乐观派UI中的错误，下面我们就开始面对那1%-3%的失败请求吧。
乐观派UI的悲观一面
目前为止，我听到最多的言辞，是说乐观派UI是一种黑魔法——作弊，如果你这么想也对。也就是说，运用这种方式，我们就是在对用户撒谎，编造他们操作的结果。从法律上说，每个法庭可能都会认同这一点。但我仍然把这种技巧当作一种预期或是希望。（记得“乐观”的定义吗？我们在这里允许某些“希望”存在。）“撒谎”与“预期”的区别在于你如何对待那1%-3%的失败请求。我们来看看Twitter的乐观派“点赞”按钮在离线状态下的表现。
首先，点击按钮后它立刻变为成功状态，这符合乐观派UI模式——当用户松开并移开鼠标，它的表现和用户处于在线状态时一样。
离线状态下，Twitter的点赞按钮仍然在点击后产生视觉变化。（查看大图）
但由于用户离线，请求失败了。
（查看大图）
那么，在用户进入心流状态后，错误信息要尽快给出。2秒通常是心流的持续时间。Twitter以一种非常微妙的方式表达这一点，把按钮的状态还原回去了。
请求失败后，Twitter以一种低调的方式还原了按钮的视觉状态，没有在视觉上小题大做。（查看大图）
认真的读者会说，失败处理还能更进一步，准确告知用户请求没有发送出去，由于发生了某个错误。这就让系统尽可能保持隐形。但还有一系列问题：
屏幕上忽然出现的任何形式的通知，会改变用户的环境，刺激他们去分析失败背后的原因，但这个原因在错误信息中可能已经说明了。
就像所有错误信息或通知一样，它应该也要引导用户进入新的环境，提供相应的操作信息。
操作信息又会进入一个新的环境。
好吧，可能大家都觉得这开始有点复杂了。因为这样的错误处理对于网站的大型表单有意义，但对于像点击按钮这么简单的事情，它就杀鸡用牛刀了——对于所需的技术开发，还有用户的记忆运转，都太过了。
所以，没错，我们对乐观派UI中的失败要有开放心态。我们要尽快告知用户，保证乐观主义不会发展成谎言。但它应当与环境相称。对于点赞失败，还原按钮状态这样的微小提示足够了——也就是说，除非用户点击的是其他极其重要的状态，需要保证它时刻运转正常。
极端悲观
这就产生了另一个问题：如果用户获得成功的反馈，但是在服务器响应之前就关闭了浏览器标签页，怎么办？最讨厌的情况是，用户在请求发送到服务器之前就关闭了标签页。但除非用户极其敏捷，或者有本事减慢时间，这种情况很难发生。
如果乐观派UI运用得当，所有对于各元素的操作都在2秒内得到服务器反馈，那么用户就得在2秒内关闭浏览器标签页。这对于快捷键而言并不难；但是我们知道，97%-99%情况下，请求是成功的，无论标签页是否激活（只是响应没有发送回客户端而已）。
所以，只有对于那1%-3%的服务器错误，这才算一个问题。然后，有多少人在2秒内匆匆关闭页面？除非他们在比赛关闭标签页，我觉得这个数量没有什么意义。但如果你认为这个关系到特定的项目，可能会导致糟糕的后果，那就应该用一些工具来分析用户行为；如果这种场景存在的可能性足够高，就把乐观派交互限定在非重要元素上。
我有意没有提及那些故意延迟的请求；这些不在乐观派UI设计的范畴内。而且，我们在悲观方面讨论得已经够多了，现在我们来总结一下运用乐观派UI的核心要点。
经验法则
我真诚地希望，这篇文章能帮助你理解乐观派UI设计背后的核心观念。可能你很希望在下一个项目中运用这种方法。那么，开始前请牢记这些：
我们所有这些讨论的前提：你所依靠的API足够稳定，能够返回可预期的结果。这点无需多言。
界面要在向服务器发送请求之前，找出可能的错误和问题。最好能够完全去除可能会导致API返回错误的因素。UI元素越简单，越容易运用乐观派UI。
在简单的是非选项上运用乐观派模式，只有成功与失败两种响应的元素。例如一个按钮的服务器返回状态包含“是”、“否”、“有可能”（每一种都代表了不同程度的成功），这种按钮就不适合用乐观派模式。
了解API的响应时间。这点至关重要。如果你知道某个特定请求的响应时间一定在2秒以上，首先应该优化API到最佳性能。之前提到，服务器响应时间在2秒以内，乐观派UI才有最佳表现。超过2秒会导致难以预期的结果，用户会更加挫败。千万注意。
乐观派UI不仅仅是点击按钮。这种方式可以运用于页面中的各种不同交互，包括页面的加载。例如框架页面就运用了相同的观念：你预期服务器能成功返回信息，所以直接向用户先展示占位符。
（查看大图）
看得出来，乐观派UI设计并不是网页中的新奇事物，也不是什么先进技巧。这只是另一种方式，另一种心智模型，帮助你掌控产品的预期表现。乐观派UI设计基于人机交互的心理学基础，聪明地运用它，能够帮你的网站树立更好更流畅的体验，同时，需要做的其实很少。但是，为确保这种模式真正有效，避免产品向用户撒谎，我们必须理解乐观派UI设计的原理。
资源
“人机对话的响应时间” (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
“RAIL简介：以用户为中心的表现模型,” Paul Irish, Paul Lewis, Smashing Magazine, 2015
“移动端网页的压力：网速对于情绪与品牌认知的影响,” Tammy Everts, Radware Blog, 2013
心流在人类发展与教育中的应用, Mihaly Csikszentmihalyi, 2014
“移动端设计细节：避免转菊花,” Luke Wroblewski, 2013
“性能的重要性，第2部分：感知的掌控,” Denys Mishunov, Smashing Magazine, 2015
原文链接：https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/
