I finally removed the last known issues with the CpNotepad Widget (Cp5 only). It is  now available for purchase at a price of $24.95 USD. I think that this is a fair price considering that the Widget can be used in almost every courses. Check out the updated demo and make sure you understand the limitations that comes with it. The major limitation is that the Export to HTML functionality can only work when the course is published with Flash Player version 10. If your customer is still stuck with version 9, don’t bother it will not work.

Now, since Christmas is knocking on our doors, I decided to make it a Christmas Launch Special. So instead of the usual price, you get a $10 off so the widget will cost you only $14.95 USD. However, there’s a catch! The rebate will only be applied to the first 5 customers. However, being generous in nature , if you buy the widget before the new year and don’t get the rebate, just e-mail me and we’ll fix that.

Happy Christmas!

It seems that I have a hard time concentrating on finishing CpGears. I always get side tracked to something interesting. A few days ago, James at Mindful by Design was looking at a way to have his users take notes when going through a course. The notes needed to be persisted across sessions and eventually printed. That was enough to get me interested and I ended up being sponsored by James to create a widget that do just that.

The CpNotepad widget offers you a rudimentary text editor to take your notes. They are saved in a Flash Player shared object so that they can be recalled the next time you take the course. For printing, I hit a few brick walls. Printing in Flash is not that great, especially for text that is too big to fit on the screen. I ended up exploiting a Plash Player 10 feature that allows to save a file on the user’s disk. So, I used this approach to export the text and its formatting to an HTML file. The user can then open it up in his favorite browser and print it if he wishes!

I still have to put the final touch and make sure that it’s robust (a few bugs here and there) but you can take a look at it if you wish.

Click here to see the widget in action!

If you see issues with it, please kindly let me know. I will probably put it on sale in a few days. I hope it’s something that will be useful to many

As for finishing CpGears … maybe during the Christmas break?

I have been confronted lately with some important limitations of the Captivate Widget Framework. It seems that Captivate loads the widget’s swf into its own Applicationdomain. An Applicationdomain is basically a container for discrete groups of Class and classes in different ApplicationDomains cannot communicate together. This segregation can sometimes be a good thing but for widget developers, it is a very bad thing!

For one, it prevents us from using Static variables. In one of my widget, I had some plans to have many instances of the widget share a common component. So, I created a Static variable that was supposed to contain the shared component. To my surprise, it looked like the component I modified in one instance of the widget was never available in another instance. It took me a while to realize that the widgets were on their own Applicationdomain.

So, I decided to try to go around this by dynamically attaching the shared component to the CaptivateMainTimeline movieclip. That worked OK until I tried to cast the shared component into its proper type. The debugger welcomed me with an error message saying that the cast was invalid. This is another side effect of having different Applicationdomains. For the Plash Player, when the exact same class definition is loaded into two different Applicationdomains, it is as if it was two different classes; just like if I was to compare an apple with an orange.

Ok, that sucks! I finally was able to do it by casting the shared component into an Object. This way, the compiler ignores the errors. The drawbacks of this is that I lose the capability to use strongly typed variables and I also lose the auto-completion in my IDE. Not a nice tradeoff at all!

So, for those of you would want to share a common component between widget instances, you will have to attach the shared component to the CaptivateMainTimeline and access it through an Object type. The only other solution that I can see is to try to use the EventDispatcher provided by the widget framework to communicate changes.

If Adobe’s developers are reading this, it would be nice to understand why this was done. I would really like the next version of Captivate to load the widgets in the core Applicationdomain so we can start doing powerful stuff.

While looking at my site’s statistics, I realized that the Youtube widget that I made when answering this post was regularly downloaded. However, I never posted it on my site in the Widget section. So, I decided to revamp it a little bit and added some new stuff. For example, you can now properly resize the widget on the stage. I also added many options such as showing related video, looping, autoplay and more.

That was ok until I realized that Youtube doesn’t allow you to embed more than one player in a Flash context. Some people were able to do it but it requires a lot more work and I don’t think I will be putting more time in this widget. Therefore, if you can live with the limitation of having only one youtube video per presentation, then be my guest and download the widget.

