Making the Switch to HTML5 Ads Webinar Transcript

Monotype’s Theo Skye talks about standardization of digital ads, authoring tool options, the usefulness of web fonts in ads, and more to help teams that are trying to make the switch to HTML5 ads.

Watch the video instead and see the related resources


Hey everybody and welcome to today’s webinar Making the Switch to HTML5 Ads. My name is Shelly, I work here at Monotype, and I’ll be your host for the next hour, broadcasting from our Belfast offices, here in Northern Ireland.

So, first off, thanks very much to all of you who have already joined us. We’ve got a couple hundred who are settled in, and the numbers keep rising. So we’re so very pleased with so many of you taking an interest in this topic. Now, if you’ve tuned in before, you know the score. Each month we tackle a new design issue or challenge, bringing in an expert to shine a little into those areas of design and typography where we sometimes stumble, or get slowed down, or just want to understand better.

Now some of you may know Monotype from our typefaces, because we have a lot of them. And others maybe use our design tools and services, that make it easy to work with those typefaces. And before we’re finished today, I hope you’ll think of us all as the folks who’ve made HTML ads feel a little less daunting, and a little more achievable for your teams.

Now with me today from London, by way of New York City, is Theo Skye, who’s our Director of Product Engagement. Do you want to say hi Theo?


Hi, everyone. Thanks for joining.


Now, I picked Theo for today’s webinar not just because he’s one of our newest colleagues and a soft target. No, I brought him in because every day he’s actually working really closely with agencies, design tool and browser makers, and working groups in the digital advertising industry to explore how our technologies can help boost the quality of digital ads and ease workflows of those of the front lines like yourselves. And in addition, he’s spent a large number of years running a digital ads company, so he’s extremely knowledgeable about both the industry and, importantly, the practical issues around ad production.

Alright, I’ve handed over the screen, Theo. I think it’s all yours.


Thanks everyone for tuning in today. Like Shelly said, my name is Theo Skye. I guess a little bit of background on me might be helpful.

I went to Art School and I’ve been a designer for more than 20 years—I guess just like a lot of you tuning in today. In that time, I’ve also learned to write some code, build apps, manage teams, and even launch and run a company.

About seven years ago I co-founded a mobile advertising company named Media lets. We helped the world’s top brands bring thousands of groundbreaking rich-media ad campaigns to market on mobile smartphones and tablets. My creative team at Medialets would conceptualize, design, and build the ads, while our product and engineering teams created a new ad server that was built specifically for delivering HTML5 ad campaigns to mobile devices. And it was pretty exciting because nobody else was really doing anything like it at all.

For example, in 2009, we made the world’s first shakable ad. And In 2010 we made the world’s first rich-media ad on a tablet device. That campaign actually launched the same day that the very first iPad went on the market.

Since Flash content never worked on mobile devices, we needed to build all those ads with something else. And since stepping away from Medialets last April and its singular focus on mobile, I’ve come to understand just what a long way the digital advertising industry has to come when it comes to embracing HTML5. And HTML5 is our only option. And it is what every one of the thousands of ads we built was made of. So as someone who has used HTML5 extensively for developing both advertising and web sites, I have come to believe very, very strongly in the future of this medium. And I also believe that the more people become familiar with and use HTML5, the better and more useful HTML5 will become.

So, my goal really is to share my experiences and help the broader digital advertising industry adopt and make the most out of HTML5. To that end, today I’m going to:

  • briefly recap the current state of affairs in digital advertising;
  • talk about some of the key differences between Flash and HTML5 when it comes to ad creation and delivery in the browser; and then
  • look at three big concerns for those of you trying to transition.

We’ll look at file size issues, working with web fonts in HTML5 ads, and various authoring methods for HTML5 advertising. And I’ll be moving pretty quickly. The slides will flash pretty fast, but as Shelly said, we’re going to upload a video of this entire seminar as well as a bunch of additional supporting materials, probably towards the end of this week, or into next, and you will all receive the link to that. So let’s start with the current state.

Today, mobile continues to dominate audience attention, and its pace is not slowing down. All the major operating systems, web browsers have effectively dropped support for Flash-based ads. Some people have referred to the confluence of these events as “The Flashpocalypse.”

It’s actually an important moment in history because at this time, decades of very specific industry expertise essentially need to be abandoned. Many creative professionals that I’ve talked to are expressing feelings similar to what actors were saying in the 1920s during transition from movies to talkies. Clara Bow was a famous actress who was working at this time, who said: “I hate talkies, they’re stiff and limiting. You lose a lot of your cuteness, because there’s no chance for action, and actions is the most important thing for me.” But she then admitted that she could not buck progress, and she just had to do the best she can.

So, you may be tuning in today because you’re in the digital advertising industry and you’ve been informed that using Flash to make digital ads is no longer viable. And you may be asking yourself, “Okay, now what? If I can’t use Flash, then what should I do?” Well, based on my experience, I think the obvious answer is: use HTML5 instead. But before we get into that, let’s establish a few key pillars of knowledge and start with a closer look at Flash and HTML5.

