Engaged

CMS as a Tool

Content Management Systems (CMS) are tools that allow a company or person to manage the content of a website without specific knowledge of the programming language used to build the site. They put control in the hands of the content creators, often saving time, money and effort in the long run.

There seem to be as many CMS platforms as there are developers to work on them. Just like tools in a shop, they all perform certain tasks depending on the intended outcome of the content. There is also infrastructure to consider: What systems are you currently using? Where do you need the CMS to reside? Who will be using it and how often?

At Intersect, we specialize in a wide range of CMS platforms. We prefer to approach every project with an open mind about which tool to use.

For most projects we find open source platforms to be the best decision. WordPress is often our first choice for many reasons. WordPress is in constant development and is always improving. Being widely adopted, it has exceptional plugin support from third-party developers, both free and enterprise. The template system is flexible and easy to scale from small- to mid-size projects. Because of its flexibility and support, it’s also the tool we’re most familiar with, and we hear great things about its editing capabilities from content managers.

For larger projects we have found Drupal to be a better option. Drupal is slightly more robust and can handle more complicated functionality built-in to the CMS. This requires more customization of the CMS for specialized cases. Drupal handles scaling slightly better than WordPress. As the project grows, Drupal can be molded to fit. The trade-off is Drupal’s complicated content editing interface. Where WordPress keeps this simple and intuitive, Drupal’s weight-lifting is centered on increased functionality for the content manager.

The important point to remember with any CMS is that no tool is always a perfect fit when we’re discussing flexible content. We work on bending an open source CMS to meet all editing capabilities of a project. However, sometimes these tools are either too much or too little for a particular scenario. In those cases, we prefer to build custom, one-off CMS tools from scratch to meet the very specific needs of the project.

We often find .NET solutions fall within this group. We mostly choose Microsoft solutions for large-scale, enterprise-level projects. There are quite a few .NET CMS solutions that work well while integrating with the bulk of a custom build.

As developers, we like our tools. Sometimes we get caught up in the comfort of one tool and discredit others. It’s best if we remain as flexible as the tools we’re using and look at every angle before a project begins. Each tool has nuances that can help or hinder the outcome of the content being managed. It’s our job to choose the best tool and provide the best outcome for our clients.

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

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