Last Call for v11 Input

i used TimelineMax for one Project and it was JUST GREAT.

no.3 – YES
tweenlite should be what the name suggests = tween LITE

tweenmax should be tweenMAX

I’d love velocity properties on the tween. Sometimes things go from automated ‘tween mode’ to interactive mode (vector math driven) and if I can get the current velocity of a particular value, it would be great. I’m guessing motion tween uses this already?
Starting velocity would be great too for transitioning from an interactively driven motion to an automated motion seamlessly.

#3, another vote for yes with keeping it lite as a priority

1) Haven’t used it yet but looks pretty good. Apart from my old gripes about you still having object properties and modifiers in the one object looks good.

2) Don’t think all plugins should be activated. You should have a function that activates the plugins if you wanted them all? I actually haven’t seen the code for plugin implementation yet so that might be a stupid comment.

3) Backwards compatilibility doesn’t seem to be a big issue to me. If users get problems when updating it can’t take more than 10 minutes to fix problems even in the largest projects as long as you’ve got an editor with a “find in file” function. If you’re not then your projects can’t be that big anyway.

4) Not that I can see.

5) That TransformAroundPoint looks amazing! Really gonna have to get you some money so I can start using that one!

6) Cycles makes sense from an animation point – at least After Effects. Flash CS3 says “Rotate CW X times” in the menu, and CS4 says something similar so neither of those can give you a good idea what to call it. I guess repeatDelay is how long between repeats/cycles? You could call it “cycleDelay”, that’d make sense. Or just “delayBetweenCycles” but that seems a little verbose.

7) I think the names should be consistent with Arrays if you worried. Push and Shift work, but then again Shift is always a weird one. Depends if you’re aiming at programmers or animators (I’m guessing programmers). Prepend is a better workd than Shift.

Anyway, my 2 cents, done. Sorry I didn’t have time to look deeper into the implementation but wanted to get some comments out before I forgot then realised it had been set in concrete.

#3, YES
having to edit the class file makes updating tweenlite quite painfull, unless you provide a public method to de-activate plugins from outside the class file.

Everythings fine, release it Jack

One question remains, will there be an AS2 Version too???

cheers

#2 Only major plugins
#3 No plugins by default
#6 Keep as “repeat”
#7 Keep those helpers in.

#2, No plugins should be pre-activated.

tweenmax is here for it’s unique features which were 4.8kb too much for tweenlite and which obviously are not the plugins !

the only reason I would need to use tweenmax is precisely for this features and certainly not because it has pre-activated plugins which I can easily activate in tweenlite if I want.

pre-activated plugins are never exactly the ones you need, you always end up having to remove some of them and add some others.
I believe it’s easy enough for anyone to activate plugins.

Re: Point 3 – TweenLite…

Would it be an idea to run with the “lite” option, but to have a static setter called “legacy”, which, if set to true would call the default activation currently in the constructor? So if you wanted to use TweenLite to be backwards compatible, you would just have one line to write – TweenLite.legacy = true?

I’d like to stress out how editing the class file to remove pre-activated plugins is not a elegant solution.

Any developer concerned about file size will certainly de-activate plugins they don’t use for a certain project.
1. that is impossible to do if you wish to have the gs library placed in a global classpath for several projects.
2. if you duplicate the gs folder for each of your project instead, updating becomes really cumbersome, you have to update the libs in each of your projects + you need to keep a list of the specific plugins you want to get deactivated for each of your projects.

for the new version number step, please consider removing ALL plugins from pre-activation. both in tweenmax and tweenlite.
and highlight the real difference between both class instead.

have MAX fully bloated! yeah! hardcore!

2: No, but for my case, frame, endArray, bezier, bezierThrough, roundProps and shortRotation could be deactivated by default, because then it more reflects the standard as3 functionality.

3: Yes, please.

4: Maybe some documentation about writing own plugins and a license model for these purposes. For example I started to write a bitmap-transition-class, but it would be much more easierer to use your tween classes as a functionality base.

Also OverwriteManager.init() should be actived by default in my opinion.

5: I like the notation most, it’s possible in most cases to do complex tweens with a single line of code.

6: repeat sounds better to me.

Also Yes on #3. I’ve already retro-ed the plugins I use to be active on TweenLite past projects, so no big deal for me…

Jack,

