Most of my work is invisible. At least, it isn't seen by very many people. Much of it is business-to-business sales tools for high-end server components. Lately, a good portion of it has been in languages where the target audience is even smaller than the English-speaking market. The majority of the projects on which I work have a maximum audience of a few thousand people worldwide. The concept demos and analysis tools that have been my bread (except for the Atkins diet) and butter over the past few years may only be seen by less than a couple hundred people.

So, it was with some relish that I took on a project this past spring that had a much higher profile, despite a couple of potential drawbacks: a very short, very firm deadline and a rather limited budget. One of the reasons I was able to get the job done in the allotted time and keep it under cost (pretty much the same goal in this case), was Director's flexibility in handling various graphic and media elements, as well as its long-standing external file linkage capabilities.

Specifications
In September of 2003, Chris Williams, an interactive kiosk hardware specialist with whom I had worked on some other projects, put me in touch with the Oregon Zoo. The Zoo was investigating the possibility of creating a kiosk that incorporated a live, remote camera. The kiosk would need to do more than just show video - it would also display information about an animal and its habitat. The design staff was aware of Director - a couple of other kiosks in the Zoo had been created with it - but they weren't very familiar with it. They wanted to verify that the hardware they were considering for the remote cameras could be displayed in Director.

I was reasonably certain Director could take on the task. Several different video formats are supported by built-in and third-party Xtras (the Director components that extend its capabilities). My own personal preference for video within Director is Apple QuickTime. It's the best integrated and most flexible of the supported video formats - in my experience - and it was the first one I tested on the camera vendor's test URLs. I was able to create a Shockwave movie within a couple of minutes that displayed one of their streaming video samples. A simple field and button added to the movie by the time of the initial meeting at the Zoo made it possible to link to almost any QuickTime-compatible video stream. The meeting went well, but then things were quiet for seven months.

Seven months, it so happens, was approximately the amount of time it took to complete the Oregon Zoo's new Eagle Canyon Exhibit. The outdoor installation is part of the larger Great Northwest section of the Zoo, and contains habitat areas for beaver, otters, water birds, salmon, and - of course - eagles, which were nursed back to health from injuries and couldn't survive in the wild.

I had more or less forgotten about the project, figuring the Zoo had gone with another developer, when suddenly, in the first week of May, things got moving again. Eagle Canyon was scheduled to open May 28. Media for the project was still under development and would be in my hands mid-month. While the artwork for the interface was minimal - consisting of only a few buttons and informational screens - and was being provided by the Zoo's own Design Services department, the video from the United States Department of Agriculture's Forest Service Pacific Northwest Region was still in the digitization process.

Additionally, there were now going to be two kiosks. The kiosks would be virtually identical in function, but one would feature eagles and the other would feature salmon. The eagle kiosk would link to a camera installed in a long-time nesting location in the southern Willamette Valley. The salmon kiosk's camera was already in place in the Columbia River, in spawning grounds near Bonneville Dam.

The kiosks would run continuously, with an attract loop showing full-screen video and inviting the user to interact with the screen. When activated, the kiosk menu would link to a screen featuring five video clips (different for each kiosk), an informational screen about the USDA Forest Service NatureWatch Program, and a credits screen. The initial design document actually required two versions of each kiosk, but because the view of the empty eagle nest and spawning grounds during the winter wasn't desirable, we were now up to four individual applications: two kiosks in two modes each (see Image I).

Planning
Right away, I started looking for ways to simplify the project implementation. You might call me lazy, but I like to think of myself as efficient. By the time I had the final go-ahead on the kiosks, we were less than two weeks away from the morning when the exhibit was supposed to open.

First, I decided that a single engine would drive all versions of the kiosks. Rather than create four separate applications, I was determined to use a single engine for both the eagle and salmon kiosks, with an easily modifiable initialization file that controlled the source for the live camera, so that the Zoo's staff could turn the camera on and off easily.

This was made much easier due to the similarities between the two kiosk versions. All of the identical content - including the operational logic - was put into the main Director movie. Using an external cast file for the unique elements meant that switching from the eagle kiosk to the salmon kiosk would require the modification of only a couple of file names. An external text file would hold the initialization information.

Cutting four applications down to a single application made the project a lot more manageable and much easier to debug when we got to the final stages.

Implementation
Most of the technical and physical details of the kiosks were decided before I was brought onto the project. The human interface is a Planar PT170M touchscreen, a 17" screen running at 1280x1024 pixel resolution (the video playback was specified for full screen at that size). The computers inside the kiosks are Pentium 4 Little PCs from Stealth Computer Corp. (measuring about 10"x6"x3"). The live cameras are from VBrick Systems and transmit a QuickTime-compatible RTSP (Real-Time Streaming Protocol) signal. The two cameras are hooked into the Zoo's internal virtual private network so outsiders can't hook into the signal. Final testing of the live camera had to be done on site.