What exactly do we mean when we refer to ‘Flash ads’? Well, Flash is a software platform. It’s created and owned by Adobe. It consists of three main components. First, creative teams use (1) Flash authoring software to (2) publish SWF. Those SWF files are the actual digital ad. So those SWF files get served to browsers and then rendered via the (3) Flash plug-in that has generally come pre-installed in most browsers. Until recently, the vast majority of digital ads have been built and delivered using this method.

And so what is HTML5, by comparison? Well, HTML5 is the fifth version of the core, open source language that has been used to build most commercial web pages since around 2010. And version five of the HTML specification added new video and animation features that have effectively made HTML5 suitable for a wider range of applications than the previous versions of HTML. And it’s also important to know that HTML5 is actually a combination of three different languages that work together:

  • HTML markup is the language used to define and structure content.
  • CSS code is used to style that content and give it specific appearance attributes.
  • JavaScript code is used to create interactivity and give function to the styled content.

JavaScript can also be used to dynamically generate HTML and CSS code. And that’s really where HTML5 starts to get even more interesting. But we’ll talk a little bit more about that later.

So interestingly enough, just about every web page you view in your browsers today uses HTML5. Let’s just take a quick look at exactly how that works.

You go to a website and an HTML file is delivered to your browser from a web server. Every HTML file contains instructions for your browser that tell it to also load in other necessary assets for the page—scripts, images, fonts, videos, etc.—that the web page needs to display and work as intended. So, your web browser basically follows those commands stored in the HTML file and then loads all those other assets as fast as it can.

I wanted to cover how web pages work in your browser because the way that an HTML5 web page loads in your browser is exactly the same as how an HTML5 ad loads in your browser.

HTML5 ads generally consist of multiple files, a lot like web pages do. An HTML5 ad will always have its sort of ‘main’ HTML file, but it will also contain separate image files, JavaScript files, maybe a video file, all to make the ad display as it needs to. This is one of the key differences between a Flash ad and an HTML5 ad. A Flash ad generally consists of that one, single SWF file. That SWF file has everything needed for the ad embedded inside it, all in one compressed package, so to speak. And that core difference in the composition of these two different formats has implications for the delivery of ads.

On the left there, when a Flash ad was served to the browser, only that one, single file needed to be delivered to make the ad display because the SWF file contained everything inside it. The Flash plug-in took care of uncompressing the SWF file and rendering everything. But when an HTML5 ad is delivered, the ad’s main file (usually named index.html) is served to the browser first and loaded, then every the other file or asset that the ad needs is loaded in kind of one at a time via individual requests from the browser and a response from the server to deliver the asset file.

There is some amount of overhead in each one of these requests/response round trips, and that can slow down how quickly an ad displays to the end user. This is why it is important to design and build HTML5 ads so that they contain the fewest total number of separate assets possible—it reduces the total number of request/response round trips and makes the ad load a little bit faster.

There are a couple techniques that you can employ to help you do that. For example, It’s generally a best practice to place the CSS and JavaScript code in your ad inline. That means within that main HTML file, rather than store them as separate, external files. This image on the slide, now, shows what that looks like, inside code. In this example, the CSS and JavaScript code are embedded directly inside the <style> and <script> HTML tags inside this HTML5 document. This reduces the total number of separate request/response round trips and it can make the ad display faster.

It’s also a best practice to use what are called sprite sheets that combine multiple image files into a single image file. Even though that single image file might actually add a little bit to the overall file weight in some cases, reducing the number of requests often pays off in faster overall load times and faster ad display time.  In their HTML5 Advertising recommendations, the IAB recommends no more than seven total requests per advertisement to assure optimal display and loading performance.

In addition to reducing the total number of asset requests, another thing to keep in mind is that since all the asset files are separated in an HTML5 ad, the ad can be larger in file weight than an identical looking Flash SWF ad would be. So that’s why the IAB has also recommended an increase in the allowable file weight for HTML5 ads, from about 40–50KB for Flash SWF ads to now being 200KB for HTML5 ads. And from what we’ve seen so far, most publishers and ad servers seem to be adopting this 200KB maximum file size recommendation. In the webinar follow-up materials, we will be sharing the link to all of IAB’s recommendations for HTML5 advertising. So, you’ll all get that, if you haven’t seen it yet.

Just as there are differences in how SWF and HTML5 ads get delivered to browsers, there are also differences in how creative teams must upload them to ad servers. Flash, SWF ads were pretty easy to upload to an ad server. You would just uploaded that single SWF file. But, again, since HTML5 ads are composed of multiple files, they’re usually placed in a folder, then that folder should be compressed into a ZIP file, ZIP archive, then the ZIP gets uploaded to the ad server. Once the ZIP file containing the HTML5 ad, and all its assets, is uploaded, the ad server will then take care of automatically unzipping the ZIP archive and stashing its contents into the correct place on its file structure, so the ad is ready to be served. So that all happens automatically.

One common sentiment that I’ve heard about using HTML5 for ads is: “I can’t do as much with HTML5 as I could with Flash!” And, you know, to some extent that is actually still true. Well, at least today. HTML5 is just a younger medium than Flash. Flash has been around for 20 years. And it’s going to take some time for HTML5 authoring tools and knowledge of HTML5 to catch up and, someday, even surpass Flash’s capabilities, I think.

