今天这篇同时有设计师@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 的方程式。不过现在还是有些好用的工具可以用,如这种网页:
/ceaser/
你可以拉动方块改变那个曲线,然后按那些按钮看到实时的效果。
当然,如同上面其他人所言,这个方程式是有现成的可以套用,比如说渐减( web engineer 喜欢说 ease-out,android 上会说 DecelerateInterpolator,由于各平台用词不同,除非是只跟特定某个平台的 engineer 沟通,否则沟通上我觉得还是用通俗的语言「渐减」来描述比较好。至少 PM 看得懂)。一般而言能有这样的描述就不错了,不过若要求更高的质量,就会需要更精确的描述。渐减这种词就跟黄色一样,是种很不精确的概念,黄色再精确一点可能会说鹅黄或香蕉黄,但是要十分精确一定是用色码来描述,否则你的香蕉黄跟我的香蕉黄可能会不同。渐减也是一样,ease-out 跟 DecelerateInterpolator 是否相同呢?有兴趣的可以研究一下,最精确的描述则一定是数学方程式。
在开发某个要求很高的手机 app 项目时,我是直接仿造上面网页的概念,在手机上面做了一个长得很像的 app 来跟 designer 沟通。他们手指拉一拉,方程式会用到的参数就出来了,也能直接在手机上看到效果。