Apreciate the feedback!
As my orginal note stated "I currently have a project with a image slide and "hotspots" that show slidettes when rolled over. How can I have the same interaction for HTML5 output on a tablet/phone"
I do understand that tablets/phones do not have a "hover" input, thats why I was asking the community if they knew of another way to have the same interaction where as maybe a button that would open the slidette? Maybe an action script that would make the button on success show the slidette? if thats even possible.
Not sure why they would not design a button with slidette for html output like the hover over slidette.
That will work if I wanted to show a caption, but the captions will not hold a video, text and images in one single window like a slidette. Unless you know of a way to create a caption that will display all of these elements at the same time like a slidette, the show/hide caption isnt going to work.
So let me see if i get this right, if we use rollover captions or slideletes in our Captivate pieces, and we want to have a similar capability in HTML 5, we have to replace all rollover captions and slidelets with advance interactions or click boxes? I know it would be easy to show items when clicking a specific area on screen, but how do you achieve the "hide" on clicking an object. Will I be able to show several objects, including a graphic with an X, and hide objects when the user clicks the X?
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.
When I insert a "click box" and configure On Success: Execute Advanced Actions to run a script that states "show slidette" the user should be able to click that click box and the roll over slidette should pop up right? I'm asking because it doesn't, you can click on that box all day and nothing happens.
Im pretty much at the end of the rope with captivate, it seems to be an excellent toy for making 4th grade quizes and HR videos on how to find a fire exit but when it comes to building a module with interactivity and delivering value based content with substance captivate is not what your looking for.
No. You are incorrect there. Captivate is VERY capable of creating interactive elearning for any kind of content. Since plenty of other developers are quite capable of using it to do just that, perhaps the issue is not with the tool but the fact that you haven't as yet learned to work with it?
Are you still trying to use a Slidelet in content that you're publishing for HTML5 output? Did you not see the statement above that slidelets are not compatible with HTML5 output?
My guess here is that you may be expecting Captivate to work in a way that makes sense to you, when in fact it was built with a slightly different mindset. In my experience, you have to forget what you might have done, or how you worked, with other tools and just learn Captivate from scratch. A lot of the frustrated developer comments I've seen in these forums over the years have turned out to be 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.
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 $.
I've used InDesign for years and this isnt an issue with it, so your right I need to learn Captivate from scratch and understand its limits. So far of all the examples of Captivate projects I have researched they are limited to question and answer slides, not alot of interactivity and all were pretty simple with very little content maybe a few quiz questions some 4th grade style match the answer to the question, some drag and drop and maybe a video to play and thats about it.
My current project is 150 slides so far with 30-40 slides housing 10-15 slidettes on each, with each of these slidettes containing some text captions, 3-4 png graphics and a demo video.
As far as "Did you not see the statement above that slidelets are not compatible with HTML5 output?"
I have to ask, did you not read my original question:
"How can I have the same interaction as a slidette for HTML5 output on a tablet/phone?"
So lets quickly look at what I have learned so far.
HTML5 does not support hover.
HTML5 does not support slidettes and Adobe did not consider that this feature would be needed in HTML5 projects with Captivate.
Advanced Actions cannot open a slidette from a click box.
Captivate is VERY capable of creating interactive elearning.
Someone replied "Use a click box and setup an advanced action to show a caption"
Got it. But I'm not looking to show just a caption, I'm looking to show a "pop-up" window that can contain text, a graphic and also a video like a slidette. Others have replied for me to use a new slide, but that's not the interaction I am looking to achieve. I don't want to leave the main slide, I just want to have a pop up. I have about 14 hot spots on a graphic on the slide and each hotspot opens up a slidette containing text, graphic and a demo video which can be closed up and another hot spot quickly selected. I do not want 14 slides to ref out to on top of the 150 slides already in the project.
Someone replied "With an advanced action you can show all object that you want at the same time, it is not limited to only a caption at all."
Sweet! Thought this is the workaround I'm looking for, but when I insert a click box with an advanced action to show the slidette on success it does not work. The cursor changes to the hand but no action happens in either HTML5 or SWF.
Only other way I can see to get this to work is to move the content to a new slide like suggested and, if even possible (??), open the content slide within the main slide somehow. I looked through the Adobe help and user manuals for Cap6 but couldn't find anything on doing this.
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.
I think something that needs to be remembered here is that the slidelet object pre-dates (by several years) any thoughts Adobe might possibly have had about HTML5.
Slidelets have been in Captivate since about version 3 (if memory serves) but they were never a very successful implementation of the concept in my view.
I agree wholeheartedly with you that Storyline's layers concept and the way you can set up triggers to display those layers on a slide is a far more flexible and useful way to handle what slidelets attempt to do.
I'm hopeful that Adobe has also noticed that Storyline got the jump on Captivate with their layers feature (as well as a few other features) and are currently feverishly working out how to catch up and pass Articulate with Cp's next major version update.
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.
I realise that this is an old discussion but I've been looking for the same answer in relation to Captivate 7.
I too am surprised that the rollover slidelet hasn't been reworked yet, especially considering that we're up to CP7 now. Does anyone know if Adobe have any plans to incorporate an HTML5-compatible slidelet/container that is activated by click any time soon?
In the meantime the best solution I can find is here: http://blogs.adobe.com/captivate/2011/12/creating-a-screen-with-a-pop-up-with-adobe-captiv ate-5-5 although I'm worried about the development time involved when creating a project with multiple popups used throughout. Unless I'm completely missing something each popup looks like it requires a new advanced action of its own.
I have a lot of content waiting to developed that requires tablet compatibility and I think it might take too long to do in Captivate without this functionality.
Slidelet are not available in Captivate 7 and nor in the update which we are working in the near future . So the best approach would be relook at your content to see how to accomplish the same /similar objective in an alternative way and I am sure you will find an answer . For folks going mobile .. expecting the same desk top experince needs to be relooked at
Captivate Engineering team
Thanks for taking the time to reply to my comment Suresh.
The issue that many people like myself face is that we're content developers and at times we don't have any input at the authoring stage. For years now the authors/instructional designers have been used to being able to show popups/reveals/layers that are activated by clicking something on the main content screen, and the most likely outcome isn't that they re-think their own methods but that they find software that allows them to do what they want. Traditionally for us this software was Flash but unfortunately the rise of the iPad inparticular has forced us to develop with tools that in many ways aren't as flexible.
I personally disagree with what you say about those going mobile needing to re-think. Tablets can't be classed as a fully mobile device due to the way that they're used, for example there are a lot of people that I know who's tablets never leave the house. For many people now a tablet is their only means of viewing online content which is why the majority of the time we're asked by clients for a single elearning solution that works on both dektop and tablet platforms. Rightly or wrongly that's what the people controlling the budgets are dictating, as much re-use as is possible for the minimum possible spend.
Captivate is pushed as an industry-standard elearning solution but its roots are still very much in the screen capture arena, with many features missing that would enhance the user experience. I do appreciate a lot of what Captivate does offer but it's the things that is doesn't offer that gives me a dilemma when recommending a piece of software to a client.
Please allow me to chime in here. As a professional e-learning designer and content developer who is also coming to grips with building content for mobile users I feel I am able to appreciate both sides of this issue.
My take is that both of you are right to some extent.
Suresh is correct that if you are intending to develop content for the mobile touch-screen environment, which will ALSO likely be played by at least some users on desktop as well, then you WILL need to rethink the way this content is developed. There are fundamental differences between mobile and desktop environments that most people don't get as yet. Ignoring their existence is a recipe for disaster.
Captivate's slidelet object is a classic example of this. In the desktop environment a mouse can be used to roll over the slidelet hit area. However, in a touch screen environment where there is no mouse cursor then the slidelet is largely useless, as would be a rollover image object or rollover caption object.
So if you are developing a single course that is intended for BOTH target audiences then objects that require rollovers are destined to be ditched in favor of other objects that display content based on a mouse click or its equivalent, a screen tap. I believe THIS is just one of the RETHINK aspects to which Suresh is referring. Objects selected for the content must make sense in both mobile AND desktop environments. It doesn't matter if the tablet never leaves the house.
The fundamental difference isn't whether the mobile device is ACTUALLY mobile and travels anywhere. The difference is in the way it's operated (without a mouse), the fact that screen size differences are huge, the fact that screens may be low or high density (e.g. Retina displays) and that the screen can be Landscape one minute and then Portrait format a moment later. Desktop users don't have most of these issues.
dt4pt is also correct that the people who put up the budgets to pay for course content development usually have no appreciation whatsoever for the technical issues that may be faced when they blithely say: "We want a single course developed that will work anywhere, including mobile as well as desktop." Some instructional designers and graphic designers also still haven't caught up with the fact that their designs may not be practical for both mobile and desktop environments. Their attitude in some cases is more akin to that famous king who planted his throne at the sea and forbade the tide to come in.
The meat in the sandwich here is the poor content developer tasked with the job of doing the impossible. I agree with dt4pt that sometimes it's simply not possible to give a client what they want. Currently there is no authoring tool out there that does everything, Captivate included. You just have to pick your best option, stand up to your clients and tell them if they're asking the impossible, and move on.
Thanks for pitching in RodWard, I think it's good to get as many perspectives as possible, after all Adobe want to deliver something that we all want to use and the only way that will happen is through this type of discussion.
I think that my issue here is that what seem to be simple adjustments to the software could make major differences to content developers, in this case the click-activated slidelet being the adjustment. Certainly from the outside it doesn't seem like a big challenge for the software engineers to duplicate and rework the rollover activated slidelet to one that is activated on click. For me the added value coupled with the positive feedback that would likely come from within the elearning industry would definitely make the update worthwhile. Even on a desktop device a rollover can be uncomfortable if there is a lot of information contained in the reveal area.
I agree that ignoring the differences between desktop and mobile is a bad idea but I think the rethink needs to come from both sides of the table. Adobe have clearly invested a lot of time in to progressing the HTML5 output in Captivate and with some subtle tweaks I actually don't think it's a million miles away from being able to produce something that CAN be deployed on BOTH desktop and tablet devices.
Again I have to agree and disagree with you.
Adobe IS certainly doing a lot to try and get their HTML5 content to work, but cosmetic changes such as just making the Slidelet operate on a click instead of a rollover isn't going to solve the main problem.
With mobile content the bigger issue by far is what SIZE should the content be, given that screens for mobile can vary enormously. On a small screen the same text that is adequate on a desktop may be unreadable. And buttons that are eminently clickable on a desktop may be extremely fiddly on a small touch screen. How will the content work if the user turns the tablet from Landscape to portrait?
I'm talking about what is known in web design circles as "responsive design". And the fact of the matter is that Captivate's content just isn't set up to respond this way. It's fixed.
I completely agree with you about the main issue being responsiveness and its importance in the quest for a one-course-fits-all solution. I guess that fully fluid layouts in Captivate would probably require a ground-up rebuild and as such are likely to remain on the wish list.
Looking at possible solutions that might be able to extend the current version, pinch and zoom seems to have been disabled in published Captivate courses, perhaps re-enabling it, coupled with setting the viewport to match the device width could be a way to avoid unreadable text. That way if someone wants to hold their device in portrait format they can and they still have access to legible text.
Granted, if someone uses a smartphone to view it then it's not going to be ideal but I think I have to draw the line there when considering what's possible and what isn't with a one-course-fits-all solution.
This was an excellent thread to read. I will just chime in that the advanced actions to replace the slidelet seem cumbersome and there are some issues with having to work around other click boxes and being able to pause properly. All this was taken care of in 2 minutes with a slidelet. So ease of development to replace a slidelet is not there IMHO.
I am frustrated by the amount of time it is taking and the team I am working with - the rate of development has slowed down for everyone because of this.
I would like to see Captivate give us a cleaner way of making this transition as others in the thread have pointed out.
I know that Captivate seems very focus on the mobile aspects, but I have to tell you that most folks are not there. You may be surprised how many places still do not have an LMS even.
LOL, Julie, on one hand you appear to be grumbling that it takes too much effort to re-create functionality that will work in the HTML 5 world. But then you seem to state that Captivate is focused on mobile when most folks "aren't there" yet. Are we to assume you are like most folks in "not being there" yet? And if so, why aren't you using the basic SWF output where slidelets are a breeze?
Well unfortunately, while we aren't using these courses on a mobile platform, these folks don't want to use any functionality now that may make it difficult in the future (just in case they decide to go to HTML5). So it is frustrating to not be able to use the slidelet now because there doesn't seem to be any plans (and please correct if I am wrong on this) to adapt the slidelet container for HTML5.