嫁給RD的 UI Designer

UI/UX 設計、教育訓練、課程演講

高雄-6月份 UI 設計師入門班,報名頁面

怎麼和 RD 配合製作 UI Animation

| Comments

昨天貼的動態效果通靈文在粉絲團釣出幾位 RD 分享經驗。在講怎麼和 RD 配合製作 UI Animation 前,先來看 Rplus Chen 推薦的這篇勸世文 Stop Gratuitous UI Animation ,這篇文在呼籲大家不要為了炫而炫,少用莫名奇妙的動態特效

(本文為個人筆記,我都用 Hype3 直接產出 Prototype 和 JS,避開和一堆數值的大混戰,但該知道「為什麼要這樣做」的部份還是要懂。)

如果設計師要產出動態特效給 RD ,他們需要幾種資訊。感謝邱政憲、Cateyes Lin 、謝孟哲的分享,綜合三位說法整理出下列 6 點:

  1. 起始狀態、結束狀態
  2. 變化屬性(寬度、高度、XY 座標、XYZ 軸旋轉角度、透明度、顏色…)
  3. 時間腳本(多少 ms 到多少 ms 做哪個屬性變化)
  4. 漸變函式(Ex. ease-in)
  5. 操作行為(停止並改為根據使用者操作、忽略、其他)
  6. 參考範例

1. 起始狀態、結束狀態

動態效果開始和結束時的狀態。也就是動畫開始前、跑完動畫後,畫面會長什麼樣子。

2. 變化屬性

有寫過標示文件的設計師都知道,一個元件需標出它的尺寸、距離、色碼、透明度等,如果是文字還要加上字體字級行高之類。在動畫的領域除了 X 軸和 Y 軸外,在 3D 空間裡要再加上 Z 軸。

所有需要製作動態效果的元件通通要標出這些數值,注意是數值,不是一個「感覺」,RD 寫程式不能靠感覺。

百度搜索用户体验中心的 H5 实现酷炫水滴效果 文中對於「水滴」有非常可怕 + 兇惡的數學示範(抖)(這完全是專業的數學領域了,我投降!)

天马行空般的设计甩到面前,含着泪也要做出来——百度前端工程师的内心独白

設計師很爽地把想像中的動態效果扔給 RD ,RD 要經過這麼複雜的計算才有辦法實現。如果有專門處理動畫的職務就算了,這是他的工作,但往往沒有這麼美夢,RD 光是解 Bug 都沒時間了,哪有這麼多心力處理錦上添花的部份呢?

3. 時間腳本

在什麼時間點、某個元件的屬性變化。同樣是關鍵影格的概念,配合「變化屬性」,從 A 時間點到 B 時間點之間,某元件的數值有什麼變化。

若各元件變化時間不同,就會有很多不同的「時間經過」搭配「屬性變化」要處理。

4. 漸變函式

可以用「動作的加減速」來理解。根據迪士尼 12 項動畫原則,第 6 條是漸快與漸慢(Slow in and slow out)Material Design 有一整個章節在說明曲線的必要性,並附上許多動畫範例說明。當然這對設計師來講很有難度。

Easing 函數速查表 可以參考這個網址,和 RD 共同討論元件動作的變化。

5. 操作行為

「觸發條件」,使用者的操作是否會影響動畫或元件?遊戲類特別會注意到這個部分。

6. 參考範例

展示動畫、模擬影片、Prototype 之類,對設計師來說不算太大的困難,難的絕對是上方提的這 5 項數值怎麼標。這些屬性狀態數值沒寫清楚就要靠 RD 通靈了。

RD 現身說法

感謝 謝孟哲 在 FB 公開分享他的實作經驗,已徵得同意轉錄。看完這篇文後,就會知道為什麼 RD 會練滿通靈 Lv.99了。

全文如下:

其實動畫會有分兩種:

  1. 一般的2D動畫(平移、旋轉、透明⋯)
  2. 特殊或3D動畫(翻頁、mac的丟到垃圾桶⋯)

後者大概都只能用口頭或是影片溝通,而且開發成本很高。我遇過的情況是:有一個專業的設計 team,一個專業的特效函式庫 team,再加上完成一切作業的軟體研發 team。

前者就比較有一定的規則可循,因為 engineer(說 RD 居然會被砲?真令人驚訝)在開發時,系統已經提供了相關的操作方式,只要給些相關的參數即可:

  1. 動畫物件的參數變化(如座標、透明度、旋轉角度)
  2. 動畫持續的時間
  3. 動畫加減速的曲線,f(x)=y 表示在時間點 x 的時候物件參數為 y。

這就是上面其他人所提到的。

前兩點是很簡單能量化的,但是光是動畫持續時間就能看出這個 team 在 ux 上的 sense:使用者覺得幾秒的動畫能被接受?動畫播放時是否能被中斷或者改變狀態(左滑到一半可以停止,或變成右滑)?或者,這個動畫是否是需要的?

