UI設計中交互動畫的設計原則

 　　1、除了透明度(Opacity)和切換(Transform)，不要改變任何屬性!即便你覺得可行，那也別沖動!動畫中百分之八十的優化會用到這項基本原則，即使是在移動端也一樣。你或許以前聽過這個原則，這不是我提出來的，但是很少有人去遵守。這跟“管住嘴邁開腿”一樣，建議很好卻也最容易被忽略。對已經習慣了這種思路的人來說這非常簡單，但是對那些習慣用傳統的 CSS 屬性去做動畫的人來說，這會是一次質的飛躍。比如，你想讓某個元素小，你可以使用 transform：scale()，而不是改變寬度;如果你想移動它，你可以使用簡單的transform：translateX 或者 transform：translateY，從而替代亂糟糟的外補白(margin)或者內補白(padding)?—?那些需要重建每一幀的頁面布局。為什么要這么做呢?對人類來說，改變寬度、外補白或者其他屬性不是什么大事?—?甚至因為簡單會更讓人喜歡這么做?—?但是對電腦來說，這事兒就像天塌了一樣，甚至比這更糟糕。瀏覽器投入了九牛二虎之力來優化這些操作，切換屬性(transform)真的非常容易且高效，并且能夠充分利用顯卡，并且不用重新渲染元素。第一次加載頁面的時候，你可能會覺得抓狂?—?處理所有圓角、引入圖像、給一切添加陰影，如果你毫不在乎那么甚至可以再做一個動態羽化。如果這種情況只會發生一次，多一些計算時間也沒關系。但是一旦內容渲染完成了，你絕對不會再想要重新加載!

　　2、用非常清楚的方式隱藏內容，使用 Pointer-Events 屬性：僅僅利用透明度隱藏元素或許會有跨瀏覽器的警示，但是如果你只是面向 webkit 和其他流行的瀏覽器，它將會讓你如虎添翼。很久以前，動畫效果必須由 jquery 的 animate() 方法來處理，許多復雜的淡入淡出效果的處理是通過 display 的屬性值切換實現的。太早顯示，那么動畫還沒完成，但是太晚的話就會在頁面上顯示一片空白，總是需要回調函數去給執行完的動畫擦屁股。CSS 中的 pointer-events 屬性(盡管已經存在很長時間，但是不經常使用)只是讓元素失去了點擊和交互的響應，就好像它們不存在一樣。它能通過 CSS 控制顯示或隱藏，不會打斷動畫也不會影響頁面的渲染或可見性。除了將 opacity 設置為零，它和將 display 設置為 none 具有相同的效果，但是不會觸發新的渲染機制。需要隱藏元素的時候，我會將它的 opacity 設置為 0 并將 pointer-events 設置為 off，然后就任由其自生自滅啦。這樣做尤其適用于絕對定位的元素，因為你能夠自信滿滿地說他們絕對不會影響到頁面中的其他元素。它有時也會劍走偏鋒，因為動畫的時機并不總那么完美?—?比如一個元素在不可見狀態下仍然可以點擊或者覆蓋了其他內容，或者只有當元素淡入顯示完全的時候才可以點擊，但是不要灰心，會有辦法解決的。

　　3、不要一次給所有內容都設置動畫，用動作編排加以替代單一的動畫會很流暢，但是和其他許多動畫一起也許就完全亂套了。編寫一個流暢的全員動畫的例子很簡單，但當數量級上升到整個網站時性能就很難維持了。因此，合理安排好每個元素非常重要。你需要將所有的時間節點安排好，來避免所有的動畫內容同時開始或進行。典型的例子，2 或 3 個動畫同時進行可能不會出現卡慢的現象，尤其是在它們開始的時間略有不同的情況下。但是超過這個數量，動畫就可能發生滯緩。理解動作編排這個概念非常重要，除非你的頁面真的只有一個元素。它貌似是舞蹈領域的東西，但是在動畫界它同樣的重要。每個內容都要在合適的方向和時機出現，即使它們相互分離，但是它們要給人一種按部就班的感覺。谷歌的 material design 有幾點關于動作編排的有趣建議，雖然這并不是實現目標的不二法門，但總有一些是你應該去考慮和嘗試的。

