I’ve been a Freelance Dev, and developing banners since 1998. I decided to write this guide to help non-Developers and people new to managing and designing banners understand it all a little better. It is not about design – It is banner development from the Developers perspective, but not for the Developer. In other words, I try to keep code explanations and dev techniques to a minimum, and just stick to subjects that concern the other people in the process.
Sometimes banner Developers may be seen as the people who just say “No” all the time when they are asked to animate something in a certain way, but I think that comes somewhat from a lack of understanding of what banners are capable of – Developers get stuck in between trying not to dumb down the creative vision, but also making sure it will actually work. There are of course some Devs out there who just don’t want to get stuck doing banners, and they become unjustly overly negative. But we’re going to pretend those guys don’t exist for the moment. I actually really like banner development, and by reading below, hopefully you will gain a better understanding of what banners are capable of, and what they are not capable of, so you can take care of the reg flags before the Developer even gets a chance to see it.
Here are the topics I will be covering:
Banner Basics
Specs
Click Tags
Process
PSDs and Design Considerations
Rich Media
I will be updating this guide whenever I think of new items. Comments and critiques welcome. Please don’t take everything said here as stone cold rules, as all projects can have differences – it’s just the experience I have picked up over the years.
BANNER BASICS
In Canada, banners typically come in 3 main sizes: Big Box (300 pixels across x 250 pixels high), Leaderboards (728×90), and Skyscrapers (160×600). There are quite a few others as well, but these three are by far the most common, and most banner campaigns will include the same creative adjusted to each of these sizes. 300×600 Super Skyscrapers (also called Double Big Boxes and a few other names) are also common. Mobile sizes typically include 300×50, 320×50 and 320×100 sizes. IAB specs were updated in 2017 to remove these sizes and use rations instead (such as 1:1, 1:4, etc), but even now these are not yet widely used.
There are two basic types of banners: Standard and Rich Media. Developing a Standard Banner just means that the overall file size needs to be quite small – usually under 100k. This greatly limits what can be done, because 100k is a very tiny file (Although its still more than twice the amount that was allowed during the 40k Flash days, it is not actually much more because HTML5 banners now need to accommodate more code files). Mobile banners sometimes have an even smaller requirement of 50k, meaning a lot of times client decides just to do an animated GIF instead of coded HTML5 banner.
Rich Media banners allow for a lot more file size, and therefore have the opportunity to contain a much richer (for lack of a better word) user experience by including things like higher rez images, expanding panels and video (more on this later).
Banner ads are usually hosted by an Ad Server (such as DoubleClick Studio, DCM, Sizmek, or Eye Return) which holds the banner on their internal servers and then broadcasts it to the websites that are displaying the ad. Which one being used is determined by the Media Company that did the campaign buy. Sometimes people will claim the host is the Media Company itself, but this is not the case. This usually just means the Media Company is uploading to a server themselves – usually DCM (DoubleClick Manager). It’s important for the PM to find out which server is being used, because the way it needs to be developed will be determined by what company is hosting it. For Standard Banners, if the Media Company is being particularly difficult in communicating this information (In all honesty, probably because they don’t understand the question. This, sadly, is not uncommon), the developer can use DCM specs, as this is by far the most common and works across several other platforms.
It’s also helpful to find out the banner specs (see below) for each individual site the banner will be displayed on. Each site sometimes has slightly different requirements, so the team will need to figure out the LCD (Lowest Common Denominator) in order to determine which specs will be suitable across all sites. Sometimes that is not possible, and multiple banner versions will need to be created. The most common differences are usually length of banner animation allowed, and file size limits.
From a PM and Media Company point of view, a banner consists of two files. A ZIP file containing all the code and images the banner uses, and a backup JPG or GIF file.
The ZIP file is the banner itself, and does not need to be unzipped – it can simply be forwarded along to the Media Company. The file size off the banner is determined by the size of this ZIP file. Some ZIP compression tools are better than others, so it’s important not to un-zip and then re-zip the file when being sent to the Media Company, as that could change the file size and even add invisible files to the ZIP which Media Companies sometimes claim cause an error in their system. DCM, in the early days of HTML5 banners, was notorious for this, and would send stuff back all the time. If this happens, get your developer to check all invisible files from within the ZIP and remove them. One tool in particular which has serious issues with DCM is DropStuff for Mac, which adds invisible files to the zip which are not viewable on a mac, even with invisible files set to visible. If you wish to view the banner from your desktop, you can un-zip the file, and double click the index.html file. This will open the banner in your default browser. Just be sure to keep the original ZIP file to send along to the Media Company.
The backup image is what the user will see if they cannot see the HTML5 banner for some reason. This image was much more important in the Flash banner days when many people did not have Flash installed on their system, or were using mobile devices which did not support Flash at all. With HTML5, it is much less important. Unless the user is using an extremely old browser, or has javascript turned off (which would cause most of the web to not work as well), very very few people will see this image. But it is still a requirement to have. The code to determine which of the banner or the backup image is seen is part of the Ad Server’s system. With most Ad Servers, the Media Company has the ability to adjust which circumstances will switch to the backup image, but this is rarely needed as the default settings are usually fine. Many Media Companies don’t know about this setting, so it’s best to leave it alone unless your banners have a very specific browser target.
Speaking of browser targets, these days HTML5 banners should be programmed to work with modern browsers. Which basically means IE10, and the latest versions of Firefox, Safari, Chrome and Edge. IE9 is generally not targeted anymore unless it’s a government, or sometimes pharma, banner. Mobile browsers should also work, but it’s not always necessary to test for it unless your buy will be shown on mobile devices, which is not always the case. It is not necessary for the developer to use their own code to see which browser is being used in order to show the backup image if required, because that is done by the Ad Server. The exception is if a banner is using a feature that is only available on certain modern browsers, and must fall back to a less complex option if that feature is not available. My recommendation, though, is not to do that. Better to find a way that is available across all browsers than to dumb down the experience for a section of users. Some non-banner developers I’m sure would disagree, and love to constantly push the envelope. But my opinion is that a banner is not the place to do that if it involves cutting out users (The exception, of course, being old browsers outside of the usual target matrix).
SPECS
Before starting to design or develop an ad, both the Designer and Developer need to know what the specs are. The PM should contact the Media Company to get a list of each site’s individual specs, and the name of the Ad Server and its contact person. There are several pieces of information that they need to find out:
File Size – How big is the banner allowed to be? For Standard Banners, this usually means under 100k. For Rich Media, this usually means 2.2 megs, which allows for a lot more creative (Rich Media specs sometimes call for the banner to be 100k initially with a polite load of 2.2 megs. This is was easy to determine in Flash, but much more of a grey area in HTML5. Because only one file – called the index file – is loaded first, it can be argued that anything after that is politely loaded). The primary item contributing to file size problems are the images in the banner. The Developer can control how big they are, to an extent, by controlling the quality and file type – Better quality means higher file size. There’s a lot more to it than that though – more to come later on this subject.
Dimensions – Usually comes in the previously mentioned Big Box, Leaderboard, or Skyscraper formats, but may also be another size, or include dimensions for an expandable panel. A common mistake is for Designers to setup Skyscrapers as 120×600 instead of 160×600. 120×600 is another valid size, but not nearly as popular. (IAB specs now use responsive sizes, though not really used yet. More on this later )
Max Animation Time – This is the amount of time the banner is allowed to animate before it must stop completely until the user interacts. This is usually 30 or 15 seconds. This time will include any potential looping, but does not include replay buttons or other user interaction. In addition, the spec may also include the amount of time an expandable ad is allowed to stay open before automatically closing if it has automatically opened without user interaction. Also, some specs require that any animation stop immediately if the user clicks out of the banner. YouTube Mastheads, for example, require this.
Click Tag Code Direction – This is the way that the banner knows what URL the user will click to. I will get into more detail on this later.
Video and Other Required Controls – These specs will give you any required user controls. Examples include a close button for expandable banners (which often require 16 point Arial “Close X”, but not always), play/pause buttons for videos, on/off buttons for sound, etc.
Backup Image Size – Max size is usually 40k, but should be confirmed. Size requirement is usually larger for bigger banner sizes such as 300×600 or 970×250.
Border Colour – Usually Black or White, but more importantly, contrasting between the site and banner. So that can include shades of grey. Pay special attention to this spec when doing things like Rich Media Expandables and Interstitials. The design team may want to remove the borders all together to have the creative float freely above the site content. This is not always allowed – make sure to check with the site.
Javascript Libraries Policy – This one will not be one that a typical Media Company will usually be able to answer, and in my experience, it’s actually better to just avoid the question. But it’s still important to understand in case the developer wants to know for sure. HTML5 banners use Javascript libraries in order to run (JQuery, Greensock / TweenLite, etc). These are essentially code files that someone else has written in order to make animation a lot easier. Some are bigger than others, but no matter which one the developer prefers, they take up file size. There are two ways of loading these files. The first is have a copy of them in the ZIP file that is sent to the Media Company. The second is to have a call from within your banner that loads it from an external location. Loading it from an external location means that you don’t take up valuable file size from within your ZIP file. If you use common URLs to load these, it also has the advantage of being cached within the users browser. In other words, the more banners that use these public files, the faster it will load for the next banner because the browser will have already loaded it. The problem is that this is a bit of a grey area in terms of file size. Technically you are loading in that file size, so it should be included in your total banner size. But because it’s not part of the ZIP, it’s hard to detect. Usually if you ask Media Companies, they will either not understand the question, or will say that the file size needs to be included. But Media Companies and Ad Servers typically don’t check this. And many Ad Servers, such as DCM, encourage it because of the caching benefit. In other words, to be safe, the dev should include the libraries in the ZIP file. But if they need the file size, it’s probably ok to load it externally.
Many times, sites will use what is called IAB Specs as its technical development guide. IAB specifications are setup to try to have a uniform standard of tech specs across Canada. The hosting site will usually send a PDF copy of these, or quote them when specs are requested. Be aware that although these specs mention almost everything a developer needs, they do not contain any information about code or Click Tags.
One important note on IAB: The new specs released in 2017 uses new responsive sizes as opposed to the classic 300×250, 160×600, 728×90 sizes, however these are not widely used yet, and and whenever a media company quotes IAB specs, it can usually be assumed they mean the old IAB specs. Though ask if you want to be safe.
Other times, Media Companies will send along spec sheets which turn out to need a little TLA. They contain outdated Flash specs (A tell-tale sign is if they include a spec called Frame Rate, or Actionscript version, which are both Flash-only specs when it comes to banners, though video does have a Frame Rate spec sometimes), or don’t mention something that you need to know. Best to ask for clarification if you can.
The most important things that need to be known are:
File Size
Max Animation Time
Click Tag Code Direction
All three can be guessed based on IAB or just the most common things done. But best practice is to find out for sure.
CLICK TAGS
As said before, the Click Tag is a piece of code (not to be confused with the URL itself, which can also be referred to as a click tag) which lets the banner know what URL the user will be directed to when clicked. The URL should never be hard coded into the banner itself. For Standard Banners, the Developer does not even need to know what the target URL is – they will use Click Tag code, which the site or Ad Server will then use to dynamically push the URL to the banner. That way, the PM just sends the hosting site the URL, and they then have complete control over where the banner goes without involving a Developer. For Rich Media banners, it’s a bit different if the Dev is setting up the campaign. They still will use Click Tags, but they will need to know the ultimate URL destination to put it into the campaign project control panel.
It’s important for Project Managers to understand what the specific Click Tag code is, because there are several different kinds, and the Developer will need to know which is required. The most common is the following two lines of code, which the developer will know how to use:
var clickTag = “http://www.google.ca”;
window.open(window.clickTag);
The addition of Google.ca in there is just a placeholder, and will be removed by the Ad Server.
There are online tools available if you want to do a quick test to see if the banners are set up correctly (For example, DCM has an online HTML5 validator here. Other servers may have their own services). You simply upload the ZIP file, and it gives you any errors or warnings.
PROCESS
The Development process from a Developer’s viewpoint for banners usually works something like this:
1) First, a brief to the design team, who may or may not want to involve the Developer at this point. Usually it’s not needed for simple Standard Banners, but it’s a good idea for Rich banners. At the very least, the Designer should know what the tech spec limitations are.
2) Creative concepts should be quickly shown to the Developer before shown to client just to make sure there are no reg flags from a production standpoint. The most common issue is that the Developer might see is that the concept will not fit within a 100k ZIP file. The last thing the design team wants is to have to go back to the client to say “Sorry, we can’t do what we promised.”
3) Once concepts are decided on, and layouts are completed and approved, a package of assets is sent to the Developer, and the Designer will give a brief to the Developer. This will include their thoughts on animations and overall flow (A PDF storyboard is excellent if possible). The PM should also let the Developer know the workback schedule, and of any tracking desired if it is a Rich Media banner. Try to make sure the banner design is final. Adding or removing items after dev has started can sometimes take more time than starting from scratch (although minor text changes are usually not a problem). The most common thing the creative and account team like to add after dev is finished is a replay button. This is usually simple but sometimes a challenge, so best to mention it up front.
4) If the campaign includes multiple banner sizes, the Developer will usually start with developing the Big Box as it is the most common size and gives a good idea as to what file size will be like across other sizes.
5) Once the Big Box is approved internally, other sizes are developed. In an ideal world, the client would have also approved the Big Box animation before other sizes are developed to confirm they are happy with the overall flow, style and timing, but that is not always an available option. But it’s awesome when the PM pushes for this.
6) Once English is approved for all sizes, French and any other language adaptations can happen. It is not a good idea to do other languages before English is approved because any changes from the client would then take double the amount of time. French adaptation can either be done by the Designer with new PSDs, or by the Developer directly in the code depending on the Designer’s comfort level with the Developer’s layout skills, and also available time and budget.
7) Once all is approved, the Developer will name the files appropriately, zip it up, and send them to the PM (the PM can rename the ZIP file if they would like, but it’s very important that they do not rename any other files, otherwise the banner will not work. If there is a naming convention, better to get the developer to do this on their end). The PM can then forward this on to the Media Company or websites directly depending on the campaign requirements. In the case of Rich Media, usually the Developer will have already uploaded the files to the Ad Server’s hosting site, so this package will be for internal backup purposes only.
8) If it is a Rich Media banner, the next step may involve sending the banner to the Ad Server’s QA (Quality Assurance) system. The Ad Server will then take around 24 hours to a 48 hours to test the banner for any possible issues. If there are any required changes, they must be done before the Ad Server will approve the banner.
PSD AND DESIGN CONSIDERATIONS
I won’t get into how to design a banner, or the strategy here. I’ll leave that up to the creative experts. However, I do have suggestions on how to setup the PSD file, some things to watch out for when designing that may cause issues later on, and some common things to forget when in the process of designing.
File size
A great skill a Designer can learn when designing for banner ads is how to estimate file size. For Rich Media this is not so important because of the extra space available. But when designing for a Standard Banner, learning what makes files big is very important.
Images are the main source of Standard Banner file size. Essentially, the larger and more complicated the image, the larger the file size. Each image that needs to be animated will be separated into individual files from the PSD by the Developer, usually as PNG or JPG files. The PNG format is a non-compressed image format so it gives the best image quality. But it is also a very large file. JPGs allow for a lot smaller file sizes, and the quality of the JPG depends on the compression settings. In the example below, the baby on the right has a lot more compression, and is therefore a much smaller image. But obviously the quality is much worse (Just as an FYI, the image on the left would be about 20k, and the image on the right would be about 5k).
PNGs, along with higher image quality, also allow for many Alpha (transparency) channels, so things like hair, shadows or smoke (anything that is transparent or only slightly transparent) would be possible to animate across different backgrounds. This is an area which can cause huge file size issues in images. Areas that are only slightly transparent, or items that have complex transparent edges, are especially large. Try to keep them to a minimum.
It might be hard to tell which items will need to use Alpha channels and which can just be flattened with the image behind them, but keep your eye out for items that will be moving or have their background change. Especially watch out for moving images that also have shadows, blurs, and complicated small items like hair or sand. The example on the right shows the same image that would have very different file sizes. Assuming that the lime would be moving and the background would be static, the top lime would be the smaller image because it’s on a plain white background and the PNG can just be flattened with the white background behind it. The bottom lime would be much larger because it would have to be close cropped, and the bubbles would need to have many different levels of transparency in order to see the background behind it. For shadows, try to keep them as separate layers so that the Developer has the option to compress them at different levels.
Photographs can be a hard thing to judge how big they are because it greatly depends on the content of the photo. Many different colours and shadows can be much bigger than just flat colours. A photo a brick wall will be much bigger than a photo of a flat white plaster wall.
The question that is always asked – Can we increase the quality of that image? The answer is usually yes, but we need to take quality away from somewhere else.
Keep your eye out for blend modes in PSDs, which do not transfer well to native HTML5. A good test of if it will transfer well would be to select all the layers used to create the image, and make a smart object out of it. If it looks the same, you’re good. If it changes, the Developer will probably have issues and may request a PSD change.
SVG files are an alternative to the more common JPG and PNG formats. While JPGs and PNGs use are bitmap based, SVG is vector, which allows for an object to be scaled without losing image quality. These are more typically used for simple illustrations and logos (Think Nike logo) because complicated vectors can be quite a bit larger than PNGs. It’s a good idea to keep your vector items in the PSD as smart objects, so the Developer has the option of using it as vector, or exporting it as a PNG. Talk to your developer about the advantages and limitations of using an SVG.
Pay attention to any zooming photos. Many times Designers would like to start off on a zoomed piece of an item, such as an eye on a persons face, and then zoom out to reveal the full item. While this is a nice concept, remember that if an image is nice and crisp and clear on the zoomed version of the specific item, the entire image – even the parts of it that are off screen – will need to be high rez as well. This can lead to a very large image.
If possible, keep backgrounds as flat colours, or simple radial or linear gradients that can be re-created in HTML5. This can save 2 or 3k in file size. Remember that the HTML gradient control is simplified compared to Illustrator’s, and does not have any gradient warping capability.
The final thing to keep in mind is whether to prepare the PSD at a normal resolution or at retina size. Whether to use retina sized images or not is something that can be discussed as a team. They cost double the file size, but are also quite a bit more crisp and clear both on mobile and desktop screens. In my opinion, it’s a good idea to prepare for retina sized images no matter what, so the developer can choose to use them if they want. This basically means designing a 300×250 banner at 600×300. Just double the intended resolution.
Complex Animations
Keep in mind that anything other than a slide in, zoom in, or fade in, will likely require extra file size and, sometimes, an animator. Things that were relatively easy in Flash, such as emulating handwriting, shape manipulation, or even what seems like a simple mask-in, are much more difficult in HTML5 and usually require it being done in a movie clip, or whats called a sprite sheet. A sprite sheet is basically all the frames of a movie within one image file and within code, you mask and then move the image from position to position very quickly to simulate a movie clip. Both of these methods require file size, and an animator to create them. Sometimes special javascript libraries can handle desired animations (vector morphing, for example), but again that takes file size and special animation/coding skills to implement.
Fonts
Fonts are a complex subject. In Flash, all the developer needed to do was have the font on their machine, and the letter glyphs needed were exported into the SWF file. So any font the designer wanted could be used as live, editable text. With HTML, any font that is not commonly available on every users machine needs to be specifically loaded in, and there are several issues with this practice. The first is finding the file itself. Fonts are available in several file formats, but only a few are compatible with loading into a browser. Once you find the file, and you decide whether to load it in externally or keep it within the ZIP (fonts can be rather large), you need to consider licensing issues. This is not something most agencies consider, but making a purchased font available over the internet is not really ethical and can make a client look bad if anyone ever looked into it. Using a Google Font is a good alternative, but the font the designer needs is rarely there, and they are usually stuck with finding the ‘next closest thing’. Another thing to consider with live fonts is that re-creating layouts with a live font within HTML means that no matter how talented the developer, it will never look exactly the same as the PSD. This is due to minor differences between how browsers handle fonts, which ever so slightly change size, kerning, letting and aliasing. It can come close, but won’t look perfect. For many banners with simple text, this is not a problem. But it is something to consider, especially when the are are several words, prices, legal symbols, or percentage signs all needing to be at different heights and sizes and lined up equally on the left and right side. QA issues are usually quite a bit more complicated because of this – The banner looks wonderful on all browsers except one random version, which bumps the last line of text down to another line, causing all sorts of headaches.
The benefits of live fonts are that, if loaded externally, take up no ZIP space as image text would (especially if retina sized images are used to match live font crispness), and they are easily editable. For banners that live beyond a few weeks in new versions, or will be changed frequently, this is a big advantage in that a designer does not need to update a PSD every time a interest rate or date changes. Live fonts are also much more compatible with dynamic content, which can change text on the fly based on pre-determined circumstances such as local weather, or time of day.
This debate is rather heated among developers and designers, and what you use in your banner will likely depend on which side puts up the best argument in the brief.
I personally prefer images. It makes it look exactly as the designer wants, causes no QA headaches, allows for any font and any style applied to that font, and is very fast to put together a complex text layout. The only time I will willingly submit to live text is for dynamic content. But again, this is personal preference, and more traditional site developers will likely disagree with me.
Other things to keep in mind
Layer comps for each frame are very important. They make sure there is no misunderstanding between Designer and Dev on how the Designer wants each frame to look, and avoid accidentally having unintended layers on or off. Best to name your comps something like: “Frame 1”, “Frame 1 transition”, “Frame 2”, “End Frame”, “Static Backup”, “CTA Rollover”, etc. Delete layer comps not being used, such as old alternate endings to avoid confusion. As an alternative to Layer Comps, Folders that are named like this are also common, but can cause a bit of confusion if there are generic folders, such as “Logo” or “Global Items”, which are intended to be turned on and off depending on the frame. No matter which way you choose to do it, it’s very helpful to make sure that both ways are not done at the same time. Many times when folders are used, there will still be forgotten Layer Comps that will not show the ad as intended and cause confusion with the Developer on which to use.
Try to keep high rez bitmap smart objects as small as possible. The Developer will not typically need to re-size the items in the layout, unless the item will be zooming (in which case, careful of file size restrictions in the final output), and it can sometimes just cause extra time in downloading the source anytime there is a PSD change. It’s awesome when PSDs for Standard Banners are be between 2 and 20 megs. This is not a rule by any means – just a personal preference.
Another personal preference that I find very helpful is when the Designer sends a file that is the exact size of the banner, such as 300×250. Sometimes a Designer will send a PSD that has all frames laid out next to each other, like a storyboard for client presentation purposes. This makes it more of a challenge to create assets. Storyboards are great as a PDF to show what needs to be done to the client and dev, but it’s not really good for dev itself.
Make sure the PSD is up-to-date with the copy deck. The Developer will typically copy and paste the text directly from the PSD, or import the text from a PSD layer, so he/she can also get the HEX colour and font size at the same time. Conflicts between the PSD and Deck can cause confusion between what is the most recent version.
Common items forgotten in the design process include:
Button rollover states – Remember that each button can (but does not have to) have a different colour or animation when the user rolls over. A layer comp for each state is helpful.
Close button – All expandable and floating banners require it. By the book, is 16 point Arial “Close X” in the top right, but you can usually get away with other designs.
Borders – Black, white or grey, as long as they contrast with the banner content, and follow whatever the specs are. Colour is sometimes ok as long as it contrasts the site content.
Legal Button – Legal buttons don’t always fit nicely into a design after the fact. Try to find out if it’s needed before design starts, otherwise it might look out of place, or even cover an important piece of the design.
Backup Image – This is usually the last item done in the development process. Commonly it is done by either the Developer or Designer saving the last from of the PSD out as a JPG. But this can be problematic if the last frame contains buttons like: Legal (user cannot rollover to see legal in a static image), or Rollover to Expand (User cannot expand in a static image). Or if there is no last frame, such as the case where it’s a Rich Media banner and the user needs to expand to get any information or imagery of the product. A static image of this would not work at all. Make sure that has been thought out. It is a great idea to have a separate layer comp in your PSD to show what you would like the backup image to look like.
Another word on Backup images – They are commonly referred to as Backup GIFs. However. JPEGs are perfectly fine.
Animation on to the Screen – If you have an item that needs to animate on screen and then off, such as something that does a bounce animation on and then flies back to be half off the screen, remember that the Developer will need the entire image, not just the final cropped version of it.
Also, keep in mind when going through your designed frames, that while moving a product image up 5 pixels from frame to frame to accommodate more text looks ok on the storyboard, it looks off when an image slides up only 5 pixels during the animation. Try to keep image placements consistent.
Finally – Don’t forget to send Fonts with your PSD to the Developer.
RICH MEDIA
Rich Media banners have the potential to do many more things due to their flexibility with dimensions and file size. They do however, take longer to do, and usually require an Ad Server to be run through. They also can require submitting to the Ad Server’s QA process.
There are many different types, but here is a short explanation of the most common:
Polite Loads
This Rich Media term means that after the Standard 100k banner loads, the Developer can then load in additional file size. As mentioned before, what is part of the initial load, and what is part of the polite load in HTML5 is a bit of a grey area. In my experience, a polite load banner now just means the overall file size of the ZIP is 2.2 megs. Polite Load Banners allow for much more creative freedom than Standard Banners
Interstitials (Also known as TLAs, Vokens, and many other names)
These are banners that float overtop of the website’s content, and must be closed, either by the user or automatically, before the user can see the website content. Each site is very specific in what it will and will not allow, including the inclusion of borders, backgrounds, transparent items, and the amount of time the banner is allowed to stay open before an auto close is required. It’s important to note these restrictions on a per-site basis. Usually you have a bit more file size than the standard 100k, but it’s a case-by-case basis.
Expandables
These are banners that start off looking like a Standard Banner (usually a Big Box, Leaderboard or Skyscraper). Then, on user rollover or click, the banner expands to a bigger size. The size of the expanded portion is usually 600×300 for a Big Box, 728×360 or 728×315 for a Leaderboard, and 300×600 or 600×600 for a Skyscraper. A key element that needs to be remembered for Expandables is that if it expands on click, it can close when the user clicks the Close button. In other words, it stays open until the user explicitly closes it. But if it expands on user rollover, it needs to collapse on user roll off. This means there will be more expansion impressions from the campaign because its easier to expand. But it also means that if the user is doing something interactive in the banner, such as selecting different videos to watch or playing a game, rolling off the banner is quite easy, and it may collapse when the user is not expecting it to. Which way expansion occurs is up to the team to decide. Expanding banners always require a close button in the top right regardless of if it is rolloff or click to close.
Clients a lot of the time ask for a banner to expand on rollover, but also have a CTA button on the collapsed portion for the user to click to go to a website. This is problematic because once the user rolls over, the banner is expanded – the mouse will never be able to reach the button on the collapsed portion. Make sure to pay attention to any conflicting user actions like this.
When designing Expandables, make sure to decide what happens to the collapsed portion if the user does not interact. A common technique would be to land on a screen that says something like “Expand to see!”, then wait a few seconds. If the user does not interact, continue the banner to reach the end frame. All of this has to occur within the animation time limit (usually 30 seconds). It’s up to the team to decide if the user can still expand the banner from the end frame, although sometimes that doesn’t fit within the creative for whatever reason.
Make sure to decide what happens when the user closes the banner. Will it revert to the end frame of the collapsed portion? Does the Ad Server even allow for the collapsed portion to do something specific when the expansion is closed, or does it have to live in a separate world? Your Developer should know, but may need to speak to the Ad Server contact to confirm.
If the expansion automatically happens before user interaction, there is usually a limit of 7-10 seconds before the banner has to automatically retract. That’s not as much time as it sounds, so plan animations accordingly. The number of times a banner Auto-Expands per day, per user, is controlled by the Ad Server, not by the banner code. So if this is required, speak to your Ad Server contact about how the team would like this to work.
Video
Rich Media banners commonly use video. Several things to keep in mind.
Sound cannot occur unless there has been some sort of user click. Which means the video needs to starts paused and the user has to click to play, or the video needs to start without sound and the user clicks “Restart with sound” or something similar. Another option would be if the video is in the expanded portion of an Expandable, the click to expand the banner would count as user interaction, so sound could be played automatically on expansion. However, this is not the case if it is a rollover to expand banner as a click would not have occurred.
Video also requires play/pause buttons, and sound on/off buttons. Sometimes a scrubber bar to show how long the video is, is recommended by the site (although I do not recommend this for videos less than 15 seconds). There is a bit of a grey area for these controls. Sometimes a video is used, for example, to show a car rotating that lasts only a few seconds. Although technically a video, you should be able to get away with not having player controls.
How to get video into HTML5 banners offers a few more options than Flash did.
The most common way is to use YouTube video. YouTube file size is not included in the overall file size, so you can get away with playing a lot of video content. YouTube also includes it’s own robust set of video controls, full screen options, and all sorts of tracking. However, it does stick a YouTube Logo in your banner.
Native HTML5 video is the other option, and was one of the big catalysts in the death of Flash. It controls are more customizable, and it is much better for using if the video is for animation purposes, not, for example, watching a commercial. The disadvantage is that because you need to include it in the ZIP file, file size is an issue. Plus, because browsers still have not agreed on which file format is best, the developer should include at least two different video file formats that show the same video. This means that your file size for that video is double (some devs agree they can get away with one file format, but if you want to be safe, at least two are needed). Some Ad Servers view video file size separately than the rest of the banner, but that is not as common and needs to be confirmed before determining which method of video code your developer decides to use.
Other Units
Ad Servers are always coming up with different ways to display ads. Keep your eye on new developments and see what your creative team can do with them!
Other notes
Other items to pay attention to for Rich Media banners:
- Sites that do not allow emulating cursors
- Sites that do not allow you to simulate anything on their site, such as colours or articles
- Sites that do not allow live data feeds, such as Twitter feeds (YouTube for example, does not allow this)
- Sites that do not allow anything loaded from an external server (such as database information)
Ad Servers
There are many possible Ad Servers out there. Most require the PM or Account person to setup a campaign on the Ad Server’s system before dev starts. How this is done might require some training in their particular method, so speak to your Ad Server rep to find out.
One note is that people commonly confuse DCM and DCS. DCM is DoubleClick Manager, and is used my the Media Company to upload Standard Banners to. DCS is the system in which a developer uploads Rich Media banners to. DCM accounts are usually held by the Media Companies. DCS accounts are usually held by the developer or ad agency, and the Media Company is then CC’d when QA is approved, which will then give them access to the traffic info they need.
SUMMARY
Well, that’s all for now. I’ll keep adding items when I think of them, and feedback is encouraged. Im interested to hear anyone else’s experience with banners, and what they had questions about or problems with.
I hope this has helped.
Kudos Brendyn, this is brilliant and well written. Thank you for sharing.
Glad you enjoyed it!