An API for teaching animations

28 views
Skip to first unread message

Fernando Alegre

unread,
Jan 26, 2017, 9:51:54 AM1/26/17
to codeworl...@googlegroups.com


I was thinking about how to simplify teaching animations, so that they are (almost) as simple as drawings. For periodic animations, I think I got something simple enough. I added an operator (&>) that is similar to (&) but for animations. Then, I created functions equivalent to translated, rotated and scaled, but for working with animations. I called them translating, rotating, scaling, spiraling and waiting. The last two do not have static equivalents for obvious reasons.


Here is a proof of concept:


https://code.world/#PsvAV5xULFXXSGWfohtJkEA


If you have any comment on how to improve it or make it even simpler, please let me know. Ideally, something like this could be part of CodeWorld itself instead of having to add it to each project.



Chris Smith

unread,
Jan 26, 2017, 3:41:40 PM1/26/17
to codeworl...@googlegroups.com
This looks cool!  Initial stream of consciousness thoughts follow.

The choice to make each PeriodicAnimation a fixed length is nice.  It reminds me of something I envy about diagrams, where there, each picture has a definite size.  That means they can implement features like "stack this list of shapes vertically", where CodeWorld cannot.  You've done something similar in the time dimension.  It somewhat raises the question of whether we ought to revisit that choice for pictures, as well.  It should be possible to compute a bounding box for pictures and have stacking combinators.

In any case, encouraging this kind of abstraction with animation can only be a good thing.  For example, another kind of PeriodicAnimation that would be very convenient is moving an object through a list of points -- and if the path taken by the object could be chosen to be consistent with the built-in path/curve functions, so much the better!  I wonder if there are other missing primitives, too.

There's probably room for some different trade-offs with respect to generality and complexity of the API.  One simplification I'd suggest off-hand is to drop the "periodic" from the meaning of the type, and just have different functions to apply the abstracted animation exactly once, versus repeating.  Then the problem that your type is called "animation" (an idea that already means something different) is made even worse... but there are other words.  ("Effect" is an appealing choice.)

There are also several kinds of composition possible: your animations can be applied one after the other as you do, or they can be layered on top of each other at the same time (with some rule for what to do if they have different lengths?).  They can be slowed down, or sped up.  It would be interesting to investigate whether there's a set of such primitives that seems somewhat complete.

One question I don't have an answer for is where this fits with the educational goals.  It's definitely nicer for some things than writing functions.  But writing functions is a skill that's solidly necessary, and all of the ideas and notation - parameters, substitution, etc. - are fundamental to mathematics.  The same isn't true for a novel set of animation primitives.  This isn't a blocker for offering the API, but I'm not sure where I'd incorporate it into a class yet.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CY4PR10MB1558E5DE039AF07B0A1A6223C2770%40CY4PR10MB1558.namprd10.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Fernando Alegre

unread,
Jan 30, 2017, 2:21:19 PM1/30/17
to codeworl...@googlegroups.com

Chris,


Thank you for your feedback.


After working on this during the weekend, I came up with this new version of the API:


https://code.world/#PBq2HkC8axLVGWaE6zljRQQ


This version aimed for generality, and it is based on 4 levels of granularity:


1) A sequence of animations (like "slides", but I called them "scripts")


2) Within a single "slide", several scripts going on in parallel, where each script animates a different object.


3) Within a single object, a sequence of movements (that I called "motions") acting on the object one after the other.


4) Within a single movement, several atomic transformations that move the object at the same time. For example, rotate an object while at the same time translate it.


I am still not happy, because the complexity also increased, as there are 4 different combinators to learn. There is also some duplication between "scripts" and "motions", which I would like to unify.


As to where to go with this, I am not sure, but I think I would like to make the drawings come alive by animating their construction process.


From: codeworl...@googlegroups.com <codeworl...@googlegroups.com> on behalf of Chris Smith <cds...@gmail.com>
Sent: Thursday, January 26, 2017 2:41:38 PM
To: codeworl...@googlegroups.com
Subject: Re: An API for teaching animations
 
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To post to this group, send email to codeworl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5PvJ9MSp3A4Vk4VLX9g9tcGakscMFSoyzdX3B%2B9A6ZZK41Q%40mail.gmail.com.

Chris Smith

unread,
Feb 1, 2017, 4:57:33 PM2/1/17
to codeworl...@googlegroups.com
I filed an issue for this, at https://github.com/google/codeworld/issues/437