我遇過新手 designer 或是 engineer 最常做的事情就是把動畫時間定義為 0.6 到 1sec,如果沒有特別的設計我通常會說「太長」而要求改為 0.3 到 0.5sec...這邊扯比較遠,點到為止就好了。

第三點那個方程式就好玩了。這個部分 designer 根本不知道該怎麼描述,即使是 engineer,在這個素質落差那麼大的年代,也不是人人都能寫出那個 f(x)=y 的方程式。不過現在還是有些好用的工具可以用,如這種網頁:

http://matthewlein.com/ceaser/

你可以拉動方塊改變那個曲線,然後按那些按鈕看到即時的效果。

當然,如同上面其他人所言,這個方程式是有現成的可以套用,比如說漸減( web engineer 喜歡說 ease-out,android 上會說 DecelerateInterpolator,由於各平台用詞不同,除非是只跟特定某個平台的 engineer 溝通,否則溝通上我覺得還是用通俗的語言「漸減」來描述比較好。至少 PM 看得懂)。一般而言能有這樣的描述就不錯了,不過若要求更高的品質,就會需要更精確的描述。漸減這種詞就跟黃色一樣,是種很不精確的概念,黃色再精確一點可能會說鵝黃或香蕉黃,但是要十分精確一定是用色碼來描述,否則你的香蕉黃跟我的香蕉黃可能會不同。漸減也是一樣,ease-out 跟 DecelerateInterpolator 是否相同呢?有興趣的可以研究一下,最精確的描述則一定是數學方程式。

在開發某個要求很高的手機 app 專案時,我是直接仿造上面網頁的概念,在手機上面做了一個長得很像的 app 來跟 designer 溝通。他們手指拉ㄧ拉,方程式會用到的參數就出來了,也能直接在手機上看到效果。(但是這只是方程式的其中一種型態,我也遇過要拆成兩段函數來描述的動畫。歡迎有同好一起來交流一下啦~)

當然一般案子是不會用這種成本感覺無上限的方式來開發,比較常見的幾種情況是:

  1. 我說隨我喜好加動畫,業主就很開心了。
  2. 說要參考別人的某某動畫,我就照做,細節大部分的人其實看不出來。
  3. 特別要求的動畫,比如「水位上升到定點還要晃兩下」,這句話就是所有的規格了,也不好找到適合的參考對象。我乾脆就直接把 code都寫好直接看效果(然後這案子就虧本了 XD)
  4. 能有影片讓我臨摹,我就已經感動涕零了。但是也不保證能完全相同,這種方式就是看感覺啦。
  5. 像上面你說的 Hype3,或是我找到的那個網頁,或是我自己寫的 app,這種才是 designer 跟 engineer 能做精細溝通的工具。

就像 UI designer 的 1px 世界一樣,歡迎來到 0.1 秒的動畫世界。就我的經驗,能對 0.3 秒的動畫做出要求的 designer 其實道行很高啊!

(至於怎麼驗證這些動畫的最終成果呢?答案是高速攝影機。其實 iPhone 已經能錄 240fps了,所以也不用花大錢啦。這就是 0.1 秒的世界。)

最後一點是,做動畫還必須要考慮到系統效能。如何用最有效率的方式做到最接近的效果,請 designer 務必要跟 engineer 以完成目標為前提來好好討論。比如說 yahoo 天氣 app 那個背景動態霧化的毛玻璃效果,designer 可能會直覺的調整背景圖片霧化的層度,可是比較有效率的做法其實是用兩個圖層,一個霧化一個清晰,藉由改變圖層的透明度來做到類似的效果,原因是半透明其實比毛玻璃的運算還快很多。(其實效果還是有差喔!只是這樣是為了流暢度所做出的取捨。)

因為效能問題而產生 drop frame 現象,就是大部分的人說卡卡的,是 designer 專業以外的「瑣事」,也往往是 engineer 要花大量時間處理的——或者他會說辦不到,這是系統限制,已超出他的能力所及。這邊就只能視專案的預算跟 engineer 的能力,去分析效能瓶頸,評估可行的替代方案,再一一實作出來評估(這樣的 engineer 很厲害喔,通常已經在求道的路上了,或者已悟道)。這時候 designer 就只能被迫配合了。這部分是很難有文件的,因為這是創新,通常都是在不斷的試誤之下才能做出成品,文件只能事後補上。(好在 engineer 的要求大多很好懂)

或者說,遇到這種情況時,說服客戶改設計是比較好的方式。畢竟通常客戶給的預算只會少不會多,尤其是創新這種難以評估成本的事,懂?

最後一段只是說明,要做出動態效果,也不見得是有一個制式的流程就能產出,過程中可能會來來回回的合作,有時是 designer 主導有時是 engineer 主導...

Comments

comments powered by Disqus