今天这篇同时有设计师@Akane_Lee 和工程师同学的现身说法，在动效流行的今天，想制作一个酷炫的动画效果，该如何与工程师沟通才能好好合作不动手呢?直接让工程师本人来亲自告诉你。
在讲怎么和 RD 配合制作 UI Animation 前，先来看 Rplus Chen 推荐的这篇劝世文 Stop Gratuitous UI Animation ，这篇文在呼吁大家不要为了炫而炫，少用莫名奇妙的动态特效。
(本文为个人笔记，我都用 Hype3 直接产出PRototype 和 JS，避开和一堆数值的大混战，但该知道「为什么要这样做」的部份还是要懂。)
如果设计师要产出动态特效给 RD ，他们需要几种信息。感谢邱政宪、Cateyes Lin 、谢孟哲的分享，综合三位说法整理出下列 6 点：
起始状态、结束状态
变化属性(宽度、高度、XY 坐标、XYZ 轴旋转角度、透明度、颜色…)
时间脚本(多少 ms 到多少 ms 做哪个属性变化)
渐变函式(Ex. ease-in)
操作行为(停止并改为根据使用者操作、忽略、其他)
参考范例
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了。
全文如下：
其实动画会有分两种：
一般的2D动画(平移、旋转、透明…)
特殊或3D动画(翻页、mac的丢到垃圾桶…)
后者大概都只能用口头或是影片沟通，而且开发成本很高。我遇过的情况是：有一个专业的设计 team，一个专业的特效函式库 team，再加上完成一切作业的软件研发 team。
前者就比较有一定的规则可循，因为 engineer在开发时，系统已经提供了相关的操作方式，只要给些相关的参数即可：
动画对象的参数变化(如坐标、透明度、旋转角度)
动画持续的时间
动画加减速的曲线，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 沟通。他们手指拉一拉，方程式会用到的参数就出来了，也能直接在手机上看到效果。
