Jump to content
GreenSock

parkcastle

Greensock JS and Doubleclick

Recommended Posts

Hello,

 

Is anyone using Greensock JS with Google Doubleclick to build HTML5 ads?

 

I know google doesn't accept Jquery. or JS from third party editors like Adobe Edge. They do accept Zepto JS, but have nothing else listed in DC support.

 

Thanks

Link to comment
Share on other sites

I'm not aware specifically about Doubleclick's stance on GSAP - I'd be curious to know what you find out. I'm also curious about why Zepto is allowed but not jQuery. Maybe it's purely a file size issue.

 

I can say that there's increasing interest in GSAP from mobile/banner ad companies. Obviously it's a great fit. Hopefully as word spreads about GSAP and the performance and capabilities, it'll become a standard for HTML5 banners just like it has been for Flash banners for many years. 

 

I wish I had a clear/easy answer to your question. But again, please do let us know what you discover. 

  • Like 1
Link to comment
Share on other sites

Here's what they posted in their support:

 

  • JavaScript file
    • JavaScript files require a .js extension, not .min.js.
      If you minify JavaScript files, you can't add tracking easily. If the
      client requests minifying, add tracking first and minify the .js file later.
    • jQuery is not recommended for HTML5 ads for these reasons:
      As an alternative, you can use zepto.js.
      • Degraded performance on mobile devices because of reliance on time-based animations.
      • Unnecessary file weight: the majority of the library's functionality isn't required.

 

 

  • Third-party HTML5 authoring tools: 3rd-party HTML5 authoring tools like Edge, Hype, and Swiffy aren't recommended as Studio doesn't support them.

     
  • JSON: Files ending with .json are not
    allowed. (JSON files are not accepted by Studio for cross-domain
    reasons. JSON files must be rewritten as static JSONP files with a .js extension).
Link to comment
Share on other sites

Well that wasn't exactly helpful, was it? :)

 

As you probably know, GSAP blows the doors off jQuery in terms of animation performance, so that should take care of objection #1 (see http://www.greensock.com/js/speed.html) and as for file weight, TweenLite + CSSPlugin is pretty minimal, all things considered. MUCH smaller than jQuery. 

 

Let us know if you get any push-back from the Doubleclick folks or need some help making your case. We'll do whatever we can to help. It really would make a lot of sense for them to start using (or standardizing on) GSAP for animation. Not that I'm biased in any way.

Link to comment
Share on other sites

Well happy to say, my html5 banner got approved. In case anyone is interested, they don't support folder structure, so all files, images, js, css and html have to be in the same folder.

  • Like 2
Link to comment
Share on other sites

That's great - thanks for letting us know. 

Link to comment
Share on other sites

  • 2 weeks later...

parkcastle,

 

Thanks for posting your experience with this. I'm working with a display ad vendor that is just now making the transition from Flash to non-flash solutions. Amazingly, they haven't heard of this platform yet.

 

I'm wondering what your deliverables for files looked like. With Flash, a simple SWF was enough (plus a fallback jpg). Using GSAP or any other platform, are you delivering as few files as possible? ie. in-line styles and the extra GSAP library or a folder containing HTML, a CSS folder, greensock, etc?

 

Any info/insight you can provide would be great.

 

thanks!

Link to comment
Share on other sites

For doubleclick it is best to use their HTML5 templates.

http://support.google.com/richmedia/bin/answer.py?hl=en&answer=1074218

 

Everything goes in one folder, including images and only include the JS files that you are using, plus only one html file. They also require a jpg backup and there is also the option of adding a flash backup too.

 

I gave them one index.html, one css file, the main js file, TimelineLite.js, TweenLite.js and CSSPlugin.js, plus all the png image files. If it's a heavy load, they will tell you to use polite load, which is easy enough, because there is a template for that as well. Hope this helps.

  • Like 3
Link to comment
Share on other sites

  • 1 year later...

Does anyone know if GSAP is compatible / usable with Google Web Designer?

 

https://www.google.com/webdesigner/

 

I'm just about to get my teeth into some HTML5 banners for the DCS platform, and I just read that they offer QA support for Google Web Designer and Adobe Edge.

So whilst I'd normally code up the HTML5 banners by hand, using GSAP, i'm leaning towards using a tool like GWD or Edge - for 2 reasons.

 

