I mainly wanted to focus on the inter-connectivity of digital and event based marketing. Digital can be very good at going broad and being readily available anywhere and any place whereas on-site event based experiences can be much more personal and stand out in a world that is becoming more and more digital. Digital for events is not just about doing techie stuff on-site; but rather I think the digital and social marketing methods are very complimentary to events.

I broke down an event+digital marketing campaign down into three main sections: Pre-Event, Event and Post-Event. I spoke about which tools are of most value at any given stage. I also found it interesting as I prepared the presentation that although the stages all have their different opportunities and challenges the goal is always to drive people to awareness, interest and eventually engagement. On an abstract level it’s all very simple but obviously each client/campaign/audience has it’s own nuances and that’s where things need to get thought through on a case-by-case basis.

So, here’s the overall approach that I advocate:

Pre-Event

Event

Post-Event

I also showed case studies for American Express Unstaged, Budweiser’s Band of Buds and U.s. Army Strength in Action Tour.

At the end I received a great question from one of the attendees, whether a website was necessary for an event marketing tour. My answer was that not as necessary as it used to be because of social media growth… but there usually winds up being something that you want to do that you can’t do through Facebook or Twitter… and it’s a nice place to aggregate all that content anyway. So, for all but the smallest events or tours I’d recommend having a website of some sort. It could obviously be a page or a section on an existing brand website. Tumblr could also provide a solution for a small event marketing effort.

Posting this a little a later than usually since I was lucky enough to catch food poisoning at the airport on my way back. Regardless, I think it was a good experience and I’m pretty hopeful it was overall a worthwhile experience for the attendees.

Presentation Slides:

Technology and Communication Objectives are connected

• Far away the objectives are to make people aware of your presence and attract them closer
• Nearby the objective is to begin influencing your audience, and to get some people to come up closer to engage
• Up close you should reward people who are unafraid and not afraid to let them engage and immerse themselves in interactive experiences, they become players in your play that the more timid watch and experience through others
• At all stages delight with quality and playfulness that is appropriate to brand tone and event setting
• Provide something digital that is easy to share through social channels, preferably personal to the attendee such as their photo, score or “personalized digital artifact” of some sort

Touch Screen Kiosks versus Tablets

• Touch Screen Kiosks are cheaper to develop for than tablets because of the tools available but cost more per unit
• Tablets are more expensive to develop for but become cost effective when using multiple units because of low hardware cost
• Tablets are more personal and private but don’t provide as much visual interest to onlookers
• Touch Screen Kiosks provide visual interest for the nearby onlookers but may intimidate the more tech-timid from engaging

I think it went over well, received a couple of poignant questions from the audience and hopefully it was a useful 45 minutes for the attendees.

Presentation Slides:

Core Ideas:

• Provide simple HTML content without reliance on JavaScript, CSS or Flash
• Enhance with CSS that is non-browser specific, optionally include browser specific markup that further enhance the presentation
• Add JavaScript to provide at least minimal functionality on non Flash browsers
• Replace select HTML and JavaScript components with Flash components
• Using JavaScript feed in the HTML content to the Flash components and parse it like XML (this allows you to update your content in one place)

Main Benefits:

• Content is SEO and text-browser friendly
• Content displays and is functional in lesser featured devices (such as iPhones and other non-Flash enabled devices)
• On full featured devices optimal displays is achieved

Sample Code:

• Content Only
• Simple Presenation
• Enhanced Presentation

Presentation Slides:

Summary:

I hope you find this presentation useful and relevant to the issues we face to day in web development. Please shoot me a comment if you have any questions or comments, feedback is always good.

1. Make an air file

Build your “NativeApplication” and export for release (Flex developers) or package your html and javascript files as an AIR file (Javascript developers).

2. Apply for a distribution license

You can apply for a runtime distribution license here.

3. Download installer files (link provided by adobe in email)

Once your runtime distribution application has been accepted you will be notified via email and that email will contain links to download the runtime installation as well as their “side-car” installer for Mac and Windows. This may take a day or two to go through so don’t do this last minute.

4. Create a file called .airinstall.cfg

As instructed by the documentation found on the download page for the runtime environment you will want to create a file called “.airinstall.cfg”. Since files starting with a “.” will be hidden on OS X I find it useful to have a utility such as Houdini at my disposal to turn hidden files visibility on and off (see link at the bottom of this article). The file should be a plain text file and the only contents of it should be the name of your air file (you could have the path and keep the air file in a subfolder but my personal opinion is that you’d be tempting fate, keep it simple and keep your air file on the root of the cd/dvd).

5. Gather both the Mac and the PC side-car install files

Now copy all the files from the Windows and Mac side-car installer downloads into a folder with your Air package. I like to master on a Mac since in my experience OS X is better at handling PC files than Windows is at handling Mac files. Your folder should look something like this.

6. Make it pretty

Rename the installer exe and app files so that they are easily identifiable as the files to click for installation.

7. Make it simple

Use a burning program to create a Mac/PC disc and to make things easier hide Mac files from the PC and vice versa, this will make it a lot easier for users to figure out what files to use.

8. Watch it work

