The Back Room

My name is Dave Nelson, and I am “the new guy” here at Boston Productions filling the role of interactive developer. Over the past few months, I have begun to adjust my methodology to be more in tune with developing compiled .exe files used in standalone kiosks. I thought in my first entry for the Back Room, I could share some of the simple differences between scripting for the Web versus a kiosk.

LOADING THE APPLICATION

One of the first and most obvious differences between the two is that many of our interactive programs are not meant to be viewed in an Internet browser. This instantaneously removes the need to detect bandwidth, create loading segments and develop for a full gamut of hardware and software capabilities. I now have the ability to develop on the machine that will be running the program, so I can observe the same experience that any end-user will encounter.

On the subject of loading, it’s possible to include more graphical assets in the Flash library, with less of a need to load graphics “on the fly.” Typically, in a Web application, I would try to get the .swf to load as quickly as possible and then load further assets as needed. This begets multiple loading screens. Oftentimes when developing for the web, it is better to have multiple short-loading segments, as opposed to a slow screen on the initial load. Many of today’s Web users will not wait very long and may get frustrated, ultimately navigating away from the site.

Typically, museum kiosks are started up once a day in the morning, before the museum opens. This means that despite a longer loading time, the compiled .exe file has to load only once a day, when no one is waiting for immediate information. During this initial load, the major graphical assets are loaded and will be available throughout the day; however, it is important to ensure your program is efficient and can run for a full day without excess scripts building on top of one another.

ADJUSTING TO TOUCHSCREENS

Another large difference is the use of touch-screens versus a computer mouse and keyboard. Of course, touch-screens have no “hover state,” and any graphical change or animation that occurs on a mouse event is typically associated with a “MOUSE_DOWN” listener. The “MOUSE_DOWN” event will typically trigger a highlighted state, while a “MOUSE_CLICK” listener will trigger the action derived from clicking on the interactive interface.

Before starting here, I didn’t imagine how programming for kiosks would be different from a Web application. As I continue developing interactive programming with Boston Productions, I look forward to contributing more to the Back Room.
Dave

 

In a recent project we worked on; the client was very adamant about being able to display a plethora of different types of unstructured data inside of a kiosk.  This included information that contained tables and images inside of the same display at the same time.  The content also included a plethora of font variations.  The length of content was greatly variable and really didn’t have any defined or repeatable structure.

If you are familiar with the flash text fields htmlText capabilities, you will see that it can render basic html.  However, this just wasn’t enough for this project so we decided to implement the Adobe AIR HtmlLoader which; from my understanding runs an instance of webkit inside of AIR.  It’s awesome being able to load web content directly into a project; but there is one huge problem with the HtmlLoader.  You can’t smooth the HtmlLoader!  If you rotate or resize the loader, you will quickly find yourself with an ugly, poorly rendered mess.

After thinking about the issue for a while, I came up with a solution.  The trick is to load the web content inside of the HtmlLoader, then use the BitmapData, and Bitmap classes to render out a bitmap of the HtmlLoader.  You will then be able to apply smoothing, size, and rotate the newly created bitmap without much distortion.

When using this technique you lose the ability to scroll and navigate web content.  Our whole point was to not let people know there was a web page being displayed inside the kiosk; so this methodology worked very well for us.
Below I have provided the class that I use in order to implement the smooth html loader functionality.  Be careful because my class is using some external references.  Namely Tweener as well as GenericNotifyEvent.