I believe the concerns about having fewer capabilities in HTML5 are actually going to be solved, at least in part, by these two HTML5 technologies that I don’t think a lot of people have had much opportunity to use yet. They’re called HTML5 <canvas> and WebGL.

HTML5 <canvas> is a native way to draw graphics on a web page. Any graphics can be drawn. The trick to it is to know how to write the code that draws the graphics. This code is somewhat complex today, but authoring tools are catching up and filling in the gap here, and they’re starting to make this much, much easier—to the point where you don’t even need to know the code. They’ll just take care of it for you.

WebGL is similar, but it’s also a JavaScript-based method for rendering interactive, 3-dimensional (or 2-dimensional) graphics within any compatible web browser without the use of browser plug-ins. So this is really exciting because, technically speaking, anything that a computer can render can be done with WebGL. The current challenge, just like with <canvas>, lies in the authoring of WebGL content. But, again, the tools are just at the verge of making this a lot easier to use.

Another concern I’ve heard Flash production teams say is: “It takes longer to make HTML5 ads than Flash ads.” And again, for the most part that’s actually true—at least today. And in my experience, production timelines for HTML5 ad campaigns are about 30% longer in overall hours and business days. We’re going to talk about some of the specific reasons for these extended timelines and, in just a few minutes, also how the industry is going to be able to move past them.

HTML5 actually has some pretty important advantages over the SWF file format, and once we apply those advantages, we’re actually going to reduce production timelines, perhaps significantly. So let’s talk about that.

First of all, I think it’s important to call out that HTML5 ads work on mobile devices. Flash SWF ads never really have and they never will. Since the majority of ad impressions are now happening on mobile devices—because that’s where the audience has gone in most cases—HTML5 is really the only viable way to reach most of your digital advertising audience. Even before all these web browsers started dropping support for SWF files, and the Flash plug-in, you could only hope to reach half of the addressable digital audience with a Flash SWF ad. And in fact, HTML5 is the only medium that can effectively render natively (without plug-ins) on virtually every type of screen, within every single operating system.

Whether it’s a mobile phone, a tablet, a smart TV, a set top box, or even a game console, in browsers or inside apps, HTML5 can be served and displayed virtually everywhere. That alone makes HTML5 a very powerful medium for communication. And this means that you could potentially create one HTML5 advertisement that could display across every screen where your audience might see it.  That’s pretty cool. But all the screens out there obviously come in many different shapes and sizes, and this has historically meant that we needed to create a separate advertisement for every different placement size. Well, this is where a responsive design methodology can be applied to help.

With HTML5 you have an inbuilt option to either continue building a separate asset for every different size or build ONE ad that automatically adapts and works everywhere that it needs to.

This responsive design methodology is actually something that website builders have long since adopted and made core to every step of their process. We’ve all heard of responsive websites that display appropriately according to their environment, whether it is a mobile phone, a tablet, or a desktop computer.

Most of the advertising industry is much, much newer to using HTML5, so they’re really only starting to utilize these new design methodologies. It may take some time, but I don’t think it’s unreasonable to say that advertisements that adapt to their environment are going to become a necessity. And this is a good thing, because if you only need to design and build one ad, instead of five or six, that’s going to significantly chip away at that 30%-more-production-time issue that people are talking about.

And by the way, using real text that automatically reflows when the column width of an ad changes, it’s a very important part of next-generation design. So speaking of text, there is something that nearly every advertisement on earth has in common. And it’s that they all contain words. Unless you’re a professional copywriter, most of us just take this for granted. We read the text in the ad and then move on. But it’s obvious that text plays a critical role in the effectiveness of advertising. And since most advertising is for branded products, and most brands adopt a specific look and feel as part of their visual identity, the ability to have complete control over how that text displays and appears is absolutely vital. In fact, virtually every set of brand guidelines specifies typefaces to be used in their branded materials, including their ads.

So, let’s talk about fonts. Some may not realize this, but Monotype has been making typefaces for decades, and we’re fortunate to work with so many of the world’s largest brands. So it’s safe to say that we have a pretty good understanding of the strong relationship between type and brand communication. The need to use specific fonts is, therefore, a fundamental part of advertising, and thusly for HTML5 advertising. So it’s safe to say that anything we can do to streamline the implementation of text in ads is going to benefit this industry.

But as straightforward as all of this sounds, there are still some key challenges with regard to how text is getting incorporated into HTML5 advertisements. Before we dive in, let’s just take a moment and envision an imaginary scenario.

Picture this: you need to use a word processing app to create a document of some kind. Only, in this imaginary scenario, the software doesn’t actually give you the ability to enter text onto the page. That functionality simply does not exist. I know this might seem like a silly example, but just indulge me for a moment. Instead of entering text on the page, what you need to do, is go and open your graphics creation app. You need to layout and design all the text for your document in your design tool exactly as it needs to appear. Then you need to export that image of your text in some graphics format, maybe like a JPG file. So, you place that exported image onto the page in your word processing document.

Keep in mind that this ‘text’ is now actually an image file, so you can’t edit that text here in your word processing app. It’s just a picture. If you needed to edit the text, you’d have to go back to your original design app, edit the text there, export a new flat image file, then place that new image onto the page in the word processing document.

