A walk down memory lane with Eyeblaster and Mediamind

Let me warn you, this post is certainly written for a niche audience. But I just made a discovery that I hope can help other people who have to deal with the same issue I was having.

So here is the situation: At ACNE Production we’re currently developing a series of Rich Media banners for one of our clients. The challenge for us is that we have a lot of different clients that use different media partners to publish and host their banners, and all of these media partners have different ways of doing things. Often figuring out the way things work with this particular media partner takes up a significant part of my time as a technical director, since I’d rather have the developers focusing on writing code. We just did a couple of banners using Google’s DoubleClick Studio, and this time the mediapartner is Mediamind, who merged with Eyeblaster last year (I think). Eyeblaster have been around for some time, and it seems they’ve been developing their framework for a LONG time. It’s certainly very big and complicated.

The problem is that to develop an Eyeblaster banner you have to build it in the Eyeblaster Workshop, which is a proprietary plugin for Flash. Once you’ve installed that plugin you have access to a very sophisticated toolbox with templates and even a sandbox for previewing as well as publishing capabilities. Unfortunately everything happens behind the scenes; You don’t know where any of the code comes from, you just know that weird classes are imported and that static objects are referenced from the timeline in the template files.

The problem is that no serious Flash developer would ever user the Flash timeline to write any code, other than maybe a stop(); action inside a graphical asset. Any code beyond that should be written in an IDE, such as FDT or Flash Builder. Our tool of choice at ACNE Production is FDT, currently version 5.5. Now, since all the mysterious Eyeblaster magic happens behind the scenes, trying to develop an Eyeblaster banner using an ActionScript IDE will result in a ton of reference errors inside your project, since all the Eyeblaster code is nowhere to be found.

With DoubleClick studio it was fairly simple and worked the way you would expect it to. There is a plugin that you install using the Adobe Extension Manager, but there are also several SWC files that contain compiled versions of the code to be used in your ActionScript IDE. With Eyeblaster, there was no such thing, at least not on the surface. So I thought that I would try and break open the .mxp file that contained the Eyeblaster Workshop, hoping to find a bunch of SWC files in there.

Unfortunately, opening an MXP file was no easy task. I assumed it was just a zip-archive, but I couldn’t get it to unzip. Enter Gooogle, that told me about an ancient piece of software called MXP Lister. And this is where it gets really old school: MXP Lister is a plugin for Total Commander(!) I actually couldn’t believe my eyes. One of the developers at my old factory used Total Commander on Windows back in 2007, and even back THEN it was totally old school, although for a semi-old geek like myself it brought back fond memories of the MS DOS days and Norton Commander or even Directory Opus on the Commodore Amiga system.

So I booted up the trusty old office Dell and installed Total Commander and the MXP Lister plugin, hoping to reveal the dark secrets of the Eyeblaster MXP package. And I certainly did – the MXP (Macromedia eXtension Package) contained MXI, which is an XML metadata file that describes what to do with the contents of the package. And this revealed that it copies actual ActionScript classes into the Flash Library. Since Flash Pro intrinsically (and secretly) understands and relies on code in there, there is absolutely no reference to that directory whatsoever in the publish settings for the .fla files created by the Eyeblaster Workshop.

Anyway, I was able to find those classes and copy the code into the project we’re working on, so that we can use a decent IDE to write the code instead of having to write code in the timeline. In case you’ve forgotton where Flash stores it’s internal classes (and I had), here it is (on OS X with Flash CS6 installed):

/Users/{USER NAME}/Library/Application\ Support/Adobe/Flash\ CS6/en_US/Configuration/Classes/Eyeblaster\ ActionScript\ 3.0/eyeblaster

So there you have it – a walk down memory lane to the days of writing code in the timeline and even further to the days of File Managers. While I’m sure the Eyeblaster Workshop works out just fine for designers who don’t write any code but just rely on simple actions and don’t care HOW it works, just that it works, it just isn’t a good solution for a developer. I hope EyeBlaster realises this and provide us with SWCs instead of the “idiot”-proof template files. I also hope someone can use this information in the future, which is the reason I wrote this post.

Geek Out,
Martin

6 comments

  1. Shane Smith

    I actually found this really quite interesting, thank you. I’ve been using DC Studio for years, in fact I go back to the Tangozebra days when the internet was all just fields of grass.

    I must admit, until this week I have been totally avoiding having to use Eyeblaster or the new MediaMind Workshop components to produce and Rich-Media but this week my client (well their media buying agency) has almost insisted I use MM for some of their other global regions. Knowing little these days of the Rich Media offering from MM, I decided to do some background research and stumbled across this post. My concerns and worst fears confirmed…

    Just wanted to say thanks as it’s always good to get this kind of info from those who know!

    Yours faithfully

    Shane (aka Your Niche Audience)

    • martinpagh

      You’re very welcome. Have fun in the Workshop and remember to download the latest version released last week. It seems the previous versions are broken in Chrome 21.

        • martinpagh

          Yes, you need a login to download the MXP that contains the workshop. You setup your creatives using the plugin workshop. If your creative needs to load external assets you have to test them through the plugin workshop as well, since there is zero transparency as to how it loads external assets and it can’t be triggered outside their test sandbox. Fortunately you don’t have to use the web workshop that much if you don’t want to.

  2. Dan (tree)

    This is pretty insightful to those not as close to the progression of rich media. I’ve been around this big web of ours with PointRoll almost since the birth fo the company and have watched each competitor evolve. It always facinated me the efforts to provide the best environment/tools to develop rich media. In my experience the more you do to make thinges easier the less freedom you give people to use your product. I’ve seen the environment within environments to build rich media with proprietary tools or you have to use “someones” component “or else”. Quite frankly it makes it more difficult to be creative. The designer makes the design “you” (the vendor) are just a tool to design with. The tool shouldnt replace the design environment or the design. I’m in the flash development dept and handle our API.

    I focus on swc files that make it easier to distribute our code so the designer can pick their own environment. Keeping code proprietary is important yes ( you don’t want to just give the keys to your kingdom away) but providing documentation is more important; “Don’t make me read the source what does your code do?”.

    Template files are also nice but they really aren’t helpful to enough people since they aren’t “solution files”. If they were called “solution files” well I guess I just did your job and I’ll expect a check at the end of the week.

    In terms or proprietary code you don’t have to give everyone the source as long as you can explain what the purpose of the code and what it does. Plus if you code API’s to allow it to be more open ended, dont force environments or components, you give freedom back.