package com.bostonproductions.web {

import flash.display.MovieClip;
import flash.display.Sprite;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.events.Event;
import flash.html.HTMLLoader;
import flash.events.HTMLUncaughtScriptExceptionEvent;
import flash.geom.Matrix;

import com.bostonproductions.events.GenericNotifyEvent;
import com.caurina.transitions.Tweener;

public class smoothHtmlLoader extends MovieClip {

public static var HTMLREADY:String = “smoothHtmlLoader_HTMLREADY”;
private var theBrowser:HTMLLoader;
private var htmlToRender:String;
private var smoothCap:Sprite;
private var rawSmoothCap:Bitmap;
private var scrollPosition:int = 0;
private var tryCenter:Boolean = false;

private var targetHeight:Number = 650;
private var targetWidth:Number = 720;

// Alter the native height based on the resize ratio
private var HeightResizeRatio:Number = 1;

public function smoothHtmlLoader(_HeightResizeRatio:Number = 1, _targetWidth:Number = 0, _targetHeight:Number = 0):void {
HeightResizeRatio = _HeightResizeRatio;

if (_targetWidth != 0) {
targetWidth = _targetWidth;
}

if (_targetHeight != 0) {
targetHeight = _targetHeight;
}

createHtmlViewer();
}

/*
* DATE: 10/14/2009
* AUTHOR: Charles Palen
* NAME: displayHtml
* DESCRIPTION: Tries to fit all the html into the instance of
* the HTMLLoader.  If it cant fit it all, it MUST return the
* non-fitting html.
*/
public function displayHtml(_HtmlToDisplay:String):String {
var nonFittingHtml:String = “”;

htmlToRender = _HtmlToDisplay;

loadTargetLocation();

return nonFittingHtml;
}

/*
* DATE: 10/15/2009
* UPDATE: 10/28/2009
* The html parser now splits html up into chunks in instances where there are tables and images
* If this occurs – especially in the case of a table – we want to be able to CENTER it.
*
* Added optional boolean to specify we want to examine the content height, and resize/center the browser
* based on it!
*
* AUTHOR: Charles Palen
* NAME: setScrollPosition
* DESCRIPTION: Stores what should be the vertical scroll for this.  Once the html content loads it can be set.
*/
public function setScrollPosition(_VerticalScroll:int = 0, _TryCenterBrowser:Boolean = false):void {
scrollPosition = _VerticalScroll;
tryCenter = _TryCenterBrowser;
}

private function createHtmlViewer():void {
theBrowser = new HTMLLoader();
theBrowser.width = targetWidth;
//theBrowser.height = targetHeight;

theBrowser.placeLoadStringContentInApplicationSandbox = true;

theBrowser.addEventListener(Event.COMPLETE, htmlLoaded, false, 0, true);
theBrowser.addEventListener(HTMLUncaughtScriptExceptionEvent.UNCAUGHT_SCRIPT_EXCEPTION, scriptException, false, 0, true);
theBrowser.addEventListener(Event.LOCATION_CHANGE, htmlClicked, false, 0, true);

theBrowser.paintsDefaultBackground = false;
}

private function destroyHtmlViewer():void {
if (theBrowser != null) {
theBrowser.removeEventListener(Event.COMPLETE, htmlLoaded);
theBrowser.removeEventListener(HTMLUncaughtScriptExceptionEvent.UNCAUGHT_SCRIPT_EXCEPTION, scriptException);
theBrowser.removeEventListener(Event.LOCATION_CHANGE, htmlClicked);

theBrowser.cancelLoad();

if (contains(theBrowser) ) {
removeChild(theBrowser);
}

theBrowser = null;
}
}

private function loadTargetLocation():void {
if( theBrowser != null ) {
theBrowser.loadString(htmlToRender);

}
}

private function htmlLoaded(e:Event) {
// Remove the event
e.currentTarget.removeEventListener(Event.COMPLETE, htmlLoaded);

// Set the vertical scroll
theBrowser.scrollV = scrollPosition;
// If the try resize boolean is set – lets try it!
// Dont center – just shrink it if possible
if (tryCenter == true) {
var resizedHeight:Number = theBrowser.contentHeight;
var resizedWidth:Number = theBrowser.contentWidth;

if (resizedHeight > targetHeight) {
resizedHeight = targetHeight;
}
if (resizedWidth > targetWidth) {
resizedWidth = targetWidth;
}

theBrowser.width = resizedWidth;
theBrowser.height = resizedHeight;
targetWidth = resizedWidth;
targetHeight = resizedHeight;
}

theBrowser.width = targetWidth;
theBrowser.height = targetHeight * HeightResizeRatio;
//var bitmapAsset:Bitmap = e.target.content as Bitmap;
//bitmapAsset.smoothing = true;
Tweener.addTween(this, { alpha:1, time:.1, onComplete:generateSmoothVersion } );
}

private function generateSmoothVersion():void {
// Create the smoothed version
var tmpImage:BitmapData = new BitmapData(targetWidth, targetHeight, true,0×000000);
// Draw it – the last parameter set to true is SMOOTHING – tmpImage will be smoothed
var transformMatrix:Matrix = new Matrix();
//transformMatrix.translate(0, 500);
tmpImage.draw(theBrowser, null, null, null, null, true);
//tmpImage.draw(theBrowser,
// Create the bitmap
rawSmoothCap = new Bitmap(tmpImage);
rawSmoothCap.smoothing = true;
smoothCap = new Sprite();
smoothCap.addChild(rawSmoothCap);
//rawSmoothCap.x = 50;
//rawSmoothCap.y = 50;
addChild(smoothCap);
// Destroy the heavy html components to free up some memory
destroyHtmlViewer();
//swapChildren(theBrowser, smoothCap);
//theBrowser.alpha = 1;
//smoothCap.x = 300;
//smoothCap.y = 100;
// Broadcast so that we know its ready
if(tryCenter == true) {
dispatchEvent(new GenericNotifyEvent(smoothHtmlLoader.HTMLREADY, false, true, true));
}
}

private function destroySmoothVersion():void {
if (smoothCap != null) {
if (rawSmoothCap != null) {
if (smoothCap.contains(rawSmoothCap) ) {
smoothCap.removeChild(rawSmoothCap);
}

rawSmoothCap = null;
}

if ( contains(smoothCap) ) {
removeChild(smoothCap);
}

smoothCap = null;
}
}

private function htmlClicked(e:Event):void {
// Auto go back to wherever we were
//theBrowser.reload();
//loadTargetLocation();
}

private function scriptException(e:HTMLUncaughtScriptExceptionEvent):void {
trace(”ScriptException:” + e);
}

public function destroyInternals():void {
destroyHtmlViewer();
destroySmoothVersion();
}
}
}