Nobody would deny that that would be a very inefficient workflow compared to just typing and styling the text inside the word processing document directly. So I just outlined that silly scenario because it might be really surprising but it demonstrates exactly what most creators of HTML5 ads are still doing today. Many authoring methods for HTML5 ads still expect ad creators to incorporate the ad copy as flat images of text, instead of as real text. Well, if HTML5 is going to succeed as the widespread authoring medium that it promises to be, I think this is a pretty serious challenge, and it’s one that our industry really needs to work on together to overcome. We cannot keep creating text inside image files if we are going to use HTML5 for advertising.

And I actually blame this inefficient workflow for implementing text for at least half of the reason why it takes longer today to create ads with HTML5.

So let’s just imagine for a moment that a typical production budget for a set of HTML5 ads for a campaign was US$18,000. So then half of that additional 30% timeline delta would come to $3,000. All of those additional costs are applied to every single ad campaign, in perpetuity, until this challenge is effectively addressed.

Whether it’s the agency, or the brand client paying for these additional production hours, it’s just not sustainable. It needs to be solved. So upon learning this information, the obvious question is “Why has the HTML5 ad building community committed themselves and their clients to such a nonsensical production workflow?”

The reasons that using real text in HTML5 ads is not yet commonplace has to do with font file formats and font licensing. Let’s take a look at this in detail because, again, this a problem that the entire HTML5 community really needs to rally around and fix if we want this medium to live up to its full potential.

When you purchase a font, it’s first important to realize that you don’t actually own that font. What you are actually buying when you purchase a font is the right to use the font in certain ways. Those specific rights are defined in what’s called an End User License Agreement. This is commonly referred to by folks in the industry as a EULA.

So in a way, buying a font is kind of like buying a movie. Whether it’s an old school DVD disc, or a digital download, when you buy a movie you can play that movie in your home, but you cannot digitize the movie and upload it to YouTube. You also can’t project the movie onto the side of your house and charge you neighbors admission to watch it. In fact, movie theaters pay a lot more for movies than you do for that privilege. The key here is that you are purchasing the right to use that content in a certain way, and it’s exactly the same for fonts.

As far as most people in the creative industry are aware, fonts are typically purchased so that they can be installed on desktop computers. When you purchase a desktop font license, that typically gives you the ability to install the font on a computer inside a particular organization. But just like a movie that you might buy, according to most font licenses, that font file cannot be shared outside the license group—outside the organization. And it also cannot be converted into other font file formats.

You can also embed that font file into other files, as long as the font file is protected from being somehow extracted and used outside of that document. This is why it’s generally been okay for PDF files, and also for Flash SWF ads, to embed desktop fonts into their published output. The embedded font files were ‘protected’ from being extracted and used elsewhere.

But web browsers render HTML5 content. They can either render the fonts that happen to be installed on the operating system, or they can use web fonts that are loaded in from a URL. But because of the nature of how HTML5 works, as a set of open source languages, it is not technically possible to embed web fonts in a sufficiently protected format in HTML5. That’s why web fonts require a different and separate font license from the desktop fonts.

The good news is that for those now tasked with creating HTML5 ads, web fonts have been used on HTML5 websites for years. So there is a lot of existing technology that we can make use of when preparing web fonts for HTML5 ads.

Unfortunately, when most web fonts licenses were written nobody conceived there would one day be a need to use those same fonts in digital ads, not just websites. So the EULA terms for most web fonts aren’t really a perfect fit for advertisement use, and they often require a customization. We realize that licensing web fonts for use in digital ads may be a little frustrating today, and the type industry, that Monotype is a part of, still has a lot of work to do to make this process better for the creative industry. So I just wanted to let everyone know that Monotype is looking very closely at how we can help with that.

So apart from the font licensing issues, there have also been some technical issues with using web fonts in HTML5 ads. Webfont files can easily be 250KB or more. A large portion of this weight is the glyph data. Glyphs are the shapes of all the characters that are stored inside the font. And good, high quality font files, have hundreds and hundreds of glyphs just for Latin characters—never mind languages like Arabic, Japanese, Hindi, or Mandarin that have much, much larger alphabets. And font files for those languages contain thousands and thousands of different characters. Font files for those other languages can often range from 3–7MB apiece.

In either case, no matter what the language, a single web font file can very often be larger than the 250KB total max file size limit for HTML5 ads. So if web font files are so large, how is it that web fonts can be used in ads? Well, this is where something called font subsetting makes all the difference.

Font subsetting involves processing a font file through specialized subsetting software to create a new, smaller font file. It creates a smaller file by reducing the number of glyphs that are inside the resulting font file.

So, let’s just look at a simple example. If an HTML5 advertisement that you were creating contained copy that read ‘Buy this product!’, only the following subset of unique glyphs would be needed to render those words. You’d need ‘B u y t h i s p r o d c !’. You wouldn’t need any of the other glyphs that were in the font file. You could just use a subsetter to remove them. That would create a new, smaller font file that the ad could use.

And just FYI, there is usually about a 1:1 ratio between the file size of a subsetted font file and the percentage of total glyphs that it uses. So, if someone was using the font Frutiger Light for an ad and they subset that font file down to just those particular characters, the resulting font file would only be around 6KB. That’s a savings of almost 98% of the original font file weight.