Regarding #3, I’d prefer to see all default plugin activations with lite. Let Lite, by default, be as light as possible and leave it to developers to decide the filesize/functionality trade off of activation additional plugins.

Excellent work all around, sir. I appreciate your thoughtfulness in soliciting feedback from those that enjoy and rely on your work.

As far as #7 I love convenience methods like prepend! I’d probably write a wrapper for it anyway. It’s so much more readable than myTimeline.insert(myTween, myTimeline.duration).

As far as #5 I sent you an email about not seeing the array manipulation features of TweenGroup, but I ‘ve probably just overlooked them.

I frequently want to apply a single tween with a stagger to an array of objects and would like to do this without having to explicitly create a bunch of identical tweens.

I like the idea of velocities too. Some things I do are done in “pixels per second” more easily than calculating a tween distance/time to get that effect.

>allTo() and allFrom() moved to TweenMax and moved the stagger
>onCompleteAll, and onCompleteParams to function parameters
>instead of special properties in the vars object

I’m inclined to keep the method signature the same and leave these in the vars object.

I personally would like all tweenmax plugins activated, and keep tweenlite as lite as possible.

I’d also prefer using append/prepend as it’s very easy to tell when an item is being tweened relative to the tweens around it.

1 thing I wouldn’t want to lose: shorthand syntax for inserting tweens. Small thing, but saves a lot of time and space.

Thanks for everything

2-no!
3-yes!
6-no!
7-no!
Can’t wait to see the final release!

#3 makes sense. However, I’d like to have a “plugin presets” feature, allowing for a one-step quick activation of useful plugins such has autoAlpha, tint and volume that would be stripped of TweenLite otherwise.

Also I feel like autoAlpha is a great feature but should be more of a true/false switch on the Tween. Then the user could just use alpha:num and if autoAlpha was set to true it would work. Seems more consistent with general class structures. Because it’s really more of an option than it is a function. Do you or do you not want it to automatically hide and show?

In addition to autoAlpha I think shortRotation would be Boolean switch as well, instead of the actually property being altered. It just seems a tad complex.

Instead of:
TweenMax.to(mc, 1, {shortRotation:{rotationX:270, rotationY:40}});

Use:
TweenMax.to(mc, 1, {shortRotation:true, rotationX:270, rotationY:40});

Just seems cleaner to me.

motionBlur is implemented perfectly! I love that you can pass true/false OR an object for more specific settings.

1 – Yep! The new API is awesome!
3 – Keep the TweenLite size small, when i need to activate to many plugins i change to TweenMax.
6 – “cycles” and “cyclesInterval”

Great work! Go on!

#2, I think having everything activated in TweenMax shouldn’t be a problem. In my experience the users who are really concerned about crunching the filesize are usually more versed in coding and it’s not as big of a deal for them to go deactivate some stuff.
I deal with alot of designers who want a dev to just set their classpath up for them once to a global TweenMax location on their machine and then they just use it on every project. They would have no clue how to add or remove anything, so they’d be more upset if they couldn’t use a feature they saw in the documentation.

removing all pre-activated plugins from both tweenMax & tweenLite. will :
1. Allow a straightforward gs library update for developers.
2. Enforce a compiled size economy ‘best practice’ when using Lite&Max
3. Wipe out future backward compatibility issues related to those arbitrary default features.
4. make my day

@ hugo:
isn’t plugin activation already a dead simple one-step process ?

One of the most valuable ‘features’ of the whole gs.* package: all the code samples and snippets littered throughout the source code and documentation — just like the text boxes in the supplemental .swf demos.

Seriously, this extra helpful touch is worth a million dollars to me. I’m deep in a project; in a haze I guess I kinda/sorta remember to import gs.* and gs.easing* — and then what? I blank on how to tween a tint color or glow.

At the top of each .as file are code snippets which demonstrate how to implement the features you care about. Truly helpful.

- Please don’t activate all plugins in TweenMax

- I would love to see the removal of all plugins in TweenLight by default. I like the idea of a simple setting for legacy mode, though.

- I like repeat much better than cycles.

- I like the prepend() and append() helper methods

- One feature I would love to see added is the ability to repeat with TweenMax.delayedCall(). It would allow me to use it instead of setInterval or Timer in many places which would be very convenient.

Really great stuff, loving everything

