Engaged

No Click Tag Improvements Allowed

Why Coding Correctly Can Cause Us Problems

Sites that host standard Flash ads will often have automated “code checking” systems made to scan a Flash swf for the correct click tag syntax.  This makes sense because it helps them to quickly find issues without the need of a human to look it over.  The downside, however, is that often times these systems have not been updated in a long time and will reject code that has been upgraded to the most recent standards of robust coding.

The old, simpler form of click tag code that most of these systems are looking for is basic code like this:

var tag:String=root.loaderInfo.parameters.clickTag
navigateToURL(new URLRequest(tag), "_blank");

There are two problems with this old form of the click tag code.

  1. It will not necessarily work if the ad is ever distributed to other sites that pass in a different click tag.  (For example, clickTAG rather than clickTag)
  2. It will break on certain I.E. browser versions depending on the security settings.

So what frequently happens when we try to plug more robust code into one of these code checking systems is that rather than looking for correct functionality, the scanner will look for exact syntax.  When this happens, the better code will get rejected by the overzealous police bot simply because the bot does not recognize what is going on.  In these cases, we often end up going back and forth a few times as we try to figure out what exactly the bot is scanning for, so that we can try to work out a way to get the highest quality code possible that will still be accepted by the site’s system.

It’s tough having high standards.

P.S. Shout out to Google’s rich media company, DoubleClick, for being one of the first companies to update their coding templates for better click tag code standards.  Woo-hoo!!

https://doubleclick-support.appspot.com/repository

Share this link: Share on Facebook Share on Reddit Share on Twitter Share on LinkedIn

The HTML5 Compendium

Background

With the growing need for mobile-compatible online media, we have experienced an increase in requests for HTML5 banners. The result is a series of questions we must answer for producers. Can we make this banner in HTML5? Yes. Can we make it in 40k? Not likely. Although we pride ourselves in our ability to squeeze a whole lot of high-quality content in a tiny package with regards to Flash, the available technology for HTML5 development is simply not at the same level. Consequently, specifications set by publishers for Flash units cannot and should not be applied to HTML5 units as well.

In July of 2013, the IAB Ad Operations Council and Mobile Marketing Center of Excellence released a publication titled HTML5 for Digital Advertising that addresses the technical hurdles of HTML5 units, and attempts to provide a set of guidelines for designing and developing them. As the IAB points out, HTML5-formatted ads rely heavily on code rather than visual platforms like Flash, and as a result increases operational overhead. In addition, a lack of a common HTML5 framework across publishers and ad developers magnifies these costs (IAB, 5).

It is our goal to provide our clients with the biggest bang for their buck, and so we are dedicated to finding the best methods for developing and delivering all our ad units. With the current deficit of testing data regarding HTML5 banner creation, we took it upon ourselves to research many of the prevalent platforms for building HTML5 ads. Our study involved the design and creation of a simple banner using six methods of development, looking closely at metrics such as build time, device compatibility, file size, and the complexity of each platform. We selected platforms that vary greatly in process to obtain a well-rounded understanding of HTML5 capabilities.

Flash Baseline & Optimized

As a first step in our study, we created a banner in Flash using timeline animations to serve as our base for comparison. The banner isn’t particularly complex, but utilized some Flash technologies that are currently unavailable via HTML5 such as blend modes and vector masks. These enabled us to save a significant amount of file size by using an overlay JPG for the orb lighting/reflection with a vector-based color fill. For all the HTML5 units, we had to bake the orb details into a PNG instead.

To further our analysis, we then recreated the banner, still in Flash, but using the GreenSock Animation Platform (GSAP) for code-driven animations. This optimized version reduced the file size by 24%, and also provided us with some animation data that could be re-purposed in one of our HTML5 tests.

HTML5 Trial 1: CreateJS

With the Flash units completed, the stage was set to test out a utility Adobe has implemented in Flash Professional CC known as CreateJS – a suite of modular javascript libraries that enable rich interactive content on open web technologies via HTML5. This suite includes EaselJS, an API that embraces Javascript sensibilities but is still familiar to Flash developers. It consists of a full, hierarchical display list and other classes to simplify working with Canvas.

