（本文为个人笔记，我都用 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 沟通。他们手指拉一拉，方程式会用到的参数就出来了，也能直接在手机上看到效果。