Captivate came along at a time when I was in a 'tight spot' as a web developer.

Imagine the words 'tight spot' said with all the ironic fret of George Clooney as Ulysses Everett McGill in the film 'O Brother, Where Art Thou?' and you will begin to identify with my situation.

It was April 2003. I had just been hired as a contract Web Based Training (WBT) developer by Children's Hospital Seattle. The task before me was to head up all technical development for the first robust WBT developed within the organization.

We were charged with creating an eLearning system to train all of Children's staff on a new medical orders system that was set to go live in November 2003. This new orders process was the biggest phase in a long term project of modernizing the way the hospital managed patient information.

Gone would be the clichéd days of unreadable prescriptions written in harried doctor's handwriting. Instead, all orders would be entered online into a new system where staff could interact with them collaboratively throughout the organization.

This is a case study of how Captivate has played into this WBT project at Children's and how we use this software in our ongoing eLearning products. If you are like me, how-to demos are valuable, but there's nothing like an in-the-trenches case study to help separate the deliverable wheat from the bandwagon chaff.

Now to move on to a few more details about this particular project.

Why an eLearning System? Why Custom?
As a 24/7 teaching hospital with over 3900 employees, 250 beds, and a constant influx of new staff and medical students, we had a lot of training to do.

Buying packaged eLearning software from the system vendor wasn't a viable option. Pediatric hospitals are very specialized organizations. Our medical orders system would be a very customized beast - quite different to the version our vendor implemented at regular hospitals.

Imagine the differences between a critical medication order for a two-week old baby and a 17-year old teenager and you begin to understand the complexity of a pediatric implementation of this kind of system.

Another driving force was the fact that using the medical orders system correctly was a huge patient safety gain - and simultaneously a risk. When incorrect use of a system can kill people, you tend to be very serious about certifying that everyone using it has demonstrated correct completion of the system tasks that are a part of their job.

With these requirements in mind, we began assessing what we had to build upon and what we'd need to develop ourselves.

Let's Make a WBT System!
Say 'Let's make a system!' with all the flair of a game show host saying 'Let's make a deal' and you will find yourself right alongside me during the first few weeks of the project.

Out of the gate, it was clear that there was no user tracking system in place that we could use to authenticate learners, track their progress, and report their results. In eLearning speak, these beasts are called Learning Management Systems (LMS). We put one LMS on the to-do list.

Another requirement was that learners would only see lessons that apply to the job they performed in the hospital. Doctors would see doctor lessons. Nurses would see nurse lessons, and so on. Now we were in the territory of a content management system (CMS). We added an integrated CMS to our list.

There was no user interface for the learner to navigate all of the lessons they needed to complete. We added the task of designing and programming a nice looking and easy to use web application shell to that list.

If you haven't noticed, our to-do list was getting pretty beefy. We haven't even gotten to developing the actual content yet, and the seven months between April and November 2003 is looking like an absurdly short amount of time.

Content Is Where Captivate Comes In
The last stage of assessment involved determining what process and tools we were going to use to build and deliver the content. We had to make quick, intelligent decisions on which web based eLearning delivery technology and tools to use. Would it be DHTML? Authorware? Flash? Other tools and technologies entirely?

We had 45 lessons that needed to move quickly through the storyboarding, editing, and finalization of the content phase and then on through technical production into deployment.

This is when I first came across Captivate (then known as RoboDemo) and it looked pretty good. It seemed a bit more robust than some comparative tools in the same price range (like ViewletBuilder or Camtasia) and was pretty user friendly. We definitely needed a tool that was easy for our non-technical Subject Matter Experts (SMEs) to use. They had to have something where they could rapidly capture screenshots and prototype lessons.

Our SMEs in particular were nurses who had never done any kind of multimedia, software, or WBT development. Getting an easy to use tool where they could storyboard their lessons out quickly and easily was going to be paramount to the success of the project. Whichever reasonably priced tool could offer more production advantages beyond these basics would be a serious contender.

This is when I got wind of a coming enhancement that nearly made our decision for us.

.FLAs Directly from Nurses' Storyboards, Developers Weep for Joy
In June 2003, a new feature was released that allowed the exporting of Captivate files as fully editable Flash authoring FLAs.

There haven't been many times in my professional career that I can remember my exact reaction upon hearing 'such and such' news, but I burst into tears of joy when I read that announcement.

Yes, real developers do cry.

Here I was in my 'tight spot' trying to balance all the competing tasks of the project. I was looking for as much leverage as possible because we would not make our deadline without it. So much was not yet designed and was still unknown that we absolutely needed the most robust, scalable, and flexible technology to build our system.