1) I'd like to easily be able to work with flash animators that don't have JS coding experience. 

2) QA is important at DCS, and anything you can do to help them will make for a smoother experience.

 

So If GSAP can be plugged into either of these apps as their tweening engine, that would be best of both worlds.

Link to comment
Share on other sites

And is there a way of using GSAP as the tweening lib within Adobe Edge Animate? 

Link to comment
Share on other sites

You absolutely can use GSAP with Adobe Edge Animate (and pretty much anything else as far as I know). Chris Gannon is a master at that. See http://chrisgannon.wordpress.com/

 

Perhaps you're asking if GSAP can be swapped in for Adobe Edge Animate's standard animation engine in order to get a speed boost, more capabilities, and tighter file size - unfortunately the answer to that is "no" as of today, but that may change at some point. ;)

 

And yes, I'm pretty confident that GSAP can be used with Google Web Designer although I've never personally done that. Remember, GSAP is just plain JavaScript and it was specifically designed to be super flexible, able to animate virtually anything that JavaScript can touch. GSAP is not like famo.us or other frameworks that force you to build everything in a very particular way, nor does it have any dependencies. Load the JS, and BOOM, start animating. 

 

If you're looking for the tightest file size, just load TweenLite and CSSPlugin - those are likely the only two you'll need. Perhaps TimelineLite if you're doing sequences and want a cleaner workflow. You don't need to load TweenMax (which is intended for convenience and has a bunch of other stuff inside it, like TweenLite, TimelineLite, TimelineMax, CSSPlugin, BezierPlugin, AttrPlugin, EasePack, etc.) 

 

Does that help at all? 

Link to comment
Share on other sites

Thanks Jack!

 

It helps a bunch. Not for this particular project, as we are restricted to 100kb, but it will for future projects i'm sure.

 

Whilst I'm here, have you made a lite version of the CSSPlugin by any chance?  

 

It's around ~33kb presently, and that's the minified version. It would be awesome if there was a version a tad smaller, perhaps with less features?

 

And is there a TweenNano equivalent for JS? Or is TweenLite.min.js the smallest it goes (~25kb). 

 

Don't get me wrong, that it TINY!!! But when we work on banners every byte counts sometimes, I'm almost saddened to say. I just built an entire banner using TimelineLite, only to discover I was 10kb over the filesize, and had to replace all the beautiful TimeLineLite code with TweenLite & delays :D

Link to comment
Share on other sites

A few comments:

  1. I totally understand the pressure to keep banner ad file size down. The ad networks impose some pretty strict limitations. I feel your pain ;)
  2. gzipped, my software says that TweenLite + CSSPlugin combined are around 14kb.
  3. No, there isn't a TweenNano for JS at this point. We have certainly considered it, but...

In order to get from TweenLite + CSSPlugin to TweenNano (with part of CSSPlugin), we have to rip out a bunch of features. In many cases, that's fine. You probably don't need them all in every project. However, imagine how frustrating it will be when you hit that wall and there's some little feature in TweenLite that TweenNano lacks and you really need it in your project. We fear this is bound to happen quite a bit if we offer a TweenNano solution. 

 

In the Flash days where Tween* gets compiled into any swf, it was impossible (well, impractical) to leverage the browser's cache for this common library among ads. So, for example, if you go to a web page where there are 5 ads and they all use TweenLite inside each swf, the user technically had to load TweenLite 5 times! Seems wasteful, right? However, one of the biggest benefits of HTML5/JS technology is that it can leverage the browser's cache much more effectively, so in that same scenario if all 5 ads use TweenLite which is sitting on a CDN, it'd load very quickly ONCE and then all the ads would leverage that. And then when you go to another page that uses TweenLite on that ad network, there's ZERO cost because it'd use the cached version again.

 

With that in mind, is it wise to create a crippled version of TweenLite (which is already pretty darned lightweight) to save a few kb? Are we helping our users or does it actually hurt things because it adds yet another flavor (TweenLite, TweenMax, and now TweenNano)? Folks might not quite understand what all the differences are, and we'd be broadening the surface area of the API. Is the tradeoff worthwhile? Remember, bandwidth is constantly improving around the globe too. 

 

