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