There are no shortage of posts this week outlining the many reasons to make the switch from Flash to HTML5. We have all known for years that Flash was on the decline, but display media and banner creation has been the final lifeline of relevance remaining. This month, we’ve heard the Chief Security Officer at Facebook Alex Stamos call for an end-of-life date. Watched Mozilla pull support on it’s browsers due to significant security issues, and read a Google blog detailing plans to “intelligently block” some Flash content based on somewhat vague parameters, forcing users to explicitly approve some Flash content. Between these occurrences and what has been known to be inevitable for more than a decade – Adobe has to choose whether to continue to support Flash or succumb to the pressure of some significant new limitations.

Adobe has been well aware of this, and abandoning Flash has been made far easier by Adobe software such as Edge Animate, Reflow, and a host of other tools made available. You can use some of these in your stack, or you can opt to set up your own workflow using a vast combination of libraries / resources, of which there are probably thousands. This article will summarize some workflow approaches based on recent production, but there are many paths to get to a rich media destination. If you are not an HTML5 or a Flash developer, fear not – I’ll try and outline the production case for making the switch and review some of the implications from a digital program level.

Banners: Flash vs. HTML5

First, lets talk about the reason Flash has been used for display media vs. HTML5. As a Flash developer, it took me anywhere from 3 – 8 hours to create a rich media banner set (usually approximately 6 banners in a set, of varying dimension). I’m sure there are others out there faster, and I know many that are slower, but for the quality of design and variation of size typically necessary for a compelling banner, this timeframe seemed to be the average. An hour to set up the environment and organize the assets, another couple hours to lay out the assets and program function via ActionScript3. After this, the additional time is spent modifying assets to fit the dimensions. This means clients could typically have a full set of banners in less than a day if you had creative, copywriting, and development working parallel and a quick turn-over with QA. For high-volume sets, the production time decreases from there based on shared assets and workflow efficiencies.

Because of this, Flash has been a quick-deploy option for display media. The most effective campaigns have a myriad of messaging targeting specific audiences, locations, behaviors, and etc., so the ability to create a large set of varied content was often easier to produce in a self-contained environment such as Flash. A timeline helps visualize the 10 – 15 second “sweet spot” length for a rich media ad, and the Flash interface and integration with other Adobe products provided an environment that made quick-deployment more achievable than a custom HTML5 banner approach would, for those of us comfortable with the program.

In contrast, the initial deployment and detail-animation approach from hand coded HTML5 can often take twice as long (or longer) – but it does not have to. Flash provides simplicity in that it is a production environment that is established – all it takes is opening the program and getting the assets to get started on production. A HTML5 banner environment requires a different workflow when creating volume levels, similar to the approach of a website. You have to structure a file-system, map the approach, and organize asset libraries before you even begin. This can be a simple process once you establish your initial workflow, however too often we see developers recreating a workflow for each individual set of banners, or not organizing the project for a quick redeployment and transfer resources.

When doing one or two banners or small batches, than many of these assertions do not apply. These approaches are based on enterprise or volume level banner production – where there are potentially hundreds in a set. For small run applications, throw it in a folder and get it done – see my note below about Google Web Designer and you can have a banner published within the hour.

Automate Processes

If the goal is to create an environment that allows for quick production of rich media ads, we have to have a stack ready to deploy so that developers can ‘hit the ground running’. Keeping in mind that Adobe has already provided a software to automate much of this workflow, I have been opting to hand-roll display media (though I have also used Adobe Edge Animate to speed the prototyping process). At this level of volume, there are typically multiple departments involved. Concept, project architecture, design, copy writing, development, QA, production, and media in varying combinations. This sounds like a complicated process, and it is – display media is a sophisticated craft and once you start down the rabbit holes of targeting and ‘Dynamic Creative’, there is no budget you can’t spend – but there is also no greater response on the spend. You can put a website online in a couple of hours by yourself, but it’s not going to perform like an enterprise website with a solid Framework, and this is true for Banners. Geotargeting, retargeting, remessaging, behavior tracking, Dynamic Creative – a host of complex options meant to maximize user engagements and provide ROI on a display media spend.

To un-complicate this workflow so that we can focus on all of the great tools provided, we can establish some process and production efficiencies, and it often starts with your file-structure.

Structure

Start with your folder. I use a directory structure based on campaign in whichever directory is appropriate relevant to the content organization structure. An average campaign will have multiple messages, then multiple sizes within each specific campaign message. Within each size, there is a web root directory structure containing HTML files, then subdirectory assets as to support these files visualized here:

This indicates a campaign with three message sets. Each message set has three banner sizes within the container. Then within each size, the actual file structure begins. Most of the time, this is broken down with three general containers. Within, I separate media, css, and scripts as my three main file directories (I am a fan of doing things in three’s for demonstration, but most medium to large campaigns have more messages and sizes than this).

In the supporting directories, we have two folders – one containing core code libraries (LIB), and another for Custom (CST). By splitting this, we are hoping to continue to develop on our library for assets and code we may re-use in the future, while providing a custom set relevant to the banner. In this manner, we can quickly deploy new projects with commonly used code sets, refining our deployment environment with every production set.

The reason for doing this is so that we can organize a large set of campaigns and messaging, taking the final asset for delivery from the root of the banner size starting from the concept and consistent through every step of the workflow all the way to the publishing platform. Beneath the ‘media’ folder, we can go down a few levels deeper for Dynamic Creative (DCO) sets and variable content, but that is for another article. By starting here, I can begin development immediately, sending production assets to their respective banner sizes.

We can already see where this is far more complex than the traditional Flash production approach. In contrast, an equivalent Flash file structure would often look more like this:

