印前

设计系统里的动画 ◆ 24 ways

印前 · 2017-03-16翻译 · 599阅读 原文链接

现代的前端工作流已经成熟,包括设计系统以及组件库,它们帮助我们保持组织有序,改进工作流,简化维护。这些系统在执行良好时,能确保可用代码的正确记录,使我们的系统能够缩减通信冲突。

但是,尽管大多数这些系统在文字,颜色,常规构建块时采取关键立场,但是他们对动画的处理仍是无组织的和临时的。让我们利用现有的结构和工作流来减少动画的摩擦,创造有粘着力和高性能的用户体验。

了解动画的重要性

我们对待动画像对待二级公民的其中一部分原因是我们没有真正思考过它的力量。但用户正在扫描一个网站时(任何环境或照片),他们正在试图构建他们周围环境的空间映射。在这个过程中,没有什么能像运动着的东西更引人注目。

我们天生对动画是有条件反射的:从进化的角度看,我们依赖它绝处逢生。因此,动画完成后可以引导用户。它可以帮助,强化这些映射,并让我们感觉,我们更深刻的了解用户的体验。我们检索信息并放回原处而不是放在弹进弹出的地方。

“菜单跑到哪里去了?噢,它在这里。”

为了更深入抛下动画如何连接不同的状态,我为CSS技巧写了关于在用户体验模式中上下文转换的重要性的文章。

移动设备上的动画流.

移动设备上的动画流

动画也有助于感知性能。Viget进行了一项研究,让用户分别体验标准的加载动图与体验一个自定义动画,他们测量两类用户的感觉,结果显示体验自定义动画的用户愿意等待的时间是体验标准加载动图的用户的近两倍, 即使自定义动画不是特别招人喜爱或疯狂的。只是通过向用户展示他们在意客户,他们与用户同在,结果跳出率下降了。

普通的加载屏幕

14秒通用加载屏。

一个自定义加载屏

22秒自定义加载屏。

这同样也适合表单提交。将个人信息通过在线过程如提交静态表单着实让人痛心。如果没有动画信号提示什么事情要发生,什么过程已经完成,这将更痛心。同样,动画也可以使用户更快乐,而且会感觉好像没有等那么长的时间。

Eli Fitch 在CSS Dev Conf上的谈话说道:“感知性能:唯一真正重要的事”,这一直是我最喜欢的谈话主题之一。在谈话中,他谈到我们如何衡量像时间轴和网络请求等因素,因为它们更具可量化性,因此更容易测量,但是测量用户访问网站时的感觉更重要,值得投入时间和精力。

在他的谈话中,他声明:“根据麻省理工学院的Richard Larson,人类高估了被动等待36%”。这意味着如果你不使用动画来加快表单提交等待时间的加载速度,用户会感觉比实际开发工具时间线记录的时间慢得多。

统一

不像字体、颜色等等,我们倾向于在最后一步添加动画,这样就导致了缺乏整体统一的杂乱的安装启用。如果你问一个设计人员或者开发人员,如果他们在不知道他们要用的字体的情况下,要创建一个实体模型或者构建一个用户界面,他们不会喜欢这个想法的。不知道要做的构建块意味着设计可能土崩瓦解,或者是开发会被最开始忽略的一些最基础的事情打断。好的动画也同理。

统一动画的第一步就是执行动画审计。观察网站上所有使用到动画的地方,或者应该有动画的地方。(暗示:感知表单提交加载的性能会大幅性地改变网站跳出率)

不确定如何做好执行审计?Val Head在她的书中有一章节对此写得很好,设计接口动画,这章中有大量的研究和很棒的想法。

甚至一个优美的组件库在文档中有些动画都犯了这个错误。你不需要所有的动画,就像你不需要所有的字体一样。这使代码臃肿。问问自己这样的问题:你真的需要一个翻转180度的动画吗?我甚至不能构想一个典型的用户界面哪里放它比较有用,但我知道的大多数组件库都有一个mixin只做这个。

这导致了。。。。

有自己的观点

很多人都对质感设计充满疑惑。他们认为质感设计是动态图像设计,很可能是因为他们之前从未见过任何人在动画上有其他观点并将其用文档表述得很好的。但是每次你使用质感设计做为动态图像设计语言时,人们看到你的网站就想到GOOGLE.帮助它打响品牌。

通过使用谷歌的动态图像设计语言而不是你自己的,你就会失去你自己品牌的显著特征。

