Update: Although Flash banners are now outdated, I will be keeping this article up until I have time to update it to include HTML5 banners.

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. Although the inspiration for doing this guide actually came from seeing a Designer lay out the best banner PSD I had ever seen, 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, 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, or stuck doing anything that might be a pain, and they become unjustly overly negative. But we’re going to pretend those guys don’t exist for now. I actually really like banner development, and by reading below, hopefully you will gain a better understanding of what banners are capable of and 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
Click Tags
PSDs and Design Considerations
Flash Dev Secrets
Rich Media
Ad Servers

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. 

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 other sizes 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.

Screencap and logo

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 40k. This greatly limits what can be done, because 40k is a very tiny file. I don’t know where that particular number originally came from, but I believe it stems from the days of slower internet speed when even 40k took a few seconds to load. Now 40k loads instantly, and it can be frustrating for both Designer and Developer to be limited to such a small size. But clever creative and dev can still allow for some great user experience. Hopefully this size increases someday, but I don’t anticipate it any time soon.

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 hosted by either an Ad Server (such as DoubleClick, Pointroll, Sizmek, or Eye Return) which holds the banner and then broadcasts it to the websites that are displaying the ad, or hosted by the website itself. Which one being used is determined by the media company that did the campaign buy. It’s important for the PM to note which, because the way it needs to be developed will be determined by who is hosting it. It’s also important to find out the banner specs (see below) for each individual site the banner will be displayed on. Each site usually 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.

ScreencapBanners consists of at least three files created by the Developer. The FLA (sometimes called an XFL file) is the code file which is used for development, but cannot be used for deployment directly. If any edits on the banner need to be made in the future, this is the file that will be needed. From this file, the Developer exports a SWF, which is the file that will be used for deployment, and is really the end product of the project. Finally, an image file (JPG or GIF) is required. This will be the backup image the user will see if they do not have Flash installed. There can be multiple SWF and FLA files, plus other folders included in the final package, but there will always be at least one of each file mentioned. Sometimes, because looking at a SWF file directly may distort the way the banner looks, a Developer will also provide an HTML file for viewing purposes. When viewing this file instead of the SWF directly, the Developer can be sure the team will see it as intended. However, this file is not needed for deployment.

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 (if any) and its contact person. There are several pieces of information that they need to find out:

SIDE NOTE: Sites occasionally turn a blind eye to Standard Banners that are slightly over 40k, sometimes allowing as much as 45k. I personally like to play it safe and never go over 40.9k to avoid a possible pushback and therefore delay. But if file size is a big issue and images are looking terrible, the PM may opt to take the chance and give the Dev the go ahead to go over 40k slightly. Keep in mind that when looking at a SWF’s file size on a desktop, Mac and PCs round out the numbers. So even if a banner is actually 40.1k, your computer, might display it as 44k, or even 39k.

File Size – How big is the banner allowed to be? For Standard Banners, this usually means under 40k. For Rich Media, this usually means 40k initially, but then the banner can load in an additional 2.2 megs (Sometimes more, sometimes less, but 2.2 is the standard), which allows for a lot more creative. 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 – 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.

Frame Rate (FPS) – This is the number of frames per second the banner is allowed to have. Faster frame rates means smoother animations. Movies, for example, are usually 30 fps. The three typical sizes allowed for banners are 18, 24, and 30.

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 ad is allowed to stay open before automatically closing if it has automatically opened without user interaction.

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.

Flash Version – This is very important for the Developer – they need to know which Flash Version (usually 8, 9, or 10), and which version of Actionscript (AS2 or AS3) is allowed. Which version of the coding language Actionscript is the most important part of this, and will determine how it is coded. Switching between AS2 and AS3 is not an easy thing to do most of the time, so it’s important to set this in stone before staring to code. Developers usually prefer AS3 as it is the newer and more robust conding language. Typically, if the banner is being run through an Ad Server, AS3 is good. Standard Banners run through sites directly are usually AS2.

