亚洲乱色伦图片区小说,久久精品一区二区东京热

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

樂觀派UI：真實的謊言

可樂橙

2016-11-30

0 評論 7818 瀏覽 17 收藏

30 分鐘

我真誠地希望，這篇文章能幫助你理解樂觀派UI設計背后的核心觀念。

想象3個用戶界面（UI）一起去了酒吧。第1個點了一杯酒，然后又再點了幾杯。幾小時后，它買了單，醉醺醺的走了。第2個界面點了一杯酒，直接把錢付了，然后又點了一杯酒，又馬上買了單，幾小時后也醉醺醺的離開了酒吧。第3個界面剛走進酒吧，馬上就已經醉醺醺的離開了——它知道酒吧是干什么的，它非常講求效率，一點時間也不浪費。你聽說過這第3種界面嗎？它就叫做“樂觀派UI”。

樂觀派UI設計并非樂觀地看待頁面——至少不僅限于此。（查看大圖）

我最近參加了許多關于前端開發和用戶體驗的會議，討論了心理表現最佳化，我很驚訝，樂觀派UI設計是業界一個如此微不足道的話題。坦白說，這個術語本身都沒有清晰的定義。本文中，我們來探討它的基本概念，尋找一些案例，并回顧它的心理學背景。然后，我們討論掌握這項用戶體驗技巧的關鍵。

開始之前，我得說，沒有任何一個單獨的界面能被稱作“樂觀派UI”。其實它是界面實現背后的心智模型。樂觀派UI設計有它自己的歷史和邏輯。

很久以前

很久以前——那時候“tweet”一詞還只有鳥鳴的意思、蘋果公司瀕臨破產、人們還會把傳真號碼印在名片上——網頁界面相當單調。其中絕大多數沒有一絲一毫的樂觀意味。比如一個按鈕的交互，可以遵循下面類似劇本來進行：

用戶點擊一個按鈕。
按觸發進入禁用狀態。
一條請求發送到服務器。
服務器返回信息到頁面。
頁面刷新，反映出返回的狀態。

那個年代，界面與樂觀派扯不上什么關系。（查看大圖）

站在2016年回顧這些，我們會覺得效率低下；但是相當驚人的是，同樣的劇本仍然在許多網頁和應用中上演，它仍然是許多產品的交互流程。原因在于它可以預測，而且或多或少總會出點錯誤：用戶知道這項操作已經請求了服務器（禁用狀態的按鈕表明了這一點），當服務器有響應，更新后的頁面清晰表明這種客戶端——服務器——客戶端的交互結果。這種交互方式的問題很明顯：

用戶必須等待。如今我們都知道，即使是最短的服務器響應延遲，也會對整個品牌，而非這個單獨頁面產生負面的用戶感知。
每一次用戶的操作得到響應，都會以一種相當破壞性方式呈現（整頁刷新，而不是更新現有部分），會打斷用戶的任務流程，可能影響他們的思維軌跡。我們甚至還沒說到多任務，心理環境的任何變化都令人不愉快。那么，如果某個操作本意不是改變環境（在線支付就是個需要改變環境的好例子），那么這種改變會在用戶與系統的交流中創造不友善的氛圍。

不久以前

然后，所謂Web 2.0出現了，提供了新的頁面交互模式。它的核心是XMLHttpRequest和AJAX。一種最簡單的進度條形式：“菊花”，補足了這些新交互模式，它的基本目的就是告訴用戶，系統正忙著處理事情?，F在，服務器返回信息后，我們不必刷新頁面了；我們只需要對已經渲染的頁面進行局部更新。這使得網站更加動態化，為用戶創造了更加順暢和親切的體驗。一個按鈕的典型交互如今是這樣的：

用戶點擊按鈕。
按鈕觸發變為禁用狀態，按鈕上顯示出某種菊花圖形，表明系統正在運轉。
請求發送到服務器。
服務器返回信息到頁面。
根據返回的狀態更新按鈕和頁面的視覺狀態。

這種新的交互模型解決了舊交互方式存在的一個問題：頁面的刷新不會導致破壞性操作，保持用戶所處環境不變。相比之前，這種交互親切多了。

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是有用的。但為什么它們有用？這僅僅是因為人們討厭等待。僅此而已啊，親！你可以直接跳到下個章節了。

不過如果你繼續往下讀，說明你對深層原因感興趣。那么，我們稍微深入一點，了解這種方式的心理學基礎。

psychology-650-opt

大腦研究幫助我們理解樂觀派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的一條推特準確描繪了這點：

tammy-preview-opt

【圖注：我喜歡心流狀態的一切，除了一點，我會連續幾個小時忘記眨眼。我的眼睛現在是這樣的?！?/p>

有時候，辨認出一個人是否處于心流狀態非常簡單。（查看大圖）

在網絡中，這些活動聚類的持續時間短得多。我們回顧一下Robert B. Miller的作品。他指出，響應類型包括：

粗略瀏覽列表信息的響應；
仔細瀏覽圖表信息的響應；
“系統，你明白我要什么嗎？”的響應。

他把這幾類都歸為2秒延遲的類型，用戶會獲得相應類型的響應。如果不繼續深究，我們應該注意，這些延遲也取決于一個人的記憶運轉（這是指一個人記住一定量信息所需的時間，更重要的是，不僅記住，還要能運用）。我們作為開發者和用戶體驗專家，這意味著在操作了某個元素的2秒內，用戶會短暫進入心流狀態，專注于他們期待的響應。如果服務器在這個時間內返回錯誤狀態，用戶仍然處于與界面的“對話”中，這是個比喻。類似于兩個人對話，比如你說了一句話，對方委婉地反駁你。想像一下，如果對方花了很長時間點頭表示同意（等同于我們UI中的成功狀態），但然后最終對你說“不”。這多尷尬??？所以，樂觀派UI必須在心流狀態的2秒內傳達出錯誤信息。

optimistic-ui2-650-opt

樂觀派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設計的原理。