For roughly the past two years there has been an assortment of articles flowing through the technical gadget pipelines regarding innovative and consumer grade touch screen technology.  Traditionally, touch technology hasn’t been ready for mainstream despite being used heavily in museum and kiosk applications.

Although we could all probably argue the value of a touch screen on a traditional home or office PC; the HP Touchsmart line of multi touch consumer grade machines is something to watch out for from a museum and visitor center perspective.  Will this line of PC’s be the freight truck that delivers touch screen technology to the masses?

My belief is that if this line of consumer grade products doesn’t make touch technology ready for mainstream then something else will.  There has already been a plethora of multi touch mobile devices making the rounds lately.

The bottom line is that we all need to get more creative in the museum and visitor center industry when it comes to interfaces.  The touch screen has been a work horse and novelty over the past several years that we have relied on to give kiosks a feeling of freshness and uniqueness.  This paradigm only has at most a few years left before the novelty effect will be gone.  Without the touch screen; where does that leave us?

Unique Interfaces

There are several sources of information available that you can find about unique interfaces scattered throughout popular and technology publishing outlets.  The New York Times has an article about possibilities called: “Coming Soon: Nothing Between You and Your Machine” by John Markoff.  Engadget has a recent article on a muscle interface in “Microsoft researchers build muscle-computer interface, play air Guitar Hero.  Tech crunch has the “CeBIT Highlight: University of Bremen’s Brain-Computer Interface”.  These are all very cool technologies, but are they applicable for museums and visitor centers?  Probably not.

The real challenge in interface design for museum and visitor center use is the immense age group and user diversity that must be supported.  Unlike many successful technology products which can target users in a specific demographic or age group; we must do our best to support all users!

One of the strategies we are employing at the National Museum of the Pacific War is a server/client content synchronization method.  The battle kiosks have so much information that it is unrealistic should we, or the institution need to update them; to perform the updates on each individual machine.

In order to remedy this, we are using Microsoft SyncToy along with scheduled tasks on each kiosk machine to synchronize their content.  Due to the fact that each time a page is loaded on the exhibit, it is parsed from HTML, you can update the html templates in the background and changes are seen instantly on the kiosks on the museum floor.  It is really a neat solution that works well by simply having each client machine able to see the master network folder on the server.

