微信輕應(yīng)用是時(shí)下的一個(gè)香餑餑。一方面是因?yàn)殡S著H5語言的定稿及其開發(fā)經(jīng)驗(yàn)的沉淀，開發(fā)者以較低的成本即可打造出具有一定可用性的Web App。另一方面，微信作為一個(gè)超級社交App，天然具有巨大的流量入口價(jià)值與傳播分享價(jià)值。因此，在微信平臺(tái)宣布全面開放接口后，無數(shù)互聯(lián)網(wǎng)創(chuàng)業(yè)團(tuán)隊(duì)、企業(yè)，甚至是個(gè)人，紛涌而入，殺成一片紅海。
但是，實(shí)際使用時(shí)，微信輕應(yīng)用的體驗(yàn)并不是那么的“爽”。誠然，這與H5語言的技術(shù)局限性有著很大的關(guān)系。但拋開這一點(diǎn)，走腎而不走心的設(shè)計(jì)也是造就“不爽”體驗(yàn)的重要原因。本人在體驗(yàn)過一些的微信輕應(yīng)用后，嘗試總結(jié)出了一些對微信輕應(yīng)用交互設(shè)計(jì)的思考。
在亮出個(gè)人總結(jié)之前，我想先談?wù)勥M(jìn)行微信輕應(yīng)用設(shè)計(jì)時(shí)的難點(diǎn)與機(jī)會(huì)。
微信輕應(yīng)用設(shè)計(jì)的難點(diǎn)源于H5技術(shù)的局限性以及微信平臺(tái)本身的局限性。
1. H5的局限性：
- 使用場景上，嚴(yán)重依賴于穩(wěn)定的網(wǎng)絡(luò)環(huán)境。由于幾乎每個(gè)元素及每次操作都需要發(fā)送網(wǎng)絡(luò)請求，因此，在弱網(wǎng)絡(luò)的環(huán)境下，使用的痛苦指數(shù)是趨向于無窮的；
- 技術(shù)上，一方面，通過Canvas標(biāo)簽與CSS來進(jìn)行圖像、動(dòng)效的渲染，效果馬馬虎虎，容易造成卡頓的即視感；另一方面，緩存技術(shù)仍不完善，如點(diǎn)擊列表進(jìn)入詳情頁再返回時(shí)，通常需要重新加載一次列表；
- 權(quán)限獲取上，無法獲取照相機(jī)、系統(tǒng)級別通知等設(shè)備或接口的權(quán)限，功能上大打折扣。
2. 微信的局限性：
- 使用場景上，與聊天場景存在著激烈的矛盾沖突，導(dǎo)致任務(wù)隨時(shí)可能被打斷。打斷之后，再次進(jìn)入的成本高如汪（需要從滔滔信息流中重新定位應(yīng)用位置，并從頭開始任務(wù)）；
- 平臺(tái)設(shè)計(jì)規(guī)范上，應(yīng)用首頁（即公眾號(hào)對話窗口）的樣式只能使用聊天氣泡+底部菜單欄；以微信瀏覽器打開應(yīng)用時(shí)，必須使用微信預(yù)設(shè)的頂部導(dǎo)航欄。這些或占據(jù)了一定量的屏幕空間，或一定程度上限制了設(shè)計(jì)發(fā)揮；
- 權(quán)限獲取上，除極少數(shù)微信家的親兒子外，其他應(yīng)用均無法獲取頂部導(dǎo)航欄右側(cè)按鈕的自定義權(quán)，這就更加限制了設(shè)計(jì)師的發(fā)揮。
但很多時(shí)候，限制即是機(jī)會(huì)。“聊天氣泡+底部操作欄”的設(shè)計(jì)規(guī)范，反而為應(yīng)用的信息框架與導(dǎo)航設(shè)計(jì)提供了更多的思路。一方面，IM工具的輸入/反饋機(jī)制，為用戶與應(yīng)用的交互方式和信息的呈現(xiàn)方式帶來了新的可能；另一方面，底部菜單欄可以是對Native App中Tab Bar選項(xiàng)的隱喻，恰當(dāng)使用可以降低用戶學(xué)習(xí)成本。
廢話了一大籮筐，下面馬上向個(gè)人總結(jié)頁面跳轉(zhuǎn)。
根據(jù)進(jìn)入場景，定義頁面架構(gòu)
用戶的認(rèn)知模式是長這樣子的：會(huì)傾向于把公眾號(hào)的對話窗口視為微信輕應(yīng)用的首頁。底部菜單欄中，每一個(gè)標(biāo)簽即是一個(gè)功能模塊的入口（相當(dāng)于Native App中的Tab Bar）。點(diǎn)擊標(biāo)簽后進(jìn)入的第一個(gè)頁面即是該功能模塊的頂層頁面，從該頁面返回則必然是回到對話窗口。
這帶來的啟示之一是，在設(shè)計(jì)頁面架構(gòu)時(shí)，可以考慮將對話窗口中的底部菜單欄視為Native App中Tab欄的隱喻，將功能模塊平攤到這些操作欄中，并削弱模塊之間的關(guān)聯(lián)性。如微信輕應(yīng)用“Yolo優(yōu)洛會(huì)”中，每個(gè)底部操作欄標(biāo)簽均對應(yīng)一個(gè)功能模塊，且功能模塊之間彼此獨(dú)立，點(diǎn)擊進(jìn)入后可獲得獨(dú)立、完整的沉浸式體驗(yàn)，讓用戶專注于任務(wù)本身，并降低了學(xué)習(xí)成本。
啟示之二是，對話窗口與功能模塊的頂層頁面之間必須建立唯一的上下層級關(guān)系。一個(gè)反例就是，“行動(dòng)流”微信輕應(yīng)用中，點(diǎn)擊對話窗口底部操作欄中的“圈子”，進(jìn)入新頁面后，再點(diǎn)擊左上的“圈子”按鈕，試圖返回，卻發(fā)現(xiàn)跳轉(zhuǎn)至了一個(gè)全新的頁面。該頁面頂部是Icon和Slogan，下面是“我”、“圈子”、“夢想”這三個(gè)功能的快捷入口，正是設(shè)計(jì)師眼中的“首頁”。然而，該頁面的到達(dá)路徑并不符合預(yù)期，容易把用戶灌醉。
使用唯一的、微信預(yù)設(shè)的“返回”導(dǎo)航樣式
微信已經(jīng)強(qiáng)制為所有應(yīng)用套上了頂部導(dǎo)航欄枷鎖，其中就已經(jīng)包含了“返回”按鈕。然而，仍然還有不少應(yīng)用堅(jiān)持添加上自己親手設(shè)計(jì)的“返回”按鈕。
雙重“返回”樣式增加了認(rèn)知障礙、擠占了屏幕空間。就算是出于“左上返回按鈕位于拇指熱區(qū)外我們來讓它更容易被點(diǎn)到吧”的出發(fā)點(diǎn)來考慮，其存在意義也仍然十分牽強(qiáng)。相反，將其移除后，騰出來的空間可以激發(fā)更豐富的設(shè)計(jì)思路(比如，用來放置全局導(dǎo)航)。
靈活使用多種導(dǎo)航樣式
即使是在高配置、強(qiáng)網(wǎng)絡(luò)的條件下，頁面跳轉(zhuǎn)在微信輕應(yīng)用中仍然是非常痛苦的體驗(yàn)。而靈活高效的導(dǎo)航是減少頁面跳轉(zhuǎn)的一大殺器。
微信輕應(yīng)用上，常見的導(dǎo)航樣式如下：
1. 對話窗導(dǎo)航
2. 一級導(dǎo)航
3.全局導(dǎo)航
4.場景式導(dǎo)航
在微信輕應(yīng)用的語境下，局限于一種導(dǎo)航樣式是很難達(dá)到“靈活高效”的目標(biāo)的。搭配使用多種導(dǎo)航樣式效果才能好。
舍棄重動(dòng)效，做足微交互
H5的技術(shù)限制，使得一些在Native App上司空見慣的動(dòng)效套用在微信輕應(yīng)用上時(shí)顯得笨拙無比。當(dāng)然開發(fā)水平是影響動(dòng)效是否流暢的一個(gè)決定性因素。但過重的動(dòng)效需要占用大量的用戶資源，同時(shí)也加大了開發(fā)的成本與難度，違背了“快速開發(fā)”的初衷。因此，在進(jìn)行微信輕應(yīng)用的設(shè)計(jì)時(shí)，要盡可能地避免“使用動(dòng)效解決問題”的思路。
但這并不意味著要舍棄一切動(dòng)效。事實(shí)上，比起Native App，微信輕應(yīng)用對“微交互動(dòng)效”更加依賴。主要表現(xiàn)在以下幾個(gè)方面：
1. Loading態(tài)
微信輕應(yīng)用需要源源不斷地發(fā)送網(wǎng)絡(luò)請求，也就留給了用戶大量用于等待的焦慮時(shí)間。而Loading態(tài)的微交互的使命正是化解這股焦慮。
2. 缺省態(tài)
Lodaing態(tài)的對應(yīng)加載方式是全局加載，這種方式比較適用于數(shù)據(jù)請求量不大的頁面加載場景。而數(shù)據(jù)量較大的頁面則普遍使用異步加載的加載方式。異步加載即各項(xiàng)元素按照一定的優(yōu)先級順序來進(jìn)行加載，因此在加載過程中會(huì)出現(xiàn)各種空元素。這時(shí)候就需要缺省態(tài)的微交互上場了。
3. 操作反饋
由于H5的效能問題，在“用戶進(jìn)行操作”與“系統(tǒng)執(zhí)行操作”之間往往會(huì)存在一小段延遲。在這段延遲期間，若沒有任何反饋，用戶很容易會(huì)誤以為自己操作失敗而做出什么不好的事來。操作反饋的微交互可以間接加快應(yīng)用的響應(yīng)速度，阻止用戶犯錯(cuò)誤。
4. 輸入
正在輸入的文本框必須要在視線焦點(diǎn)范圍內(nèi)。這點(diǎn)聽起來似乎是天經(jīng)地義。但很不幸的是，這個(gè)世界上存在著太多的無情無義的微信輕應(yīng)用了。
僅讓重要的信息可視，并減少其加載量
“如何讓用戶覺得運(yùn)行速度很快”是進(jìn)行微信輕應(yīng)用設(shè)計(jì)面臨的一個(gè)核心問題，而頁面加載的速度正是衡量“運(yùn)行得快不快”的一個(gè)重要尺度。
用戶是如何感知、判斷頁面加載的速度的？這主要取決于第一個(gè)可視元素出現(xiàn)所用時(shí)間和“感覺這個(gè)頁面已經(jīng)完整了”時(shí)所用時(shí)間。將這些用戶視角的體驗(yàn)需求轉(zhuǎn)化為指導(dǎo)設(shè)計(jì)的方法論則是，減少頁面中可感知到的信息的數(shù)據(jù)加載量。這些可感知到的信息必然是重要的、高展示價(jià)值的。至于其他次級信息，可選擇性地將其隱藏，并降低其加載優(yōu)先級。這樣，即使次級信息仍在加載中，但由于其已被隱藏，用戶感知不到，因此仍會(huì)認(rèn)為當(dāng)前頁面的加載速度是nice的。
隱藏信息的方式總結(jié)有以下幾種：
1. 將一段長信息不完整展示
2. 將信息分組，通過控件隔斷不同組的視圖空間
3. 設(shè)置一次性加載的數(shù)據(jù)量的閾值，加載更多時(shí)需要額外操作
提高列表篩選效率
由于技術(shù)限制，現(xiàn)階段大部分微信輕應(yīng)用從詳情頁面返回至列表頁面時(shí)，并不能定位到最后停留的列表位置上。
突破該技術(shù)瓶頸固然是最有效的解決方法。但據(jù)觀察，目前只有微信錢包中自帶的“京東”輕應(yīng)用解決了該問題。因此可以基本斷定該解決思路暫時(shí)無法實(shí)現(xiàn)。
面對如此艱苦的設(shè)計(jì)背景環(huán)境，另一個(gè)解決思路是提高列表篩選效率，降低用戶從詳情頁返回列表頁的概率。比如，往列表中注入更多的輔助用戶決擇的信息字段；又或者是將詳情頁中的關(guān)鍵入口前置，縮短用戶到達(dá)路徑。
在微信錢包中自帶的“大眾點(diǎn)評”輕應(yīng)用中，店鋪列表頁處囊過了該店鋪的團(tuán)購入口，一來團(tuán)購信息可以輔助用戶進(jìn)行店鋪篩選，二來縮短了購買團(tuán)購的路徑，極大地提高了列表的篩選效率。
考慮逆向路徑，避免無效的“返回”
設(shè)計(jì)師或許掌握了成噸的讓跳轉(zhuǎn)頁面無感化的技巧，但一切真相都逃不過“返回”按鈕的審判之眼。按照微信的邏輯，每一次點(diǎn)擊“返回”的結(jié)果，必然是回到上一次加載的頁面。這使得一些在正向操作時(shí)感覺高效簡潔的設(shè)計(jì)方案在逆向操作時(shí)讓人疼到無比。
比如微信錢包中自帶的“美麗說”輕應(yīng)用中，使用Segmented Control控件承載化妝品分類。切換類別時(shí)，體驗(yàn)近乎無感。然而，當(dāng)點(diǎn)擊“返回”按鈕時(shí)，并不是回到微信錢包首頁，而是回到上一個(gè)化妝品類別的列表視圖，嚴(yán)重不符合用戶預(yù)期（明明就是同一個(gè)頁面，怎么點(diǎn)了返回沒反應(yīng)的）。
正因?yàn)槿绱耍?strong>在技術(shù)上無法解決該問題的前提下，并不十分建議使用那些容易引發(fā)“不需要進(jìn)行跳轉(zhuǎn)”的錯(cuò)覺的導(dǎo)航樣式，比如Tab式導(dǎo)航。不僅在正向路徑中違背了“肯定不需要跳轉(zhuǎn)啊”的用戶預(yù)期，也在逆向路徑中也顯得臃腫低效。
最后之YY：提供返回最后停留頁面的入口？
用戶正在使用微信輕應(yīng)用，手機(jī)突然震動(dòng)了一下。這時(shí)候用戶是會(huì)選擇將當(dāng)前任務(wù)進(jìn)行到底，還是會(huì)離開應(yīng)用查看微信信息呢？這取決于用戶使用應(yīng)用的目標(biāo)強(qiáng)度以及獲取新信息的迫切程度。但無論如何，用戶一旦離開了應(yīng)用，如果想要再次回到最后停留的頁面，就必需從頭開始。
無論是對用戶還是開發(fā)商而言，這種交互邏輯都不是什么好東西。那么，能否在淺層級的頁面中提供返回最后停留頁面的入口呢？比如，在輕應(yīng)用的頁面中提供“稍后閱讀”按鈕，點(diǎn)擊之后，公眾號(hào)可以將該頁面的鏈接以信息流的形式推送給用戶。這樣，用戶只需要重新進(jìn)入公眾號(hào)對話窗口，直接點(diǎn)擊信息中的鏈接即可以重返最后停留的頁面了。
當(dāng)然，這只是個(gè)人YY，是否具有可實(shí)現(xiàn)性仍需要技術(shù)同學(xué)的審批。
由于個(gè)人知識(shí)體系實(shí)在淺薄，關(guān)于微信輕應(yīng)用設(shè)計(jì)的思考暫時(shí)就只有這么多了。在此真心希望H5的開發(fā)技術(shù)快高長大，讓微信輕應(yīng)用與原生應(yīng)用之間的體驗(yàn)差距越來越小。
