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