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