Copy link to clipboard
Copied
A button that I'd covered with an image still caused the cursor to change to a hand and still responded to a mouse click. I believe that in HTML it's normal/expected that a mouse click event on one element doesn't bubble/capture to a separate element unless those elements are nested. I doubt Captivate nests a DIV within an IMG so I guess Captivate is doing something with Canvases or tracking the click coordinates instead of the targets to (in my opinion) decrease usability.
I find the behaviour confusing. Does anyone know why it works like that?
Covering an interactive object with a static object never deactivated the interactive object in any version of Captivate that I used. Since I'm not a programmer, I cannot explain why but sometimes this can be really interesting.
I experienced some us cases where this wasn't the case for HTML output, but always for SWF output. Instead of covering up the interactive object, you need to disable the interactive object or hide it.
Copy link to clipboard
Copied
Covering an interactive object with a static object never deactivated the interactive object in any version of Captivate that I used. Since I'm not a programmer, I cannot explain why but sometimes this can be really interesting.
I experienced some us cases where this wasn't the case for HTML output, but always for SWF output. Instead of covering up the interactive object, you need to disable the interactive object or hide it.
Copy link to clipboard
Copied
Thanks for confirming another Captivate usability "flaw" for me 😉
Copy link to clipboard
Copied
I think this should be considered a bug. The web app that I'm designing uses pop-up modals (a pretty common thing). When a pop-up comes on screen everything behind it is darkened (I put a transparent black rectangle between the pop-up and everything else). When someone is previewing the prototype I don't want them to be distracted by clickable links in the background when there is a pop-up present.
Ignore the ugly dark blue rectangles. That was just me trying to redact some information.
Clicking on something that is covered up in the background throws off the entire flow of the prototype. Now I understand that this is just one scenerio and some people may want to have things clickable even when they are covered up (even though I can't think of a reason why). So maybe this should be an option that you can toggle on and off.
Copy link to clipboard
Copied
I have explained in my answer what happens. You may consider it to be a bug, but probably engineers will say it is by design. There is a command 'Disable' which you can use to make the button or other interactive object disabled temporarily. Covering up has never been a good practice, even with SWF output. In Fluid Boxes it is even impossible to stack.
Launch a bug report if you want to do so.
Copy link to clipboard
Copied
Here's a workaround:
As you've seen, interactive objects retain their interactivity when covered by none-interactive objects. However, if you cover them with other interactive objects, those will intercept any mouse events instead.
So if you build your gray transparent lightbox above from a SmartShape covering the wole screen, turn this SmartShape into a button and assign the action 'No Action' to it, your buttons below will remain inert when the user clicks in their spot. You'd have to make the lightbox slightly bigger than the actual stage to account for the infamous 'Button Shrinking' on mouse down, delete roll-over and down state that will have been automatically created, and make sure Hand Cursor is not ticked for the lightbox.
Copy link to clipboard
Copied
Having two interactive objects in the same location at the same time is a very dangerous workflow for HTML output. Anyway, can never be used in a Fluid Boxes project. Did you test this out extensively? Disable the button temporarily is a safe workflow, your proposal not so much. I have been testing this quite a while ago and got in troubles.
Copy link to clipboard
Copied
I never experienced any problems with that, as long as the upper interactive element covers the lower one completely. I'd be curious to learn what kind of problems you came accross.
Obviously it woudn't work in a fluid box, but then the whole scenario of stacking objects as described by the OP wouldn't work there to start with, so I guess it's save to asume that this work case is about a none-responsive project (all the more since the appearence of that system that is simulated here looks rather 'desktopish' to me, whatever it is).
Copy link to clipboard
Copied
You have been lucky, but I have pushed Captivate often to the limits without Javascript. I have sent several projects with that kind of issues to the team, and they confirmed this is a situation you'd better avoid....
I have blogged about workarounds for Fluid Boxes for this type of lightbox.
Copy link to clipboard
Copied
PERFECT! This was the answer I was looking for. Thank you.