Around the office we have also been using Microsoft SyncToy to backup our development machines to a Drobo that we have on our office network.  Sync Toy is a free utility for people using Windows XP and higher.  You need at least the .NET 2.0 framework in order to use Microsoft Sync Toy.

A large percentage of Boston Productions has been working on the National Museum of the Pacific War.  The facility opened to the public on December 7^th, 2009 with a ribbon cutting ceremony by former president George H.W. Bush.  There was a special preview event for veterans the Saturday prior to the official opening.  Many of them had a difficult time completing the tour due to the emotional impact of some of the media.

There are roughly eight kiosks in the institution that Bruce, myself, and our production staff worked on.  Boston Productions also worked on a large portion of the video and audio media for the facility.  The kiosks have been added to the Boston Productions Interactive Exhibit key.

The over-all theme that I heard from military personal, veterans, museum staff, and donors while on-site; is that the facility will help convey the severe cost of war and sacrifice of our previous generations.

If you’ve never developed a touch screen application before, there’s a lot to think about that makes it different from a browser based or native application. It’s impossible to go through the full breadth of things to consider, but I figured posting a few helpful tips might be good.

Well Spaced and Big Button Sensing Areas
So, this does not necessarily mean giant buttons. Often that’s a good solution, since museum visitors are not just those familiar with computers but include many folks who don’t interact daily with computers. Really though, it’s about making sure that the sensing areas of buttons are forgiving enough to work with clumsy fingers, and to account for the different alignment people will get from looking at the screen from different angles. If you touch a screen from a low angle on what you see as the button area, and then change your perspective, that button area can be drastically different from above. A mouse is absolute. The button is the button. But with a fingers on a large screen, it can actually chance. So, large sensing areas for the buttons, and don’t put them too close together to account for different perspectives and clumsy fingers.

Consider Hand Position
When using a touch screen, a person uses their hand, thus creating a natural block for some of the screen area. With a mouse pointer, it’s small enough that unless an interface is very tiny, it won’t block anything when using it to select menu items, etc. But, with a finger, you’ve got a whole hand attached. So, imagine you have a screen where you have 5 buttons. Each button makes a change to a large image in the center of the screen. Although many web pages have navigation and other items at the top, this makes little sense in our scenario, because you want to see how your selection is changing the screen. If the buttons are at the top, you’ll have to move your hand away each time you press one to see the results. It may make more sense to place buttons along the bottom, or the right side. Although it may seem biased, you have to consider that most people are right handed, and if you have to favor one or the other, then choose right. The main thing to get from this one is just to think about where people’s hands are going to be and if they’ll be blocking items you need them to see when operating the screen.

Choose the Best Viewing Angle
This has more to do with fabrication than the software programming. You should make sure you consider who the audience is when choosing what angle and height to put the screen at. It seems like a basic enough idea, but there are many times when we haven’t been involved in the hardware or installation decisions of an institution, and they’ve installed a touch screen for children flat on a table that’s 36 inches high. How can a kid see that properly without standing on something? Or, a kiosk is supposed to take a photo of a person to put on postcard and email home, yet the camera is pointing almost at the floor, so if you’re over 3 feet tall, you’re bending awkwardly and contorting to get in the picture. Little things like this really affect the usability of a screen.

Hide the Mouse
I really don’t understand museum exhibits that have mice showing. I think people leave it there so that you see where you’re clicking and navigating. The thing is, you don’t want people to walk up to a touchscreen and see it as just a computer program running. You want them to walk up and see it as an experience that is something they can’t get at home. You can click on buttons at home, but you can’t touch a screen and move elements around the same way you can on a touch screen. Having the mouse pointer on screen breaks up your interface and reminds people they’re just looking at a computer screen.

Give Clear Direction
An interface must give users clear direction about what to do. Children will walk up to an exhibit and start banging away on the screen and they’ll figure it out. It’s the visitors that are new to touch screens and computer interactive programs that will just stand and stare at the screen, not sure what to do next. Things need to be clearly defined, and text must be readable. Sure, many people won’t read the directions, not matter how much you highlight them, but they need to be able to understand what to do by visual clues. There is a lot that can be written about creating touch screen interfaces, but my overall comment here is make sure people understand what to do.