2) yes i think so. Its called tween max after all and tweenlite is there if you need to save the extra kb`s.

3) yes, as small as possible please

6) repeat makes a lot more sense to me

One feature i would find very helpful would to be able to have an array of speeds. So with one call you can tween multiple properties with a separate speed for each one.

I really like it Jack, I think you should keep append() and prepend(), and I think repeat just sounds more intuitive than cycle.

One thing I would like to have is the option to use numbers instead of full names for plugins when I activate them. For example when I’m setting displayObject.blendMode, instead of blendMode = “layer”; I can just use blendMode = 2;

Sure you need to have a decent memory, but this really speeds things up for me and the ability to do that with plugins would be great.

Full disclosure: I’m a “newbie”, but I think this is a great way of developing the platform, so I’m glad to chime in …

1.) TimlineLite/Max is a slick way of adding flexibility and functionality to tweening and insertMultiple expands on those aspects considerably ((\\… Respect …//))

2/3.) I think less is more, particularly in respect to the TweenLite target user. Given the fact that plugins can be activated within a project on a case per case basis, having none of them activated by default keeps file size at a minimum, but doesn’t prevent developers from taking advantage of them. I’d personally prefer making a couple of different templates with a couple lines for import and activation, than have to think about modifying the actual classes.

6.) Repeat is more intuitive (IMO)

7.) I like append() and prepend() and I hope you keep them. For what it’s worth, I didn’t grasp the example you posted, which used “myTimeline.duration” where I did get the append() and prepend() examples in the API docs. Once again though, I’m a less experienced user.

That’s all. Keep up the good work!

3) maybe make a new class BannerTween which is even smaller/more basic than tweenLite? ATM I generally write my own simple tweening classes for banner work where filesize is really an issue, and a new micro class would be great, and would solve the concerns over backward compatibility.

#4 I know this can somehow be achieved through timeline, but since allTo(), allFrom(), and stagger are back into tweenmax, I’d love to be able to to something like this from tweenMax:
TweenMax.allTo(myTargetsArray, .5, { y:[0,10,20,30,40]} );
or:
TweenMax.allTo(myTargetsArray, speedArray, { y:0} );
where 2 types of arguments could be used : array of values or single value.

I would definitely like to see a scrollRect feature – similar to the one the Zeh has incorporated in Tweener. Allows one to tween

_scrollRect_x
_scrollRect_y
_scrollRect_width
_scrollRect_height
….top,left,bottom and right

very intuitively
cheers Jack – great work!

ABSOLUTELY IMPORTANT: ALL plugins Should be activated in TweenMax by default, PLEASE !!!

EVERYTHING ELSE IS JUST FANTASTIC, BLESSINGS DEAR JACK.

1) Feels good the way it is, especially after the change for play()/reverse()

2) No. In my mind that would make the plugin architecture useless (outside of 3rd party plugins) because users would not have to activate the ones they want/need and maybe for the future not even know how to activate plugins because they never have to do it. they may not realize that you have to activate a third party plugin after downloading it (i know, but it happens). Plus, it is TweenMax, but that doesnt mean u need to bloat it unnecessarily. TM already has the plugins i use most activated so i don’t see the need to add more; i think its well covered with whats used by default.

3) Yeah, this would probably be a good idea. Again, its TweenLite but this time around emphasis on the Lite. Plus, activating plugins is a one step process and super simple. It encourages using the plugins and maybe push people to further develop their own (ones that may not realize this family uses plugins).

4) I think the current feature set is amazing. Everything I have asked for in the past has already been added and I don’t see a need for anything else right now, personally.

5) Although I havent used it as much, i think bezierThrough is one of the best features of TM. I use the colorMatrix stuff alot and I love the new way of easily doing rollovers. you should write a little tips/tricks section and show stuff like that to users. its not always visible right off the bat (and i dont mean post it in the forums, i mean have a separate section for it, just like third party plugins ). Not everyone reads the forums consistently but separate pages for each of these things would get more visibility.

6) I think repeat is more intuitive.

7) little helper methods like append/prepend are always a welcome addition to an API.

How bout a “removeTarget” function that cuts an object when its alpha goes to 0 (something I know I could use in my projects)?

Hi Jack,
I’d love to see if you can release a tiny version of TweenLite (TweenVeryLite) that do the simplest work: Tweening. Sometimes you/me just use TweenLite to do a very simple work of tweening like tweening x, y, alpha, that’s all, nothing else. So if a very lite version comes out that would be very helpful for people that just need simple code. Your TweenLite/TweenMax now is very powerful, I really appreciate your awsome work but it become more and more complicated now. Try to make something simple.
Thank you so much for your great work Jack.

I agree that allplugins should be activated in TweenMax by default, there is tweenlite in order to have small size

I would like to see TweenLite extend EventDispatcher and dispatch TweenEvents like TweenMax does. With my own tests, extending a class with EventDispatcher doesn’t add much to the filesize footprint of a class. In my tests, it didn’t even add ONE kilobyte to the filesize.

This would be a great feature as it would make TweenLite use event dispatching functionality that many other built-in AS3 classes use.

1 – API is intuitive. only thing is that the label thing throws me off sometimes in .insertMultiple because it’s using a wild card, so if I forget it’s there the type checking doesn’t alert me that I’m putting the stagger string value instead of the insert position. ALSO – doesn’t that decrease performance since it requires the AVM to figure out what type it is?

2 – yes, if using tweenmax I probably wouldn’t worry about an extra 40k, and can always go back and deactivate if I need to save space.

3 – yes, should be bare bones and expandable if needed.

4 – One thing I found to be somewhat of a hassle sometimes is remembering the syntax for less common tweens (like blur or contrast) — even though those ARE intuitive, I still come back to the blog everytime and take the snippets of code from there (NOTE – brightness/contrast seem to be missing from the plugin explorer…). if there was a way to add some classes that provided more auto completion or even a downloadable standalone or AIR app that would act as a snippet generator I think it would be very useful.

5 – by far the new timeline feature is awesome! that was the only thing I was really missing. I also really like the remove function added to the end of the tween.

6 – repeat seems more common.

7 – append and prepend are MUCH more intuitive than the method described in the question, especially for less experienced coders. I would keep append and prepend.

awesome stuff!

-i

event dispatching by TweenLite would be really nice; event-driven models are quite obvious for AS3 developers and it would be much more functional/intuitive/elegant for us to use it in all cases instead of cluttering our code architectures with those legacy handlers; and like Jaxim said, it wouldn’t add much to the KB footprint; besides, it’s an AS3 version of GreenSock Tweening Platform, isn’t it? thanks anyway, it’s a great stuff you’re bringing here

1) The API feels great!
2) Probably?
3) No, keep em for backwards compatability
4) I can’t think of any
5) Not sure
6) Don’t care
7) Keep em! Please! They are very intuitive!

2. YES
3. YES. And for the 40% that want backwards compatibility leave an link to download all version of TweenMax & TweenLite engine. So everybody is happy.
4. Please add a property called “scale”. So it scales scaleX and scaleY to the same amount.

2) Yea why not..
3) If it’s easy to “unplug” all plugins.. then just leave it for compability.
5) “Switch to framebased”-feature MUST prevail.. this is the feature i’m most exited about. TweenUltraLite+Framebased engine.. ULTIMATE tween engine for online banners.

event dispatching by TweenLite would be really nice; event-driven models are quite obvious for AS3 developers and it would be much more functional/intuitive/elegant for us to use it in all cases instead of cluttering our code architectures with those legacy handlers; and like Jaxim said, it wouldn’t add much to the KB footprint; besides, it’s an AS3 version of GreenSock Tweening Platform, isn’t it? thanks anyway, it’s a great stuff you’re bringing here

I appreciate the suggestions for adding event dispatching to the AS3 version of TweenLite, but I’d like to explain why I haven’t done so: Not only would it increase the file size a bit, but event dispatchers are definitely SLOWER that callbacks. I ran some tests and they were more than 21% slower. TweenLite is intended to be lightweight and FAST, and since you can accomplish almost anything with callbacks that you could with listeners, it seemed appropriate to use callbacks in TweenLite and offer event dispatching as an “upgrade” in TweenMax. Typically developers that rely heavily on event dispatching are working on projects that aren’t as bandwidth-sensitive, so they can easily afford the extra few kb that TweenMax costs in order to get all the added features like event dispatching.

Thanks everyone for the feedback! We’re getting close to the final release.

I agree with everything with one exception, plugins should never be active by default. It goes against the nature of plugins. Furthermore, deactivating plugins seems is a messy way of coding. Even from a visual stand point, its better to see what plugins are loaded when you look at your code. rather than trying to figure out what you have removed and if it is enough.

Haven’t tried v.11, but I favor simplicity and backward compatibility over size and speed. Make it so you can tweak your import and exclude plugins if you’re super worried about size, but keep it as plug and play as possible. I don’t want to have to go to the top of my file and import more things every time I decide to tween an additional property.

Thanks Jack!

3) Keep TweenLite as is for backwards compatibility and add another called TweenSuperLite (or whatever) that includes no default plugins

I’ve been using the timeline classes and they rock. I didn’t have any suggestion but right now reading this I had one idea: The possibility to ‘name’ tweens or timelines inserted inside a timeline, and use that names to modify or remove the tween or timeline later. I now this can be done keeping a reference of the tween or timeline passed, but right now seems easier and more intuitive that way. What do you think?

Definitely the best tweening solution existing! Thanks for the good work!

7. I’d keep the methods and its names. The Timeline classes represent tweening lists after all and I can’t think of any implementation of a list with methods called push and shift…

I agree with Ramiro: Tween identifiers would be a nice thing to have. If you try to identify a given tween, you have to do a lot of iterating through the get Children()-Array or save a reference when istantiating the tween. This could be made smarter, I guess.

#1 / #4
one tiny thing maybe: to tween objects relative how about an option kinda like: relative:Boolean or delta:Boolean to switch between relative and absolute, instead of setting quotes.
would make it easier tweening object with dynamic size

otherwise: it’s more than i thought i’d ever need… i’ve done animations that would have been quite difficult with other engines… LOVE TimelineMax

#2
yes. it’s called TweenMax, then max it

hence:
#3
yes. no plugins (although i’m more of a Max user)

#4 -> #1

#5
bezier, autoAlpha,… and all the others ^^ keep them all, at least within *Max

#6
either suits me. repeat is ok. never change a running system ^^

#7
keep both! let user decide if he need append() or insert()

1: Everything works great, this version has the best API in my opinion. I like the use of initialising objects in the constructor as this fits in with other API’s I’m using (Away3D for example).

2: yes

3: yes

6: No, repeat keeps it inline with everything else

7: keep them, and possibly add appendMultiple() and prependMultiple() for consistency.

AutoBlur would be a great option (if an element is moving fast on x or y, it automatically would set the blur accordingly to create a great speed effect)

cassio, That’s exactly what MotionBlur does! It even changes the direction of the blur based on the angle of movement.

1) It feels fine, but the use of append/prepend is inconsistent. Personally I’d like to see it expanded for consistency rather than eliminated for consistency, but in general either way would probably be an improvement.
2) No, I always comment out some of the ones that are already activated anyway already.
3) Yes.
4-5) Can’t live without the addCallback, but an appendCallback/appendMultipleCallbacks would be more intuitive and consistent, I think, especially if, via appendMultiple, you could be sure they would get called in that order. I’m not saying that any of this is particularly important because you can sequence them already with the time parameter, it would just kind of fit in with the rest of the interface better.
6) No, I’m a heavy AE user but I still say repeat is fine and easier to understand.
7) Keep them and I second the motion for appendMultiple() and prependMultiple()

I am new to AS and TweenMax – haven’t used v11 yet (just d/led it) but have been using v.10 this evening. Repeat is SUPER INTUITIVE and I love it. I could live with the change, but imho it would be a step in the wrong direction.

don’t have much to contribute constructively on the other questions.

I was hoping their would be an easy way to do text effects on a per character basis (I have seen the swish-like stuff in your forums, and that is exactly what I am talking about – even in your v11 Max timeline example – the way the letters drop in fade in and bounce – very cool).

I’m not complaining – the solutions offered seem to be sufficient (if not tedious). I haven’t tried them myself yet, but read enough to understand the concept.

I don’t know if doing effects on a per-character basis is within the scope of v11 but, hey, you were asking for suggestions.

Anyway, from my brief experience with Max 10 it seems like you’ve got a fine product here at a MORE THAN FAIR price (I just read your blog on the license issues). Keep up the good work, and I am sure a grateful public will reward you for your efforts. (as I said elsewhere, in faith I am saving my pennies to become a green club member).

Best wishes to you.