A way to show a rollover slidette in html5?

[JKurtBrown]

Hi,

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? My slidettes contain text and a demo video, so the standard button action to show a text caption is not gonna work this time plus I like the option of closing the slidette when done. Any ideas or work arounds?

Thanks,

JKB

[dt4pt]

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.

[RodWard]

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.

[dt4pt]

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.

[RodWard]

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.

[dt4pt]

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.

[Julie88]

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.

[Captiv8r]

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?

Cheers... Rick

[Julie88]

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.

[Captiv8r]

Who knows what the future holds for Adobe? The developers are some of the most creative folks around. We may see something that is even better than a slidelet emerge for the folks clamoring to use HTML 5 and Responsive outputs.

Cheers... Rick

[Julie88]

Well I certainly hope they do this soon.  I am not enjoying using the advanced actions to try and simulate something close to t he slidelet.

[estherau]

I found this link which may be helpful for hovering in html 5 to reveal...

http://lindsay-oneill.com/html5-compatible-rollovers-and-hover-to-reveals-in-adobe-captivate/

[Lilybiri]

This is an old thread, but the article you are point at is not at all an answer. Rollover Slidelets cannot be used at all for HTML5 output because they were Flash-based.

Lot of incomplete/wrong information in that article as well, will not expand on it.

Truth is that rollover captions, images and rollover shapes do work whatever the output if the hardware supports it. That means you need a mouse or trackpad. Mobile devices will never support rollovers.

in a FLuid Boxes porjec tyou can miimck the rollovers (as I explained in a long time before the blog you point at) but it  reamins limited (no slidelet) and will work only on mouste/trackpad devices.

Rollover in Fluid Boxes? - Captivate blog

[estherau]

The thread is old but I had the problem because i was trying to fix a learning module made in a very early version of captivate so it would work in html5. I thought the link i posted had the answer, because i tried it on my desktop computer.  So the rollovers aren't going to work on ipads etc it seems.  pity.

Kind regards,

Riesa

[Lilybiri]

Indeed, not the first blog that gives only a very partial solution. That is why I wrote the blog I mentinoed a year ago, and it has published file included which allows you to test it out. Whatever you do, rollovers (not slidelets, will never work) will only work on dekstop/laptops. No need to mimick rollovers when you create a non-responsive project, just realize that mobile device users will never see the rollover. On the whole I think, if you r goal is all devices, you should get rid or all rollovers.

[estherau]

thanks.  I'll see what i can do.