I’m open to suggestions here, and I am not saying my comments are the be-all and end-all, but we’ve certainly learned a lot from working in this area for years. Some other miscellaneous items to consider:

- There are no rollOver or rollOut commands. Tooltips, highlights, etc. won’t work since it’s just about single touches.
- It’s good to use high contrast colors to make sure it’s visible to as many people as possible
- Choose a type of touch screen technology that works for what you need. (Capacitive, Resistive, SAW, etc.)

Anyone else have any tips?

One of the major components of many interactive exhibits is a touch screen.  We routinely work with a variety of touch screen types and technologies at Boston Productions.  Without firsthand experience it is difficult to know which technology works best for a given situation.  The process of purchasing and implementing a screen that will be used by thousands of people a day is also a bit of a mystery unless you have done it before.  You’re in luck because I am going to provide a firsthand overview of each technology I have worked with and common mistakes made while implementing them.

About Purchasing Touch Screens

Usually the big monitor manufacturers such as NEC and Samsung don’t actually make touch aware systems.  When purchasing touch monitors you usually buy them from a company that purchases a monitor and modifies it by adding touch capability after the fact.  This adds to the complexity of purchasing because you need to make sure that you are initially getting a good monitor, but are also working with a competent touch screen integrator.

The Types of Touch Systems

Capacitive – Capacitive touch screens work by sensing small changes in the electrical pattern over the touch screen surface. Your skin creates small electrical connections, and the touch screen software can interpret these to know exactly where your finger is located. Skin, or another conductive material is needed to make capacitive screens work properly. Using a stylus or other pointing device will not work. For instance, the iPhone touch screen is a capacitive screen.

Resistive - Resistive touch screen work by sensing any pressure by any object. It contains a couple layers of sensors and materials. There is a thin layer of a similar material that is the main part of the capacitive screen. It will detect small connections made when contacted by a conductive material. In this screen though, there is another layer of this conductive material that is very thinly separated from the capacitive layer. By touching the screen, you’re pressing down to create contact between the layers, and registering a touch with the computer. Many devices that use a stylus are resistive screens like the bottom screen of a Nintendo DS, or Palm handheld devices.

SAW – Surface acoustic wave is based on sound waves traveling across the surface of the touch screen.  When they are disrupted, the sensors know where you have touched.  For the programmer, a SAW screen can emulate a mouse just like you would expect it to. The SAW technology is what we prefer and use on most of our systems.

Infrared – Infrared is usually based on IR LED’s close to the surface of the screen coupled with cameras that can detect where the IR beams are being disrupted.  You normally can purchase an IR overlay as a completely separate piece of equipment from your monitor and install it on site. These are commonly used on larger screens where other technologies become less accurate. For instance, making a capacitive screen that is 40 inches is very difficult, so often an IR overlay is used. Often, this detects when a finger or other object breaks the plane of the IR beans, so you can sometimes operate an IR screen without actually ever touching the screen.

DST – Dispersive signal technology is based on sensing changes in the mechanical energy happening on the surface of the screen.  You can touch the screen and it will recognize it as a click, but if you continue to hold your finger down, without moving, this type of overlay will think you are no longer touching it.
An advantage of this technology is you can have items already sitting on it, and if they remain stationary; touch functionality will be unaffected for the rest of the screen.  This situation works best for touch screens that are integrated into work surfaces that you could benefit from allowing stationary items to rest on the screen.
Remember that with this technology it is not possible to accurately or consistently touch and hold items while remaining stationary.

Implementation

Although they may seem very similar, each type of technology requires different care and consideration when implementing.

General Considerations

Proper ventilation is always needed when using touch screens.  You will often find that when a monitor overheats you lose touch intermittently or altogether.  This usually means purchasing 80mm fans and installing them in your monitor enclosure.

Be very careful with the bezels of monitors and area directly around the touch surface.  We routinely work with fabricators that love to cover up the bezels of a touch monitor.  When this happens it’s imperative that these covers are not putting pressure on the bezel of a touch screen, or are physically contacting the touch surface.  When this happens you normally end up with a non functioning touch screen.

If covering the IR sensor for a monitors’ remote, have the fabricator drill a small hole so your remote does not become useless.  It’s always handy to be able to use the remote even with a touch screen.