This signifies the workflow differences in organizing an HTML5 stack vs. Flash production, however, we can use this complexity to our advantage over time. Creating the additional layers in depth provide a modular workflow that is not as simple to integrate within self-contained Flash environment counterpart. Outside this environment, the scripts directory gives us the ability to rapidly deploy libraries and resource frameworks*. This approach also opens the door to “Dynamic Creative” display media options that can result in a significant increase in user engagement. Up to 400% more banner engagement according to a recent Sizmek study[1].

*Note – there are many variations of additional workflow automation tools such as Yo/Bower/Grunt/Git and literally thousands of deployment approaches, standards, and stacks you can use in conjunction with this approach, it’s all about preference, situation, and what works best for your team.

Resources

In Flash, we are limited to ActionScript. While many integration options are available, Flash display media is kept self-contained for publishing reasons. ActionScript is robust and the animation / interface capabilities of Flash provide a wide array of rich media options, however, we can achieve almost all the same effects now using resources and libraries like jQuery, Greensock, and the Adobe Edge Animate timeline production. Below are some few but great resources for HTML5 rich media production in 2015:

Greensock

Greensock has been in the game for a long time, making effects for Flash and now. Already an essential for many rich media developers in Flash, it provides many of the same animation functions as it did in flash. The biggest difference – the math requires a bit more planning now, or to put it differently, it feels like I have to pay a little more attention to the big picture when I’m experimenting with it. This isn’t a bad thing, and it is far easier to save custom Greensock snippets for reuse than it was saving similar processes in Flash. For Flash developers who used it in ActionScript, it is an easy library to pick up.

Google Web Designer

The shortest path from initial asset structure to working HTML5 banner is Google Web Designer. Adobe Edge Animate is a contender as well, but Google Web Designer has an interface that is more usable to those who haven’t lived under the strict reign of Adobe for almost two decades. With assets in hand, you are less than an hour from deploying your display media ad directly to publisher – Google will build the right framework in based on publishing options including DoubleClick, AdWords, or Generic for everything else. There is also a multitude of various banner templates to use as a base.

RazorFlow

The market for real-time data visualization through banner media is only going to grow. Applications from providing short-form survey’s with real-time results and email sign-up, to the ability to use charting for banner gamification elements provide interesting options for new methods to encourage display media user engagement. To put it more succinctly, it’s a charting tool that is easily customized with great API documentation.

Sizmek

As a publishing platform, Sizmek provides a host of resources. The interface takes a bit of getting used to, but as far as publishing platforms go, few options gives you as much control over the customization of your campaign and how it is served than Sizmek. You still need to develop the display media using supplementary production approaches, but at the publishing level, the directory structure diagramed above starts to make more sense. Sizmek provides all of the audience targeting, regional targeting, and etc., but takes more time to learn and the interface can be a resource draw on the production side.

Workflows

So far we have organized our assets into a structure, detailed some of the production resources available for creating the media object, and outlined a couple of the resources involved in the overall workflow. Now I’m going to try and visualize / define the workflow steps in a hilarious Visio set to summarize three different workflow approaches. All of these take place at the agency or enterprise level.

General Workflow

A basic approach to HTML5 banner creation starts with the initial concept design. The structure is defined and a flowchart of messaging and content should be outlined here. A dimension brief is provided to copywriters (unless they are part of the concept design, which is recommended), then production artist / designer which includes the asset file structure, such as the one diagrammed above.

Once ready for digital production, assets can transfer directly from production artists in appropriate dimensions ‘sliced’ and ready by simply replacing the campaign message folders with the set from production. Using Adobe Edge Animate or hand-rolled code, the asset package is zipped at the ‘dimensions’ level and ready for immediately integration with publishing platform. At this point, media and digital strategists would work with the assets to create and monitor the messaging approaches and display media buys to provide the best engagement and response. This is the most common workflow for campaigns.

Responsive Workflow

Responsive banner design means that you can cut quite a few steps off your production efforts by creating one banner that scales to any size using a single base of assets. Build one banner and serve it at any size, on any device. Intuitively, this approach is limiting as getting a rich media banner to be effective and compelling at all sizes takes a clever or more simple design than designing for sizes specifically makes available. The responsive chart is exactly the same, though time within each workflow step changes. A responsive workflow can often take less time due to few revisions for creative to design for and production to organize. It’s limiting, but perfect in the case of some campaigns.

Video Based Rich Media

Avoid the production complications by paying the extra CPM to do a full video rich media campaign. This allows your designers to go crazy in programs like AfterEffects to create a theatrical rich-media experience where there are few limitations on design and HTML5 Canvas provides the platform to play it without need for plugin or player. The biggest disadvantages to these are the inherent size increases the video and effects require. It’s easy to get an HTML5 custom banner to be 20k or less – video banners are always significantly larger than this, and consequently more expensive. There are also engagement implications on mobile when building resource-heavy display media sets.

Using any of these sample approaches, you can start to refine an HTML5 production process that is right for your organization. The most important item to note that at the last step of this process is where the real work begins – leveraging the multitude of targeting tools available to get your content in front of the right audience, but as with some other references, that is an article for another time.

If you are still reading this, then thank you for your time. There is enough information just within an enterprise display media workflow to fill a book, this is a brief and general summary of some approaches I have taken over the years. In the last decade I’ve created Banner workflows and sets for a host of companies around the globe. I’ve created many thousands of banners in Flash, and nearing 100+ HTML5 ones more recently. While Flash was a great option for it’s time and I have enjoyed it, I think the time for using it is over and organizations should be taking steps to refine their HTML5 production, processes, and workflows before Flash loses any more of the market.

[1] “Sizmek Mobile Index 2015” | http://go.sizmek.com/rs/475-TXN-604/images/Sizmek_Mobile_Index_2015.pdf