Using CreateJS, Flash files can be quickly converted to HTML5 units with the click of a button, but there are a number of limitations. As mentioned earlier, we could not use the blending options for the orb images, so the baked imagery increased our asset sizes. However, since CreateJS draws to the Canvas element, vector masks translated well so we could avoid using 24-bit PNG files for our images. The greatest strength of this method is the quick conversion process from Flash to HTML5, but the API itself and javascript generated by the utility are massive (125k + 48.7k) and would likely be rejected by publishers that are used to 40k spec requirements.

HTML5 Trial 2: GreenSock Animation Platform

For the second HTML5 trial, we wanted to test out one of our favorite tools in-house: the GreenSock Animation Platform. Originally for Flash only, GSAP has a 12-year history of being one of the most robust, reliable, and efficient animation platforms available. When GreenSock ported their system to javascript towards the end of 2012, developers rejoiced and we found ourselves applying a very familiar API to HTML5 projects.

Rebuilding our test unit using the JS build of GSAP was a breeze. We didn’t have to consider any cross-browser compatibility, as that is all addressed by the API. The Canvas element wasn’t used so we did lose vector masks, but that wasn’t much of a hurdle as the rest of the process was straightforward and effective. We styled div elements to behave like Flash’s MovieClips, and then treated the unit as we would a code-driven Flash unit. The positioning and animation values from the optimized Flash version translated exactly to the javascript.

HTML5 Trial 3: Adobe Edge Animate

Our third test took a stab at Adobe Edge Animate: a part of Adobe’s Creative Cloud that brings a familiar user interface to web animation. Edge allows developers to create animated web content without code in a similar manner to Flash timeline.

We found animating in Edge to be slightly more robust than Flash. In particular, each animatable property recieves its own timeline (similar to Premiere & After Effects). This allows for more complex easing combinations as well as easier fine-tuning of animation timing. Many of the naming conventions and aspects of the UI paralleled Flash well, so we were able to familiarize ourselves with the interface quickly.

Unfortunately, the Edge javascript library is the largest we’ve found, weighing in at 198k. As an animation tool in general, Edge seems promising; but for banners, it doesn’t seem viable at its current state.

HTML5 Trial 4: CSS3 Animations

For the final iteration, we stripped down to the HTML5 basics and excluded any external libraries or APIs. We recreated our banner using only simple javascript and CSS animations.

The results were acceptable, and likely most pleasing to a publisher, but also the most difficult to complete. Development took twice as long as our base unit, and the overall quality of the animation fell short of all the other trials. As animation complexity increased, the style script grew exponentially, and it was a nuisance to maintain identical sets of -webkit and standard keyframes. The overall size of the code (js, css, html) was twice that of the GSAP version (sans API), and for creatives that push the envelope animation-wise, that size could easily overtake that of APIs like GSAP.

Results

Platform Animation Development Timing Assets Code & Tweens API Total Total Compressed Compatibility
Flash Timeline 1.0 (base) 14.4k 9.3k 0.0k 23.7k 23.7k Desktop Only
Flash GSAP 1.0 14.4k 5.2k 1.6k 18.0k 18.0k Desktop Only
HTML5 CreateJS 1.1* 35.6k 48.7k 125.0k 209.3k 83.8k Desktop, Mobile
HTML5 GSAP 1.2 41.0k 9.7k 59.5k 110.2k 63.8k Desktop, Mobile
HTML5 Edge 1.5 41.0k 29.5k 198.0k 268.5k 112.0k Desktop, Mobile
HTML5 CSS3 2.0 41.0k 17.1k 0.0k 58.1k 41.7k Desktop, Mobile

*CreateJS requires the unit to first be built in Flash as a timeline-animated banner, which is included in the development timing.

References

Interactive Advertising Bureau. (2013, July 15). HTML5 for digital advertising. Retrieved from http://www.iab.net/media/file/HTML5DAv101.pdf.

Share this link: Share on Facebook Share on Reddit Share on Twitter Share on LinkedIn