《Motion Design for iOS》(十二)

自然的动作

标准的动画时间曲线是好用的,但还可以更好,而且它们不足以让你的用户觉得对你的界面感到惊奇和愉悦,因为它们仍然是机器人的感觉,而不是如人类或受外力驱动的物体般完全流动性和自然。如果我们想要让动画变得真正的自然,我们就需要去观察自然世界以及真实的物体的行为,这样我们就可以模仿其动作。这就是软件中迷人、自然的动画的秘密本质:让你的物体动作符合物理法则,这样你界面中的元素就仿佛有了质量和动量,就如在屏幕上滑动或就在你的用户手指下方一般。

所以自然的动作时怎样的呢?符合物理法则的移动例子是什么?好吧,就如下面这个一般。



弹簧的阻尼



一个挂着方块的弹簧。它就如你所期望弹簧上的方块一样移动,因为你之前已经看过或体验过类似的弹簧运动很多次了。它的运动和之前说的简单动画时间曲线有很大的不同。让我们看一下弹簧上物体的动画曲线。



阻尼的震荡运动



这个曲线表示了挂在弹簧上的物体的运动,有很多的属性(例如拉力、摩擦力和阻力)都影响了其动作。如果你观察上图中的深蓝色曲线,它表示欠阻尼的系统,意味着物体在到达最终稳定位置前会来回震荡(反弹)。这就是让动画如上面的例子一般感觉像弹簧上挂着的方块一样需要的动画曲线类型。这种欠阻尼的弹簧动作可以让动画变得有弹性,很多app都在界面动画中采用了这种类型的动作。比如说,Facebook Paper几乎对所有界面动作使用了这种弹簧动作。

上图中中间的蓝色曲线也显示了一个欠阻尼的系统(在稳定前反弹过最终点),但它是一个反弹较少的更加平滑的动作类型。这会导致一个更精细的感觉,而过度反弹的动画会让你的界面变得太丰富或热情。

红色曲线描述了一个很少反弹而且只在到达最终位置前越过一点点的动作。如果物体一点都不震荡和反弹,只是缓慢地到达最终位置,这种弹簧就叫欠阻尼。



版权所有:http://blog.csdn.net/cloudox_

长期致力于iOS英文资料翻译

觉得有帮助的可以打赏支持一下小弟~

时间: 2024-10-10 15:52:16

《Motion Design for iOS》(十二)的相关文章

构建之法(二)

团队开发模式. 这学期我们主打的就是团队开发模式.对于团队而言,我算是有了一点儿基本的理解.书中什么各种团队模式,明星模式,秘密团队,特工团队.但是我发现在我身边的都是一个人担当起整个团队.文中说这是主治医生模式的退化版.就是“一个学生干活,其他学生跟着打酱油”.这也算是团队的一种把.对于团队的沟通也是很重要的.我们一起开发设计,有时候我们的沟通确实很不到位.导致工作进度一直跟不上计划.很多时候也就是30分种解决的问题,但是就是一直拖着. 开发流程被采纳的是瀑布模式.之前看大道至简的时候也提到了

【老孙点评】古人读书十二法

书,人人都可以去读,但是有的人就读不懂.读不通.读不进,甚至越读越糊涂.这里说明读书是有得法与不得法的区别的,但要相信方法总是可寻的.读书不得法,就如上面所说的那样,反之,也有不少人把书读懂而且读通了.读书的方法,也不止一种,现在选列了古人读书十二法,以供借鉴与参考: [法一]."思·问·习"读书法.这是孔子主张的读书方法. [例]1.重视思考.在学习过程中,要动脑筋.他说:"学而不思则罔,思而不学则殆."(<论语·为政>) [例]2.不懂就问.读书在于

读《构建之法》之一,二,十六章有感