对动态图像的有自己的观点在实践中应该是什么样子呢?它可能意味着你已经决定再也不翻转东西了,可能意味着你总想用滑动。在那种情况下,你会把你的精力放在寻找一种轻松,它看似滑动,而且会用所有的转换:你发现你网站会有scaleX(-1) 的动画。在团队中,每个人都知道不要花时间嘲笑翻转动画(即使它们工作于两个完全不同的代码库),做一些感觉像在滑行的东西。你既节约了时间,又不必一遍一遍地沟通让东西看似一体。

创建好的开发者资源

有时,人们不将动画融入设计体系是因为他们不知道如何超出基本的hover状态。所有的动画属性都可以拆分成可交换的片段。这允许开发人员和设计人员都可以迅速混合,匹配和迭代,同时仍然保持使用正确的语言。这里有一些推荐(代码和示例紧随其后):

创建时间单元,和h1, h2, h3.相似。在我最近工作的系统里,我将其称为t1, t2, t3. T1 为更长的片段保留,逐减到t5 ,这有点像默认的h5(通常约0.25秒左右)。保持动画对进入、退出的缩放,在人们通常涉及到的进入和退出强调。这,而且animation-fill-mode,好像是唯一两个属性可以在进入退出动画中重复使用的。使用 animation-name属性来定义动画本身的关键帧。我推荐在让它们回来之前开始用5或6,如果你需要更多可调整。编写30种不同的动画可能像是一个好的资源,但是就像你的颜色调色盘有很多不必要,使你的代码臃肿,让他们感觉统一和谐。精密思考你需要的是什么。

请看Sarah Drasner(@sdras) on CodePen的这个示例组件库的模块动画

以上示例是极简单的,但是你可以看到在一个强健的系统中,如果在整个系统中缓存可交换的片段,就可以节省迭代和原型时间,更不用说轻松地在同一动画中对不同感觉的移动调整。

一个轻易实现的东西可能是一个加载器,引导一次成功的对话.在一个大网站上,你可能有多次使用这样的模式,因此编写一个组件,专注于帮你移动更快,并且允许你真正的放大和关注那种模式。避免在最后一分钟把一些东西扔在一起,或是使用GIF,GIF在视网膜上非常的繁重。可以制作单独看起来真正精致可重用的片段。

React和Vue实现都是很棒的可复用组件,因为你可以创建一个通用的动画模式的构建块,一旦被创建,为所有资源所用。记住利用类似道具的东西来定时和缓动调整,就像我们前面的例子一样。

响应

至少我们需要确保交互在移动端运行良好,但是如果我们愿意利用所有提供的手势移动创建交互,我们可以使用库如zingtouch或者hammer来滑动或多只手指检测。另外,这些也都可以通过原生检测来创建。

响应式web网页可以在meta标签里指定initial-scale=1.0,这样设备就不会在回调行为之前,在二级标签上等待300毫秒。触摸事件的交互必须从一个更大的触摸目标(40px × 40px或者更大)开始,或者使用 @media(pointer:coarse) 做为支持允许。

买入

有时人们不会因为它被优先级花了就创建简单的动画资源。但是设计系统也是我们曾经争取的东西.今年在CSS Dev Conf大会上,Rachel Nabors演示如何绘制动画需求于图形上的需求(经她许可可以转载),以帮助他们确定优先级:

A graph showing animation wants and needs, split by 'low hanging fruit', 'long-term investments', 'pet projects', and 'you'll never get to these'.

A graph showing animation wants and needs, split by 'low hanging fruit', 'long-term investments', 'pet projects', and 'you'll never get to these'.

这帮助与你共同工作的人们理解相关必要性和额外的工作量,并更批判性思考它,你可能会得到收获通过证明你所创造的东西被需要并且可以被重复利用的。

好的妥协可能像这样:“我们不打算制造出所有动画,还在'关于我们'的页面创作你想看到的动画,但是我认为可以通过电子邮件的方式告知用户通过一个小的进程或成功。”

通过帮助构建对你们团队的信任,成功的推动更小的项目,让人们看到这样的合作是怎样的。这构建了必要关联来推行更多涉及的项目。再次强调好的沟通是关键。

开始吧!

通过这些工具和良好的沟通,我们可以使代码库更加高效,更高性能,更好的用户体验。我们可以增强我们网站的用户体验,为我们的团队创建更好的资源,帮助团队迅速迁移,且创造足够优雅。

相关文章