It’s important to know that high quality font files don’t JUST contain that glyph data. Font files also include what are called kerning and hinting data, which, while much smaller in terms of file weight, are exceptionally important.

A kerning table is what stores information in a font file about the default spacing between characters. For example how much space there should be between an A used with an H versus an A when used with a V, as shown here.

So these kerning tables get very, very detailed, and they take a lot of time for the font creator to create. And they reduce the amount of custom kerning that you, as a designer, need to do. And these kerning tables are one of the underlying attributes that separate high quality fonts from the rest.

Hinting tables are highly detailed mathematical information that provide rendering instructions for different display environments, whether it’s different types of screens or different types of printers. The glyphs in the font define the basic shape of each character, but the hinting tables make sure that the characters will always look their best everywhere that they might be displayed. So, from what I’ve seen, in my opinion most free fonts don’t actually contain good (or at least, not detailed) kerning and hinting tables. I mean, these things can literally take years to create, and it’s one of several reasons why using free fonts can pose significant risks for commercial production work. They just don’t contain this important stuff.

Another thing to be aware of is that existing, third-party subsetting tools on the market may actually strip out those important kerning tables and the hinting tables altogether and they won’t even tell you that they did it. I speculate that the creators of those tools maybe didn’t even understand what those tables were used for, and they made their tools behave that way in the name of reducing file weight as much as possible. But not only does removing those important tables from the font file not pay off very much in terms of saving file weight—I mean, they’re actually really small to begin with—removing them adversely affects how a web font will display on different operating systems.

So if you only remember two things from all of this talk about font subsetting, and kerning and hinting tables, and all that, it’s just that:

  • Make sure your font licenses do allow for font file subsetting, because most desktop font licenses do not allow font file conversion or subsetting.
  • If you are not using a Monotype font subsetting tool, be sure to test your subsetted fonts on a wide range of operating systems, iOS, Android, Mac OS & Windows, for starters.

A few minutes ago we talked about how important it is for HTML5 authoring tools to give their end users the technical capability to use and edit any font they need to. Otherwise, stylized text needs to be implemented using images of text instead of real text, and that costs everyone more time and money.

This year, Monotype’s actually been working with a number of tools to do just that. In May we released an API called the Web Font Platform that empowers authoring tools with several important functions related to using web fonts—things like font hosting, font discovery, font serving, font subsetting, and matching desktop fonts to a web font. It also takes care of validating font licenses.

To be absolutely clear, this Web Font Platform is not a product that consumers use directly on its own. It’s a set of cloud-based, back-end software services that other authoring tools can use. But ultimately it does help you create better work, with better type, in the form of better web fonts.And I’m going to tell you about some of those tools now. Let’s talk about the range of methods for creating HTML5 ads.

First of all, there is the option to hand code your HTML5 ads. This is actually how many folks who have already begun to create HTML5 ads have been doing it. I know it is how my Team at Medialets built nearly every one of the thousands of ads we made for our clients. We hand coded the ads because there were no HTML5 authoring tools that did what we needed to, even a few years ago. And as I mentioned earlier, HTML5 is made up of those three open source languages: HTML CSS and JavaScript. If you have a team with the skillsets to code those languages, then you may decide to create HTML5 ads that way. And if you do, you’ll have the ultimate power to create anything you have the ability to create. But with great power comes great responsibility.

Hand coding HTML5 ads takes a lot of expertise, and it can be especially challenging because of the amount of fragmentation across all the disparate environments and operating systems where an HTML5 ad might be displayed. It’s really just too much for most production teams to keep track of on an ongoing basis, especially when their primary task is to create ads, not to create tools to create ads. I really think ad creators really need to use HTML5 authoring tools to create HTML5 ads.  The makers of HTML5 authoring tools aren’t busy building ads, so they have the time it takes to keep up with all the fragmentation and build solutions for it into their tools. That way, the teams that make ads don’t have to worry about the fragmentation; they can instead focus on getting ads out the door as efficiently as possible.

So Google has a piece of software called Swiffy. It’s an online tool that takes a Flash SWF file and turns it into an HTML5-compatible format that can play the animations in a SWF file without the Flash Plug-in. In some cases, this has served as a decent stopgap for creative teams who may have had an inventory of Flash SWF banner ads that would have all had to be rebuilt (and paid for by someone!). But you know what they say about things that sound a little too good to be true. As impressive as Swiffy might be from a technical standpoint, it has some issues that keep it from being much more than a stopgap.

In my own testing, I have observed that Swiffy’s output animations can have very low frame-rates on mobile phones and tablets, particularly on Android. So I think Swiffy is really only suitable for very simple banner ads. You just can’t do anything very complex with it.

Using Google Swiffy to convert Flash ads to HTML5 ads may also incur some font licensing issues. For example if a desktop font was used to make a SWF file, as they often are, then converting the SWF file to HTML5 with Swiffy would mean that Google would need to have a specialized font license to use Swiffy to convert that desktop font to a web font in its output. Since there are tens of thousands, or more, of fonts that Google does not have a license to do that with, I mean fonts like Helvetica, that means by using Google Swiffy, you and/or Google might be violating a desktop font license.