　　4、適當增加切換延時能夠更簡單地編排動作動畫的編排非常重要，同時也會做大量的試驗和測試才能恰如其分。然而，動畫編排的代碼并不會非常復雜。我通常會改變一個父元素(通常是 body)的 class 值來觸發一系列的改變，這些改變有著各不相同的切換延時以便能夠適時展現。單從代碼來看，你只需要關心狀態的變化，而不用擔心一堆時間節點的維持。Gyroscope Chrome Extension 的動畫交錯安排一系列的元素是動畫編排的一種簡單易行的方法，這種方法很有效，因為它在性能良好的同時還好看—但請記住你本想讓幾個動畫同時發生的。你想把這些動畫分布開來，讓每個都表現地流暢，而不是一下子太多動畫從而顯得特別慢。適當部分的重疊會看起來連續流暢而不是鏈式的單獨動畫。代碼示例有一些很簡單的技巧來錯開你的元素—尤其是其中有非常多的內容。如果頁面中有小于 10 項內容，或者元素數量可預估(比如靜態頁面)，我通常會在 CSS 中指定特定的值。這是最簡單易行的方法了。一個簡單的 SASS 循環對更多的內容或者動態內容來說，可以在循環中動態地給每項內容添加時間節點。一個簡單的 JavaScript 循環有兩個典型的變量：基本延時和各個項目的延時。它很難協調，但你一旦找到正確的值，效果將會非常完美。

　　5、在慢動作中使用增量設計，過后再加快動畫的速度動畫設計中，時間節點就是一切。20% 的工作是用來實現效果，剩下的 80% 使用來尋找合適的參數和持續時間來讓一切在同時發生時顯得流暢。尤其是在編排多個動畫的時候，為了達到高性能和高共同性，觀察動畫的慢動作會讓一切工作變得非常容易。無論你用的是 JavaScript 還是 CSS 預處理器比如 SASS(我們非常喜歡它)，都需要簡單地做一些額外的計算并且需要聲明一些有用的變量。你必須確保它能夠非常容易地嘗試不同的速度或時間節點。舉個例子，如果一個動畫效果在 1/10 的速度下還表現地結結巴巴，那么可能會有一些非?；A的錯誤。如果在放慢 50 倍的速率下表現流暢，假以時日定能找到運行流暢的最大速度?；蛟S正常速度下 5 毫秒的差池很難被注意到，但是放慢速度，它就變得非常明顯了。家居網站建設營銷推廣的成功經驗總結尤其是做非常復雜的動畫分析，或者解決非常棘手的性能瓶頸，慢動作查看元素會非常的有用。重要的一點就是，在慢動作下你會將非常多的細節優化地完美，當動畫加速之后它將會給人完美無瑕的感覺。盡管這些都顯得微不足道，但是用戶會注意到動畫效果的流暢和細節的。只有 OS X 才有的功能—如果你 shift + 點擊最小化按鈕或者一個應用圖標，你將會看見它在緩慢移動。基于這一點，我們甚至在陀螺儀上實現了這個功能，當你按下 shift 鍵的時候將會激活慢動作模式。

　　6、給你的用戶界面錄個像，并且在重復播放中得到一個有價值的第三人視角的看法有時候不同的視角能夠幫助你對事物有更加清楚的認識，而錄像則是一種很好的方法。有的人會用 AE 做視頻然后放到網站上，而我恰恰相反，我總是嘗試將網站界面錄制成很棒的視頻。發布視頻其實門檻很高的。有一天我對做出來的東西感到非常激動，想記錄下來和朋友們分享。然而，當看第二遍的時候，我發現了一些瑕疵，時間節點設置得不那么恰當，并且出現了一個延遲尖峰。這讓我有點打退堂鼓了，我發現還有很多的內容需要優化，所以我不能就這么把視頻發送給朋友。在使用過程中這些瑕疵都很容易被掩蓋，但是在視頻中一次次地觀看慢動作的動畫能夠讓一切問題都暴露地非常明顯。有人會說拍攝出來和看起來的效果并不完全相同，但也許它變更加精確了呢。這已經成為我工作中很重要的一部分，我會觀看慢動作的視頻并且修改任何我覺得不妥的地方。其實也可以很容易地將這類問題歸咎于瀏覽器性能差，但是再多優化一點多測試一點，這些問題就能夠得到解決。等到你在視頻中不會發現非常尷尬的延遲尖峰，并且感覺視頻挺好的可以曬出來了，這個時候你的頁面就可以發布了。