Someone on the forum brought back to life an old post to which I contributed when I started to be interested into Captivate. In this post, someone wanted to access the slide’s duration. Since there was no way to get that information directly (… and to my knowledge it’s still the case), I created a small animation that calculated this. The animation was built when Cp4 ruled the earth and now a new user is trying to get it to work in Cp5. It seems that it’s not really working in newest version of Captivate so I decided to take a couple of hours to build a widget for it. So, here is the Slide Duration Widget.

Have fun!

Every tool has its weak spots and I believe that for Captivate, it might just be the question slides … and especially the rendering of the questions themselves. When you compare the quizzes produced by other e-Learning tools, one quickly asserts that Captivate is light-years … behind. Don’t get me wrong, I think that there are good things about the Captivate Quizzing Framework but the end results are not that great. So, I decided that I would try to inject some life into some of the question types. Maybe we can bring Captivate up to par with the rest of the quiz tools out there.

A few days ago, I blogged about starting the creation of the Question Widget base classes in CpGears. In order to properly test these classes, I took the habit of creating a widget of the same type. So, I started to work on a new version of the Multiple Choice Question (MCQ) that is a little bit more dynamic. For example, I added some mouse over effects and tweens to the question distractors. One thing that I haven’t done yet but I will soon do is to show, on the MCQ itself the wrong and right answers during the review phase. I really hate that box showing your answer and comparing with the proper answer. Why can’t Captivate just show me directly on the question?

In order to give you a sneak peek of what the widget capabilities will be, I created this small demo. The widget is far from being complete as I just started working on it this week-end and most of the features are not working. However, you can see the distractors flying into place (reload the demo if you missed it) and see the effects when you mouse over the answers. I also added the Image Zoom Widget to complement the question.

So, let me know what you think. Do you believe it’s doing to be useful and do you like it? What additional features would you expect to see on top of those demonstrated and those described in this post? Me, I would like to be able to just create the question rendering. Because it’s a widget, I will need to create an interface to record the question answers and other parameters. This already exists in Captivate. It would be great if Captivate was in charge of collecting the information and that I would just create some skin that would render the question. Maybe one day …

Funny, it seems that question widgets are this week’s topic of choice. First Tristan wrote a very nice article about how to create one and now I will ask your collaboration on the same topic. I am currently working on providing a Question Widget template in CpGears. I found out that the best way to test these templates are by creating a widget that will use it. That’s what I did with the Image Zoom Widget and the Static Widget template. So, I want to create some type of Question widget. I think there are so many things that I can do, starting with improving the current question types available in Captivate. However, I would like to hear from you on the subject. I know some suggestions have been made through the Wish List but I would like to have more ideas.

So, what type of question widget would you like to see created? Or what type of extension would you like to see added to the existing question types? I’m also curious to hear what types of question you use most when creating a quiz? I was thinking of creating a more jazzed up version of some question types. Would that be helpful? So, please feel free to express yourself!

As mentioned in my previous post, in order to test the static component of CpGears, I created a small widget that I call the “Image Zoom”. It’s a Captivate 5 widget that creates a thumbnail from an image and displays it full size when clicked on. This is very useful when you want to save real estate like in a quiz. I have build a small demo that showcase its capabilities.

Now, I decided to put it on sale since I did spend a little bit of time fine tuning it. The use of the widget is fairly intuitive but I must admit that I did not yet create a page for it with all the explanations on how to install it and how to configure it. So, since I’m ashamed of myself I decided to cut down the price until I write all the documentations. I was thinking of selling the widget for about $10 but I will cut the price to $5 for those who read this blog!

In order to claim the special, when buying, just use the code: MISSINGDOC

Addemdum: The page has now been created here. So sorry but the special has now ended.

Have fun!

I saw today a very interesting comment in my previous post about widget events. I was basically complaining (I know … I need to stop doing this ) about the Slide eventing system to be a little bit flaky. Shameer (Senior Product manager at Adobe) was very helpful (as usual) and got one of the Adobe software developer to take a look at my comments. It ended up that the developer did explain the behavior but I was not really happy with the explanations since I still see the eventing system as flaky. I also mentioned … again … that the API could see some improvements and I asked Shameer if they would be working on the API for Cp6. Turns out that they will and they will also listen to me and other widget developers in the community. That’s great news!

