2021-3-26 鶴鶴
當我們設(shè)計師輸出了精美的設(shè)計稿，然后附帶了一個流暢的手勢動畫，交付給開發(fā)的時候，也期待著開發(fā)大佬搞出和自己預(yù)期一樣體驗流暢。但是等到實際體驗的時候，卻發(fā)現(xiàn)有一種說不出的鬧心。
“這個感覺不好按...”
“劃起來咋這么費勁呢？”
“怎么感覺動畫怪怪的。”
當你正準備和開發(fā)一通友好探討的時候，這個時候開發(fā)向你發(fā)起了一系列靈魂拷問：
“你這個左滑的手勢，劃多少才算觸發(fā)？劃多快才算觸發(fā)？如果劃了一半劃回去算不算觸發(fā)？如果我先點擊后滑動算不算觸發(fā)？松手之后的動畫是多快的速度？什么速度曲線？要不要回彈效果？回彈阻尼系數(shù)是多少？”
這個時候你發(fā)現(xiàn)，自己提出的設(shè)計需求根本太天真了。
剛才的問題真實原因是，在做很多手勢識別或者一些我們看起來日常的效果，其實是蘊含了很多復(fù)雜邏輯的。
這些復(fù)雜邏輯原本被封裝在操作系統(tǒng)內(nèi)，在系統(tǒng)內(nèi)時可以隨時調(diào)用。但是一旦脫離了操作系統(tǒng)，那手勢的處理邏輯就會比較簡陋，導(dǎo)致最終的體驗不佳。
那這個時候也許你會想問，我們怎么會脫離操作系統(tǒng)呢？我們的手機不都是iOS和Android的嗎？不都是操作系統(tǒng)嗎？其實這里指的操作系統(tǒng)，是指操作系統(tǒng)的原生組件。這類組件只有在原生開發(fā)中才能被調(diào)用。
如今，很多App都使用前端語言來開發(fā)內(nèi)部頁面(HTML/CSS/JS)。隨著Web混合開發(fā)，F(xiàn)lutter等跨端技術(shù)棧的出現(xiàn)，越來越多的團隊開始擁抱這樣的跨平臺技術(shù)棧。在節(jié)約了開發(fā)成本的同時，隨之而來的就是，在日常開發(fā)過程中，離純原生組件越來越遙遠。
在這樣的背景下，研發(fā)團隊的體驗設(shè)計師需要自己來研究用戶行為，手勢、組件和動效，實現(xiàn)原生組件類似的復(fù)雜邏輯，才能最大程度的接近甚至超越原生組件的體驗。
其實使用各個技術(shù)框架，也是有內(nèi)置一些接口的。例如一些事件監(jiān)聽器 / 動效曲線等。這也是騰訊文檔之前一直在使用的，但是會遇到一些問題。總結(jié)下來，主要有以下幾個問題：
無法精確操作：用戶的操作和操作反饋被自己的手指擋住，無法完成精確操作。
手勢識別誤觸：同一熱區(qū)支持了多個手勢，可是用戶的實操時的手勢動作又沒那么標準，導(dǎo)致用戶誤觸其他手勢。
手勢觸發(fā)費力：滑動費勁，需要滑動很長距離才能觸發(fā)預(yù)期的動作。
動畫不流暢：各個技術(shù)框架自帶的動畫曲線和插值器，良莠不齊，體驗不統(tǒng)一且不夠流暢。
對于原生組件，我們習以為常的系統(tǒng)控件和手勢設(shè)計，里面蘊含的智慧遠比我想象的更多。
舉個簡單的例子：iOS系統(tǒng)的首頁，它可以支持橫豎各個方向的滑動，并且在觸發(fā)一個方向的手勢之后，就無法再觸發(fā)其他手勢了。
但是其實有個問題，手指和平時演示的不太一樣。
就是手指貼合上屏幕的時候，手指與屏幕的貼合面，并不是均勻向四周擴散的，而是向下的擴散更大一些。對于觸摸中心點，在觸摸的過程中，就會有向下的一個偏移。
如果直接識別，這個偏移直接被識別為向下滑動，那就會無法觸發(fā)左右滑動的手勢。
例如在iOS內(nèi)的手勢識別，有一個專門的接口來做識別：PanGestureRecognizer，這個接口會在10px內(nèi)先判定手指移動的方向和距離，再對具體觸發(fā)的手勢來做定義。例如下圖，雖然剛開始手指位置有些許下移，但是最終還是可以左滑判定成功。
所以你會發(fā)現(xiàn)，如果在iOS桌面上輕微的向左右滑動(10pt內(nèi))，桌面是不會有任何響應(yīng)的。就是因為在10pt內(nèi)，系統(tǒng)還無法確認手勢的方向。
另外，系統(tǒng)還自帶了很多手勢反饋操作，包括回彈效果，甩出效果。里面的小邏輯設(shè)計需要非常精準。并且對于滑動的手勢還帶了回彈效果，看起來非常爽。
騰訊文檔是基于Web / Flutter的應(yīng)用，并且接管了很多原生系統(tǒng)的能力，包括排版能力、光標選區(qū)能力，拖動能力等。因此，很多基于Native開發(fā)能很簡單解決的問題，在Web下就要重新打磨一套我們?nèi)粘Ａ曇詾槌s邏輯復(fù)雜的組件。
由于騰訊文檔是基于Web的的應(yīng)用，接管了很多原生系統(tǒng)的能力，所以不能使用系統(tǒng)的Gesture Recognizer，也不能使用系統(tǒng)的選區(qū)光標能力。
如果是簡單的使用前端的操作監(jiān)聽器，那會要求用戶使用極其標準的手勢操作才能觸發(fā)，否則就會觸發(fā)失敗。因此需要設(shè)計更精準且適應(yīng)性的規(guī)則，來包容用戶不那么標準的實操手勢。需要幫助用戶在粗糙的實操手勢下，猜測用戶原圖，并精準完成的操作。
可能你以為手勢操作并不常用，其實并不是的。
一個單擊，一個雙擊，其實本質(zhì)上都是手勢。
不過，很多人可能會認為，按說這些操作都有原生的監(jiān)聽器，不需要再去定義。但是其實如果不做一些進階定義，就會出現(xiàn)操作不靈敏的問題。例如下面這個問題。
在很多安卓手機上，或者是我們自己的騰訊文檔里，時常遇到一個問題：就是原本以為雙擊文本區(qū)域可以選中文字，可是卻發(fā)現(xiàn)這個雙擊成了一個玄學(xué)事件。雙擊有時生效而有時不生效。
理想的雙擊大概是這樣的，是需要2次有效的Tap事件：
這個Bug讓我們來定位一下。讓我們還原一下事情的經(jīng)過：
哦！原來是因為雙擊的其中一稍微偏移了一下，拖動到了光標，導(dǎo)致系統(tǒng)判定是一次Tap一次Drag的行為，這樣就沒有辦法觸發(fā)雙擊行為了。
解決方法也很簡單。把10px偏移距離內(nèi)的滑動行為都判定為點擊行為就可以了。從這里看，我們其實需要做的是，規(guī)范“點擊”這個手勢的定義。
因為原來的系統(tǒng)自帶定義，容易造成誤操作，而且手指貼上屏幕的時候，都會產(chǎn)生輕微位移，或者一不小心滑動了頁面，或者不小心拖動了光標，導(dǎo)致手勢識別的不靈敏。
原定義：“點擊并在500ms內(nèi)在原處松手”。
需重新定義為：“點擊并在在500ms內(nèi)，在10px以內(nèi)處松手”。
另外，文檔移動端也定義了一系列更進階的手勢的操作，在這樣對手勢的進階定義后，操作可以被更精準和智能的判斷。這些定義被寫在了設(shè)計規(guī)范中，包括了單擊 / 雙擊 / 長按 / 拖拽
騰訊文檔的整個文本編輯區(qū)域都是使用Canvas實現(xiàn)的，由前端自主控制渲染。因此，選區(qū)光標就無法直接使用系統(tǒng)能力，需要設(shè)計師來設(shè)計一套選區(qū)光標，并且支持系統(tǒng)的各種選區(qū)光標的手勢。
由于騰訊文檔的光標選區(qū)是非常基礎(chǔ)基礎(chǔ)的編輯組件。這個組件在一般的產(chǎn)品中，都是直接復(fù)用的系統(tǒng)組件，但是在騰訊文檔中，就需要重新去考慮光標組件。
首先有個需求，光標是可以在文本中快速拖動的。
經(jīng)常會遇到拖動。無論是光標拖動，還是長按選中，我們都希望能清楚的看到光標的位置，所以我們在用戶拖動光標和選區(qū)的時候，使被拖動的組件放大1.5倍，使用戶可以看到拖動效果。
這就夠了嗎？不夠的。
如果用戶想要精準的控制光標，首先要讓用戶完整的看到光標。用戶在拖動光標的時候，手指經(jīng)常會不自覺的向下移動。這是為了讓自己看清光標，這個時候，我們不應(yīng)該把這個移動當做是把光標向下移動一行，光標本身不應(yīng)該跟隨向下，應(yīng)該只在同一行，并且只響應(yīng)左右移動。
但是當我向下拖更多距離的時候，光標就應(yīng)該一直保持在手的上方，以確保用戶可以精確操作。
同樣，我們定義了長按后可以拖動選擇的手勢。在拖動的過程中，允許用戶向下偏移一定的區(qū)域，來看清選區(qū)的具體邊界位置。
手機端的光標選區(qū)，一個我們?nèi)粘Ａ曇詾槌５墓鈽耍锩婢谷挥心敲炊嘈〖毠?jié)在里面，才能讓光標變得好用。
當一個滑動手勢被觸發(fā)時，我應(yīng)該如何判斷這個手勢已經(jīng)被觸發(fā)了呢？這個判斷并非簡單的橫劃豎劃，而是針對的不同的場景，去做特殊的處理的。
案例1：向下滑動手勢
例如說，一個非常簡單的手勢，半屏向下滑動關(guān)閉。我們通常來說我們的日常體驗，會是一個對距離的判斷，當手指拖動容器超過一定的距離，然后松手，就可以觸發(fā)手勢。
但是僅僅判斷距離是不夠的。因為手勢是對現(xiàn)實世界的映射。很多時候用戶希望滑動很短的距離，把東西“甩”出去。
如果僅僅判斷距離，那就很難“甩”出去。這時候就還需要判定用戶手指在離屏時的速度了。最后能達成一個比較輕松就能觸發(fā)手勢的結(jié)果。
案例2：左右切換相機
這是騰訊文檔的文檔掃描頁面。上半屏是大面積的取景畫面，底部是文檔類型的選擇。
因為取景頁面可以點擊對焦和測光，因此輕微的滑動不應(yīng)該導(dǎo)致整個取景頁面或者底部Tab的滑動，應(yīng)當是當整個頁面檢測到一個比較大的滑動動作之后，才自動移動切換。
但是如果需要離手才能觸發(fā)，如果用戶劃動的速度比較慢，整個體驗也會隨之變得過于拖沓。所以這里還加了一條邏輯：當手指滑動速度的加速度急劇減小時，不用松手也可以觸發(fā)手勢。這樣的體驗感會覺得流暢很多。
在騰訊文檔中，點擊、滑動、懸浮、長按等手勢操作貫穿用戶的使用過程，動畫效果是所有交互操作的視覺反饋，也許它沒有那么的「高逼格」，但它卻是這臺精密儀器運轉(zhuǎn)不可缺少的“潤滑劑”，流暢愉悅的動效能夠讓體驗更美好。
但是由于騰訊文檔起初是基于web混合開發(fā)，后面又加入了Flutter框架，這就導(dǎo)致多個平臺、框架的動效邏輯混在一起，在這個背景下，設(shè)計師們就需要從多方面重新梳理并定義動畫的基礎(chǔ)規(guī)則。
自然流暢是騰訊文檔內(nèi)所有動效運行的基礎(chǔ)原則。
由于騰訊文檔是基于Web、flutter等多框架混合開發(fā)的應(yīng)用，動畫曲線又都是基于各自框架自帶的貝塞爾曲線（cubic-bezier），這就經(jīng)常導(dǎo)致一些同類型的手勢操作，最后所呈現(xiàn)的動畫效果卻相差很多。并且原生的動畫曲線，在實際使用上并沒有達到很好的效果，只是能夠比沒有動畫要強上一些。因此，確定一套統(tǒng)一、自然并且適合騰訊文檔的動畫曲線，是設(shè)計師優(yōu)先要解決的問題。
為此我們根據(jù)動畫使用的場景，定義了四種標準曲線。同時輸出給開發(fā)同學(xué)，作為標準可調(diào)用的曲線。
緩動曲線應(yīng)用的場景最為廣泛，也是騰訊文檔的默認曲線。相對于傳統(tǒng)web端或者flutter框架內(nèi)的默認曲線，騰訊文檔的緩動曲線開始時會比較迅速，這樣能給用戶及時反饋、高效運行的感受；在運動快結(jié)束的階段，為了避免快速反饋帶來急躁的負面感受，曲線會更加平緩，進而使正在運動的元素吸引用戶的注意力，并讓用戶能夠有一定的思考時間，保證動畫的合理性。
即減速曲線。運動元素在開始階段時位移變化會很大，但是后面會越來越小。緩出曲線前期快速運動，不需要過多讓用戶留意，在結(jié)束的時候逐漸減慢速度，讓用戶關(guān)注到其新的狀態(tài)，用戶就可以提前切入到定位尋找的階段，等動畫停止后就可以立即進行操作。這種類型的曲線通常是用在元素進入界面時使用。
彈性曲線是一種基于阻尼彈性振蕩的原理實現(xiàn)的復(fù)雜曲線，阻尼比決定了曲線具體動畫感受，根絕阻尼比的不同，彈性曲線可以分為三種，分別是欠阻尼運動、臨界阻尼運動及過阻尼運動。在騰訊文檔中，通常只會使用到欠阻尼運動及臨界阻尼運動。
彈性曲線卻并不適合在所有的使用場景中，因為這種運動一般情況會需要相對多一些的時間來完成整個運動過程，讓整個過程變得過于拖沓。同時過于活潑的彈性動畫也會過分的吸引用戶注意力，打斷主進程的操作，影響效率。
時長是元素移動所需的時間，在創(chuàng)建自然流暢的動畫中起著重要作用。如果動畫太慢，會使用戶感到卡頓和厭煩；但是如果速度太快，就會給人緊張急迫的感覺。因此動畫的持續(xù)時間應(yīng)該給與用戶充分的反應(yīng)時間，同時又不用過久等待為標準。
在移動端上，我們設(shè)定動畫的持續(xù)時間在300-400ms。而在web端上，我們設(shè)定動畫的持續(xù)時間在200-300ms內(nèi)。具體的運動時長視具體動畫而定，時長并不一成不變。
曲線是動效的靈魂，有時候你覺得平凡的動畫，或許只需要簡單地撥動那條運動曲線，就可以讓這個動畫瞬間變得充滿靈氣。盡管曲線可以解決大部分動效問題，但在動畫的實際落地中，還是有一些問題，是它無法解決的。這就會涉及到動畫更底層的渲染及邏輯。比如說在web端，前端動畫卡頓與否其實是和動畫本身實現(xiàn)性能有關(guān)系的，瀏覽器的屏幕刷新率都可能被代碼拖慢。這也是騰訊文檔在初期并沒有在web端增加太多動畫的原因，過多的動畫效果其實意味著需要更多的性能資源傾斜到動畫上。
在動畫上除了希望提供自然流暢的積極體驗，我們也希望繼續(xù)深入，“讓工具褪去冷冰的外殼，走進與智能隔空對話的新世界”。讓體驗更有情感，讓用戶更愉悅。
在待辦事項上，優(yōu)化前每當用戶點擊完成一項事項時，完成動畫僅僅是機械的從未完成向完成圖標的替換，反饋效果非常“高效”的完成了它的任務(wù)，但是這樣就足夠了么？不一定，當一項事項被列為待辦時，就證明這件事對于用戶來說是重要的。在現(xiàn)實中，當重要的事情完成時，我們都是歡欣的，就像心里在放煙花，完成待辦時候的動畫理應(yīng)如此，讓用戶在完成的那一刻體驗到“煙花”的綻放。
但是總有一些產(chǎn)品，或者是通用性的考慮，或者是一些歷史原因，或者是一些成本考量，走上了非原生開發(fā)的路，這樣的產(chǎn)品在未經(jīng)打磨的情況下直接一把梭搞出來，的確會顯得卡頓，或者難用。
這其中不僅需要工程師一點一滴的性能優(yōu)化，這也對體驗設(shè)計師對細節(jié)的把控提出了更高的要求。只有對用戶的行為處處關(guān)照，才能無限接近最極致的體驗。
文章來源：站酷 作者：騰訊ISUX
藍藍設(shè)計( www.lapeinture.cn )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)
藍藍設(shè)計的小編 http://www.lapeinture.cn