　　7、網絡活動可能會造成延遲 應預加載或者延遲處理非常大的 HTTP 請求圖片便是其中一個元兇，無論是幾個大圖片(大的背景圖)或者非常多的小圖(五十個頭像)，或者非常多的內容(一個從頭到尾有很多圖片的長頁面)。頁面首次加載的時候，許多的東西會被初始化并下載。其中內容解析、廣告和其他第三方腳本會使性能變得更糟糕。有時候，將動畫效果在頁面加載后延遲零點幾秒將會對性能有很大的提升。如果沒有必要的話，不要過度優化動畫延遲，一個復雜的頁面要求非常精確的延遲和時間節點才能運行流暢。通常你會想要在開始的時候加載盡可能少的數據，當主要內容和介紹動畫完成之后再繼續加載其他的內容。一個有很多數據的頁面，需要深思熟慮地加載所有內容。一個在靜態頁面中表現良好的動畫效果也許就會在實時數據的加載中變得緩慢。如果有些內容仿佛應該生效但卻沒有，或者不能一如既往地流暢表現，我建議檢查一下網絡活動，確認一下你是否也在同時處理其他的內容。8、不要直接綁定滾動事件 貌似是個好主意，其實不然基于滾動的動畫在前些年一段時間非?；鸨绕涫巧婕耙暡罨蛘咂渌匦У膬热堇?。它們的設計模式是好是壞仍有待考證，但是在技術上有著良莠不齊的實現方法。基于滾動的動畫中有一種非常流行的處理方式，即將滾動一定距離作為事件處理同時觸發動畫內容。除非你對自己的行為了如指掌，否則我會建議不要使用這種方式，因為它真的很容易出錯并且很難維護。更糟糕的情況是自定義滾動條功能，而不用默認的功能—又名 scrolljacking 。請不要這么想不開。在這十項準則中，這項尤其適用于移動開發，另外可能也是理想用戶體驗的好的實踐。網站設計顏色搭配教程如果你確實要求獨特的體驗并且你希望它基于滾動或者其他的特殊事件，我建議創建一個快速原型來實現，而不是費力不討好地去設計事件形式。

　　9、第一時間、多次在移動設備上的測試大多數的網站都是在電腦上搭建的，并且最常用本機做測試。因此，移動端體驗和動畫性能就被次要考慮了。一些技術(比如 canvas)或者動畫技術可能在移動端表現地并不好。然而，如果代碼寫得好優化也到位(參考規則 #1)，移動端的體驗甚至比電腦更加流暢。移動端的優化是一項非常棘手的事情，但是新的 iPhone 比手提電腦更快!如果你采用了前幾項建議，你將會得到一個非常棒的移動端表現。移動端訪問網站將會變得非常非常的重要。我建議你專門拿一個星期的時間認真地用手機查看你的網站，這或許有些極端，你可能會感覺像是在接受懲罰而被迫使用移動端版本，但是你應該調整好心態。不斷優化設計和提高性能，直到網站在移動端的表現和在電腦上一樣優美和方便。如果你堅持一周都用移動端來訪問網站，你將會得到一個比電腦上更優化體驗更好的網站。即使在使用過程中遇到非常惱人的事情也是值得的，那意味著這些問題將在你的用戶體驗到之前就被解決掉了!

　　10、經常在不同的設備上測試，不同屏幕尺寸、分辨率，或者有著各種樣式的設備除了移動端和電腦之外還有很多因素能夠對性能產生極大的影響，比如是否是 “retina” 屏幕、窗口的分辨率、硬件的老舊程度等等。即使 Chorme 和 Safari 都是基于 Webkit 的瀏覽器并且有著相似的語法，但是他們也有各自的特點。每一次 Chrome 升級都會修復一些問題同時也會引入新的 bug，所以你必須時刻保持警惕。

　　2017年聚劃算年貨節H5網頁設計欣賞當然，你不會只想著搭建一個對于所有瀏覽器放之四海而皆準的網站，所以尋找一個靈活的方法以便于你能夠增加或者移除一些功能是非常有用的。我通常會交替在較小的 MacBook Air 和大屏的 iMac 中使用網站，每次都會暴露出新的問題然后再修復?—?尤其是動畫性能方面的問題，有時候也會有全局設計的題、信息密度、可讀性的問題等等。Media queries 是一款非常強大的工具，它典型的用處是定位由于高度或者寬度造成的樣式差異，但是它同樣能夠用來根據分辨率添加目標內容或者其他屬性。另外，識別系統和設備類型的功能也是非常有用的，因為移動設備的性能特征和電腦還是有很大區別的。