Artwork Preparation
Prior to the installation of the Eagle Canyon Exhibit kiosks, the Zoo had two other computer-driven interactive kiosks (there are, of course, many other types of interactive exhibits at the Zoo). While the Design Services department was very familiar with preparing printed materials and outdoor signage, they weren't accustomed to digital preparation standards.

I received eight Adobe Illustrator files per version/configuration combination for screen art. Due to some effects and type translation problems, I couldn't open the files with FreeHand MX, so I worked on them with Illustrator 10.

Regrettably, all of the screen art was sized to the approximate physical dimensions of the screens (13.3"x10.6") and not to 1280x1024. The proportions are close, but not as exact as you'd like when shifting between screens with corresponding elements. Simply exporting bitmap images from the original files wouldn't work either, because they come out about one-third too small (13.3" @ 72dpi is only 957 pixels). The positioning images I created were from scaled-up versions of the screen comps.

To create the bitmap elements used in the kiosk, I used a combination of direct bitmap manipulation in Fireworks and cropping of the screen comps in Director's Paint window. Because the scaled comps weren't sized to the exact pixel dimensions of the kiosk screen, I just opened the image in Fireworks and sized it there. The video captures used as buttons on the video selection screen were obtained by duplicating the placement screen capture, then cropping the image. The background was shared between both versions of the kiosk, so its bitmap was placed in the default Internal cast of the movie. The video buttons show scenes specific to the kiosk version; they're in the external media cast file.

The only other elements created outside of Director (apart from the video) were the round button elements, which were exported from Illustrator to Photoshop format, then converted to Director-friendly PNG format in Fireworks (Director can import Photoshop PSD files, but there is a difference in how the alpha channels are built for things like drop shadows that makes PNGs preferable).

Graphics of the text for the credits and information screen information were exported in the same way and placed on the stage rather than recreating the elements inside Director from individual text and graphic elements.

The Rotis San Serif font was used throughout. All of the original artwork had been developed on a Macintosh, but the delivery platform was a Windows XP computer. When building the Director movie, I embedded the font on my own Mac so that I could use the embedded version throughout production. Type associated with buttons and messages was created using text cast members (although I used Director MX 2004 for this project, I didn't use the new Flash component cast member types, preferring to rely on that with which I was more experienced).

Initialization
One of the key items to be addressed was a simple way for the Design Services (or Information Technology) department to modify the kiosk's live camera function. They needed to be able to turn it on and off, and to change the URL to which the kiosk connected if there was a modification in the camera setup. I decided to make it as easy as I possibly could.

In a different situation, I probably would have used some sort of formal data structure like XML for the initialization file, but due to the simplicity of the initialization data, I just used a text file delimited by line feeds as the easiest to understand. There are two lines in the file: the first contains information on the camera URL, the second contains file and timing information about the video clips.

The initialization file (called settings.txt) looks like this:

rtsp://128.0.0.1/video1
[#path: "salmon.mov", #clips: [[#start: 360, #end: 4140], [#start: 4560, #end:
6900], [#start: 7420, #end: 10200], [#start: 10740, #end: 12960],
[#start: 13380, #end: 16080]]]

The initialization of the kiosk happens right in the startMovie handler:

  vfile = new (xtra "fileio")
  vfile.openfile (the moviepath & "settings.txt", 1)
  vsettings = vfile.readFile()
  put line 1 of vsettings into field "liveurl"
  put line 2 of vsettings into field "cannedInfo"
  vfile.closeFile ()
  gInfo = value (field "cannedInfo")

Nothing fancy. Create a FileIO Xtra instance, open the file for reading, read the entire file into a variable, then pop the two lines of the text variable into separate field cast members and close the file. The cannedInfo field is converted from pure string data into a property list and stored in the gInfo global variable.

The Dispatcher
The heart of the kiosk is its ability to do things on its own: to change what it displays during the attract phase, to return to the attract screen when people walk away, etc. Even in this very simple kiosk, there were a number of variations I had to keep in mind when determining what, when, and how to get the kiosk to its next stage.

Fortunately, Lingo's timeout command provides a great method for handling these types of automated instructions. Director's timeouts let you create a named timeout object, give it a cycle time, and execute an action when its cycle comes up. I called this section of the movie script the dispatcher.

As an example, during the attract phase of the kiosk, the message shown in the blue band at the bottom of the screen cycles between an invitation to click on the screen and an attribution of the video to the Forest Service. As is the case with so many tasks in Director, this could be done several different ways. I chose to use handlers called go1A and go1B (1A and 1B corresponded to the original design document's screen designations) and a timeout in each along these lines:

timeout ("default").new (12000, #go1B)

This command sets (or resets) a timeout object called default with a 12-second cycle. When the cycle expires, the go1B movie script handler is executed (the timeout command in go1B is identical except that its action is #go1A).

The movie script for the kiosk has seven such handlers, no more than six lines in length (although most call a video subroutine discussed later). There are two non-video screens for which the dispatch handler script consists of nothing more than resetting the default timeout object, deleting a video reconnect timeout, and moving the playback head with a go command.

Video Setup
If it hadn't been for the video, this project wouldn't have been much more than buttons moving between marker labels in the Score, with some timeouts thrown in for good measure. The video added a layer of challenge that affected both the programming and the design.

Initially, the five pre recorded video segments came to me in DVD format. Director MX 2004 can now incorporate DVD video. I could have used it as it was, running the video from the hard drive of the computers (as they didn't have internal DVD drives). DVD video can only be displayed in direct-to-stage (DTS) mode, however, and a couple of the screen designs had graphics overlaying the video, which would preclude overlays. For that reason, I had the video shop provide me with QuickTime versions of the eagle and salmon videos, because QuickTime has the option of running in non-DTS mode with other sprites appearing on top of the video. Although that affects playback quality, my tests with the samples didn't find it to be a problem. This decision also simplified my video management tasks. Instead of switching between DVD and QuickTime, the kiosk application would use only QuickTime.

A single QuickTime cast member is used in the kiosk, sized to 1280x884 pixels (the area of the screen above the blue menu band). All digital video cast members in Director are linked; the kiosk's QuickTime cast member would be alternately linked to the streaming video from the live camera and the file for the canned video on the hard drive.

Video Handling
The canned video segments were the simple part of the video handling. There are two conditions under which the video segments appear. The first is when one of the buttons is pressed on the video selection screen. The other is in the kiosk's attract loop. If the first line of the settings file has only a line return and no URL, the kiosk automatically chooses a random canned video clip to display instead (this is the "winter" mode for the kiosk).

The settings file tells the kiosk application movie which digital video file to use for the canned videos. The video shop that handled the creation of the QuickTime files only gave me a single file for each of the kiosk versions. Rather than take the time to split them up, I used Director's great control of QuickTime media to play back selected portions of the single video where appropriate.

The second line of the settings file contains a property list with path and clips properties. The path is just the file name for the canned video movie. The clips property is a linear list with five items, each of which is another property list, with start and end properties. The five canned video clips are defined by these values, which are in ticks (measurements of 1/60th of a second) from the beginning of the digital video file. The order of the clips determines which button plays each section of the video. In the example of the settings file above, the first button (top left) would play from 6 seconds (360 ticks) to 69 seconds (4140 ticks) into the movie.

The video selection buttons have a simple behavior on them that identifies the button with an integer (from 1 to 5).

global gClip

property pVideoID

on getPropertyDescriptionList
  return [#pVideoID: [#comment: "Video ID", #format: #integer, #default: 1, #range:
  [1, 2, 3, 4, 5]]]
end

on mouseDown me
  sendAllSprites (#setVideoHighlight, me.spriteNum)
  gClip = pVideoID
  go4
end

When the touchscreen detects that one of the buttons has been activated, the button for selected video becomes highlighted in red, the gClip global variable is set to the identifier for the selected button, and the go4 dispatch handler is called.

on go4
  member ("livevideo").filename = gInfo.path
  timeout ("default").forget ()
  timeout ("reconnect").forget ()
  go "4"
end

To play back the canned video segment, the filename property of the QuickTime cast member is set to the appropriate video file. When the video segment is finished playing, the application returns to the video selection screen, so the default timeout isn't needed. The reconnect timeout object is used for the live camera, but is also unnecessary in this section of the application. The go command takes the movie to a position in the score with a marker labeled 4 (again, to correspond with the design document), not frame 4.

The section of the Score that plays back the canned videos contains a QuickTime video sprite with my Canned Video behavior:

global gInfo, gClip

property pSprite

on beginSprite me
  pSprite = sprite (me.spriteNum)
  pSprite.member.video = true
end

on enterFrame me
  if pSprite.movietime < gInfo.clips[gClip].start then pSprite.movietime =
  gInfo.clips[gClip].start
  if pSprite.movietime > gInfo.clips[gClip].end then
    go3B
  end if
end

The beginSprite handler ensures that the video playback of the sprite's cast member is enabled. The enterFrame handler is simplicity itself. The sprite's movieTime property is checked against the start property of the clip selected when the button was pressed (and gClip was set). If the movieTime is too low (which it will be when the sprite is instantiated), the movie is brought up to the starting point. When the movieTime reaches the clip's end value, the go3B dispatch handler will reset things and return the movie to the video selection screen.

Dealing with the attract loop is a bit more difficult because of the live camera. The attract video shows up on three screens and should appear seamless as those screens are navigated. Two of the screens are the different phases of the unactivated kiosk, when nobody has touched the screen. The third screen is a menu screen showing the attract video and three menu options, which is the first thing users see when they touch the screen in attract mode.

Each of the dispatch handlers for those screens uses the setupVideo handler to link to the proper video source:

on setupVideo
  vPath = field "liveURL"
  if vPath = "" then
    vPath = the moviePath & gInfo.path
  end if
  if vPath <> member ("livevideo").filename then
    member ("livevideo").filename = vPath
  end if
end

If the liveURL field is empty (i.e., if the first line of the setting file is blank), then the vPath variable is set to the canned video path. Then, if the filename of the QuickTime cast member isn't already a match for vPath, it's reset. This keeps the video from being reset when it's not needed; it's also the mechanism that changes back to the live video stream when the movie returns from canned video playback.

Of course, this was complicated by the fact that the kiosk needed to operate with canned video when the live camera wasn't available. In the attract mode, the live camera would be on continuously. However, but the canned video clips that would show as an alternative needed to play back in some sort of random order. This could have been accomplished by creating different sections of the score to handle the live video and canned video tracks, but I felt that would be more trouble than the alternative, which was to create a system that automatically detected which mode was playing. This was easily checked by looking at the liveURL field and writing a behavior to accommodate both. The behavior is actually a bit too involved to go into in this article, but, essentially, it expands on the Canned Video behavior previously mentioned. In the portion of the behavior that handles the canned video, instead of jumping to the video selection screen, a new random clip is selected and the movieTime is immediately set.

I put together the essential elements of one version of the kiosk in about three days. Things worked pretty well using a live video test feed from vBrick's Web site and the QuickTime files. The whole thing needed to be tested in situ, however, with the actual video stream from the salmon beds (regrettably, the aerie was empty this year due to a road-killed eagle). The video was only accessible through the Zoo's network, so six days before the opening, I schlepped my laptop, a USB drive, and the latest copies of the application up to the Zoo for testing.

A couple of things were immediately obvious. For whatever reason, the live cameras took significantly longer to synchronize than the test streams did. It was taking ten or more seconds for the image to fully resolve. Also, while I hadn't encountered any problems running the test streams in non-DTS mode, the actual streams weren't working well that way, which meant some minor redesigns were needed. The latter wasn't a significant problem, because we'd discussed the possibility earlier in the process, and the client was aware that we might need to make some sort of change to avoid overlays. The resolution issue was more distressing because of the extreme delay it caused before an acceptable image was displayed. Further testing showed that it happened every time the sprite's image was initialized on the stage, whether or not separate cast members were used for the live and canned video feeds.

I'd love to say I found a great solution for the problem, but what we ended up doing was to slap a screen capture on the screen, turn off the video property for the QuickTime cast member so no picture was visible, and add a film loop that says "Connecting to Live Video" in the center of the screen for 15 seconds. Such are the constraints of time. Of course, all of this had to be turned off when the canned video was used as the attract loop.

Testing and fixing the video issue took almost as long as the initial phase of developing this project. But once everything was up and running the way we wanted it to, I took a copy home and slapped the text and graphics in place for the eagle version in just a couple of hours.

One glitch turned up after installation: when the link to the camera would be lost overnight. I added a reconnect timeout to handle that problem, kicking it off every few hours when the live camera was active.

Conclusion
The end result of this project was that, even though I received the artwork and canned video in the middle of the week before the exhibit opened, I had a working video kiosk application that ran in two versions. It had capabilities for text control of video streaming, video playback, and even clip timing control, all of which were up and running on the Sunday before a Friday opening.

Both of the computers used for the kiosks have the same data on them. The salmon kiosk can be switched to an eagle kiosk by renaming the external cast files and swapping a text file. The most time-consuming part of setting the application up on another computer, should something happen to the one in the kiosk, is duplicating the large video files (the eagle movie is 1.6 GB). The rest of the data for the kiosk is less than 25 MB, so updating the engine is a snap. Once the Design Group is done with their next project, I'll show them how to change the graphics in Director. Meanwhile, on opening day, I was inside the eagle enclosure, holding one of the monitors up out of the water as it was being installed, because I was on hand to make sure things ran smoothly.

Director is responsible for getting this project done on time. Its media handling is rugged enough that I can expect it to do what I tell it to, particularly in a controlled environment like a kiosk. The ability to combine video from hard drive and streaming sources by simply changing a cast member property, the font portability in both playback and authoring, external position-based cast swapping, even bitmap editing within the application, all combined to bring this project to fruition.

The fact that there are many ways to accomplish the same task was also critical: it gave me the options I needed to structure the movie with a combination of simple movie scripts and behaviors. Simplicity is much more reliable than complexity. Some people count their programming accomplishments in the number of lines of code that they've written. Call me lazy, but I count mine in the number of lines of code that I didn't need to write.