Click Tags – This is the way that the banner knows what URL the user will click to. I will get into more detail on this later.

Backup Image Size – All banners require a backup image to show the user if they do not have Flash installed. Max size is usually 40k, but should be confirmed.

Max CPU Percentage – This is not a commonly discussed spec, but basically means the amount of computer power the banner is allowed to take up while running. This will probably only ever come into force with Rich Media banners that are doing a lot of complicated animations and slow the computer down.

Border Colour – Usually Black or White, but more importantly, contrasting between the site and banner. So that can include shades of grey. Colour is also usually accepted as long as it contrasts the site content. Pay special attention to this spec when doing things like Rich Media Expandables and TLA / Vokens. 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 (more on this later).

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.

SIDE NOTE: If a site is saying to a PM that they will host a Rich Media banner directly, be suspicious. This is not common, and 9 times out 10, not true. Rich Media requires an Ad Server the majority of the time, and sometimes a media company will try to save money by skipping the ad server without realizing that it’s required. If the media contact at the hosting website cannot answer questions on where the Developer can find the API on how to close the banner, or answer if the Developer should set up an expandable as one, two or three SWFs, and they keep directing the PM back to IAB specs, that’s a big reg flag. IAB specs show things like file size and frame rate – they do not handle rich media code. Get the Developer involved in the email chain.

One last important note regarding this topic. When requesting specs for a Standard Banner, getting the above information or instructions to follow IAB should suffice. Rich Media banner specs are another story. Because Rich Media requires functionality that is more complex, each Ad Server writes its own code (or API) to handle these things. The Developer uses this API to do things like close an expandable banner, load video, load polite content, track user interaction, etc. The Developer will need to know which Ad Server is being used, and what their API is in order to code the banner properly. IAB Specs are not enough in this case. The Ad Server will have a web page dedicated to this which the Developer should be directed to.

As said before, the Click Tag is a piece of code 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 (The PM still does need to let the site know what the URL is). That way hosting site has 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 is, because there are many different kinds, and the Developer will need to know which is required. The most common is the following:

getURL(_root.clickTag, “_blank”);

Sometimes this will be documented in slightly different ways, such as:

getURL(_level0.clickTag, “_blank”);


     getURL(_root.clickTag, “_blank”);