大二下学期已经过去两周了,个人感觉,课程方面压力与动力并存,相信一步一步走下去终将得到自己的一份收获. 这几天阅读了<构建之法>的第一,二,十六章,我个人的阅读速度应该属于比较慢的那种,遇到什么不确定的,不理解的概念总要停下来好久,各种百度,否则继续阅读的时候总有种急躁的感觉,老想着前面的停顿,到头来一头雾水,还是跑去理解前面的概念.作业中关于精读的part1,2,3一开始我觉得可能不适合我这种节奏慢又钻牛角尖的,但贵在尝试,以前我的阅读习惯是只读一两遍,虽然第一遍把不理解的概念都慢慢弄明白了

构建之法第一、二、十六章

<构建之法>第一.二.十六章疑问 我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章  概论 软件=程序+软件工程 扩展:软件企业=软件+商业模式 软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营.和维护上的过程.软件的特殊性有a.复杂性 b.不可见性 c.易变性 d.服从性 e.非连续性.软件工程与计算机科学的区别:计算机科学中与实践相关的部分,都和数据以及其他学科发生关系:

《构建之法》读书笔记之:第一、二、十六章

这周看了邹欣老师<构建之法>的1,2,16章,获益匪浅.这本书写得妙趣横生,用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念,让我对软件工程有了初步的了解:原来开发软件并不是我们想的那样简单:上手直接敲代码就可以了,而是会有一套详细的流程规范.下面是我看书时的一些心得笔记,和一些无法自己解答的疑惑,烦请各位老师批评指教. 第一章: 笔记: 软件=程序+软件工程,是否可以通俗地理解为,程序只是死的机器的东西,为什么做(需求分析),做什么(软件设计),做完后这东西是否可行(软件测

《构建之法》第十一、十二章学习总结

第十一章的内容是软件设计与实现. 在第一节中,讲的是关于分析和设计方法,向我们介绍在"需求分析"."设计与实现"阶段."测试""发布"阶段该搞清楚的问题. 在第二节中,讲的是关于图形建模和分析方法.在表达实体和实体之间的关系时,可以用到思维导图(Mind Map).实体关系图(ERD).UCD ;在表达数据的流动时,可以用到DFD工具:在表达控制流的时候可以用到FSM工具:前面提到的这些图形建模方法各有特点,UML却可以有一个

阅读《构建之法》十一、十二、十三章

第十一章 问题:为了避免误解,我们是不是可以把我们理解的告诉用户,并且最好是图像的形势或是其他方式展示给用户? 第十二章(P230) 问题:为了让用户满意,是否可以在用户的原来基础上创新,体现出一些人文关怀,请问这是一些好的想法吗?还是这是程序员的顾忌?

阅读《构建之法》十一、十二、十三章之感

第十一章 问题:为了避免误解,我们是不是可以把我们理解的告诉用户,并且最好是图像的形势或是其他方式展示给用户? 第十二章 问题:为了让用户满意,是否可以在用户的原来基础上创新,体现出一些人文关怀,请问这是一些好的想法吗?还是这是程序员的顾忌? 第十三章 问题:(220)文中提到用户需要帮助,但是用户没有那么蠢.是一个人非常典型的例子,但是这个例子问题太过突出.有时候就算我们记住了用户的选择,考虑了用户的感受,但是还是难免把握住那住个度,那么我们如何准确的把握住那个度.

《构建之法》读后感系列之二

关心自己更关爱你 “本是同根生相煎何太急”,大家都是程序员,规范自己的代码结构不光方便自己还方便看代码的人. 还记得大二的操作系统上机,我的代码因为是在vim里编写的,实在是懒得缩进,大括号也没有对齐,结果在编译时候出错,当时找错误真是找瞎了眼.虽然结果最终是正确了,但是助教检查的时候还是善意地指出了我代码结构的规范性问题. 所以看到邹欣老师在<构建之法>第四章指出的代码规范性问题,给我的共鸣还是很明显的.我认为,程序员在成长的过程中,不仅是知识的不断堆砌,更重要的是不断规范自己的过程.书中指

Android学习路线(二十二)运用Fragment构建动态UI——构建一个灵活的UI

先占个位置,下次翻译 :p When designing your application to support a wide range of screen sizes, you can reuse your fragments in different layout configurations to optimize the user experience based on the available screen space. For example, on a handset devi