樂觀用戶界面的真實謊言

三個用戶界面 (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 年