on (release) {
     if (_root.clickTag.substr(0,5) == “http:”) {
          getURL(_root.clickTag, “_blank”);

All of the above, essentially do the same thing, and different versions of the banner are not required if multiple sites require any combination of these. The only important thing to pay attention to that would require a different version of the banner would be if the Click Tag was required to be the following:

getURL(_root.clickTAG, “_blank”);

Note the difference in the the capitalization: clickTag vs clickTAG. This is an important distinction. The clickTag version is the most common and used across most sites. However, clickTAG is used with Google, and sometimes Yahoo and MSN. Different banner versions will be required for each type required for the campaign in this case.

The part of the code above that says getURL is only done in Actionscript 2. In other words, if you see this phrase in the required Click Tag, you know it is AS2. Site specs that state this may also say that 3rd party Ad Servers are accepted. And if the Standard Banners are indeed being served through an Ad Server, this Click Tag spec can be ignored and the Developer can instead use the Ad Server’s Click Tag API, which will be different for every Ad Server and may allow AS3. Will get into Ad Server specifics a little later on.

AS3 click tags will look something more like this:

navigateToURL ( new URLRequest ( root.loaderInfo.parameters.clickTag ), ‘_blank’ );

But as a general rule, these are less common because if you are using AS3, it’s more likely to be a Rich Media banner, in which case we follow Ad Server code requirements.

One last note – because URLs are not normally given to Developers directly, when testing Standard Banners during development, usually the click through will not work (Rich Media Click Tags tested through the Ad Server’s system should still work however). That does not mean that the Click Tag is broken. It just means that the testing page the Developer has set up does not dynamically populate the URL as the site eventually will. There are online tools available if you want to do a quick test to see if the Click Tags are working in the SWFs. Please be aware that these validators may not work if the banner is setup for a particular Ad Server, and some validators may not recognize newer coding styles. Sometimes when submitting to sites directly, for example, the site will reject a correctly coded ad because the particular tool they are using is outdated. If this happens, there are two alternatives. The first is for the PM to ask the site to publish the banner to a testing server and confirm that it works directly. If the person is willing to do this, it should work just fine. If they are playing it by the book and will not allow it unless it passes the validator test, the Developer will have to go back into the banner and hack old code into new. This can be messy, and hopefully will not need to be done. Also make sure the Developer double checks to make sure there is indeed not a mistake in his/her code.

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 40k banner. 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 very hard, 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.

SIDE NOTE – Your browser has some temporary memory, called Cache, that stores items you view while browsing so that the next time you visit it, the browser won’t need to download it again – it will already be loaded and ready for viewing. This makes browsing the internet much faster. However, this can be problematic during the dev process because there is no easy way to tell if you are looking at the current version of the banner, or a cached version. If you are viewing a cached version, you will not see changes the Developer has made to the banner. You will need to clear your Cache in order to know for sure. Each browser does this in a different way. Ask your Dev for help if you are having trouble seeing changes made.

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.

SIDE NOTE – Sometimes it’s hard to check small details in Flash, such as if a dot in legal text is a comma or a period. If you right click on the banner, and then click Zoom In, you can confirm things like this. Be aware though, that when zoomed in, the creative may look slightly different (such as lines not matching up, or text shifted slightly). The final creative approval should be made on what the banner looks like when viewed at normal size.

7) Once all is approved, the Developer will name the files appropriately, package up all source and deployment files, and send it to the PM. 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 (more on this later), 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 anywhere from 24 hours to a week to test the banner for any possible issues. They are pretty thorough, so they will almost always come back with at least a few suggested changes, but those suggestions usually can be skipped with no problem and no difference to the user. If there are any required changes that must be done before the Ad Server will allow the banner, or if the team decides any of the suggested changes should be done, the Dev will make the appropriate revisions, and then re-submit to QA.

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 files. The PNG format is a non-compressed image format, so this allows the Developer to dynamically control compression (image quality) from Flash. The better the image quality of the image, the larger the file size. 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 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 import and animate. 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. There are tricks to get around using Alpha channels, such as masking directly in Flash or using a Darken layer to knock out a white background, but discuss this with your Developer to see what is possible on your particular project. Blurring is something that can be natively done in Flash without much file size increase, however keep in mind that Flash does not do zoom blurs or radial blurs natively. For shadows, try to keep them as separate layers so that the Developer has the option to try to re-create them as a blurred vectors in Flash.

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 overly complicated blend modes. Flash does have native use of things like Multiply, Darken, Lighten, etc. But what it does not do well is when these effects are combined on top of each other. Feel free to use one, but avoid multiple layers using different blend modes (common uses for this are to create certain colour combinations, or make shadows of objects without close cropping). A good test of if it will transfer into Flash 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.

Vector is commonly thought of as smaller than bitmaps and saviour for file size. While this is true in many cases of simple vector objects (think Nike logo), complicated vectors are actually quite a bit larger than bitmaps, and can sometimes actually cause the banner to slow and chop during animations. 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.

Fonts, once imported in Flash, can be used over and over again without increasing file size. There are a few tricks to this though. The first is that individual letters (glyphs) are imported only when specifically used in the design. So if you use Arial for a button that says “LEARN MORE”, it will only import 7 letter glyphs from Arial, which would only be a few hundred bytes. But if you suddenly then decide to include the entire paragraph of legal on the end frame of the banner, the entire font would then have to be imported. Your file size would go up to 3 or 4k. Keep in mind that lower and upper case letters are different glyphs, and that complicated fonts are heavier than simple fonts. Also keep in mind that bold, italic, compressed, and extended are all different fonts and will be imported separately. To save file size, try keep your fonts and font styles to a minimum. One trick is instead of always using Arial or Helvetica for legal, use a font that is already being used in the creative. Also, remember that French will take more file size due to extra font characters.

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. The trick to get around this is to have the zoomed item as a cropped high rez photo, and then the rest of it as a lower rez photo behind it, and then flash or blur between the two as it zooms out. Usually works out ok, but keep in mind it will not be super fluid.

As a general rule of thumb, the Skyscraper banner type usually ends up having the largest file size, and the Leaderboard usually ends up having the smallest. It’s good to note that when translating the design into different formats, as it’s a natural instinct to enlarge the images in the Skyscaper format to accommodate the unusual space the designer has available.

If possible, keep backgrounds as flat colours, or simple radial or linear gradients that can be re-created in Flash. This can save 2 or 3k in file size. Remember that Flash’s gradient control is very simplified compared to Illustrator’s, and does not have any gradient warping capability.

Think about the animation itself when designing – how to get from frame to frame, how each element will get on screen, and how much file size that will take. Common animation styles include fading, sliding, and zooming. These are the least heavy on file size. Custom detailed masking in, such as emulating handwriting, is much larger because it has to be done frame by frame. Blurring out and in, as long as the blurring is done via Flash’s native blurring tool, is not heavy on file size.
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 import into Flash, and match font sizes and image placements because it can’t be aligned perfectly to the edge of each frame. 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.

ScreencapA few things come into play with Flash and Photoshop font control differences. First are superscripted items. Flash’s native superscripting control is terrible, so things like superscripted legal marks have to be manually inserted as separate pieces of text. The final SWF superscripted items may not look exactly as they do in the PSD. Nothing that the Designer can do there, just a heads up. Next, the ALL CAPS option in the Character panel in Photoshop – When copy and pasting from a PSD to an FLA, this effect does not transfer over. So the Developer will have to re-do all your upper case letters. Not a huge deal, but typos can happen when this is done, especially if it is using a special font that uses upper case and lower case letters in unexpected positions. To avoid this, try to skip using this feature if possible. Finally, the anti-aliasing options in Photoshop do not match Flash’s anti-aliasing options. Keep this in mind when using these options in Photoshop to finesse your fonts as it will not transfer to Flash perfectly.

SIDE NOTE – Flash does have a more robust font control in newer versions called TLF. This is not commonly used in Flash banners because it adds a significant amount of file size. It also requires an external file called a .swz file, which can be a pain when using on Ad Servers.

Flash does not do partial font sizes well. Re-sizing a line of text in Photoshop might make the font size 12.56 or something like that. Flash devs will just use 12 or 13, whichever looks closer, because 12.56 won’t really change much and may in fact cause the text to shake during animation. Again, nothing the Designer can really do – just a heads up.

If specific letter kerning is done, it would be great if the Designer can make a note of it in the briefing, or with the Note Tool in the PSD, as this is hard to spot when laying out the text in Flash.

If exact kerning and other font items are important, text can be imported as images. This gives some advantages and disadvantages. It does allow the font to look exactly as the Designer intended, and also allows for the text to animate a bit smoother when the font sizes are small. However, it can significantly increase file size, especially if alpha channels are needed to see the background behind it, and makes it so changes to the copy take much more time. Typically this is not done on banners unless very small details on the text are important, and it will fit within file size.

Two things that are done quite often in Illustrator but are surprisingly not available in Flash are the ability to put a stroke, and the ability to put a gradient fill on font characters. The only way to do it is to break apart the fonts so they are simply vectors, and then add the stroke and gradient. Depending on how much the font is used, this could increase file size by quite a bit, and also make editing the banner more work. There is another trick to adding strokes to font characters involving a very bright glow, but it’s not technically an outline. Generally, this is an annoying oversight on Adobe’s part.

Screencap and logo

Try to avoid animating perspective changes on objects, as this cannot be done in Flash 9 and below natively. This is commonly attempted with things like rotating a piece of text in a 3d manner, or having something move into the distance on a road. Flash can natively do single directional skewing, but not perspective. If this is required, talk to your Dev about possible tricks to get around it. If complex, an image sequence might need to be done by the Designer, which will increase file size by quite a bit. Or, if AS3 Flash 10 is allowed, native 3D might be able to be used if it fits within file size.

Morphing vectors in Flash is possible (for example animating the letter A to become the number 3), but is quite a tricky thing to do. A lot of times the Flash animation engine just refuses to co-operate. A dotted line running down the centre of a road to simulate movement on the road is no problem. But if you start to bend and curve the road, the line will need to morph from side to side, and that becomes hard to do. My personal opinion is that vector morphing usually ends up looking a bit cheesy. If complex morphing is required, a specialized Flash Animator may be able to tackle this part. Specialized Flash Animators are also great for character animations, such as body movements and facial expressions, as typical Developers might not have that sort of classical character animation training. Talk with your Dev about his or her capabilities.

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.

Backup Image This is usually the last item done in the development process. Commonly it is just done by the Developer using the last frame of the banner and exporting an image. 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, GIFs are not used very often anymore. 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.

Just as an FYI, there are two ways to code banners – timeline based or code based. Timeline based means that animation is done visually. A dev can pick up an object and move it from one place to the next to make it move. The advantage of this is that it’s quite simple to create (depending on the creative of course). If there are a lot of complicated animations though, file size can add up because points where an item starts and stops (called keyframes) take up space. Also, this form limits what you can do with interactivity. Timeline banners are usually just for simple start to finish animations. Code based banners can do the same thing, but all through code. They are much more flexible in what can be done, can be smaller file size in some cases, but are much more complicated and harder to change once started.

If you see an image that looks wobbly while moving or zooming, it’s likely the Developer has forgotten to turn Smoothing for the image on. This setting allows Flash to dynamically blur the images pixels slightly to give it a smoother appearance when it’s not showing at exactly 100% size, or is on a half pixel. Smoothing does tend to make an image look a little fuzzy though, so it may be turned off on purpose to keep the image crisp when static.

Speaking of half pixels, that term means that the object is not located on a full number on the x and y coordinates. In other words, if an image is located at 123.5 pixels on the X grid, and 100 pixels on the Y grid, it might appear blurry because the X grid is on a half pixel. A trick to get things to look clearer is to put everything on a full pixel.

Rich Media banners have the potential to do many more things due to their flexibility with dimensions, file size, and availability of AS3 and Flash 10. They do however, take longer to do, and usually require an Ad Server to be run through (See earlier side note in the Specs section regarding warnings on where Rich Media banners should be served). 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 40k banner loads, the Developer can then load in additional file size. The two step process ensures the user can see something while the heavier stuff happens in the background. Polite Load Banners allow for much more creative freedom than Standard Banners. The amount of loaded content allowed is usually 2.2 megs, but may be restricted if not user initiated. In other words, the banner can load 40k, then 100k in the background, then a further 2.2 megs if the user clicks something. But usually the 2.2 megs can be loaded anytime after the initial 40k

TLA / Voken (Also known by 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 can polite load 100k or so, but not often more than that because by the time the standard 2.2 megs would have loaded, the banner will have auto-closed.

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 drawing 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.

If the design calls for something in the collapsed portion to animate into the expanded portion, there are a few things that need to be taken into consideration. Remember, these are usually two separate files. For example, lets say you have a collapsed banner with a ball on it that you want to fly into the expanded portion once the user mouses over the collapsed banner. The ball is not moving. When the user expands the banner, the expanded SWF replaces the collapsed SWF. Because the ball is in a static position, the expanded SWF knows exactly where that ball is, can duplicate it, and then have it look like the same ball flies into the expanded portion fluidly (even though it’s now technically a ball in the expanded SWF). However, if the ball is moving around the collapsed banner instead of staying still before user rollover, this poses a problem because the expanded portion has no idea where the ball will be when the user expands the banner, and won’t be able to match its position. There are some ways around this depending on the Ad Server and the timeline, so speak to your Developer about what is and isn’t possible when expanding and collapsing the banners, and what animations can be done between them. The safest bet is to just cover up the collapsed with the expanded, not worrying about matching content between them. But of course the Designer’s imagination shouldn’t be restricted if possible.

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 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.

These are basically just Expandable banners that push the website content down to show the expanded content when expanded, instead of having the expanded content cover the website content.

Rich Media banners commonly use video as file size will now allow it. 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 as they can be buggy). 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.

Using YouTube video is a common way of bringing video into the banner. This can be beneficial because if done through DoubleClick, the size of the videos do not count towards your 2.2 meg polite load. So you can have very long videos of high quality. The disadvantage of this is that you are forced to use the YouTube player, which is limited in its customization, and always has a YouTube logo on there somewhere (although it does have all the player controls pre-coded which is nice).

Combo Units
Combo units use two banners on the page at the same time, and have an element of the animation work between them or animations happening at the same time. There are two ways for the Developer to do this. The first is to just use two Standard Banners and make them the same length and start at the same time so you can have items animate simultaneously. This usually works well and is the cheapest option for serving. Sometimes, however, the banners could load at slightly different rates, so the timed animation could be a bit off. If timing is very important, such as if a piece of food is falling from one banner to another, then consider looking into doing a Rich Media version with an Ad Server that allows what’s called a local connection (or has their own API equivalent). Talk to your Developer and Ad Server to see what’s possible.

Other notes
If the ad requires keyboard input from the user, the SWF file needs to have whats called Focus before the keys will be registered in the unit, otherwise the banner will not know the keyboard is being used. Having Focus means that the user has clicked somewhere in the SWF file. A common design tactic is to have a start button to make sure there has been a click in the SWF before the keyboard needs to be used. Clicking to expand on an Expandable may also work, but sometimes does not because the Focus may stay on the collapsed SWF (depending on how the Ad Server handles it) and not the Expanded SWF where the keyboard interaction would be needed.

Other items to pay attention to for Rich Media banners:

  • Sites that do not allow emulating cursors or replacing the cursor with a custom graphic
  • 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)

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 how this is done. Below is a quick summary of the most common Ad Servers in Canada.

DoubleClick (DoubleClick Studio)
One of the most common Ad Servers, DoubleClick runs its Rich Media ads through a website called DoubleClick Studio. An account will need to be set up with your contact at Google. Once ready, the Developer can set up different projects for the campaign. The great things about using Studio is that any Developer can use their own personal account for any client. If an Ad Agency is hiring a freelancer for example, they do not need to give the Developer their Studio account login information, thus giving them access to all other projects. The Developer just needs to create whats called an Advertiser Association on their own account to link it up with the advertiser. Talk to your Developer and Google contact to get details on how to do this in your particular case. Once the project is ready, the Developer sends a request off to QA.

One technical quirk with DoubleClick, is that they sometimes like Developers to set up Vokens and TLAs to actually be setup as Expandables in order to lock their relative positions on a website.

Sizmek (Sizmek)
Sizmek has a few ways to upload to their system. Developers commonly use an extension that loads into Flash. They can then control all the elements, such as URLs, backup images, and expansion, from Flash directly. An account is required, and usually the username and password is shared with everyone. The campaign management is usually controlled by the PM or Account person. Speak with your Sizmek contact on how to set things up.

Sizmek is a bit different with their Polite banners in that instead of having a banner appear and then load additional content into itself, its template has a small temporary banner load up front, and then completely replaces itself with the larger banner. This might effect creative in some rare cases.

Pointroll (PointRoll Resources)
PointRoll has an online system which requires an account. Developers will commonly upload their stuff through Creative Manager, which is a Desktop AIR app, and works similar to Sizmek’s system, but is a bit more robust. Again, username and password is required, and a campaign will need to be setup on the account side.

Eye Return (eyeBuild Specs)
Eye Return does not have a tool to upload their ads with. You just send them the files and they set it all up, although the Developer still needs to implement their API and custom Click Tags.

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.