Captivate 6 has just been released with a myriad of new and awesome features. I’m happy to say that widgets have been given a fair amount of attention in this new release, and a number of the features we’ve drooled about over the years have been implemented by Adobe!
Hot on the heels of Captivate 6 will of course be WidgetFactory 6. Although it’s not documented yet, I will be releasing it as soon as possible. I’ve just got caught up with a last minute feature which should make life easier for those building Question Widgets. WidgetFactory 6 has a lot of new and exciting features in it as well, but that’s a post for another day. It is now time to start the drooling.
HTML 5 Widgets
Perhaps the biggest feature of Captivate 6 is the new HTML5 export. However, as you already know, widgets are coded in ActionScript, which doesn’t run without the flash player. So how do widgets fit into the HTML5 export?
Now there is a little bad news. Currently only Static Widgets support HTML5. So if you have any Interactive or Question widgets up for sale, unfortunately you’re not going to be able to create a HTML5 export for them just yet. But not to worry, I have it on good authority that support for HTML5 Interactive and Question widgets will be coming speedily in the future.
With the announcement of HTML5 widgets, I can also confirm that I’m working on a HTML5 version of WidgetFactory. Once I’ve updated all Infosemantics widgets to work with Captivate 6 and released WidgetFactory 6, I’m going to start developing a new Static widget for Infosemantics which will have both a SWF and HTML5 export. This should aid the progress of the HTML5 WidgetFactory.
Now if that doesn’t get you excited, then this will.
Okay now this is huge. From the very start, accessing the library this has been somewhat of a holy grail for widgets. Well it’s time to call back your knights of the round table, because Captivate 6 widgets can do just that!
Here’s how it works: When the widget is in Properties Dialog mode, it can invoke a Captivate Library browser dialog, the audience uses the dialog to pick an object from the library (this can be either an image, sound, animation swf, or video), you then load the image/sound/animation/what have you into the widget and do whatever you want with it.
Widgets can load items from the library in Runtime, Stage, and Properties Dialog mode, but they can only browse the library in Properties Dialog mode.
Every item in the Captivate library comes with an id. If there is a particular object you want to access at Stage or Runtime mode, then you add this id to a list of Library Resource that the widget will request from Captivate. Then you save that ID to a widget property and in Stage or Runtime mode, use that ID to load the object into your widget once again.
I really can’t wait to build some widgets that use this. Did you see I mentioned sounds up there? SOUNDS! Finally a practical way for users to customize sounds! And that’s just the tip of the iceberg.
The last major feature for widgets is Localization. Up till now, most widget interfaces have been written in English; as it is the most common language of Captivate users. Now however, Captivate will inform the widget what language the user’s Captivate install is running. So if their Captivate install is French, you can detect that and display your widget interface in their native language. Hopefully this will make widgets much easier to use for everyone earth wide. So I recommend making friends with people who can translate to the following languages.
- English (US)
- English (International)
- English (Canadian)
- Portuguese (Brazilian)
Does anyone know how to speak Canadian English?
That’s pretty much all the exciting stuff, but there are a few minor features that probably won’t concern anyone unless they happen to be building a Widget framework… But let no one say I was not thorough.
- Captivate now directly informs the widget what version of Captivate it is running in. This should make supporting different versions of Captivate easier in the future.
- In Stage mode, Captivate informs the widget of the stage mode dimensions. This is because stage.stageWidth and stage.stageHeight can’t be trusted in this mode.
- As the new Interactions in Captivate are really just widgets in disguise, you can add your own .wdgt file to the Gallery/Interactions folder under the Captivate install folder and they will appear inside Captivate’s Interactions dialog. There is a new tag in the .wdgt file that allows you to specify an image to represent the widget in the Interactions folder. (Fun Fact: All the Captivate Interactions are Static widgets so that they can be exported to HTML5)
Another Important Note
Technically this is not a widget feature, but it’s still important. SO IF YOU’VE ALREADY STOPPED READING THEN START AGAIN.
DOWN HERE! YES YOU. YOU NEED TO READ THIS.
Okay. A big physical change has been made to the Captivate runtime. Previous to Captivate 6, Captivate would load and build every slide in the movie and hold them in memory until the movie was closed down. In Captivate 6 this is no longer the case. Captivate now only builds the slide currently being viewed by the user. Once the movie moves to the next slide, the old one is removed from memory. Slide objects are only created when they enter runtime, and are deleted the moment they exit runtime. This means that widgets are now created the VERY INSTANT they enter runtime. So if you’ve used the enterMovie() template to make the widget to do stuff before it enters runtime, this will not work in Captivate 6. So if you find that your widget is working perfectly in Captivate 4, 5, and 5.5 but not in 6, this is most likely the cause of the problem. Don’t worry, I’ve made sure that the enterMovie() template method still gets called, but only just before enterRuntime() is called.
This is a big change, but it’s not a bad change. In all honesty, this is how the Captivate runtime should have been working from the very start. This method takes up much less RAM and memory, and we know most of the audience are watching the Captivate movie on pretty low end computers, so this is a very good thing.
Don’t freak out too much though. Unless your widget is seriously bending the rules of Captivate, then it’s not likely the runtime change will affect you; but it’s something you need to be aware of nevertheless.
In a future post I’ll explain how you can use widget rooms to bypass this runtime loading and unloading and allow your widget to keep monitoring the movie long after its time has past.
Until then, I’m going back to work on WidgetFactory 6.
Did I mention it’s awesome?