In order to keep my comments in one place, I have created a new page just for that purpose. I will start putting more comments there as I hit problems and frustrations with my CpGears API. You are welcome to contribute through the comments and I will move the data to the main page as I read them. By the way, I have just installed a new plugin that will allow you to follow the comments in the post. Just make sure you check the ”Notify me of followup comments“ checkbox below the comment box.

When Captivate 5 came out, one of the  interesting feature that was added to the widget API was the EventDispatcher and the different movie events. Before this feature, the developer had to hook himself on the ENTER_FRAME event and check, on each frame, the value of different captivate variables in order to determine the current slide, the current frame or the movie status. This seemed to be a very promising feature long awaited by widget developers.

Unfortunately, tapping into it is not as simple as it seems. First hurdle:  the Captivate Helpdoesn’t mention this EventDispatcher at all. However, sometimes if you dig and are patient enough, you can find gems … and the Captivate 5 installation folder has a few nice ones. Hidden in the ActionScript folders are the different classes that can be accessed by the widget at runtime. If you are familiar with the lifecycle of a widget, you know that at runtime, a movie handle is passed to the widget via the cpSetValue() function. For those of you that aren’t, consider reading this.

So, at runtime, the Captivate player passes the movie handle to the widget. From there, you can call the getMovieProps() function to retrieve a reference to the CPMovieProperties instance. This class instance contains a property that is not mentioned in the help and that is named: eventDispatcher. This property will return an instance of an IEventDispatcher which will allow you to monitor the following Captivate events:

• CPSlideEnterEvent (Entering a slide)
• CPSlideExitEvent (Exiting a slide)
• CPMovieStartEvent (Starting the movie)
• CPMovieStopEvent(Stoping the movie)
• CPMoviePauseEvent (Pausing the movie)
• CPMovieResumeEvent (Resuming the movie)

You would think that the problems stop here and that the widget can now live happily ever after. Hum … sorry to disappoint you but the eventing system is a bit flaky. Here are my observations:

• The first time the EnterSlide event is fired on the first slide, the movie is on frame #2. If you rewind the movie, the EnterSlide event is now fired on frame #3. So, why frame #2 initially and frame #3 ever after?
• There is a lost frame between the ExitSlide event and the next EnterSlide event. For example, Side 2 fires up an ExitEvent on say frame 181. The movie keeps playing and the next EnterSlide event is firex on frame … #183. What happened to frame #182? Granted it’s not that important but it’s bizarre none the less.
• When the movie stops on the last slide (say 4) and on the last frame (say 285), if the movie is rewound, an ExitSlide event is thrown originating from Slide 4 (fine) but for frame … #1! That is impossible, you expect it to be Slide 4 – Frame 285. Looks like a bug to me.
• There is a very strange behavior when dragging the thumb of the progress bar in the playbar. If you start the movie and pause it after a few seconds but before the first slide ends, you can scrub the thumb back and forth without any problem. That is as long as you scrub within the first slide. If the thumb crosses over to slide #2, an ExitEvent for slide 1 and an EnterEvent for slide 2 are thrown. That is perfectly normal. What is not is when you scrub back the thumb into slide 1, then you get an EnterSlide event for each frame of slide #1. This is very annoying! If you want to check that up for yourselft, just let the movie play to the end and then click on the thumb and scrub back. If your movie has 200 frames, you’ll get 200 EnterEvents. Again sounds like a bug to me!
• When you click on the thumb of the progress bar you get inconsistent events such as pausing, resuming, exiting a slide, etc. I was not able to get a reproducable pattern. However, one thing I can reproduce is if I scrub the thumb all the way back to the beginning of the movie, I then always get a Resume event  followed by an Enter event.

This inconsistent behavior makes this feature hard to use in real life without resorting to hacks. If you plan to use Captivate Events, just be on the look out for unwanted side effects. Now, I will need to report these problems to the Captivate team … unless one of the Captivate  developer happens to read this blog