For the past few years, Adobe has had another tool as part of the Creative Cloud subscription. It’s called Adobe Edge Animate®. It was made to create HTML5 animations, but frankly it was never made specifically to build HTML5 ads. Nevertheless, this did not stop some creative teams from testing it and even using it to build ads.

What I’ve found is that Edge Animate® has never really had very good web font support. It’s almost impossible to use web fonts outside of Adobe’s Typekit library. And even then, you would still need to buy an additional font license to use web fonts in an HTML5 ad that you built. But, perhaps, most importantly, Adobe recently announced that Edge Animate® is going to be sunsetted. That means it will no longer be worked on. So, if you have been testing, or even thinking about testing Adobe Edge Animate®, you will probably want to consider other options right at this point.

Also, it’s important to mention that just two weeks ago, Adobe announced that Adobe Flash authoring software is going to be released in early 2016 under a brand new name, called Adobe Animate®. This shouldn’t be confused with what we just talked about, the sunsetted Adobe Edge Animate®. That’s a different tool. And it is really best to think about this as the next version of Flash, just with a new name.

Adobe says that Animate®, when it comes out in 2016, will contain some new features for outputting HTML5 content—perhaps as <canvas> and WebGL. So I think it’s going to be interesting to see what it can do and how widely supported its output will be across all those various fragmented environments where HTML5 might be displayed. Also, Adobe has made no mention yet as to whether web fonts will be supported in the HTML5 output of Adobe Animate®. This is important, especially from a font licensing perspective. So, fundamentally, I think we’re just going to have to wait a few months and see what the new Adobe Animate® really lets the HTML5 ad-building community do.

Google has created their own tool for building HTML5 ads. Oddly the name they have given this tool is Google Web Designer®. But names aside, some teams are using Web Designer® to build HTML5 ads, especially teams that are building ads for Google’s ecosystem of ad serving products.

Google Web Designer started off pretty simply, but it has become more capable over the past couple years as Google has been actively developing and releasing new features for it on a regular basis. The current version of Google Web Designer® caters pretty heavily toward Google’s own library of 200 or so open source web fonts. If you currently use Monotype web fonts, you’ll be pleased to hear that our team has discovered that it is possible to use those with Google Web Designer® too. We actually have instructions on exactly how to do that on our website,, and we’re going to provide the link to that page in the follow up materials that you will all receive.

A few years ago, a company named Adcade started development on an HTML5 authoring solution that would meet the needs of creative teams who were used to a Flash SWF workflow, but needed a tool that could create HTML5 ads. They’re now on Version 2, and their tool, named Epoch, and an accompanying LightSpeed Extension for Adobe Photoshop, offer a pretty robust solution for HTML5 ad development that will feel pretty familiar to most Flash users.  Epoch is also integrated with several of the major ad servers out there, including Google, Atlas, and Sizmek, so ads that are made with Epoch can be uploaded to those, and other ad servers and “just work” on pretty much every screen.

Another ad authoring solution called AdCreator is made by a company named Celtra. Celtra has been developing AdCreator for a number of years and has enjoyed widespread adoption and success among the mobile advertising community, which is what they focus on. AdCreator launched support for cross-screen advertising in 2014, and they built a pretty robust web-based authoring solution that supports a wide range of ad formats and use cases.

One of the reasons why Celtra’s customers like it so much is its extensive library of customizable components that can be just dropped into ads and tailored for each execution. It’s a lot easier than building similar components from scratch. I definitely recommend checking out and keeping an eye on Celtra because they are working on some pretty cool stuff.

Flite is a company that has a robust, browser-based ad authoring tool they call Design Studio. Flite also began development quite a few years ago with an aim on solving the authoring challenges around mobile rich-media advertising. But Design Studio has had cross-screen ad support for quite some time now, too.

Design Studio utilizes a familiar and flexible web-based environment that reduces the complexity of building ads so their users can focus on the creative process, not the technical stuff. They can also offer a range of off-the-shelf ad products, which serve as pre-baked customizable solutions for common digital advertising needs. They also allow their customers, some of whom are publishing organizations, to create custom ad products that make the creative authoring process a lot easier.

Next up is Hype. This is a desktop HTML5 authoring application made by a company named Tumult. They’re now on version 3.5, and it’s used to create HTML5 animations and ads. It offers a range of unique features that cater well to a designer audience that is looking for straightforward but capable software to get great work done. With support for multi-screen ads and advanced visual filters like blur, this tool has many former Flash users forgetting they ever needed it. And in just a few minutes I think we are all going to see a live demonstration of Hype presented by Tumult’s CEO Jonathan Deutsch, who’s joined us today. So you’ll definitely want to stick around for that.

Responsive Ads is a company that has created a really interesting, browser-based tool that they call Narrator Studio. For the past several years they have been working with major publishers and agencies to create all-new, responsive ad formats that essentially look perfect on every screen—just like responsive websites would.

Today’s multi-screen world really calls for a new design philosophy, I think—one that lets advertisers reach audiences wherever they are and display the most appropriate message in the best way for each context. The solutions that Responsive Ads have put together, I think they really address that need and certainly deserve attention and exploration.