Looks promising, but I agree that it would be nice if we can remove some of this complexity and unify types and combinators.  The cost is likely to be that the underlying types may become abstract, that we might end up with nonsense cases of composition that behave oddly, or that we'll lose some opportunities for reuse.

This trade-off has been made before, in the direction of unifying types.  For example, Picture really should be two different types, called something like Shape and Picture, and you should get a Picture from a Shape by specifying an outline or filled style, color, etc.  But this added too much conceptual surface area to the API, so we've shoehorned the two concepts together instead.  Perhaps there are similar choices that could be made here.

On Mon, Jan 30, 2017 at 11:21 AM, Fernando Alegre <FAl...@ebrschools.org> wrote:

Chris,


Thank you for your feedback.


After working on this during the weekend, I came up with this new version of the API:


https://code.world/#PBq2HkC8axLVGWaE6zljRQQ


This version aimed for generality, and it is based on 4 levels of granularity:


1) A sequence of animations (like "slides", but I called them "scripts")


2) Within a single "slide", several scripts going on in parallel, where each script animates a different object.


3) Within a single object, a sequence of movements (that I called "motions") acting on the object one after the other.


4) Within a single movement, several atomic transformations that move the object at the same time. For example, rotate an object while at the same time translate it.


I am still not happy, because the complexity also increased, as there are 4 different combinators to learn. There is also some duplication between "scripts" and "motions", which I would like to unify.


As to where to go with this, I am not sure, but I think I would like to make the drawings come alive by animating their construction process.



Sent: Thursday, January 26, 2017 2:41:38 PM

Subject: Re: An API for teaching animations
This looks cool!  Initial stream of consciousness thoughts follow.

The choice to make each PeriodicAnimation a fixed length is nice.  It reminds me of something I envy about diagrams, where there, each picture has a definite size.  That means they can implement features like "stack this list of shapes vertically", where CodeWorld cannot.  You've done something similar in the time dimension.  It somewhat raises the question of whether we ought to revisit that choice for pictures, as well.  It should be possible to compute a bounding box for pictures and have stacking combinators.

In any case, encouraging this kind of abstraction with animation can only be a good thing.  For example, another kind of PeriodicAnimation that would be very convenient is moving an object through a list of points -- and if the path taken by the object could be chosen to be consistent with the built-in path/curve functions, so much the better!  I wonder if there are other missing primitives, too.

There's probably room for some different trade-offs with respect to generality and complexity of the API.  One simplification I'd suggest off-hand is to drop the "periodic" from the meaning of the type, and just have different functions to apply the abstracted animation exactly once, versus repeating.  Then the problem that your type is called "animation" (an idea that already means something different) is made even worse... but there are other words.  ("Effect" is an appealing choice.)

There are also several kinds of composition possible: your animations can be applied one after the other as you do, or they can be layered on top of each other at the same time (with some rule for what to do if they have different lengths?).  They can be slowed down, or sped up.  It would be interesting to investigate whether there's a set of such primitives that seems somewhat complete.

One question I don't have an answer for is where this fits with the educational goals.  It's definitely nicer for some things than writing functions.  But writing functions is a skill that's solidly necessary, and all of the ideas and notation - parameters, substitution, etc. - are fundamental to mathematics.  The same isn't true for a novel set of animation primitives.  This isn't a blocker for offering the API, but I'm not sure where I'd incorporate it into a class yet.

On Thu, Jan 26, 2017 at 6:51 AM, Fernando Alegre <FAl...@ebrschools.org> wrote:


I was thinking about how to simplify teaching animations, so that they are (almost) as simple as drawings. For periodic animations, I think I got something simple enough. I added an operator (&>) that is similar to (&) but for animations. Then, I created functions equivalent to translated, rotated and scaled, but for working with animations. I called them translating, rotating, scaling, spiraling and waiting. The last two do not have static equivalents for obvious reasons.


Here is a proof of concept:


https://code.world/#PsvAV5xULFXXSGWfohtJkEA


If you have any comment on how to improve it or make it even simpler, please let me know. Ideally, something like this could be part of CodeWorld itself instead of having to add it to each project.



--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CY4PR10MB1558E5DE039AF07B0A1A6223C2770%40CY4PR10MB1558.namprd10.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CY4PR10MB1558DC02E16A6E18837EC4B5C24B0%40CY4PR10MB1558.namprd10.prod.outlook.com.
Reply all
Reply to author
Forward
0 new messages