I had a customer of my Interactive Label Widget ask me how he could prevent the widget from pausing the presentation. He wanted the interactivity but didn’t want the presentation to pause. I had to explain to him that, by nature, an interactive widget expects the user to interact with it so it pauses the presentation in order to wait for the user’s interaction. That’s all dandy in theory but in practice he had other needs. The answer to this dilemma is easy, I just need to create a Static version of the widget.
However, this made me think a little bit. Creating a static widget will solve the pause problem but will come at the cost of losing the capability of displaying the Hint, Success and Failure captions. What if someone wants that as well?
I believe that there are some improvements that could be done to the widget logic. First, that automatic pausing should be optional. The user should decide if he wants or not to pause the presentation when the widget is displayed. Captivate already allows this type of behavior for the “button” control. In the Timing section of the button, you can select if the presentation will be paused or not. It should be the same for a widget.
Talking about the pause functionality, It caused me some headaches too when coupled with advanced actions. If you want to put a few widgets together and tie their behavior via advanced scripting, you might be in for a nice ride! No matter what action you decide to run when the success criteria is met, the presentation will always resume. The only way for the presentation to stay paused, is by setting the action to “No Action”. This doesn’t make sense to me, in many cases I didn’t want the presentation to resume but I still wanted to run some action! I believe that running an action should not resume the presentation unless we want it to. So, the Action section should also offer an option to resume the presentation when an action is run.
So, if I resume, I would like Captivate to offer two new options: the first one is an optional pause and the other one is an optional resume. That would make interactive widgets a lot more powerful!
What’s your thought on this? Anyone else feels this way and thinks that it should make it’s way as a feature request?
Subscribe to the feed
August 30th, 2010 at 00:13
In you Captivate 5 widget you could listen to the WidgetEvent.PAUSE event and react to it by playing the movie. The problem with that would be if something else paused the movie before the InteractiveWidget did. You could cut a bit of the guess work down by checking the isActOfUser property on the event object. Tie this all in as on option in the widget’s interface and you have a work around. However, it would probably be confusing having two places where the pausing controls are dealt with.
Hmm… It’s tricky.
August 30th, 2010 at 06:18
Thanks Tristan! Good idea but by doing this you are still trying to compensate for what I believe is a missing functionality. Captivate offers this for their own components … why not making it available for widgets.
August 30th, 2010 at 09:49
Yes, I agree. If we could get this for Interactive Widgets as well, that would be great.
August 31st, 2010 at 05:13
Here’s my thoughts – maybe we should have one generic widget framework and within the widget design, you, as the programmer, define the interactivity with captiavte. You have all the hooks available to you, you just decide which ones to implement.
Then you wouldn’t need to decide if you are developing a static,interactive or question widget – you’d just be developing “a widget”.
I really think Adobe are missing a trick by not opening up captivate a bit more to widget developers
August 31st, 2010 at 05:51
@Fran,
I partially agree with you here. I do think that the Static and Interactive widgets could be merged together by the changes I proposed. However, I’m not sure about the Question widget. His nature is very different.
One thing is for sure, I agree 200% with your last statement. Adobe should have seized the opportunity to rewrite from the ground up the player and playbar code when doing Cp5. They kept mostly the same code base which is not friendly to developers. It is basically impossible to extend without huge hacks. An opened architecture means that more developers would be developing widgets.
August 31st, 2010 at 08:20
I see the appeal of combining Static widgets and Interactive widgets. The problem I for see is: how do you automatically impose the Interactive settings on the Properties Dialog Interface without giving the developer lots of tedious skinning work? Even if you do find a way of doing that without conflicting with the Developer’s Properties Interface, how are you going to make sure the two look the same aesthetically?
August 31st, 2010 at 15:03
Just goes to show, its hard to anticipate all the crazy ways people will use widgets!
September 1st, 2010 at 05:43
@Tristan,
That’s a valid point. My initial thought was only to add the two options to the interactive widget so it makes it more powerful. It’s only later that I thought that the two could be combined. At the end, maybe both still have their places in the widget jungle. So I will return to just adding the 2 options. However, we also need to think about the fact that having both as separate widget will probably have the developer duplicate code.
@Graham,
I don’t think we could ever anticipate all the ways a product will be used. However, it’s by having customers communicating their needs that a product will improve … just like you did. Thanks!