ONe more thing, like the original poster said in this discussion board, the great thing about slidelets is that you can have pictures, audio and different objects at the same time. I don't see how using clickboxes and advance interactions will allow me to display a picture and or video WITH  audio , or even synchronize the appearance of pictures with the audio. We would need a timeline to do that. The only solution i see is redesigning the content so that it is in a slide insteas of a rollover caption.

JKurtBrown, I share your frustration--not with this particular issue, but with other ones. I don't agree with you on Captivate's capabilities. Captivate is a very powerful program. However, RodWard hit the nail in the head when he said "A lot of frustrated developer comments...due to trying to use Captivate to do something the wrong way, or trying to get it to do something it's not meant to do." The problem with Captivate (and other tools for that matter) is that because there are no standardized training tools to show you how to use the tool "the right way", we are forced to try to figure the tool out. Some solutions that may seem obvious to us, might not be obvious to others, and so on. So, we design the content using the tool the way that it seems obvious to us, only to later realize that we should have done it a different way.

What i am learning is that, to use the tool effectively, we must either spend a lot of time building complex things in it, find an experienced developer or solid training program to learn how to use it. Unfortunately, the latter are very few and cost $.

Rod,

I was just reviewing this thread and your response after having recently developed the same frustration with Captivate's slidelet concept.  I think there is a broader point that's being missed here. The slidelet, in the abstract, is a means of providing a powerful slide-within-a-slide popup of sorts in response to an interaction or trigger, much like Storyline does with the layer concept, but not as flexible nor well thought out, unfortunately. Part of that power is in the fact that it acts as a container so that several objects can be conveniently laid out on this one animatable entity... So far so good. The real issue/problem is that Captivate restricts this nice container, the slidelet, to be used ONLY with rollovers.  Given that rollovers are the one, most obvious interactive object that  CAN'T be used with HTML5/mobile projects, the possibility of having a convenient popup container of this type is eliminated.  Why would Captivate developers do that, as opposed to making the slidelet generic so it could also work for click-oriented objects and so that the HTML5 output could be as "similar" as possible (in other words, the concept of a slidelet and the concept of a rollover are independent and separate concepts, so why marry them in such an exclusive and limiting way). 

So, this isn't just an issue about adjusting expectations/mindset to fall in line with what a tool's  philosophy is, it's really more to do with the bewildering choice Captivate developers made to restrict the much-needed and powerful slidelet concept (one that is arguably among the most essential in many types of interactive design) to only one type of interactive object -- the very object that falls by the wayside for mobile/html5.  This seems more like an oversight than a tool philosophy.

That said, there is the alternative of grouping objects and having a click-based object show/hide the group. This is a fairly crude workaround though, as groups can't be animated or have effects applied as a whole, like slidelets can.

- Doug

Rod,

Yep, I agree that, in the early days, having slidelets linked exclusively to rollovers would not have  been seen as the big limitation it presents today for those pursuing mobile/html5 compatability.  I was really commenting on why this limitation has been allowed to persist in more recent versions (5, 5.5, and especially 6), during a period of html5 and touchscreen emergence that made it clear there is a major downside in relying too much on hover and rollover behaviours for interactive functionality. This should have been recognized and dealt with by now imo, especially given the obvious shift in emphasis toward HTML5 publishing that Adobe undertook with version 6.  The remedy could simply be allowing slidelets to be triggered by on-success of other click-based interactive objects -- doesn't seem like it would be a huge challenge as the basic functionality is already there, but that's easy for me to say --- Another widget opportunity Rod?

Anyway, I'm sure this issue has been registered and is being thought about. Just offering some encouragement.

As you say, and regardless of how people may feel about newer products like Storyline overall (granted, SL has a lot of catching up to do on the animation and advanced logic side of things), SL certainly provides a best-in-class approach and benchmark for flexible slidelet-like layering (which is weird, since Adobe products are usually king when it comes to layer-oriented thinking), as well as the ability (in SL) for any object to trigger states/actions on any other object/layer based on virtually any type of interaction.  I guess it's just another example of the laws of authoring tools: 1) At any given time, each tool is required to have a few gaping holes to maintain the interest in competing tools, and 2) the new kid on the block gets at least a short term advantage from a fresh design architecture that is  not "legacy-strapped".   In the long haul, having stiffer competition in this space should prove to be a good thing for all involved.

Doug