I also want to mention that these tools we’ve looked at (Adcade, Celtra, Flite, Hype and Responsive Ads) are among a range of tools that all use the Monotype Web Font Platform to give users like you the functionality that you need to seamlessly use web fonts inside HTML5 ads.

In addition to all these HTML5 Ad Authoring tools that we’ve mentioned, there are a number of other tools out there that are specific to certain ad servers. Many of those tools have also integrated Monotype’s Web Font Platform because those companies recognize the importance of being able to use brand-mandated, pixel-perfect text in the HTML5 advertisements that their platforms deliver.

So, we’ve taken a look at why the transition to HTML5 for digital advertising is so significant for the ad industry. And while change can certainly create challenges, it also serves as a forcing function for really close scrutiny of our current practices and assumptions. Situations like this almost invariably result in innovations and new opportunities. But I think it’s also important to mention that the promise of HTML5 is relevant to a lot more than just digital ads.

I believe that the use cases for authoring content with HTML5 are going to continue to expand. Just look at its short history so far: first it was used for web pages, then web apps, digital video like YouTube and Netflix, and now digital ads. Next, I believe HTML5 is going to be used for many other forms of expression like email, digital signage, native apps, augmented reality, virtual reality, real-time on-screen graphics, messaging, gaming, artwork, and the list goes on.

HTML5 already has the components and architecture to support expression and content creation across all of those channels. And there are already numerous examples of each, so we just need to continue developing the tools and technologies that empower content authors to express themselves across all of those channels, using HTML5. And we have an unprecedented opportunity in front of us. I ask you: What other single authoring medium has ever made so many, so capable, of expressing themselves so flexibly, across such a vast range of communications channels? And for the foreseeable future, what other medium ever will? Maybe HTML6, someday? I don’t know.

But if we want to get to that point, we all need to embrace HTML5 today, and we need to continue the work that will unlock its full potential. And as I look toward the future, I’m pretty confident that we will do just that.

So thank you all for your time today. I really hope that this presentation was informative and helpful. I want to encourage you, feel free to reach out to me directly on Twitter at @theoskye. And while you’re there, also follow @monotype to stay abreast of the progress we’re making to empower the HTML5 authoring ecosystem. Stick around for a brief demo from Tumult and we’ll look forward to hearing your questions in the Q&A session immediately following that.

So Shelly, I’ll pass the mic back to you. Thanks everyone!


Yep. That was great Theo! Thanks!

There was a decided decrease in the questions as you were talking about the ad tools. Everybody obviously was very zoned in on what you were saying there. But we’ve got lots of great questions already in the queue, so I’m quite excited about that.

So, before we move on to that, we’re going to talk about this demo. Now, as Theo just showed you, there are a number of tools already available that are devoted solely to designing these HTML5 ads. But we thought it would be helpful for you to see one of those tools in action—just to give you a feel for how easy they are for visual designers who don’t code to use.

So let me introduce to you Jonathan Deutsch. So, Jonathan is the founder and CEO of Tumult, and he’s joining us today from San Francisco. And he’s going to give us all a peek inside of their design tool called Hype. So are you ready for me to hand over to you Jonathan?


Okay, so yeah, I’m really happy to be here! The main thing I wanted to show was how easy it was to make HTML5 ads.

Theo had a slide up that said ‘hand-coding is difficult’ and I kind of found that out the hard way. Over five years ago I wanted to build a photo album website with a bunch of animated transitions. I started looking into HTML5 and I realized there were just no tools to help me do it. So I started hand-coding and I realized I needed to make a tool. And so that’s where Hype came from.

And back then there were no tools like there were to do Flash for HTML5. So this is really trying to solve the problem of getting content onto the iPhone and iPad. But nowadays that content needs to go across all browsers, with the incoming death of Flash.

So Hype’s been around for quite a while. As Theo said, we’re around version 3.5 so we’re pretty mature, and we’re used in a lot of different domains. But recently we’ve been getting a lot of inbound interest in building ads with Hype, so I thought this would be a good example to show.

So why don’t I just dive right into the product. The product’s very familiar if you’ve used Flash, but especially if you’ve used tools with timelines such as AfterEffects, or FinalCut. But really, it has anything you might expect from a typical design tool. So let’s go ahead and build an ad. And this is going to be an ad showing boots for sale. It’s a pretty simple ad, but I wanted to show how easy and quickly you can do it.

I’ve passed some presets that you can use to set the canvas size. So we’ll do just a vertical rectangle image. And you can, of course, import any assets that you want. So, we’ll do a couple of boots in here. And of course you can move things to back and front if you want—so pretty much everything you would expect from a typical design tool. And so, I’ll go ahead and do some layout of my shoes. We change the background color of the ad, and of course text can be added as well. So I’ll add some text; I’ll call it ‘Leather Sale’.

And as was mentioned, we integrate with Monotype fonts, so if we want to change this to be something a little less boring, and maybe more stylistically appropriate to our leather sale, we could choose a font from the library. We’ll go ahead and choose this one.

Selected this, make it a little bigger. So we’re starting to put the layout together, and of course, with any ad, we might want a call-to-action. We’ll go ahead and create a button—set it as ‘Buy now!’ Also, we’ll change this to the font and do some styling on this button, set the text color and the background of the button, maybe change the border-radius a little bit.

And with a button, we can actually choose different styling for different states pretty easily, so this doesn’t need to be coded. Maybe on the hover over we’ll lighten up a little bit, and on the press state maybe we’ll darken the button. Creating interaction is very easy. We can just go to the ‘Action Panel’, and there’s various actions that you can do. The most simple one is just ‘on mouse click’. There are a lot of actions that you can do to help drive the animations system. In this case I’m just going to say ‘go to URL’. And this would be our exit event of the ad.

So, one thing I’ll note about the environment in Hype, is that the environment itself is HTML. So, if we were to select a certain amount of text, we can see the HTML behind it. So we can make this text bold, for example, and you can see, just like with HTML, it adds the bold tag (<b></b>). I stomped around.

Or, if we wanted, we could actually hand-code in here, and you can see the live updates. That now, that’s italic. I don’t really like that styling, though.

And of course, when you preview in a browser, what you see in Hype is exactly what you’ll get in the browser, since we’re using all web technologies. And this text using the font, is, of course, selectable and accessible. And we can click the button. That doesn’t go anywhere, but that’s what it would be.

Hype’s really, mostly about animations and interactivity. So Hype uses a keyframe animation system. So, let’s say we wanted the ‘leather sale’ to fade in as part of the ad. We can set the opacity down to 0, add a keyframe, and add another keyframe, and set that to 100%. And this will automatically perform the in-between transitions for you, so you’ll get a smooth fade-in.

But really Hype is about making animations as easy as possible. And so, hitting every single little keyframe button, we thought was kind of a difficult way to work, so we introduced a record button. [Mobile rings in background] Sorry about that. And so, we can select a bunch of different objects, move them to the start position, and now what we can do is actually hit record, and this will automatically generate keyframes for the movement. So now, just like that, we can see what the animation looks like.

That’s not the most attractive animation in the world, so maybe what I’d like to do is stagger coming in a little bit and have the opacity come in later for the text. So now I can preview what that might look like. That looks a little bit better.

One thing that’s probably hard in a screen-sharing session is to see the animation at 60 frames/second, which this is animating at. But if you’ll notice, the animations by default used an ‘ease-in-and-out’ effect, which doesn’t really look like the shoes are dropping. So I could do a different timing function. This is one of the more advanced bits of functionality in Hype.

If I wanted, the shoes could theoretically drop in, or bounce in. And so, we can see what that looks like. That’s maybe not quite so realistic. So I could change it maybe just to a simple ease-in curve if I wanted there. And just like that, the ad builds in.

So now I’m pretty happy with the ad. I think it’s animated. It kind of shows what I want. In Hype, you can export pretty easily. The export is an HTML5 folder, and this will first, if you’re using Monotype fonts, set up all the licensing. You may have to log in with your Monotype credentials if it’s a paid-for font. But now I get the option to export as HTML5.And that wrote out the HTML page to the desktop, and also created a folder of resources.

So, I just wanted to show the anatomy of the HTML really quickly. It’s pretty simple for the most part. You only need to drag and drop three lines of code, so that’s similar to a ‘Flash embed’, and then move around this folder of resources if you so desire. So it’s pretty get going.

But also, if you’re doing more complex ads, let me bring up another version of this. So this is a more complex shoe ad, and I’ll just show you the completed ad. This ad has a little bit more animations. It’s also a responsive ad, so if you resize the page, it can also change its size and reanimate.

We have another option that’s pretty geared towards the advertising community, which is an advanced export.  And here we have different layouts for different sizes. So theoretically you could choose to set each export as one of the layouts, and then upload those all separately if your ad server only wants separate sizes. And there’s other options, such as supporting Internet Explorer 6–9, which you can disable to reduce some of the file size if you’re not going to display ads on those browsers—things of that nature.

One other thing I’ll mention is that Hype has a system of plug-ins that can work with different ad servers. So, for those of you using Sizmek, Sizmek has some instructions on how to use Hype to create ads, and they also produced a plug-in that can be downloaded. That plugin will show up in the export menu, so you can export to a Sizmek workspace file, which will produce a .zip, which can then be uploaded. So Hype’s pretty flexible as far as export formats for advertising.

So that’s pretty much Hype in a nutshell. Hype’s a pretty advanced piece of software, so I only covered some of the basics. And there are some really fun things you can do with it. It has physics-based animations system. So that’s all animating even without keyframes. That’s basically setting physical properties on objects. There’s a lot of fun you can have with it. For the most part, the goal of Hype is to deal with the problems of HTML5 so you don’t have to. That includes browser compatibility, animation performance best practices, keeping file sizes low. Hopefully that’s a tool that can be in your toolkit and help you produce ads. If you want to learn more, you can always just go to the Tumult Hype website. We have a trial available. And yeah, I think that’s Hype!


So thank you very much for your time, audience. Thank you very much, Theo, for all the work in putting together that presentation. It was excellent and I know it was really informative. Jonathan, for doing that demo for us and giving everybody an idea of just how intuitive some of these HTML5 authoring tools can be for visual designers. That’s all from all of us. And I hope you guys have a great evening, morning or night wherever you are. And maybe we’ll see you at the next webinar. Thanks very much!