Our hope is that banner ad networks will standardize on TweenLite/CSSPlugin, put it on their CDNs, and not count that file size against banner ad creators like yourself. I think that's a win-win-win for everyone because:

  • It separates the core animation engine from the actual banner ad assets. It seems silly to penalize every banner ad (kb-wise) for that core that's pretty essential and could be shared among them all. Imagine if the Flash Player itself had to be downloaded each and every time a swf showed up on a page - it's a little bit like that.
  • It gives ad creators a much better and more realistic kb budget.
  • It allows ad networks to provide better support if there's a common engine driving the majority of their ads. If every ad is using a different random 3rd party engine and something breaks, the ad network is going to have to learn the ins and outs of each of those tools that might be causing the problems. It'll save them time and hassle if there's primarily one engine that they can become experts on. 
  • If they standardize on TweenLite/CSSPlugin (and maybe TimelineLite and EasePack), there are a tremendous amount of bells & whistles in there, so the core engine is quite capable rather than going "cheap" and using a crippled TweenNano flavor. Ultimately performance-wise, I bet it'd be virtually indistinguishable anyway because of CDNs, caching, and ubiquity. 

Hopefully the ad networks will see the light and adopt this strategy. I also hope that the IAB will make that recommendation (I know 2 co-chairs on the committee for digital advertising who are big GreenSock advocates). We'll see what happens. 

 

All that being said, if you still need a customized flavor of TweenLite/CSSPlugin that has a subset of the features in order to save kb, we are available for hire to do something like that. It's not a super-quick thing, but it can definitely be done. Feel free to reach out to me via a PM or email if you want to pursue that. 

  • Like 4
Link to comment
Share on other sites

Thanks Jack,

 

I really appreciate you taking the time to write such a comprehensive reply :)

 

The Gzip idea is a good one. I hadn't thought to ask DoubleClick if this was possible. I just sent them a support request asking if they will allow GZipped JS files.

 

They don't even normally allow minified JS files, which is just crazy.

 

If their web server is capable of serving GZIpped files, there is no reason why they shouldn't allow this, but I'll report back here once they let me know. We could really do with that additional ~20kb.

 

I totally agree - they should have all of GSAP in their CDN, and not count it towards any file size. I'll suggest that too them afterwards, I don't want to push my luck.

 

I still can't believe they are setting limits of 40kb and 100kb for HTML5 banners. They want us to use the latest technology but with 10 year old file sizes :x

 

I'm so thankful for your CSSPlugin - I haven't had to do animation in a *.css for ages now, and hope to never have to do animation directly in CSS ever again thanks to GSAP + CSSPlugin!

Link to comment
Share on other sites

Yeah, it is rather shocking to see how these massive ad networks seem so out of touch with practical realities in the tech and that they haven't created better standards yet, but on the other hand I'm sure it's not an easy task to get all the decision makers on the same page. 

 

If you do decide to ask them about standardizing on GSAP and not counting that file size against your budget in the future, I'd be happy to field any questions from them, or hop on a call or video chat. I really think this is an important step for the industry. 

 

I'm very happy to hear that you're enjoying GSAP and that it allows you to avoid the nasty headaches of CSS animations. Those can be an utter nightmare to use for anything even moderately complex, as I'm sure you discovered quickly. 

 

Let us know if you need anything else. 

  • Like 1
Link to comment
Share on other sites

By the way, were you kidding about them not allowing minified files? Is it just because they want to be able to read the source in case there are problems, but they do the minification on their end before pushing the ad out? I cannot fathom why they'd mandate that the actual published files not be minified. 

Link to comment
Share on other sites

I wish i was kidding lol. 

 

https://support.google.com/richmedia/answer/2672512

 

This is a perfect example of their specs being out of touch with modern techniques. 

 

They obviously mean the main JS file shouldn't be minified, not the libraries, but its not specified so they could reject if they wanted too. This is in case they need to add tracking. This kind of makes sense in theory, but in reality if it halves the size of the file why wouldn't they want it minified. It's a win win for the client and the customer.

 

But then they go and talk about libraries such as jQuery and Zepto, so they are obviously aware clients will want to use libraries for many tasks, such as animation etc.

 

And then at the end they go and suggest using Google Web Designer or Adobe Edge. Which is nuts considering the base library that Edge produces is well over 100kb on it's own. And from my experience, the vast majority of ad placements on their network are 100kb or less.

 