Technology Specific Considerations

DST – In my experience with DST, I worked on several large monitors that were to be mounted vertically.  Due to the way that DST works, you have to be extremely careful when mounting

the monitor not to put any pressure on the screen or bezel.  Because it works based on mechanical energy, if you apply pressure from your mount on one area of the screen more then another, your touch overlay will become biased in one direction.  The result of this biasing is that you have a touch overlay that is more sensitive in one area then the other, or completely unusable.

SAW – Just make sure that you don’t have anything else touching the overlay when you implement it.  Also make sure to clean the monitor surface semi-regularly.

Infrared – With infrared, just make sure you don’t have debris blocking any portion of the IR LEDs or their associated cameras’.  An example of a debris that is pretty common is packing material.  If using an external overlay that you strap to the monitor, make sure that the overlay is very snug against the side edges of the monitor so that it will not move when mounted.  Many external IR overlays can conceptually be imagined as a picture frame.

This is meant as a brief overview of touchscreen technology, and a starting point when trying to determine which type of screen is right for you.

If you are streaming mp4 files with Flash or using IIS with mp4 files, it is likely that you may have had a few issues.  The problems normally range from irregular video playback to no playback at all.

Mp4 Files and IIS

IIS 7 (and I assume 6) by default does not have mp4 (or even .f4v) files added to its known MIME types.  This will not allow Mp4 files to playback in your flash applications even if you have implemented them correctly in your code.  In order to fix this, you simply have to add a handler mapping for it.  I will demonstrate how to do this in IIS.

Assuming you have it installed, in Administrative tools -> Internet Information Services (IIS) Manager you will find an icon for MIME Types on the default website selection menu.  Click Add in the top left.  For File name Extension: enter .mp4 and MIME type enter video/mpeg.  After doing this, you should be able to playback the video assuming you don’t have a metadata issue, which I will describe below.

Mp4 Files and Metadata With Flash

When doing video playback in Flash I have always been a huge fan of using Netconnections in conjunction with the Netstream class.  Although this is not as easy as using the FLVPlayback component, I feel like it gives me a lot more control of the video playback.  If you are familiar with using Netstream, you will know that there is a continual event called onMetadata that gets called when starting playback of a video.  I normally use this as a trigger to do things like resize the video.

With mp4 files generated by most video encoding and editing software, you will not receive the onMetadata event until the end of the file!  That means in order to even start playback, your users would have to download the entire video!  This is because the metadata of an MP4 file typically gets stored at the end of the file.  There are a free software tools that you can use to move this metadata to the front and allow the mp4 file to be streamed.

I have really gotten to love FFMpeg and the capabilities it can bring. It is very frustrating for me that it’s not really distributed with some GUI attached, or with some way of compiling it that doesn’t require a computer scientist. I think that most people that could benefit the most from it are media producers, editors, etc. Many of those folks just don’t have the programming background to sort through source files and binaries and understand really what to do. But, if you get it up and running, it’s really a treat.

I have a project that has a bunch of (about 100 so far) video files that I want to make screen captures of and use as thumbnails in my interface. I could go through one by one, but that’s a real pain and not necessary. So, I created a couple batch scripts that would do the conversion for me. The first script just cycles through a directory and feeds each file that fits certain requirements to my second script for processing. In my case, I have a bunch of .mov files that I want to pull frames from. So, the first script is named “startConvert.bat” and is only a few lines long and looks like this:

for %%i IN (*.mov) DO (doConvert.bat “%%i”)
pause

That basically says that I should feed any file that has an extension of .mov to my second batch script, which is named “doConvert.bat” and looks like this:

IF EXIST “%~d1%~p1%~n1.jpg” GOTO exit

@echo ————————— >> “%~d1%~p1%convert.log”
@echo Conversion for %1 started on %DATE% %TIME%  >> “%~d1%~p1%convert.log”

ffmpeg -i “%~d1%~p1%~n1.mov” -r 29.97 -ss 10.000 -an -vframes 1 -qscale 1 -f mjpeg -y “%~d1%~p1%~n1.jpg”

@echo ————– DONE – SUCCESS ———————- >> “%~d1%~p1%convert.log”

:exit
@echo ——————————– >> “%~d1%~p1%convert.log”
@echo “%~d1%~p1%~n1.jpg” already exists >> “%~d1%~p1%convert.log”

This does a few things. It checks to see if the file already exists, and if so, it skips it. It also writes the results of each conversion to a text file so you can see what happened. There isn’t really much error checking in this, but if you’re familiar with batch scripts, you could probably add some to figure out if there were errors or look for other problems. I am creating deinterlaced .jpg files of freeze frames from 10 seconds into my clip. If you see where the file name gets inserted, you can modify the command line with options from here to do whatever you want and copy/name the files whatever you need. You put both of the files above in the directory with your movies and then double click the first one “startConvert.bat” to rip through them all.

I wanted to put a simple script up though that people could quickly grab and use, without trying to sort through bits of forum posts and other nonsense.

I am not going to make this a huge run-down of how to use XML in Flash, but instead share a few tips I’ve come across while incorporating it into my applications. If you’re looking for a place to start from the beginning and get the basics of using XML with Flash, then I’d go here to kirupa.com

Use a Configuration File

Since we mostly develop stand-alone exhibits for public spaces, there is some basic configuration information that we want in all of our programs and so each application has its own config XML with some standard parameters, and some that are specific to the application. The file we load at the start of each program has a config node, which will hold much of the items we use for every application. It might look like this …

<config>
<timeout>90</timeout>
<attractScreen>attract.swf</attractScreen>
<showMouse>0</showMouse>
</config>

It loads values that the application will use to determine the time the program waits to go to the attract loop, the location of the attract loop file, and whether or not the mouse should be shown at program startup. Another common thing that is done with our config XML is loading any dynamic text into the program, so it’s easy to change this text and it won’t have to be done by a programmer. There’s a text node and it holds a few different items that we may use.

<text>
<intro>Please Choose a category</intro>
<menuInstructions>Now, select a submenu below to start exploring.</menuInstructions>
<outro>Thanks for visiting, we hope you enjoy the rest of your day!</outro>
</text>

It’s important to pull that stuff out of the code and into easily configurable external files. It’s very common to have a client call and let you know that they think wording should be changed, or that the timeout happens too fast on a particular exhibit, and the ability for that change to be made by them is valuable.

Deleting an XML Node

So, to add a node to an existing XML instance in Flash, the most basic function is appendChild(). If you have two variables holding XML, and want to add one to the other, it could be as simple as …

myXML.appendChild(myXML2.copy());

This will vary depending on what you want to do specifically, but that’s the basic idea. So, if you want to delete a child from XML, you’d think you would just use a function like removeChild() or deleteChild(). Sorry, that’s not how it works. You actually have to use the fairly odd delete command. And, it doesn’t even get values fed like a regular function. If you had your XML that held photo nodes and wanted to delete the second item, it would look like …

delete myXML.photo[1];

It is not intuitive at all, and I am sure there is some reason it’s done that way based on the object model and available functions in the different classes, but it’s still a bit difficult to figure out.

Creating XML in Flash

For some applications, you may want to create a variable that holds XML for whatever reason. Now, if you’re just making a copy of or adding to some existing XML, it’s pretty straightforward. But, if you create the XML from scratch, there’s one important step that if you skip, will cause your XML not to work properly. You have to create a top level <data> node in it to hold your child nodes. If you don’t do that, it may not act as it should. So, if I am doing some sort of searching or sorting, and want to create a brand new XML that holds photo nodes from another XML document that fit certain search criteria, I can’t just say …

var newXML:XML = new XML();
newXML.appendChild(photoXML.photo[2]);
newXML.appendChild(photoXML.photo[5]);
//try to trace out the new XML, but you’ll see nothing
trace(newXML);

What you have to do is create a <data> tag when you make that new XML, so that it will have a node to append the children to. So, instead try …

var newXML:XML = <data></data>
newXML.appendChild(photoXML.photo[2]);
newXML.appendChild(photoXML.photo[5]);
//Now you’ll see the new XML nodes reflected
trace(newXML);

So, make sure you create that top level to allow items to be manipulated with code.