Flash was robust enough to handle all the requirements of the client side of the application, but, as anyone who's built a robust Flash app will tell you, it takes a lot of work. You are not a junior college 'design hipster' cranking out 'bleeding edge' splash screens. You are building software - a Rich Internet Application (as many folks refer to them), and it is hard work.

We tested the export to FLA feature the day it was released and it did exactly what we needed - exporting all of the assets of the Captivate movies in an organized FLA.

This gave us the robust path we needed to rapidly prototype and build the content for our WBT - one that could quickly adapt to emerging system needs. I will touch on some real-world, saved-my-BLEEP, examples of this in a bit.

One important thing to note that we discovered in how this feature works is that exporting an .FLA requires that the Flash authoring environment be installed on the same machine as Captivate.

In that, it is not so much an export .FLA feature as it was an import Captivate to Flash MX (and later Flash MX 2004) feature. This is an important distinction that has been confusing to many since its debut. Misunderstanding what that means is a $500 difference if you need the supplemental software the function requires.

Our Production Process
So we adopted Captivate as our content capturing and design tool of choice, with Flash as our delivery technology for the client shell and the lessons. The production process we setup for the initial 2003 project looks very much the same today as it did then.

It would be really romantic to tell you that we use all of Captivate's great features (like AICC/SCORM compliant output or easily crafted audio narration), but we don't. In a nutshell we take the raw Captivate .FLAs and hand copy the backgrounds and captions from them and into the custom .FLA lesson template. This file houses all of the code required to track and manage everything in conjunction with our homegrown LMS.

Not very sexy, I know, but it makes good business sense. We are now at the point where we've been able to automate nearly all of our technical FLA production via the creation of custom captions in Captivate and the use of Flash MX 2004 JSFL scripted commands.

In all, it takes us less than 1.25 hours of technical production to create and deploy a 20 interaction lesson - and it's getting shorter all the time. This is for a template that includes the interaction and a demonstration of the task if the learner makes two incorrect attempts.

Happy We Chose Captivate
In all likelihood, we would not have met our initial 2003 deliverables without Captivate. We needed something that was inexpensive, easy to use for non-technical folks, and robust enough to leverage into the land of enterprise web application development. Captivate hit this sweet spot for us and continues to do so today. We've been through three versions of the software (RoboDemo 4.0 and 5.0, Captivate 1.0) and the current implementation is so much more robust than when we began using it.

Captivate 1.0's productivity enhancements continue to reduce turnaround times for our content. Notable timesavers for us have been: 1) Snap capture window to an open application, 2) recording defaults for caption styles that automatically set all captions to our design style guide during the capture process, and 3) visual timeline editing for each slide.

Captivate also continues to lead functionality wise for its price point. Cost of the next level tools is around $10,000. Knowledge Planet's Firefly (www.knowledgeplanet.com) or Epiance's Epiplex (www.epiance.com) deliver more functionality, but they do so at a steep price difference.

Captivate's Leverage Toward Flash FLAs Has Paid Off
Captivate's foot in the door toward Flash FLA development has also delivered big payoffs. Here are three of the real-world implications of Flash FLA development that have saved us from disaster:

Wider adoption means more developers...
Given the growing weight of the developer community behind Flash, it is easier to find developers for it than for many of the other less popular eLearning tools in circulation. In July 2003, when we needed an extra Flash developer to come in who was very code-centric, we had one within a few days.

Wider adoption also means more supplemental software...
In August 2004, when Microsoft quietly killed Internet Explorer's full screen chromeless window display mode with their Windows XP Service Pack 2 and effectively broke our WBT, we had third party vendors like Multidmedia (http://www.multidmedia.com) we could turn to for help.

They provided alternate fullscreen standalone projectors that would support seamless right click interactions in Flash - something that we had been mitigating with Internet Explorer dependent DHTML hacks since launching our initial WBT in 2003.

A mature IDE means more leverage...
The automation of the Flash MX 2004 IDE with JSFL is a dream come true for those of us faced with repetitive coding tasks that require just enough customization that they cannot be fully automated very easily. It's very satisfying to go to my command menu in Flash, click my "Text Entry" demo command, and watch it do 97% of the work for me.

The Last Word
Bottom-line - Flash as a technology and delivery platform is robust enough to quickly develop for and adapt to changing enterprise needs. When folks from elsewhere in the enterprise tell you they are about to make changes that will break your application, it's nice to have a robust enough technology that you can adapt in a reasonably short amount of time.

Having a tool like Captivate that strongly leverages content toward Flash FLA development for our WBTs enabled us to deliver the requested functionality. My clients are always much happier when my tools and technologies allow me to say "yes" when they ask "Can we do that?"