a. If you don’t have the AIR framework installed the installer should first run you through that installation



b. Once the framework installation is completed or if you already had it installed the installer should go on to install the application.

That’s it. I hope you find this tutorial accurate and simple to follow. If you have any other ways of putting together an installer post a comment and let me know how you like to do it.

Tools of the trade

Houdini

A very useful tool for turning file visibility on and off is Houdini

Toast

There’s no getting around the fact that if you’re mastering for CD/DVD delivery you will need some sort of burning software. I’ve been prett happy with Toast.

Known issues

I should note that one of my testing computers, running Windows 2000, was not able to run the all-in one installers although when installed separately both AIR and my sample application installed and ran without any noticeable flaws. I will post update if I discover a more elegant solution than what I have done so far, which is to have a Win2000 install folder with the two installation files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class UpdateManager{
   private var appUpdater:ApplicationUpdaterUI		
 
  Static singleton class
  // singleton function and singleton variable
 
  protected static var updateManager:UpdateManager;
 
  public static function getInstance():UpdateManager {
      if ( updateManager == null )
        updateManager = new UpdateManager();
      }
      return updateManager;</code>
  }
 
  public function UpdateManager(){</code>
      appUpdater = new ApplicationUpdaterUI()</code>
      appUpdater.configurationFile = new File("app:/content/data/update.xml");</code>
      appUpdater.initialize();</code>
  }
 
 
  public function updateNow():void{</code>
    appUpdater.checkNow();</code>
  }
 
}

There are two basic “flavors” of the update framework, one without a user interface and one with it. I have chosen to use the framework with it’s default UI and that’s often a good starting point for an application. If you have time later you can always switch over to the UI free framework (that’s why I like to isolate all calls to the update framework in my own class).

1. Use a “SystemManager class” where you make all your AIR specific calls.

This will make it much easier when you (or your client) decide to make a web based version of the app or if you are already maintaining web and AIR versions.

PlaybackManager.as (responsible for loading files, stopping, pausing, etc…):

1
2

  var songURL:String = SystemManager.getInstance().getAudioUrl(fileVO.file)
  sound1.load(new URLRequest(songURL));

SystemManager.as (responsible for handling file paths and basically anything that’s dependent on AIR):

1
2
3
4
5
6
7

  private var audioDirectory:String = "content/audio" 
  /* or we could use air to reference the application storage directory
  * private var audioDirectory:String = File.applicationStorageDirectory.resolvePath("content/audio").nativePath;
  */  
  public function getAudioUrl(fileName):String{
    return audioDirectory+"/"+fileName;
  }

2. Make an icon and give your app a name

Air and Flex gives you all those nifty settings in the –app.xml file so use them. This includes application title, window titles, installation directory and icons. For more information see this page on livedocs.

3. Get a security certificate

If you are building an AIR app for commercial distribution you should probably sign up for a security certificate. You can create your own certificate through FlexBuilder but it will not look as official during installation and will give a higher warning level to the end user. For more information see this page on livedocs.

4. Set up an update feature before the first release

In my next article in the series I will go over updating and I just want to stress the importance of adding this feature early. This really should be the first feature you build since it will make it so much easier to fix bugs or add important features after the first initial release. If you omit it you have no easy way of pushing it to your users.

5. Let users know what version they’re using

If you want an easy automatic way of displaying the current version of the app you can tap into the “-app.xml” to retrieve the version number of the app. I found this method in the sample files from Adobe’s Update Framework (more on that later) and I find this more reliable than me remembering to update a version number somewhere on the UI.

1
2
3
4
5
6

private function setApplicationNameAndVersion():void {
	var appXML:XML = NativeApplication.nativeApplication.applicationDescriptor;
	var ns:Namespace = appXML.namespace();
	lblAppVersion.text = appXML.ns::version;
	lblAppName.text = appXML.ns::name;
}

6. Have a strategy on how you save data

Something that is a little different from other wrappers I have worked with is that after installation you can’t save any data to the applicationDirectory so you should plan to either save data to the applicationStorageDirectory or creating your own custom directory in the user’s document directory. I’m as gulty as the next guy when it comes this, but don’t forget about the built in sqllite feature.

However, there are some grey areas when it comes to cairngorm that each developer has to figure out for himself such how to decide between using a cairngorm event and when to use a normal flex component event. Antoher grey area is how deep to go when binding to the ModelLocator.

Here are my general rules that I try to follow as my own “best practices”:

1. Only dispatch cairngorm events in first level components.

This should work great for simple to moderately complex applications and make event dispatching more consistent. It should also make your custom components more reusable since you don’t have to dig through them to remove references to cairngorm events that don’t exist. If you have a very complex application you can extend this second or even third level components but simply staying consistent will help in the long run.

2. Only bind to the model on first level components.

This follows the same logic as rule number one and I would also suggest that if you are binding a component to more than two properties in the ModelLocator, consider using a value object for it.

3. Events and Commands should only “work with” one type of value object.

This allows you to pass the VO you are working with as the data parameter of a cairngorm event without worrying about typing errors occurring at runtime.

For samples of cairngorm applications and to download the framework swcs go to:
http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm