Using Cross-Domain Policy Files in EyeWonder Ads
Deceit, Treachery and Other Flash-Based Drama
A while back, I worked on an ad featuring dynamic content supplied by a third-party database. The goal was simple: load a list of stores, each store’s information and a selection of products available at each location.
When I tested the ad from within Flash, it worked fine—better than fine, in fact. The progress bar I had included showed the status of information coming from the database; all the store locations, product data and images appeared neatly in a list without so much as a hiccup. All was right with the world.
Or so I thought…
I published my files through AdWonder and waited to see the fruits of my labor brought to life on the staging server, heralding a milestone in the project and the end of my workday.
The basic ad loaded fine, but when the product list appeared, it was empty. The progress bar refused to budge, complacently sitting at 0%.
Perplexed, I tested again from within Flash. The data showed up perfectly. Perhaps I had imagined the issue—it wouldn’t be the first time.
I uploaded the ad once more. Again: no data. A knot formed in my stomach…What was I not seeing? Had I offended the Flash gods?
After a few rounds of forehead-to-desk interaction, it dawned on me that I had not discussed the issue of Flash security and cross-domain policy files with the client. After checking the third-party server, my suspicions were confirmed: no crossdomain.xml file was present, and Flash Player refused to grant access to the data my ad so desperately yearned for…
“Et tu, Flash Player?”
I sent a quick e-mail to the client, and within minutes, we had the crossdomain.xml file formatted and in place on their server.
Hoping that was the only cause of the problem, I hit the “Publish” button in AdWonder, and sat with bated breath…the tension was overwhelming as I watched the browser window open and begin loading the ad.
The progress bar, once woefully unresponsive, began to move…
“SHAZAAM!” as my co-worker John would say. A digital cornucopia of products appeared before me! All neatly displayed in the ad—names, prices, thumbnails, the whole glorious lot.
Problem solved. Much rejoicing.
What are they and how are they used?
Cross-domain files are small XML documents that reside in the root directory of a remote server and grant access to SWF files on various other domains. Flash Player uses these to determine if a SWF file at one location may access content on that particular server.
These files play an essential role in EyeWonder creatives that run on dynamic data from a remote database. Because the SWF files reside on the eyewonder.com domain, they must be granted access to the remote Website’s content via the crossdomain.xml file in order to function.
While many websites already have cross-domain files already in place, it never hurts to double-check a remote domain that you plan to interact with. The quickest way to check is by going to the root domain in a browser and adding “crossdomain.xml” to the end of the URL:
http://www.mywebsite.com/crossdomain.xml
If your ad requires access to a third-party domain, check with the tech support contact at the Website to see if they have a cross-domain policy file set up. If not, ask them to add one and to allow access from “*.eyewonder.com” and “*.eyewonderlabs.com”. This will ensure smooth sailing when it comes time to publish your ad.
The XML Code
Cross-domain files can be formatted a number of ways, but they all do pretty much the same thing. The XML markup is fairly straightforward:
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”master-only”/>
<allow-access-from domain=”mywebsite.com” />
</cross-domain-policy>
In its simplest form, it allows a SWF file that reads it to access content from the domain “mywebsite.com”. The individual XML tags are described below.
1. <site-control permitted-cross-domain-policies=”master-only”/>
Tells Flash Player that this policy file is the only crossdomain.xml file that should be acknowledged and obeyed.
2. <allow-access-from domain=”mywebsite.com” />
Specifies the actual domain a SFW must be on in order to access this domain’s content.
You can add multiple access tags to give more flexibility as to who may access content on your domain, like so:
<cross-domain-policy>
<allow-access-from domain=”projects.mywebsite.com” />
<allow-access-from domain=”blog.mywebsite.com” />
<allow-access-from domain=”misc.mywebsite.com” />
</cross-domain-policy>
This means that Flash Player may read content that specifically resides on the domains “projects.mywebsite.com”, “blog.mywebsite.com”, and “misc.mywebsite.com”. It also means that Flash Player may not access data on other sub-domains of mywebsite.com. For example, a SWF file would not be able to read content from “apps.mywebsite.com”, since it is not explicitly listed in the XML file.
Alternately, you can use the “*” symbol before the “.mywebsite.com” to allow access to data on any sub-domain of a specific root. The above XML is shown below with the shorthand notation.
<cross-domain-policy>
<allow-access-from domain=”*.mywebsite.com” />
</cross-domain-policy>
This would grant Flash Player access to any sub-domain on the “mywebsite.com” root.
Further Reading
Cross-domain policy file specification
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Policy file changes in Flash Player 9 and Flash Player 10
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
IAB VAST and VPAID
EyeWonder is closely engaged with the IAB to help define standards related to in-video advertising. We sit on the IAB’s Digital Video Committee and were present during the drafting of the “Digital Video Ad Formats and Best Practices” along with the “VAST” XML tag standard. We have expanded UIF to support VAST pre-roll and wrapper tags in the newest Framework 2.7. We are also on the Digital Video Player-Ad Interface Definition (VPAID) subcommittee, involved with drafting a new ad to player communication standard.
EyeWonder has also been certified for adherence with VAST and VPAID standards. Because VPAID is essentially just an ad to player communication layer (much like the EyeWonder UIF was), we think we can help speed up adoption by providing some of the “glue” that can be used to hold this into the video player. There is a lot of additional code that publishers would otherwise need to write to hook VPAID in.
In-Stream 2.0
EyeWonder is well known for in-page units; however, we also have a wealth of experience with in-video advertisements as well, dating years back. In 2007, we decided to push the envelope far by working on interactive in-stream. So, you may be asking why and how we approached it.
The challenge of in-stream and our solution
By 2007, a few forward-thinking publishers had already created their layer for interactive ads to communicate with the player; however, advertisers needed to build a creative differently for each publisher even in that case. Therefore, publishers were having trouble selling their inventory. That was the challenge we saw that needed to be addressed.
As a result, we began the initial development of the Universal In-Stream Framework (UIF). UIF was created to solve the problem of a lack of a standard way to communicate between interactive advertisements and the video player. To put things in context, this was before the discussion of VAST and VPAID had even begun (more on that in a future blog).
Creative
Based on research of what works and what doesn’t, we came up with a few engaging interactive in-video ad formats. There were more we experimented with, though we settled on what had the most appeal and what people were most ready for. We also developed templates to help creative agencies build creatives through the AdWonder Flash Component. At the top of the list of interactive formats are:
- Interactive linear
- Ticker
- Bug
The most exciting format to me right now is the interactive linear format because although we have linear ads, the interactive linear ads are still not too far off what people are used to, but allow full interactivity. I’ll be covering the interactive linear format in a later blog entry.
Tickers and bugs are non-linear formats that allow ads to be present during content video playback in an unobtrusive manner. If the user is interested, the user can expand the ad to do more.
Adjusting EyeWonder Expandable Template Transitions With Ease
We at EyeWonder always recommend that you start with the EyeWonder templates as a base for building your ads. The code for expanding properly, waiting for content to load, preventing the ad from sticking open and appropriate tracking are all built in to these easy-to-use files. But sometimes the transition you are looking for when loading the expand content isn’t what you want for your creative.
The nice thing about the EyeWonder templates is that they are easy to adjust and work with, and you can do it while only changing a bare minimum of code.
In this entry, you will see how you can alter the basic expanding of the ad into a more impressive swiping motion as well as add transitions to the loaded content during the expand.
Watch the video or follow this step-by-step breakdown:
Here is the original timeline layout and a link to the way the ad behaves before editing.
1. Position the topContainer layer above the mask in the main FLA, but below the border.
2. Remove the tweening of the mask in the main FLA; it should just maintain itself at 300×250 through the entire timeline.
3. Create a new layer above topContainer and make this a mask layer JUST for topContainer.
4. Considering your expand direction, create a mask rectangle in this new mask layer (must be a MovieClip) that lines up with the opposite edge of the expand direction (expand left should have the rectangle on the right side, expand right should have the rectangle on the left side, etc.)
5. Mimic the keyframes from the border shape tween. This will be used to tween the mask to cover the entire expandable in the maximum expand frame, and back to the hidden edge by the final frame of contract. You will also want to set the easing for these tweens to 100 out if you want the transition to look both quick and smooth.
6. Adjust the border keyframes to closely match up with the new topContainer expanding mask. They should not begin their shape tween until the topContainer mask reaches the edge of the contracted ad. Additionally, the border should finish its contracting at the same time that the topContainer mask reaches the contracted size.
7. If additional keyframes are needed to make the mask and the border match exactly—these keyframes should only be added to the border, NOT the mask. Also—adjusting the easing of the border tween may be necessary to get it to line up precisely with the mask tween.
8. Now you can transition your topContainer with motion and/or filters to adjust its animation into and out of the expand state.
9. If the ad expands in two directions (down and left)—the mask can be placed in the opposite corner of expand.
10. An additional keyframe in the topContainer mask layer may be required to make the expanding mask match the contracted frame before expanding to the remainder of the expanded ad.
Here is a link to the above expand transition in action:
New Ad Formats Announced and Google Expands Its Inventory
Recently the Online Publisher Association (OPA) http://www.online-publishers.org/newsletter.php?newsId=499&newsType=pr announced three new creative sizes to help avoid ad clutter on a publisher’s page and to help advertisers emphasize their brand prominently on the page. With these new units being featured prominently on the publisher’s pages, you can be sure your client’s brand is front and center and not lost in a clutter of different ad units.
The proposed new units will be available come July for sale through the publisher’s direct sales team. EyeWonder will be introducing templates for these new creative units in the near future, and test tags are available currently and can be provided by contacting pubgroup@eyewonder.com. The new units and their sizes are:
-
The Fixed Panel (recommended dimension is 336 wide x 860 tall), which looks naturally embedded into the page layout and scrolls to the top and bottom of the page as a user scrolls
-
The XXL Box (recommended dimension is 468 wide x 648 tall), which has page-turn functionality with video capability
- The Pushdown (recommended dimension is 970 wide x 418 tall), which opens to display the advertisement and then rolls up to the top of the page
These new units will allow for richer creative executions, and we will be glad to help your creative team realize the full potential of each of the new unit sizes. If you are a publisher, our publisher team will be available to help identify the best way to incorporate these new format sizes into your pages.
In other new developments, Google announced recently that they are expanding their product offering across their Google Content Network (GCN) and accept expandable creative. EyeWonder is fully certified to 3rd party serve these units across their ad network, and the benefit provided by Google’s method is that they use a friendly iFrame to serve each of the units, which eliminates the need for each of their publishers to post an interim file. What this means to you is that you will see a higher reach and metrics due to every site having the ability to serve expandable creative correctly.
AdWonder in 2009: Faster, Easier, Smarter!
As the AdWonder component approaches its 3rd birthday, the future has never looked brighter for our favorite ad creation tool. What began as a humble set of class files to open EyeWonder’s industry-leading API to the world has evolved into what we all know and love today, the AdWonder for CS3/4 Flash Component. Today I’m going to talk about a couple of upcoming features and improvements which are distilled from all the valuable feedback we’ve received—keep ’em coming guys!
Adobe LiveCycle
What’s one thing we can use more of? SPEED! This is a major performance-oriented improvement for faster workflow. As the number of ads and videos being managed by our component increases, ad/video list refresh speeds tend to suffer. With LiveCycle, instead of a constant call to the server to retrieve updated information, our servers will now “push” updated data out to individual AdWonder instances, dramatically lowering data overhead. Another added bonus is that our support staff will be able to make adjustments server-side, and those changes will auto-propagate to the client designer’s panel.
New Demo Creator
Ok, I’m not going to sugarcoat it: the current demo creation process in AdWonder can be described as “functional” at best. It doesn’t have the most user-friendly interface or a great degree of flexibility, but like my old car in high school, it got us places. Well, getting places is good, but getting there with style is better—ladies and gents, I present to you the new Demo Creator. We’ve put a ton of effort into this: it’s got a shiny new drag and drop interface, allows for custom backgrounds, custom ad positioning, multi-ad demos and various other improvements too many to list.
Campaign Status Page
Sounds boring right? WRONG! This is a feature everyone will enjoy—a page which consolidates all ads, demos and other creative assets which have been associated with a particular campaign, allowing everyone to easily review creatives, check ad progress and do a host of other cool things. Gone are the days of passing e-mails full of approval/staging links between designer, project manager and clients; simply bookmark this page and all the information for that campaign will be at your fingertips. The time saved from miscommunications/digging for the same info repeatedly can be put to better use such as beer pong or making cooler ads—either’s good.