Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'banner'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

Categories

  • FAQ

Categories

  • Examples
  • Showcase

Categories

  • Products
  • Plugins

Categories

  • Learning Center
  • Blog

Categories

  • ScrollTrigger Demos

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Twitter


CodePen


Company Website


Location


Interests

  1. Hi, I'm looking to find an elegant and simple way to preview html5 banners for clients. The situation is that we have Project Managers running multiple projects each with different developers, and they need a common way to show the client work-in-progress, ideally with our company brand. Instead, so far I've seen HTML files either hand coded our output to HTML using Swiffy, which each produce a full html file. I am looking for something simple that a PM can get from a developer and either drop-in or upload to a tool like Wordpress, so they can easily create a preview page with multiple banners (or links to banners) in a consistent manner. Anyone out there have experience in this area? Having PMs hand code HTML pages, or using more advanced features of WP is....less than ideal. Appreciate the insight!
  2. Hi, I am new to banner ads and GSAP. I am trying to get acquainted with creating multiple framed banners (transitions and fades of content). I am trying to replicate the actions of this https://share.bannersnack.com/bvzpax1t6/ to the code I uploaded, which in my mind is 1 frame and the css is extremely long. I am just not sure how to get this started. The css and HTML I can do but the js is where it gets confusing. desktop.html desktop.css
  3. Hi, Aphalina Animator is a visual authoring tool that produces human-readable gsap + svg code. I just launched version 1.2 with some new features: path motion, hand-drawing imitation, clip masks, sprite sheets, sequence animations (similar to GSAP staging). It is paid app but can be used for free for non-commercial projects. Project link is aphalina.com. Any feedback is highly appreciated!
  4. This isn't a GSAP question, but I was wondering if you guys had gotten this from a media agency before. Four of the six ads we sent over got kicked back from their QA (I'm assuming they're using DCM, since they're standard banners), and they reason they gave was: "One of your HTML5 assets is invalid and cannot be analyzed. Please correct any malformed assets and try again." Have you guys seen this before? These ads are all based on the same code, so I don't understand why some of them passed and some failed QA. I've tried a bunch of stuff, like un-minifying the javascript, deleting comments that reference unused assets, but I really feel like I'm shooting in the dark here. I would have thought it was an issue with nested assets, or too many assets, but that doesn't seem to be the case. We reached out to the ad ops guys for more clarification, but the media companies seem to have the sense of urgency of a slug, and I really want to get this resolved as quickly as possible. Help!
  5. I am trying to make a image slider, with same effects shown in the below video url https://youtu.be/VfIfy5fZLhM I have this code below: this.tl.from("#panel1", 4, {autoAlpha:0, ease: Sine.easeInOut}) .set("#panel2", {top:0}, "+=2") .from("#panel2", 6, {autoAlpha:0, scale:1.5, ease: Sine.easeInOut}) .set("#panel3", {top:0}, "+=2") .from("#panel3", 8, {autoAlpha:0, scale:1.5, ease: Sine.easeInOut}) I am trying to achieve the same image effect shown in the video [zoom in, out and second image is sliding inside]. Can someone please help?
  6. Hello everybody, i just had a little inconvenience occuring to me, when i wanted to animate a Sizmek Deluxe Banner (inside of their Template) using TimeLine Light and Tween Light. The code is read properly, console log is also working, no compiler errors and so on. just ... the animation wont play. I have contacted their support that is pretty good but unfortunately they also couldn't come up with a solution. Did anybody have a same experience or has an idea about how to fix that (i also tried not to use timeline but only TweenLite in its stead, but no response whatsoever)? Thanks in advance and best regards Felix 01_DeluxeBanner_2.0.0.zip
  7. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements. While it is backward compatible with most GSAP 2 features, some parts may need to be updated to work properly. Please see the GSAP 3 release notes for details. Published: 2015-08-07 Google sparked an urgent and rather violent shift away from Flash technology when it announced that Chrome will pause "less important" Flash content starting as early as September 2015. Flash has served as the de facto standard for banner ads for more than a decade. Firefox also blocked Flash after major security issues were discovered and Facebook's security chief called for Adobe to kill Flash once and for all. Amazon says it will no longer accept any Flash ads after September 1. Clearly Flash is on its way out of web browsers. Advertisers can no longer afford its liabilities. Now what? Modern browsers are remarkably capable of handling slick animations natively using HTML, JavaScript, and CSS (collectively referred to as “HTML5” or just “H5”), making them the obvious choice as the tag-team successor to Flash. No more plugins. However, a few barriers are clogging up the transition. Some are technical, some are political, and some have to do with a glaring lack of information. Let's address things head-on, identify some solutions, and get things moving in the right direction. GreenSock has a rich heritage in the banner ad industry, serving as its most popular animation library in both Flash and HTML5. In fact, it’s one of the fastest-growing JavaScript tools on the entire Internet and it was originally born out of banner-specific needs. We obsess about animation in the browser, studying the technical challenges, performance benchmarks, and workflow. Consequently, we’re in a unique position to lend a hand during this transition and perhaps illuminate the path forward. 40 kilobytes? Are you kidding? Years ago, when bandwidth was a tiny fraction of what it is today, the ad industry codified a set of standards for banner ad file sizes. A common limit was 40kb (sometimes even 30kb) including all images, fonts, animations and scripts which Flash compressed into a single amazingly small swf file. Technically each publisher determines its own file size policies, but almost everyone looks to the IAB (Interactive Advertising Bureau) as a standards-setting body, like the W3C for web browsers. The IAB exists to help guide the industry but they don't mandate or enforce anything. When Flash ruled the banner ad landscape, certain file size specs were recommended by the IAB and the system worked well. However, the technology landscape has changed drastically. Bandwidth, page size, and banner budget over the yearsBandwidth (Mbps)Banner budget (kb)Page size (kb)2008200920102011201220132014201540kb33Mbps40kb1,795kb Year Bandwidth (Mbps) Banner budget (kb) Page size (kb) Jan 1, 2008 5.86 40 312 Jan 1, 2009 6.98 40 507 Jan 1, 2010 9.54 40 679 Jan 1, 2011 10.43 40 788 Jan 1, 2012 12.7 40 1081 Jan 1, 2013 15.62 40 1529 Jan 1, 2014 20.83 40 1622 Jan 1, 2015 32.78 40 1795 Page size (kb) Since 2008, average bandwidth has grown by a factor of 5.6 which is remarkably on-pace with the growth of the average web page size (5.7), but the IAB has been cautious about declaring HTML5 specs due to all the complexities involved. They released a set of HTML5 guidelines in 2013, but omitted any file size specs, saying only that HTML5 ads weigh "more" than swf ads. Without specs, many publishers clung to the safe limits of yesteryear. The gatekeepers who impose the 40kb budgets often do not have the authority or wherewithal to allow more than what the latest IAB spec dictates. Consequently, developers are forced to shoehorn HTML5 banners into archaic Flash specs which isn't what the IAB intended. This must change. From our vantage point, fear is driving the industry. Publishers and networks are afraid to raise the file size limits without IAB approval. Some do it anyway, but disagree on exactly how much, leading to wild variations. Developers have no choice but to build for the least common denominator in their ad campaign which is either totally unclear or ends up being the dreaded creativity-crushing 40kb. (UPDATE: The IAB released a draft of its new HTML5 specs.) HTML5 is fundamentally different...embrace that HTML5 banners often weigh 3-5 times as much as a Flash swf but far too many people myopically focus on the aggregate total file size. They miss the unique strengths of HTML5 technology that we should be exploiting - shared resources and browser caching. These have a tremendous impact on loading time and overall performance which is the whole point of the file size limits anyway! Flash compiled all assets into a single swf meaning that if 10 different banners on a site all used a certain library, it got baked into each and every swf. End users paid the file size price 10 times. Multiply that by millions of ads and it gets pretty crazy. In HTML5, however, a library can be dropped onto a CDN (content delivery network) and shared among all banners, thus end users only load it once and it’s completely "free" thereafter...for all ads pointing at that CDN...on all sites. This is a BIG deal. It means that common animation chores like the requestAnimationFrame loop, timing, sequencing, intelligent GPU layerizing, lag smoothing, compatibility workarounds, performance optimization, etc. can be extracted and shared among them all (much like what the Flash Player did for swf files). The unique banner-specific code can be much more concise, reducing overall load times and improving performance. File size limitations should be applied to the banner-specific assets, excluding the shared resources that drive common functionality. Imagine how silly it would have been if the 17MB Flash Player download was included in the aggregate file size for each swf banner. Ad networks and publishers can put a certain subset of tested-and-approved libraries onto their CDNs and exempt them from file size calculations. We're thrilled to see industry leaders like Advertising.com/AOL, Google DoubleClick, Flashtalking, and Sizmek already taking this approach with GSAP. This strategy allows developers to avoid burning hours manually cooking up their own proprietary libraries to fit within the ad specs. Ad networks and publishers win because load times (and costs) are lowered and it's easier to troubleshoot problems when a common toolset is used. They reap the benefits of all the compatibility and performance optimizations in tools like GSAP. End users get ads that perform better, load faster, and look more appealing. Animation technologies and approaches For those tasked with building HTML5 banners, the choices are perplexing. Is it best to use a visual IDE like Adobe Edge Animate, Google Web Designer, or Tumult Hype? Even Flash is capable of outputting HTML5 content. These tools can make building ads easier (especially for designers who don’t want to write code), but a common complaint is that the resulting output is bloated and slow, making them ill-suited for banner ads. Some networks explicitly state that they won't accept ads built with these tools. We'd love to see the visual tools mature and export concise, performant, ad-friendly code because plenty of designers aren't comfortable hand-coding banners yet. Ideally, they'd tap into GSAP under the hood so that designers and developers could collaborate on the same files without worrying about runtime redundancies. There are also network-specific banner-building tools but their proprietary nature makes them impractical for many campaigns. If an agency uses one network’s proprietary tool and then their client asks to run the ad on another network too, it must be rebuilt. Learning how to use each network's proprietary tool can be cumbersome. Hand-coded animations are usually much lighter-weight, performant, and universally accepted, but building them requires a particular skill set. And which underlying technologies should be used? CSS animations? jQuery? GSAP? CreateJS? Once again, answers vary wildly among ad networks and publishers. The goal of this article isn't to provide an in-depth review or comparison of the various tools. Each has its own strengths and weaknesses, but let's briefly touch on some of the major runtime animation technologies: CSS transitions and CSS animations - these are supported in all modern browsers, but not IE9 or earlier. They're cheap from a file size standpoint and they perform well. For simple animations like button rollovers, they're great. However, file size rises quickly and things get cumbersome when you attempt even moderately complex animations. Simply put, they will take longer to build, they won't work in some older browsers, there are bugs (particularly when animating SVG elements), and certain tasks are outright impossible. Additional reading: https://css-tricks.com/myth-busting-css-animations-vs-javascript/ and http://greensock.com/transitions/ and https://css-tricks.com/svg-animation-on-css-transforms/ jQuery - it was never intended to be a robust animation tool, so jQuery suffers from poor performance and workflow issues. Most ad networks strongly advise against using it. GSAP is up to 20x faster. Additional reading: http://greensock.com/jquery/ CreateJS - Adobe Flash can optionally export to this canvas-based library. You can't just publish existing Flash banners to CreateJS (you must do some conversion work and leverage JavaScript instead of ActionScript) but for designers who are already used to the Flash interface, this can be a boon. One down side to canvas-based libraries is that you lose accessibility (the browser sees it as essentially a blob of pixels), but that's probably not a top priority for banners. File size can also become a concern (possibly mitigated by CDN standardization). You can use GSAP to animate CreateJS content. Additional reading: http://createjs.com Zepto - like a lightweight version of jQuery that uses CSS transitions under the hood for animations. Zepto is better than jQuery for banners, but it suffers from similar workflow issues as well as the inconsistencies/bugs inherent in CSS transitions/animations (like with SVG transforms). Active development seems to have stalled. Additional reading: http://zeptojs.com Web Animations - a new spec being worked on that has a lot of promise, but it just isn't a realistic contender at this point because it is in flux and several browser vendors remain noncommittal about ever supporting it. The polyfill has performance problems. Additional reading: http://w3c.github.io/web-animations GSAP - Widely recognized as the performance leader, GSAP solves all kinds of real-world animation problems from browser inconsistencies to workflow headaches (far too many to go into here). The Flash banner ad community is full of designers and developers who use GSAP daily, making it much easier to transition to HTML5; no new syntax to learn. Ongoing development and support have a solid track record for over 7 years. Additional reading: http://greensock.com/why-gsap/ Recommendations Based on our experience and the results from our survey, we suggest the following: Standardize a few JavaScript libraries Ideally, the IAB would equip the community with a short list of recommended libraries that get CDN-ified and exempted from file size calculations. Historically, the IAB has been extremely reluctant to officially endorse any third party tools. That's understandable - it could be seen as playing favorites or unfairly excluding someone's favorite library. However, without specific recommendations, the HTML5 landscape is so fractured and complex that it will result in a free-for-all (which is basically what it is now). The IAB can set the tone and move the focus away from aggregate total file sizes and into the modern era that leverages shared resources and browser caching to deliver excellent performance. It is imperative that this list of "recommended" libraries be very short, otherwise the caching impact will be diluted. The IAB can run their own independent tests and look at performance, features, compatibility, support, workflow benefits, and overall industry demand to determine which libraries get recommended. Of course we feel strongly that GSAP belongs on that list because: It is the top performer. It has widespread industry acceptance, both in Flash and HTML5. It's recommended by Google, used by the biggest brands in the world, etc. It is framework-agnostic, super flexible and robust, able to animate anything. It is professionally supported, yet free to use in banner ads. Modernize file size specs Given the 5.6x growth factor of bandwidth and page size since 2008, it seems entirely reasonable to adjust the old 40kb limit to 200kb (5x) for the modern HTML5 era. This is entirely consistent with some in-depth testing that has been done recently aimed at identifying the file size threshold at which real-world users perceive a dip in performance. The results showed that the threshold was upwards of 250kb. Combined file size isn't the only issue that contributes to slow load times; the number of server requests can have a significant impact. A single 300kb file can often load faster than 200kb split among 20 files. HTML5 banners can't realistically mash everything into one file, though. Doing so would kill the benefits of caching and resource sharing. So a reasonable compromise seems to be a 10-file maximum. Sprite sheets can be used to combine images. Given all the factors, we'd recommend the following for standard (non-rich media) ads: 200kb combined total (gzipped) Maximum of 10 files. Any additional must be loaded "politely" (after the parent page finishes loading) Shared CDN resources like GSAP don't count toward these totals. Some have suggested slicing the 200kb standard limit into two parts - a 50kb initial load, and then the rest "politely" loads. However, we advise against this for standard (non-rich media) ads because it unnecessarily complicates the design and production process as well as QA and enforcement. Rich media ads will likely require more files and kb than the limits mentioned above, and those should be polite-loaded. By "rich media", we mean ads that contain video or expand or perform API calls (like feeding the viewer's zip code to a backend script), etc. Update documentation and guidelines It is surprisingly difficult to get answers to some of the most basic questions when preparing a banner ad campaign for even the biggest networks and publishers. What are the file size limits? Which libraries can be used? Do CDN resources count against the total file size? Is there a network-specific CDN link for common libraries? Online docs either have outdated information or none at all related to HTML5. Drop support for IE8 Legacy IE support is not just painful for developers, it's exceedingly expensive for advertisers. Certain effects are outright impossible, so creatives must learn about the IE8 pitfalls and adjust their designs. Developers are forced to rebuild entire portions, implement workarounds and perform extra testing, all to accommodate a tiny fraction of the web audience who probably don't represent the demographic that advertisers are targeting anyway. This was never an issue for Flash, but it's a HUGE issue for HTML5 because it relies on native browser technologies that are absent from older browsers like IE8. Our recommendation is to draw a line in the sand and drop support for IE8 for sure, and potentially even IE9. Consider SVG instead of iframes Displaying ads inside an iframe is nice for security, but it forces ads into a strict rectangular space (ruling out fancy overlays with transparency/mask effects that show the main web page behind) and there's a performance price too. SVG is widely supported and it has some excellent transparency/masking capabilities, plus it can serve as a single container for an entire ad (see Chris Gannon's blog post and video)! Further testing needs to be done to better understand the performance and security implications, but it certainly seems like a worthwhile contender. Create a gallery of sample banners and templates Rather than pouring over specs and instructions and then building something from scratch, most developers prefer to analyze banners that already conform to the standards and use one as a template for their own project. Each network has different API's and ways you must track clicks, etc., so it would be lovely if each one provided a gallery of demos at each standard size. Codepen.io is a great place to host a collection because it's so easy to see (and edit) the HTML, CSS, and JS as well as the result all in one place. Developers can simply click the "fork" button and start producing their own version of that banner immediately in the browser. Codepen even integrates nicely with crossbrowsertesting.com for easy QA. Adjust client expectations As the industry transitions from Flash to HTML5, clients must be made aware of the design, budget, and schedule implications. HTML5 banners take more time to produce and test, therefore they will be more expensive. Plus there are certain effects that were easy in Flash but are virtually impossible in HTML5, so creative expectations need to be adjusted as well. Common GreenSock Questions With the broader discussion out of the way, let's narrow our focus to GreenSock for a moment and address some of the most frequently asked questions: Which networks support GSAP? All networks that we're aware of allow GSAP, and most even exempt its file size from the ads and host it on their CDNs. Google DoubleClick recommends GSAP for complex animations. Here's a breakdown of how some of the major players stack up: Allows GSAP Excludes GSAP from file size calculation* Hosts GSAP on CDN Advertising.com/AOL YES YES YES Google DoubleClick YES YES YES Flashtalking YES YES YES Sizmek YES YES YES Flite YES YES YES Cofactor YES YES YES AdWords YES YES YES *Unless publisher objects which is uncommon TweenMax is too big! Where's TweenNano? Let's face it: TweenMax (the most robust tool in the GSAP suite) is overkill for many banners that are only doing simple fades and movement. Wouldn't it be smart for GreenSock to create a super-small animation engine that's targeted at banners and only has the basic features? In the Flash days, we did exactly that and called it "TweenNano". It weighed about 2kb. On the surface, it sounds like a great idea but there are several reasons we avoided TweenNano in the HTML5 toolset: Caching - this is the biggest factor; loading the JavaScript file is a one-time hit and then the browser caches it, mitigating the entire loading issue on every page thereafter. Realistically, TweenNano must include a subset of TweenLite and CSSPlugin features and weigh at least 8kb; how much longer would it take for the average user to load an extra 25kb for TweenMax? It's not even noticeable (less than one second). So it doesn't seem like a worthwhile tradeoff to rip out all those features just to gain a fraction of a second only the first time it loads, especially for banners where caching and resource sharing could be used so effectively. If networks toss TweenMax.min.js on their CDNs, it effectively becomes "free" (zero load time) very quickly, giving them instant access to all the timeline tools plus a bunch of advanced plugins. Thus it seems smarter to press the full-featured, super-fast TweenMax engine into service rather than a sliced-down TweenNano with limited effects. Performance - GSAP has been engineered with a huge priority on performance which sometimes comes with a file size tradeoff. We could accomplish the same tasks with less code in places, but runtime performance would suffer. We feel strongly that when it comes to animation, it's wiser to pay a small up-front kb tax (only a fraction of a second in most cases) in order to get maximum runtime performance. Animations must look smooth and conserve battery power. Think of it this way: would you rather buy a computer that boots up 2 seconds faster or one that's 30% faster all the time (after it boots)? Flexibility/Creativity - what if you want to animate a non-essential CSS property like boxShadow or slide along a curve or scrub through a timeline? Even if there's just one part of your banner that needs a more advanced feature, it presents a dilemma. Creativity is hampered. Again, the fraction of a second one-time cost difference for TweenMax seems well worth it for the added flexibility and peace of mind. API confusion - years ago, Adobe created a lightweight version of the Flash Player dubbed "Flash Lite" with similar aspirations (bake only the essentials into a lighter weight flavor), but it was a complete failure. One of the problems was that developers couldn't remember which features were available in the regular Flash Player versus Flash Lite. Likewise, TweenNano's feature disparity would create some confusion/frustration. What about creating a tool that lets users select only the features they need, and then it spits out a customized stripped-down version of TweenMax? Again, this sounds appealing, but it would likely lead to worse load times because instead of having one common TweenMax that gets shared and cached, every banner would have its own different (and partially redundant) flavor to load. Ultimately, we're committed to delivering the tools that are needed most, so if the broader industry decides not to leverage shared resources and publishers insist on sticking to all-inclusive aggregate file size totals, we're open to creating TweenNano. Luckily, it looks like there's excellent momentum behind TweenMax getting CDN-ified and exempted from file size limits. In our opinion, that's definitely the smartest approach. What's so special about GSAP? It's beyond the scope of this article to explain all the benefits of using GSAP; see http://greensock.com/why-gsap/ for a summary. If you're still wondering what the big deal is, we'd encourage you to find someone who is proficient with it and ask about their experience. Usually people who take the time to learn it have a "light bulb" moment pretty quickly and never want to go back to using other libraries or CSS. It's difficult to explain to the uninitiated - lists of features don't really do it justice. It's not merely about performance (although that's a biggie) - it's about feeling empowered to animate almost anything you can imagine with minimal code. Do I need a commercial license to use GSAP in banner ads? GreenSock's standard "no charge" license covers usage in banner ads even if you get paid a one-time fee to produce the banners. We fully encourage the use of GSAP in banner ads and beyond. You may want to check out Club GreenSock for some bonus plugins that allow you to easily achieve advanced effects. Is anyone building a GUI for GSAP? A visual tool for building GSAP-based animations is a popular request, and we have been approached by several large and small companies about the possibilities, but there's nothing rock solid to report yet. We hope that companies like Adobe and Google will offer export options from their tools that leverage GSAP as the runtime engine and produce well-formatted, concise code. There's a pretty neat tool called Animachine that's in alpha and can be installed as a Chrome extension. It shows promise, but isn’t entirely stable at this point. There are also several online GSAP-based banner builders: http://html5maker.com/, https://tweenui.com/, and http://www.loxiastudio.com. Where can I get GSAP training? You can have GreenSock come directly to your organization and sit with your team to get them up to speed quickly. We can even convert one of your Flash banners and then teach you how we did it which is an excellent way to learn banner-specific tricks. The Q&A sessions are invaluable. We have limited slots available, though, so contact us as soon as possible to get your event scheduled. There are plenty of other learning resources available: GreenSock's getting started video/article GreenSock's learning resources New GreenSock eBook (published by Noble Desktop) Lynda.com course ihatetomatoes.net course (intermediate/advanced) Noble Desktop class in NYC 02Geek course Egghead.io The GreenSock forums are a fantastic place to not only ask your question(s), but also poke around and see what others are saying. It's one of the best places to learn even if you never ask a question. There are plenty of demos on codepen.io as well. For inspiration, we'd suggest following these people: Chris Gannon Sarah Drasner Petr Tichy Sara Soueidan Diaco.ml Blake Bowen Ico Dimchev UPDATE: The IAB released a draft of its new HTML5 specs and is soliciting public feedback before finalizing the document. The outstanding news is that they agreed with our assessment regarding a 200kb limit for standard ads. The IAB is expected to release an update to its HTML5 Best Practices guide soon which will likely contain a short list of JavaScript libraries that are recommended for exemption from file size calculations. We're confident GSAP will be on that list. #network-support { border-spacing: 1px; border-collapse: separate; background-color: #ccc; width: 830px; line-height: 1.1em; } #network-support thead td { background-color: #333; color: white; } #network-support td { text-align: center; vertical-align: bottom; font-family: Asap, Arial, sans-serif; padding: 10px 14px; background-color: white; } #network-support .network { text-align: left; font-weight: bold; } #network-support .yes { background-image: url(/wp-content/themes/greensock/images/licencing-check.png); } #network-support .yes, #network-support .no { background-color: white; background-repeat: no-repeat; vertical-align: middle; background-position: center center; background-size: 35px 35px; color: transparent; } .disclaimer { font-size: 11px; color: #777; padding: 2px; }
  8. Note: This page was created for GSAP version 2. We have since released GSAP 3 with many improvements including a much smaller file size! Please see the GSAP 3 release notes for details. In recent months, the whirlwind shift to HTML5 in the banner ad industry has prompted a slew of policy changes. Publishers and networks are scrambling to answer questions from designers who want to build things "properly" (a term whose meaning can vary wildly these days). Growing pains abound. Shortly after we published an article describing the state of affairs and offering recommendations for a path forward, the IAB released a draft of their new HTML5 ad specs which echoed many of those recommendations. For example, the file size limit for standard ads was raised to 200kb. This was cause for much celebration across the industry. But we're not out of the woods yet. There is still a persistent mindset about how we look at kilobytes that's crippling the web. This article aims to challenge the old paradigm and explain why it's so important to re-assess kilobyte costs. Why limit kilobytes? Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. File size limits exist to promote better performance. Period. Does conventional wisdom apply the same way in the HTML5 era? As we modernize our kilobyte-count policies, let's remember what the goal is: performance...or more accurately, better user experience. Not all kilobytes are created equal HTML5 has unique strengths that challenge us to move beyond the simplistic "aggregate total file size" mentality of yesteryear. We need to look at kilobyte cost in a new, more nuanced way. There are four primary factors: Cache status When is 35kb not really 35kb? When it's cached. A cached file has absolutely zero bandwidth cost regardless of its size. It loads immediately. This is particularly relevant in banner ads because there are certain chores common to almost every ad (like animation management tasks) that can be encapsulated and shared among many, many banners. The end user only loads that shared resource once and then it's cached and completely "free" thereafter...for all ads pointing at that file...on all sites. Does it really make sense to penalize ads for using those ubiquitous shared resources even though they're so pervasively cached that they don't typically affect load performance? In the modern world, file size limits should apply to the banner-specific assets that have a direct impact on loading times, not standardized shared resources. Location Kilobytes loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically dispersed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability. Spread 200kb spread across 24 files will take longer to download than 200kb spread across only 4 files. This isn't particularly relevant in the discussion about shared resources (which should be cached very quickly), but is an argument in favor of loading TweenMax rather than the combination of TweenLite, CSSPlugin, EasePack, and TimelineLite even though they collectively use fewer kilobytes. If the industry remains focused solely on aggregate total file size, it pushes designers/developers toward less capable solutions that use fewer kilobytes even though they don't necessarily affect load times and could be replaced by more robust options that allow more creative expression. Performance yield Some kilobytes are cheap in terms of the initial load but expensive for runtime execution. If our goal is better user experience, this factor should weigh heavily into the overall kilobyte cost equation. Would you rather have a banner that loads 200ms faster with janky animation or one that's super-smooth at runtime but takes a fraction of a second longer to load? Are publishers primarily concerned with displaying ads faster initially or ensuring that their site runs smoothly once loaded? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. For example, GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, leverages 3D transform matrices, avoids layout thrashing, organizes things internally to make auto overwriting super fast, etc. - would removing those features for the sake of milliseconds on initial load (and zero savings once it's cached) be a step forward or backward? Incentivizing the wrong things If the IAB and publishers don't embrace a common set of shared resources that get excluded from file size calculations... It creates inefficiencies and redundancies - thousands of ads may each contain their own [duplicate] copy of a library like TweenMax, squandering valuable bandwidth. It penalizes the use of robust, industry-standard libraries in favor of custom JS and micro-libraries that probably aren't nearly as capable, well-tested, cached, compatible, or performant. When something breaks, it will be more difficult for the various ad networks and publishers to troubleshoot and support custom JS and diverse micro-libraries. Lots of APIs to learn (or in the case of custom JS, more advanced expertise would be required). GreenSock would likely need to create a minimalistic version of TweenMax that has a tiny subset of the features. We feel strongly that this is a step backward and explain why here. So ultimately, an "all-inclusive" file size policy could actually hurt load times as well as runtime performance. Yet the primary goal of file size limits is to protect performance. Hm. If the industry rallies behind a few popular, well-maintained and performant libraries, exempting them from file size calculations because of their ubiquity, it would not only deliver a better overall user experience, but also make it easier to create high quality banners. There would be fewer headaches for networks and publishers too. TweenMax (GSAP's largest file) technically weighs around 34kb but those kilobytes are the remarkably inexpensive kind. TweenMax is widely cached, it's on multiple CDNs, it packs various tools into a single file (zero "spread"), and it has an extremely high performance yield because of its many runtime performance optimizations. There are so many ads using it already that it has little or no effect on load times. Should it really cost banner ad designers/developers 34kb against their file size budgets? Is it wise to incentivize cooking up their own custom code for handling animation tasks instead? The good news Every major ad network we’ve contacted understands the value of shared resources and is very GSAP-friendly. In fact, virtually all of them have GSAP on their own CDNs and don't count its file size against ads unless the publisher insists otherwise (which is rare). One notable exception is Adwords, but we have been told they're working on a solution. Allows GSAP Excludes GSAP from file size calculation* Hosts GSAP on CDN Advertising.com/AOL YES YES YES Google DoubleClick YES YES YES Flashtalking YES YES YES Sizmek YES YES YES Flite YES YES YES Cofactor YES YES YES Adwords YES YES YES *Unless publisher objects which is uncommon Google DoubleClick is even pioneering a process that will automatically detect when GSAP is used in an ad and swap in its own CDN link to maximize caching benefits. Pretty cool stuff. Conclusion Let's embrace the unique strengths of HTML5 and modernize the way we count kilobyte costs. Let's support policies that incentivize better performance and user experience rather than a race to the smallest total file size for each individual ad. Caching, CDNs, kilobyte spread, and performance yield should all factor into the way we view kilobytes the HTML5 era. FAQ Isn't it unfair if the IAB only recommends a few popular libraries? What about newer or lesser-known libraries? This is an entirely valid concern. The list should be reviewed regularly and the IAB can assess each library's industry support, performance profile, compatibility, and track record for ongoing updates and bug fixes. New contenders could be submitted for consideration anytime. But remember that the key to realizing the performance benefits is keeping the list short so that caching is focused and pervasive. If there are too many "standardized" libraries, it dilutes caching and defeats the purpose. There's no way that everyone will agree on which libraries should be on the list but if we get hung up on not offending anyone or being afraid to appear biased, we'll miss the opportunity to move the industry forward. The list won't be perfect, but not having a list at all is much worse. What happens when a library gets updated? Wouldn't it need to be re-cached? Yes. And trust me - we want libraries to be updated somewhat regularly to work around new browser inconsistencies, patch library bugs, and implement new features that drive things forward. But these updates wouldn't need to interfere with existing or legacy ads - when a library is updated, a new CDN URL would be generated and new ads could optionally point to that version. Those ads would indeed trigger browsers to cache that new version but this should happen very quickly. Most likely within a matter of days the new version would be pervasively cached across the web. Yes, each end user would pay that kilobyte tax once on the first load and then it would be "free" thereafter. Would GreenSock still recommend this policy if GSAP wasn't included in the short list of exempt libraries? Absolutely. This isn't just about getting GSAP an exemption - this is what we believe is best for the industry overall even if GSAP isn't on the list.
  9. Hello everybody, I am totally new to GreenSock banners, but I have a task, which is suppossed to be not so hard, but seems to be very hard for me and I would be glad for some help. I have to make 728x90 test size by modifying the necessary javascript modules and css using GSAP. Everything I have is in https://codepen.io/mikiko16/pen/RqBvPo file.
  10. Hi all, What measures do you take to optimize your banner ads in terms of file size? Do you optimize the file size of your images? Do you minify the HTML, JS and CSS? Any other things? We've recently integrated an image optimizer into our platform which optimize all images (PNG and JPG) in your HTML5 ads. Just wondering what the experts do more
  11. Hi Guys, my Name is Oliver. I am the developer of anivendo. A fast, modern and easy to use HTML5 Banner-Animation-App for Windows (Mac-Version will follow) which uses TWEENMAX. · No Coding Experience required! · NO COMPLICATED TIMELINE! anivendo animates your Banner Creatives very much faster than traditional HTML5 Animation Tools like Google Webdesigner, Adobe Flash, Adobe Animate CC, Adobe Edge Animate, etc… Why don’t you take a Look. We are currently searching for alpha-Tester! https://anivendo.com/ Update (03-23-2018): anivendo is now fully documented! https://anivendo.com/docs/ Questions, Bug Report and Improvement Suggestions can be made via anivendo Community Forum https://anivendo.com/community/ _ Cheers Oliver
  12. AdsMaker is an intuitive banner feedback, approval and sharing tool. AdsMaker supports all media formats: HTML5 banners, newsletters, social media ads, mobile campaigns, print or TV- and radio ads. More infos: https://www.youtube.com/watch?v=cEGaOxieJ4Y
  13. I recently struggle to deliver a couple of banners for XAd. They needed to be a 320x50 and a 300x250 with weights of 20k and 40k respectively. After some research I ended up doing it in Photoshop. However "Video Timeline" only allowed for linear interpolation. My question is: When requested for GIF banners what is your approach? tools? workflow? dealing with the art director?
  14. Hi there, I've been struggling with this for a while now and finally decided to submit this to the forum. I've read a number of posts that make this seem easy, but I'm obviously missing something. I'm trying to simply add an HTML video element to a timeline so I can control when it starts to play and coordinate it with my other banner elements. In this simple example, I want to control how long I see a black screen with the intro text before I fade that black background and text away and start the video. (The Pen I've posted here is a much shortened version, btw, for simplicity.) I have tried a number of configurations of .play() and .add with a callback function, but it just doesn't seem to work. The only reason the video plays in the Pen I have now is that I have autoplay set in the HTML attributes in the video element. If I remove that attribute from the video element, the rest of my timeline plays over a blank box. Is there something I'm missing with how to configure a video element and add it to a simple timeline? Thanks so much for any insight you can give me!
  15. Hey guys, I'm creating a banner, which will play 3 times (loop 2), and use GSDevlTools. The bannerflow is like this: Intro, Scene 1, Scene 2, Scene 3, Outro Scene 1, Scene 2, Scene 3, Outro Scene 1, Scene 2, Scene 3 So after the first loop Intro should be removed, and the last loop should not play the Outro. My issue here is, that i cannot figure out a way to write the code, so it also works with GSDevTools. - the final timeline is not showing the correct length. I've tried with var master_timeline = new TimelineMax(); master_timeline .add(intro()) .add(scene1()) .add(scene2()) .add(scene3()) .add(outro()) .add(scene1()) .add(scene2()) .add(scene3()) .add(outro()) .add(scene1()) .add(scene2()) .add(scene3()) ; But that makes it very messy writing the scenes.. - i cannot use .from at all because, the it conflict with the scenes later on. Then i've tried with var master_timeline = new TimelineMax({repeat:2, onRepeat:check_replay}); master_timeline .add(intro(), "intro") .add(scene1(), "+=0.5") .add(scene2(), "+=0.5") .add(scene3(), "+=0.5") .add(outro(), "outro+=0.5") ; function repeat(){ master_timeline.remove("intro"); } Which does not remove the intro. Then i've tried var master_timeline = new TimelineMax({onComplete:repeat}); var loops = 0; var max_loops = 3; master_timeline .add(intro(), "intro") .add(scene1(), "+=0.5") .add(scene2(), "+=0.5") .add(scene3(), "+=0.5") .add(outro(), "outro+=0.5") ; function repeat(){ loops++; if(loops == 1){ master_timeline.remove("intro"); } else if(loops >= max_loops){ master_timeline.remove("outro"); } master_timeline.restart(); } Which it does not remove any of the labeled scenes, and the GSDevTools timeline, does not show the correct maxtime. I'm really out of solutions, so i would be very happy if any of you guys have a solution, or just a hint which can lead me in the correct way. Best regards Christian
  16. Hi all, This isn't really Greensock-related but I was wondering how you guys create backup images for banners, you know those 40k backup images that are needed when JS is disabled on the browser for example. I mostly use Animate CC (in combo with TweenMax of course) and how I do it now is right clicking on the banner (the canvas object) in Chrome once the banner reached its end and then saving it as a PNG, and then also mostly compressing it afterwards in Photoshop as a JPG to get it under 40k. Are there better practices or tools that can automate this? This is really time consuming. Thanks! Nicolas
  17. HI everyone, really happy to get a job animating HTML5 banners using GSAP. Making and animating the banners are not the problem, i am having a problem getting them loaded into sizmek. I followed some documentation and registered click events but the agency i have to send them to says they won't work. Does any one have a blank biolerplate i can load my project into with sizmek built into it. The static banner template from sizmek set they gave me keeps throwing errors it's just a simple one size banner that needs a to be fully clickable. Any help would be appreciated.
  18. Hi guys! Is it possible to find an example of a responsive banner that I can make in Adobe Animate 2017? All my old source files that worked a year ago do not work now and my skills are not enough to understand what has changed, I just see that the code that generates Animate just diferent. The banner should stretch the entire length of the page, have a minimum width (for example 800 px), and inside there should be 3 independent moveclips - "left", "central" and "right", which change their position depending on the width of the banner. Thanks for any help!
  19. Hi Guys, How's it going? I can't seem to figure out how to target inside movieclip on my banner. Basically i want to play the background once my timelime reaches the button - also how I'm i suppose to make the slideshow in code-based? please find attached. http://chriswebstage.com/html5/pcf-rental-bnr-300x250-html5-v2.fla Thank alot, Chris R Archive.zip
  20. I'm new to banner development and I'm pretty much on my own. Living and learning... I've built quite a lot of DCMs without any issues. My DCM template is pretty solid already but this template I created doesn't work well with other formats and ad platforms. I ran into a lot of issues while doing DCRM and sizmek ads. I've tried BannerTime and I liked it for the most part like being able to choose which platform specific template to use and all but it's using smart objects and stuff which the dumb me doesn't really see the point of using all that while every KB counts. I also noticed that it served the ad right in the middle of the page horizontally and vertically. I also do not see the point of that. Aren't ads supposed to be at the top left corner by default? But I digress. I'm scared if I changed something, it would break something else. I plan to create my own builder in the future once I gain more understanding on the requirements of each ad platform. For now I just want a very minimal builder that can create boilerplates for different ad platforms with gsap so that I don't run into any more issues. That's it. Please help if you know any. Thank you. Oh and does anyone run into issues by using outdated templates? I don't know why ad platforms do not make it easy to get the latest stable templates. So, it would be great if it's a builder that is being updated quite regularly.
  21. I've been using this for a while, it's not perfect but the idea behind it I guess is to generate multiple banners with minimal effort plus a presentable preview link, with backup images. https://github.com/bastole/dc-richmedia-automation-template If anyone can review or comment on what can be done for improvementr, it'd be great! cheers
  22. Please check my tutorial on my Layout Helper tool to create banners faster:
  23. I tried to add a border to a banner Ive made, but none of the tries worked i tried .to(type1, .3,{backgroundColor: "#000000", border:"40px #00a1d6 solid"}) I tried with an inset and i get the same effect but I dont want it to be transparent. .to(type1, .3,{backgroundColor: "#000000", box:"inset 0 0 0 7px #00a1d6 solid"}) I like how it looks with the inset but I the only thing about it is the shadow effect and how things can be seen under the inset once the logo passes by. Here is my codepen
  24. Hi all! I'm new to GSAP - are studying it. I found this example of the banner - http://gsap-banner.getforge.io/. However, this banner needs to be redone. Said that it was necessary - "Need to size it down for adwords, and also make a few variations". But please tell me, I don't know what I need to change in this banner? I need to make changes - just tell me, please, what should I do and what changes to make?
  25. Hello! I've been making svg animated banner ads, and the client ran into a bit of a snag- there are some artifacts being left behind by the animation on certain computers. It seems to only be in Chrome, but isn't consistent across computers. The client is running the same OS and version of Chrome as I am (Windows 10 / Chrome 55.0.2883.87 m), yet I have no issues. Here is a screenshot of what's showing up underneath the Call-To-Action button (scales in from 0, there is no shadow under the button) and some text (moves up from below the viewbox): This is the transformations I'm applying: t1.fromTo(text2, 0.75, {y:75}, {y:0}); t1.fromTo(cta, 0.4, {autoAlpha: 0, scale: 0, transformOrigin: '50% 50%'}, {autoAlpha: 1, scale: 1, ease: Back.easeOut}); Has anyone else encountered this?
×