It's obviously teething issues DCS are going through with HTML5, and it's taking them time to get it right. I remember they had similar problems with their mandatory flash components when DCS was first released many years ago. The flash components were obviously poorly coded, and in turn had MASSIVE file sizes, sometimes over 60kb - 70kb, leaving a paltry amount left over for images and code.

 

Sure, they do tracking and reporting really well, and have a pretty awesome admin area for publishing, but It's almost like they forget that clients might want to design a banner that actually looks semi decent !

Link to comment
Share on other sites

What a mess. Thanks for the additional info. And good luck with the project. We're here if you need us. 

Link to comment
Share on other sites

I just heard back from DCS support, and some good news.

 

Their servers do support gzipping, so at least we can gzip the TweenLite & CSSPlugin - which would be a saving of around 40kb!!  

55kb -> 15kb is awesome, which means I can now bring back the TimeLineLite magic.

 

May I ask what gzip app you are using to get these to 14kb in total?

 

I'm using Keka, and when I gzip each of them at full strength, they come to a combined 20kb. 

 

This is still awesome, and a saving of over 50%, but am curious how you got it down to 14kb?

  • Like 1
Link to comment
Share on other sites

Nah, my software was just estimating from what I understand. It's part of a grunt-based build tool. Something like grunt-uglify if I remember correctly. 

 

That's great news that they'll allow you to gzip and you got a bunch of kb back that way. Sweet! And yeah, having TimelineLite will be a big help. Happy tweening!

Link to comment
Share on other sites

Ah cool. No worries. 20kb is still a massive saving - you'd think they would mention in their build guide that you could gzip files. I'll push them to mention this along with including your files in a CDN.

 

I'm well happy now. I can have my TimeLine lite back yee-hah!

 

Happy Tweening indeed!

Link to comment
Share on other sites

So Timo, just to be clear you uploaded a file with .gzip extension?

Link to comment
Share on other sites

Hey Emmanuel,

 

Actually not quite.

 

I was advised by DoubleClick that we could use .gzip, but I had assumed this meant they would gzip it for me afterwards, since it's not possible to reference a gzip file through html i.e. blah.js.gz is a no go.

 

But after much deliberation, it turned out that they couldn't (or wouldn't) gzip JS files on their end, but they were prepared to upload any GSAP lib files to their CDN. So they uploaded TweenLite, TimelineLite, CSSPlugin to their CDN, and provided links to use in the html. Obviously all JS files being served from their CDN will be compressed on the server side, so making a massive saving for them.

 

And the bonus is that any files being served from a CDN do not count towards the file size limit. That's right folks, they do not count!!!

 

I was even advised we could use the Greensock CDN if we wanted too. Of course this sounds too good to be true, so I'm triple checking now, but it seems like they are finally receiving enough interest from the Greensock community, who rely on GSAP and such libs to build banners.

 

I think they also realise it's not fair to bill us for the total file size of JavaScript files, when they are going to be compressed by the server. We have full control over image compression on our end, so we should have similar control over the js as well in one way or another. There is only so much you can minify.

 

So if you are working with DCS, then just send them a quick support ticket asking them if you can use GSAP CDN. If you are using another media agency then ask the same and cross your fingers ...

  • Like 5
Link to comment
Share on other sites

Hi, TimoStSuaber.

 

This is excellent news. Thanks for the elaborate details and for pushing through with DC. I'm sure this post will serve to give others confidence when pursuing HTML5 ads with DoubleClick and other vendors. 

 

It would be great if they would make this info easily available to all devs as I'm sure it will attract many developers and clients that want to move beyond the swf for banner ads with GSAP.

 

Thanks again

 

Carl

  • Like 1
Link to comment
Share on other sites

That's great news indeed! Wow, doesn't get much better in fact.

 

I think it says a lot about them being a smart company who is getting in touch with the needs of their customer base (and the market in general). It gives them a competitive advantage too. Heck, if I am a company wanting to build and place some banner ads and I have a choice between DoubleClick (who gives me GSAP for free) and some other ad network (who dings my file size budget for using GSAP), there's no question: I'm going with DoubleClick. 

 

I'd really like to get official confirmation from DoubleClick so that we can share that news with the rest of the community. Can you put us in contact with someone there who can confirm that they're putting GSAP on their CDN and not counting the file size against customers? You don't have to put it in this thread - you can Private Message me (or fill out our contact us form or email me). 

 

Thanks again. Glad you pushed so hard for using GSAP. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×